William of Occam says the problem is with EMC.
Don't they have a mechanism that moves hypervolumes
to rebalance the box ? Is it possible that this kicked in
on the fly when you copy started getting busy, and made
a mistake when moving a production file ?
--
Jonathan Lewis
Yet another Oracle-related web site: http://www.jlcomp.demon.co.uk
Practical Oracle 8i: Building Efficient Databases
Publishers: Addison-Wesley
See a first review at:
http://www.ixora.com.au/resources/index.htm#practical_8i
More reviews at: http://www.jlcomp.demon.co.uk/book_rev.html
kineticguy wrote in message ...
>First the particulars:
>
> Sun Solaris 2.7 (RISC)
> Oracle 7.3.4.4
> Veritas Volume Manager 3.0.2c
>
>For the last three years, we have routinely made backup/test databases by:
>
> 1. Full export a production database
> 2. Create the database on another set of drives by building the exact
>same object names (datafiles, rollback segments) but different datafiles
> 3. Import the exported database.
>
>This has always worked smoothly. This was done with a Sun A3500 array.
>(All disk is raw under Volume Manager control).
>
>Two weeks ago we hooked up an EMC Clariion 4500. We started to create a
>copy of a database during the day when there were 150 users on the
>production databases. During the creation of the tablespaces for the COPY
>of the database, a few random datafiles corrupted on the production
>database. Not all of them, just a few. To make matters more confusing,
the
>first four datafiles were fine, the last four corrupted. Off to tape we
>went with a down production database.
>
>This problem only seems to occur when high IO is going on in the system
>(Enterprise 5000). The A3500 is connected via SCSI, the Clariion 4500 via
>Fibre Channel.
>
>The vendors are stumped! Anyone have any ideas?
>
>Thanks!
>
>
Received on Fri Jan 19 2001 - 02:38:04 CST
