I need help figuring out a practical solution for handling big bursts of archive logs.

DB: 10.1.0.4 / ASM / OMF
OS: RedHat AS 3

From time to time we have a process that writes 20gb of archive logs in about 1/2 hour. It floods our available space (17gb reserve) for these logs and hangs the database.

Adding diskspace to the ASM diskgroup will obviously help but we'd I want to avoid the downtime of adding new raw disk devices.

I've thought of writing a pl/sql job that checks the rate of archiving and if it hits a threshold, then trigger an rman process to flush the logs, provided it's not already running.

Am I over-thinking this?

Ken

12-07-2005, 11:36 AM

tamilselvan

Quote:

Adding diskspace to the ASM diskgroup will obviously help but we'd I want to avoid the downtime of adding new raw disk devices.

You don't need to add raw devices for archive log file system. You need to increase the arch file system only.

Tamil

12-07-2005, 12:38 PM

bazza

Rather than writing pl/sql, can't you just set up a threshold/notifcation (in grid - I know you use it!!) for when the file system/archive area hits x% full? If you still want to automatically kick the rman job, then set a response action up.
Either that or more space ;-)

Bazza

12-07-2005, 01:01 PM

KenEwald

Quote:

Originally Posted by tamilselvan

You don't need to add raw devices for archive log file system. You need to increase the arch file system only.

Unless I choose a locally mounted file system and switch my archivelog destination to it, I believe would need to add a raw device to the ASM disgroup where my archivelogs are going now.

Ken

12-07-2005, 01:09 PM

KenEwald

Quote:

Originally Posted by bazza

Rather than writing pl/sql, can't you just set up a threshold/notifcation (in grid - I know you use it!!) for when the file system/archive area hits x% full? If you still want to automatically kick the rman job, then set a response action up.
Either that or more space ;-)

Bazza

Yea, Great suggestion. I'd love to do this. I'm just not real comfortable with the alerting system 10g OEM. We've been running it side by side with other systems and they have been 100% right on, while OEM has missed some really big problems 50% of the time. That's probably me, but I think it needs help.

I also have the addition of not wanting to fire this when an rman backup (datafile or archivelog) is already running.

There's probably a sql query that could tell me if the db is currently being backed up through rman.

I'm working along the lines of a cron job that counts the rows in v$archived_log where status = 'A' ('D' is deleted), and if rman isn't already running (grep rman or something) and I've got 20 archived logs or so, then kick off the rman process.

Any thoughts/opinions are greatly appreciated.

-Ken

12-08-2005, 07:50 AM

bazza

Instead of grepping for rman, you could check V$session instead and check for sys sessions running rman (program column is populated by rman).

Know what you mean about grid, our whole setup stopped working for targets that were discovered > 250 days ago, due to a bug. You using Release 2 yet?

Bazza

12-08-2005, 10:54 AM

KenEwald

Quote:

Originally Posted by bazza

..check V$session .. for sys sessions running rman..

Great idea. Thanks!

That's a nasty bug we haven't run into. Was the root cause discovered? Was it platform specific?

I'm working on installing OEM 10.2 on SuSE-9 64 bit without much success. I've had a compilation error TAR open for a few weeks. Some TAR's just don't get good traction. :confused:

12-08-2005, 11:12 AM

sambavan

My take would be to add more disk space to the archive destination and point your archives to collect in there.

12-08-2005, 12:26 PM

bazza

Quote:

Originally Posted by KenEwald

Great idea. Thanks!

That's a nasty bug we haven't run into. Was the root cause discovered? Was it platform specific?

I'm working on installing OEM 10.2 on SuSE-9 64 bit without much success. I've had a compilation error TAR open for a few weeks. Some TAR's just don't get good traction. :confused:

It's a known issue with R1 apparently, have a look at bug 3674467 and note 303106.1. Its not platform specific, its a bug with grid itself.

I'm going to have crack at Grid R2 on Red hat 3 next week. Just had to resolve a bug with the installer itself!!

Happy times

Bazza

12-08-2005, 12:57 PM

KenEwald

Quote:

Originally Posted by sambavan

My take would be to add more disk space to the archive destination and point your archives to collect in there.

Yea, me too. Unfortunately I'm limited to the disks I have in that ASM diskgroup.

This happens once every 2 weeks. I think we can "swallow the frog" if I can flush logs before it can fill up the space. I'm also thinking about adding online redo logs so we have a little more lead time before the "archivelog dest full" alert is triggered and when the db finally halts transactions.