This content has been marked as final. Show 14 replies
Bolaji80 wrote:what is ORACLE_SID value?
I am working on a new server (VM) that was cloned from a physical hardware server. Environment is Linux 4.9 and oracle is 10.2. Here is the error I am getting:
When I set the ORACLE_SID and try to startup, I get this error.
Ora 03113 end of file communication
Instance will start, database will mount but will not open.
I used rman to connect (just to check the state) but it gives this error:
Ora 01033 oracle initialization in process
I can connect to sqlplus but I can't do anything from sqlplus. Any idea what to do?
post last 100 or so lines from alert_SID.log file
I actually did this:
connect sys/**** as sysdba
ORACLE INSTANCE STARTED
alter databse mount;
alter database archivelog;
ora 00265 instance recovery required
Any idea what I need to do?
00265, 00000, "instance recovery required, cannot set ARCHIVELOG mode" // *Cause: The database either crashed or was shutdown with the ABORT // option. Media recovery cannot be enabled because the online // logs may not be sufficient to recover the current datafiles. // *Action: Open the database and then enter the SHUTDOWN command with the // NORMAL or IMMEDIATE option.
BJ, Reviewing the Oracle error message text is always a good first step on receiving any error message from Oracle. Sb's posting of the error message makes the solution pretty obvious. In order to change the database setting you need a clean shutdown. Instructions for chaning the database archive log mode are contained in the DBA Administration 11gR2 manual chapter 13 Managing Archived Redo Logs under the section Controlling Archiving.
Reviewing the Oracle error message text is always a good first step on receiving any error message from Oracle.
HTH -- Mark D Powell --
Thanks, but what can I do at this point?
Bolaji80 wrote:Hi folks,I wonder about the correctness & validity of the resultant 'clone'.
I am working on a new server (VM) that was cloned from a physical hardware server.
Explain, describe, show in detail what was done prior to trying to start new DB.
On a normal database you could do just what SB suggested: open the database and let Oracle run crash recovery, then shutdown immedate (clean shutdown), followed by the documented steps to turn on archiving.
Because this is a clone you should have completed the cloning: restore, recovery process first. If so, then the database was accessible in which case the process above followed by the documented steps should work just fine.
If you had not completed the restore and recovery to a consistent database first then you should repeat the clone process then make the parameter change.
HTH -- Mark D Powell --
This is the story. A replica of production server was done by the Linux admin while the server was running. He said he made VM copies. The only reason the server was not shutdown was because there is no backup as database is in no archivelog mode. The cloned server is VM and has same credential with production. Now that the clone has been done, my mandate is to ensure that the database is open and running. My fear is the consistency of datafiles since it was copied while the database was running (without rman).
If Oracle was shutdown when the VM copy was made then Oracle is likely OK. On the other hand if Oracle was running when the copy was made then the liklihood is the Oracle database is corrupt. After going back and reviewing your posts I see you attempted to change the archive log mode after the database failed to start. Why?
You need the database to perform recovery. If you just do a normal start the database should automatically attempt crash recovery. If it fails to do so then look at the alert log. If it says recovery is necessary then the VM imiage is likely no good to begin with. You will need to get a new image with the database cleanly shutdown first.
You can try the following before resorting to gettting a new image: startup mount followed by alter database recover. If the online redo logs contain all necessary changes it might work. But it is possible corruption will exist within the database that Oracle is unaware of. Generate a select * from every table to verify that no bad blocks exist within the database.
I expect that recovery will probably fail. Modern Oracle writes on its own behalf so recoverying using files copied while the database is running is unlikely to work. I managed the trick once back when the VMS admin he could backup the system while Oracle ran. I was lucky and the restore worked because absolutely no one accessed the system while the off hours backup was performed. Now days like I said Oracle dumps all kind of information all the time: AWR, SCN numbers, etc ....
If the source system is no longer available then before telling whomever that the database is a complete loss in the absence of backups being available then I would suggest looking for export files (.dmp). If available a full import could be used to restore the last export of the database.
Ensuring a usuable backup exists is DBA job 1.
HTH -- Mark D Powell --
Edited by: Mark D Powell on Nov 29, 2012 11:32 AM
Thanks for your response. I did 'alter database recover' and the database opened after that. However, after rebooting, I am back to another different error.
ORACLE instance started
ora 00607 internal error occurred while making a change to a data block
ora 00600 internal error code, arguments: ...
As I said the odds are that your database is corrupted. Did you run the select * from every_table_on_your_system I suggested? Because you got an ORA-00607 the corruption is probably in an rdbms base table. Before rebooting was Oracle shut down cleanly? Or was the box shut down under Oracle forcing Oracle to perform crash recovery on start up?
Per Oracle support document: OERR: ORA-607 Internal error occurred while making a change to a data block [ID 172469.1] if you get an ORA-00607 you need to talk to support. Considering the recent history of this database I can predict with what I believe is a high degree of accuracy what the support analyst will tell you namely that your database is a total loss and needs to be restored from a backup or a new VM image made while the database is closed (clean shutdown required).
Did you look to see if an export (.dmp) file exists?
Note - when you post startup problems you really need to post copies and paste of the actual full alert log messages. There are usually several related messages and it is important to be able to see the root (first) problem reported.
-- Mark D Powell --
I am glad your database is up and running. If you did not do so I strongly encourage you to scan your data. Making a full export is an easy way to do this. If there are any corruption problems detected you can then based on the type of problem. Corrupt indexes can be dropped and re-created, a corrupted table row can be deleted, etc ....
HTH -- Mark D Powell --