This morning all the Oracle databases showed a 'down' status in OEM.
Going through my emails, I noticed the that the targets (agents monitoring the databases) were facing some trouble uploading their data. I noticed the oem host was out of disk space...
Usually this problem is solved when the *.trc files under $ORACLE_HOME/admin/SID/udump or $ORACLE_HOME/admin/SID/bdump are deleted, so that's what I tried this time. But the the rm command didn't work anymore, and als the find command gave the same error.....Argument list too long
Using google I found the following unix commando that did work !!! I adjusted it a little bit, so the last seven days will remain..
find . -name '*.trc' -ctime +7 -exec rm "{}" \;
After starting the database again, the targets showed the 'up' status in no time...
Wednesday, May 21, 2008
Thursday, May 15, 2008
Autorecovery
Yesterday I was testing some recovery scenarios with a customer. We decided to restore a backup of a database from a month ago, and recover it to yesterday.
Because the backup was one month old, we had to apply a lot off archived log files. First I just recovered using the suggested archives by entering. It took me more then 20 minutes to recover and open the database.
SQL> recover database until time '2008-05-14:12:00:00';
ORA-00279: change 1274237264 generated at 04/14/2008 23:40:14 needed for thread1
ORA-00289: suggestion :/opt/oracle/product/10.2/db_1/dbs/arch1_100_646855611.dbf
ORA-00280: change 1274237264 for thread 1 is in sequence #100
Specify log: {=suggested filename AUTO CANCEL}
I decided to test again but thios time with the 'set autorecovery on'. Now, the recovery does not wait for your enter, but automaticly applies the next archived log file.
This time, recovery and open database took me 8 minutes....
SQL> set autorecovery on
SQL> recover database until time '2008-05-14:12:00:00';
ORA-00279: change 1274237264 generated at 04/14/2008 23:40:14 needed for thread1
ORA-00289: suggestion :/opt/oracle/product/10.2/db_1/dbs/arch1_100_646855611.dbf
ORA-00280: change 1274237264 for thread 1 is in sequence #100
Because the backup was one month old, we had to apply a lot off archived log files. First I just recovered using the suggested archives by entering. It took me more then 20 minutes to recover and open the database.
SQL> recover database until time '2008-05-14:12:00:00';
ORA-00279: change 1274237264 generated at 04/14/2008 23:40:14 needed for thread1
ORA-00289: suggestion :/opt/oracle/product/10.2/db_1/dbs/arch1_100_646855611.dbf
ORA-00280: change 1274237264 for thread 1 is in sequence #100
Specify log: {
I decided to test again but thios time with the 'set autorecovery on'. Now, the recovery does not wait for your enter, but automaticly applies the next archived log file.
This time, recovery and open database took me 8 minutes....
SQL> set autorecovery on
SQL> recover database until time '2008-05-14:12:00:00';
ORA-00279: change 1274237264 generated at 04/14/2008 23:40:14 needed for thread1
ORA-00289: suggestion :/opt/oracle/product/10.2/db_1/dbs/arch1_100_646855611.dbf
ORA-00280: change 1274237264 for thread 1 is in sequence #100
Wednesday, May 14, 2008
uCertify...
After writing a review for the Prepkit 10g OCP, uCertify posted some info about me on their own blog. http://www.ucertify.com/blog/bas-appraises-ucertifys-ocp-prepkit.html
Also they told me that anybody reading my blog can get a discount when buying any prepkit from uCertify. The discount will be 10%, all you have to do is use the following code "BASK10".
So, check it out....
Also they told me that anybody reading my blog can get a discount when buying any prepkit from uCertify. The discount will be 10%, all you have to do is use the following code "BASK10".
So, check it out....
Subscribe to:
Posts (Atom)