Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: "Mirroring" of DBF files

Re: "Mirroring" of DBF files

From: Ed Stevens <nospam_at_noway.nohow>
Date: Fri, 07 Nov 2003 10:54:08 -0600
Message-ID: <gjinqvcdqc9sp2o1kvrilfls8paj1ql22t@4ax.com>


On 7 Nov 2003 06:05:47 -0800, dejanews_at_keithkris.com (Keith Kris) wrote:

>Hi all,
>
>I'm a UNIX admin, and only have minor oracle experience, so chances
>are this is a stupid question (there are no stupid questions, only
>stupid people.) We have a production database which is growing a
>little large. We're in the process of adding more disk to allow
>growth. We'd like to migrate the existing system away from the 12GB
>volumes it currently uses, and toward 72GB volumes. We'd like to have
>only one size of volume used on the system, so we'd need to move our
>data from the old ones to the new larger filesystems. Talking to our
>DBA, he says the only method to accomplish this is to shut down the
>database, move the files, modify init.ora and bring the instance back
>up. The problem with this is it would create too much down time
>(we're moving more than a quarter terabyte.) Is there any method
>within oracle to have the database either use two identical copies of
>a DBF file simultaneously (essentially mirror them) or to have oracle
>itself relocate a DBF file to prevent downtime? I'm open to ideas
>here, so creative thinking is welcome.
>
>Thanks
>Keith

Key question: What version of Oracle?

Can you keep the old volumes and simply add the new ones to the system?

Assumng the answers are "8.1.7" (or greater) and "yes", the first thing that comes to my mind is:

1 - create new tablespaces for data on your new, larger file system. 2 - move tables from old to new tablespaces via ALTER TABLE . . . MOVE commands.
3 - rebuild indexes in new tablespaces.

4. create new rollback tablespaces and segments on the new file system
5. bring the new rollbacks on-line
6. take the old rollbacks off-line and drop them.

There could be some complications regarding LOBS and such, but I've never dealt with them. Also, possible complications if apps are altering sessions to use specifically named rollback segments.

All of the above can/is done with the db up and running, though it will probably incur some performance hit. The advantage is that the work can be spread out over several days --- there is nothing here that would have to be "all or nothing."

Others with sharper minds may find some fatal flaws, in which case I'll learn, too. If you can't have both the old and new file systems in place at the same time ... . I'll defer to those with sharper minds. Received on Fri Nov 07 2003 - 10:54:08 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US