lium1
asked on
Archieved Logs Full
First, when archieved logs are full and run out of space, what do you suggest to do first?
Second, what is your suggestion to delete archieved logs, please in details!
Finally, you procedure or steps to take for actions. Database is in Oracle 11gR2 RAC.
Thanks in advance.
Second, what is your suggestion to delete archieved logs, please in details!
Finally, you procedure or steps to take for actions. Database is in Oracle 11gR2 RAC.
Thanks in advance.
ASKER CERTIFIED SOLUTION
membership
Create a free account to see this answer
Signing up is free and takes 30 seconds. No credit card required.
>>Second, what is your suggestion to delete archieved logs, please in details!
We really cannot answer this.
This is specific for your database and organization.
for example:
What are your disaster recovery requirements?
What are your uptime requirements?
We really cannot answer this.
This is specific for your database and organization.
for example:
What are your disaster recovery requirements?
What are your uptime requirements?
>> Do I need to shutdown the data base to make the changes and make changes effected?
NO.
slightwv : if using RMAN then i see no problem since it will comply with the retention period they configured.
NO.
slightwv : if using RMAN then i see no problem since it will comply with the retention period they configured.
>>i see no problem since
The fact that the space filled up likely means there isn't a proper disaster recovery policy in place.
I would make sure I am safe before I deleted anything.
The fact that the space filled up likely means there isn't a proper disaster recovery policy in place.
I would make sure I am safe before I deleted anything.
i agree that is why i said use rman and backup the logs then remove them VIA rman.
so if no backup was taken the no archives will be expired.
but again i agree "liuom1" you should check what is your disaster recovery plan and act acording to it.
so if no backup was taken the no archives will be expired.
but again i agree "liuom1" you should check what is your disaster recovery plan and act acording to it.
SOLUTION
membership
Create a free account to see this answer
Signing up is free and takes 30 seconds. No credit card required.
ASKER
Excuse me for the dumb question, where do I look for rman scripts for backup in OEM? Also, where do I check for disaster recovery plan that I have?
>>where do I look for rman scripts for backup in OEM?
It might not be set up under OEM. Many shops have them separated out as part of a server backup process.
If it was set up it should be under the backup tabs somewhere. I'm not a GUI admin so I'm not sure exactly where it is.
The OEM docs should have information on how to set it up and view backup jobs set up through the GUI.
>>Also, where do I check for disaster recovery plan that I have?
Your DBA's, System Adminstrators, Project Managers, ???
In some larger organizations they have their own disaster recovery groups.
Someone should know how important the data is and makes sure it is able to be recovered.
It might not be set up under OEM. Many shops have them separated out as part of a server backup process.
If it was set up it should be under the backup tabs somewhere. I'm not a GUI admin so I'm not sure exactly where it is.
The OEM docs should have information on how to set it up and view backup jobs set up through the GUI.
>>Also, where do I check for disaster recovery plan that I have?
Your DBA's, System Adminstrators, Project Managers, ???
In some larger organizations they have their own disaster recovery groups.
Someone should know how important the data is and makes sure it is able to be recovered.
ASKER
I can view the backup jobs through GUI, but I don't see RMAN scripts for that in GUI. Any idea?
Then backups have not been scheduled through OEM.
Doesn't mean you are not using RMAN.
Your DBA should know how things are backup up.
Doesn't mean you are not using RMAN.
Your DBA should know how things are backup up.
If your archivelog destination is full, such that the disk is 100% full and that's causing your database to stall then:
1) Move (don't Delete... MOVE) a bunch of the oldest archivelogs to a different filesystem/disk that has spare capacity. This will allow the database to continue and will get the boss off of your back whilst you fix it properly. (You can find the archivelog destinations by running this in SQL*Plus: "show parameter log_archive_dest")
2) Consult with your DBA, or keep pursuing this thread in EE to get it resolved correctly. As the previous posters have noted there are many and varied ways to clean this up, and it relies heavily on your specific requirements.
1) Move (don't Delete... MOVE) a bunch of the oldest archivelogs to a different filesystem/disk that has spare capacity. This will allow the database to continue and will get the boss off of your back whilst you fix it properly. (You can find the archivelog destinations by running this in SQL*Plus: "show parameter log_archive_dest")
2) Consult with your DBA, or keep pursuing this thread in EE to get it resolved correctly. As the previous posters have noted there are many and varied ways to clean this up, and it relies heavily on your specific requirements.
ASKER
The solutions provided were not quite completed.
ASKER