| I used MV rbs01.dbf instead of CP, everything is hosed! [message #50842] |
Wed, 10 April 2002 17:45  |
John Pinochet
Messages: 5
Registered: April 2002
|
Junior Member |
|
|
Greetings!
I'm an Oracle newbie, so bear with me.
I have two Oracle instances running, SID1, and SID2.
An insert statement failed due to no remaining diskspace for SID1.
rbs01.dbf could not be increased in size.
I looked at the settings in DBA Studio for SID1 rbs01.dbf, and saw that they were correct and allowed for growth.
I did a df -k, and quickly found that the problem was that the partition where rbs01.dbf (SID1) was located was 100% full.
I shutdown the (SID1) and (SID2) databases and used the following command to move rbs01.dbf to another empty partition.
mv rbs01.dbf /another empty partition
df -k showed that the move occured as the current partition had space and the new partion was now occupied by rbs01.dbf.
I then realized I had made a mistake as I now needed to perform the RENAME command, so I copied the file from its new partion back to the old partion, using CP.
I then logged into the (SID1) database via svrmgrl, and tried to perform alter database rename file and received an error, ORA-01516: nonexistent log file....even though the file is there in both the new and old partition.
Also, the paths in the command were correct.
Thinking the password file was corrupt, I saved it to another directory, deleted it, and then performed the ORAPWD command, and yes, the correct path was used specifying SID1 database.
Wanting to now see what DBA Studio would show me, I logged in, and found that SID1 did display...BUT...it wasn't SID1, it was SID2!
I did a ps -ef, and it showed that the processes running were labeled SID1, (and no SID2 processes were running).
In DBA Studio for the SID1 database, the display of tables, usernames, etc is in fact the SID2 database.
I checked the initialization file for SID1 to make sure it was pointing in the right direction, and it was. The path in the initSID1.ora file points to the correct location for all files related to SID1.
Does this make any sense at all? I even went back to DBA Studio, and checked the paths for all files under the "Storage" folder and ... you got it...they are all for the SID2 database.
In conclusion:
The SID2 database was shutdown prior to doing all of this. I did not start it back up. It shows no processes via ps -ef.
When I start SID1 (remember SID2 is shutdown), it shows SID1 processes via ps -ef, but in DBA Studio, when I display the folders for SID1, they are in fact SID2 folders with SID2 paths.
Trying to simply go back to the way things were I copied the old password file back (the old rbs01.dbf was already copied back earlier in my post), shutdown SID1, and started it back up again. Problem remains.
Thanks in advance for your help.
|
|
|
|
|
|
| I was able to correct the error. Here's how. [message #50848 is a reply to message #50842] |
Thu, 11 April 2002 00:01  |
John Pinochet
Messages: 5
Registered: April 2002
|
Junior Member |
|
|
OK, well, if you read the above initial post, and you have some comments please reply. I still am not sure what happened but here is what I did to fix the problem.
I deleted the orapwSID1 file. I copied back the original which I had saved to another directory (per my post).
The original rbs01.dbf file had already been copied back of course.
I asked my Unix admin to reboot the machine.
I carefully watched the startup sequence on the unix monitor and noted that both Oracle instances started with no error messages.
I logged in to the Unix box. Did a ps -ef. Found both SID1 and SID2 processes running.
I logged in to SID1, and everything was back to normal. So, my immediate concern is over.
I'm still curious to know what happened. Any ideas?
|
|
|
|
| Re: I was able to correct the error. Here's how. [message #50865 is a reply to message #50848] |
Thu, 11 April 2002 10:29 |
Grant
Messages: 578
Registered: January 2002
|
Senior Member |
|
|
|
Very strange. Were these DB's cloned? I would do an "alter database backup controlfile to trace;" and verify that all the files are in their rightful directories. The trace file will be put in user_dump_dest as defined in your initSID.ora (or do s"show parameter user"). Do a "select * from global_name" also.
|
|
|
|
| Re: The essence of my above post is: Will simply moving and then putting back a rbs01.dbf file mess [message #50866 is a reply to message #50845] |
Thu, 11 April 2002 10:31 |
saleem
Messages: 65
Registered: January 2002
|
Member |
|
|
If you moved the file and then replaced all while the database was completely shut down then you should not really have a problem. if, for any reason, the db was up and running, then even if there are no transactions that may have been processing at that moment, you may have corrupted your db.
there is a step by step instruction in the oracle docs for moving database files. refer that should help you get the move done.
another option you should consider is simply adding anther file to your tablespace. that way you don't have to worry about moving files around and you most likely will have some kind of performance gain.
regards
|
|
|
|
| Not cloned. [message #50872 is a reply to message #50848] |
Thu, 11 April 2002 15:15 |
John Pinochet
Messages: 5
Registered: April 2002
|
Junior Member |
|
|
Hey Grant,
Thanks for the reply. No, not cloned. I'll do as you suggest.
I'm just glad that I got everything back in order.
|
|
|
|
|
|
] 
Blog
Search
Help
Members
Register
Login
Home
