cancel
Showing results for 
Search instead for 
Did you mean: 

Archival Error

SOLVED
Go to solution
allan_47
Occasional Contributor

Archival Error

hi!I have a test db running on unix platform. I'm processing a long process that would update and insert in the db. My question is that, If my archiver stops while I'm running a script that would update and insert records on the database, Is it possible that my database will shutdown?And is it possible that when my archiver stops does my db will have an error stating "Shutdown initialization in progress".
4 REPLIES
Yogeeraj_1
Honored Contributor
Solution

Re: Archival Error

hi,

When your archiver stops, your database should not stop. However, if your archive log destination (log_archive_dest)is full, you may have archiver error and you might not be able to connect to the database.

why do you want to stop the archiver??

if you wan to stop the archiver, you can issue the following command:
archive log stop;

however note that if the ARCH process is currently archiving a log, it must complete archival of that log prior to terminating...

see also, metalink note: 45042.1 - Archiver Best Practices

regards
yogeeraj
No person was ever honoured for what he received. Honour has been the reward for what he gave (clavin coolidge)
Mic V.
Esteemed Contributor

Re: Archival Error

Allan,

YOu may want to post which version of Oracle you're using (assuming it's Oracle).

I'm not a DBA, so get out the salt, but the only times I've seen this message are when a SHUTDOWN command has already been issued but is not completing for some reason (such as a process still accessing the database, presumably for a write, etc).

I'm not clear whether you're asking a hypothetical question or whether you have an existing mystery... :-)

Mic
What kind of a name is 'Wolverine'?
Indira Aramandla
Honored Contributor

Re: Archival Error

Hi Allan,

If you database is a TEST environment and it is in archivelog mode and you are planning to run a long process that has updates and inserts, then I would recomment you to.

1. swithch data to noarchivelog mode
2. Run you job
3. switch the database back to archivelog mode.

Beecause when the databse is on archivelog mode, and the inserts and updates will generate many archive logs which may result in your archivelog destination filesyatem to be full and this will cause to suspend your database activities, which will resume when there is some space in the file system. There is no harm to the database but will suspend the activites.

For this reason, as it is a test environment, trun the archival off, run you script/job then trun the archive on.

To do the above the database should be in mounted status before open.

SQL>shutdown immdiate;
SQL> startup mount;
SQL> alter database noarchivelog;
SQL> alter database open;

Do your job. when completed

SQL>shutdown immdiate;
SQL> startup mount
SQL> alter database archivelog;
SQL> alter database open;


Indira A




Never give up, Keep Trying
R. Allan Hicks
Trusted Contributor

Re: Archival Error

No matter the platform (windows, unix or linux) Oracle behaves the same way. As you run your transactions the changes are written to the redo logs (whether you are in archive log mode or not) The difference being that when an redo log is filled.

If you are in archive log mode, the archiver starts and copies the redo log to an archive log file. While the archiver is copying the full redo logfile, Oracle switches to the next redo log file in the series. The redo log file that is in the process of being copied is unavailable until the archiver finishes copying it.

Let's say you have three redo logs (A,B and C). When A fills, the archiver copies it and the database (LGWR) writes new redo info into B. When B fills, it switches to C. When C fills it should switch back to A. If something happens so that the archiver can't copy the redo log, the system will continue to run, but...........

When it needs to switch to the redo log that hasn't been archived, (because something happened to the archiver) Oracle will enter what is known as a "Polite Wait". That is Oracle will politely wait until the redo log is available. This can happen when you have a long running transaction that generates a lot of redo data. The archiver must finish before the database continues, lot's of database activity can cause the system to switch back to an unarchived redo, and cause the database to pause until the archiver catches up.

The remedy for this is to add more redo logs so that the archiver has a chance of catching up or perhaps make the redo's larger.

The shutdown initialization message that you refer to, should only occur if you shutdown the database with the option of waiting for transactions to complete. If your transaction is a long one, and you do a shutdown as opposed to a shutdown immediate or shutdown abort, the database will wait until the transaction is committed before shutting down.

You can test this on your test database by being the only one connected and do the following:

1.) log on as scott/tiger (doesn't really matter who)

2.) update a table. update emp set salary = salary*1.1;

3.) log in a sys on another sqlplus and issue a shutdown or simply run dbshut (provided that /etc/oratab is set up to allow it to work).

The database will not shutdown.

4.) In the scott/tiger sqlplus, type
commit;

5.) The database will shutdown.

Try it again with shutdown immediate instead of shutdown. The difference is that the original transaction will complete and all employees get a 10% raise. The second case causes the transaction to be rolled back and no one gets a raise.

I suspect that your long running transaction has not completed and someone issued just a shutdown or ran the dbshut script. The database will hang until the long running transaction commits. New users connecting to the database will get the Shutdown initialization in progress message. If you abort the transaction, it should break free. Killing application with the long running transaction should also break things loose.

Hope this helps
"Only he who attempts the absurd is capable of achieving the impossible