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: moving database on raw devices

Re: moving database on raw devices

From: Mark D Powell <markp7832_at_my-deja.com>
Date: Sun, 10 Dec 2000 02:45:08 GMT
Message-ID: <90uqnk$gfk$1@nnrp1.deja.com>

In article <RyrY5.2767$d62.174974_at_bgtnsc04-news.ops.worldnet.att.net>,   "Bonnie Steinman" <BJSteinman_at_worldnet.att.net> wrote:
> I am attempting to move a database created on raw devices. The
> server is Oracle 8.1.6. All the datafiles are operating system links
> to the raw devices. Of the logfiles, each first member is also an
> operating system link to a raw device. Each second member is
> a regular file. All the control files are regular files.
>
> We thought that since the datafiles are all links, we could shutdown
> the database and do a block-by-block copy of each raw device,
> re-link to those new raw devices, startup the database and be back
> in business. However, after going through this process, we got the
> following message on startup and couldn't open the database:
>
> ORA-01157 cannot identify/lock data file 1 - see DBWR trace
> ORA-01110 data file 1: STRING CONTAINING DATAFILE PATH
>
> I looked up the error messages and it says
> ORA-01157
> Cause: The background process was either unable to find one of the
> data files or failed to lock it because the file was already in use.
> The database will prohibit access to this file but other files will
> be unaffected. However, the first instance to open the database will
> need to access all online data files. The accompanying error from the
> operating system describes why the file could not be identified.
>
> Action: At the operating system level, make the file available to the
> database. Then either open the database or do an
> ALTER SYSTEM CHECK DATAFILES.
>
> ORA-01110 is only the message to identify exactly which datafile is
> not being accessed.
>
> I attempted the ALTER SYSTEM CHECK DATAFILES command.
> It indicated that it completed, but did not solve my problem. We were
> out of time for the job for which we obtained permission to have
> downtime, so we put everything back the way it was and decided
> to get some more information before trying it again.
>
> The datafile on which I got the error was the system datafile. When
> I did a query on V$DATAFILE, everything showed as ONLINE
> except this file, which showed as SYSTEM. I'm not absolutely sure
> that the other files are really okay or whether the SYSTEM datafile
> couldn't be recognized by the database and it just didn't really know
> whether the other files could be recognized.
>
> A couple of issues I'm wondering about:
>
> Would it make any difference if the links were created by root or
> by the oracle account?
>
> Would it make more sense to make the new raw devices connect
> to a new link and to do an ALTER DATABASE RENAME DATAFILE
> instead?
>
> Can you think of any other reason why this would have failed?
>
> We're under some pretty serious time pressure. I'd appreciate
> any information any of you can offer.
>
> Thanks,
>
> Bonnie
>

If you build a database using link names for the datasets then with the datafile offline you should be able to move the physical file and update the link to point to this new physical file and bring the file back online successfully for every database data file except those that make up the system tablespace. The procedure for moving system tablespace datafiles used to be documented in the DBA Admin manual.

Now since you had the database shutdown I believe you should have been able to move the system file. Since you got an error then either you have to follow the directions in the manual for moving system or perhaps someone did have the file.

If the script that moved it did not contain an exit and had been nohup'd or someone had accessed the file using a utility like head, tail, more etc... just to try to check it out. Also in UNIX just because you remove a file and it no longer shows with an ls command does not mean it is gone. UNIX does not remove the file until every process that was using it closes it. Perhaps something along these lines got in your way.

You can test if you procedure works by building a small database on raw partitions and trying your procedure. If it opens then something had your file. If it errors then there must be something special about system and I would check the manual for the procedure to move system datafiles and follow that.

Good luck.

--
Mark D. Powell  -- The only advice that counts is the advice that
 you follow so follow your own advice --


Sent via Deja.com http://www.deja.com/
Before you buy.
Received on Sat Dec 09 2000 - 20:45:08 CST

Original text of this message

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