It’s quite an interesting way that’s used to implement concurrent request schedules in Oracle Applications. In this post I’ll describe how “Periodic” and “On Specific Day” type of schedules are stored in the Database and if you will be patient enough to read all the story, I’ll give you a query that can be used to report all the request schedules in the environment.

This is the continuation of Concurrent Manager internals (Part 1), where I described how concurrent manager selects a list of requests that have to be run. It was also discovered, that there is no special queue of requests for each concurrent manager and that there are some settings that are obtained only at the time of startup of a concurrent manager. At the moment it is clear that all the processes of the same concurrent manager (e.g. Standard Manager) use the same select to query the requests for execution, therefore it is possible that more than one concurrent manager process will have the same request_id’s to run. In this post I’ll describe the mechanism that’s used to assign the request to a particular concurrent manager process.

It has never been absolutely clear for me how concurrent managers decide which request should be executed next and what conditions drive the distribution of requests among all the different concurrent managers and processes of each concurrent manager. I decided to take a closer look, if you’re interested in what I found - read on!

Today was the 1st day (of 3) of attendance of Oracle Database 10g: Backup and Recovery course. During explanation of RMAN retention policies I found myself thinking about how backup of database containing corrupted blocks relates to the retention policy. The question is important in case Flash Recovery Area (FRA) + RMAN backups with any retention policy configured is being used, because if there is not enough space to store the ongoing backup ore archived redo log in FRA, an obsolete backups will be automatically deleted.

What happens if ORA-19566: exceeded limit of 0 corrupt blocks for file ... pops out during backup? One may want to allow some corrupted blocks in the backup just to have a fresh backup (and deal with the corruption later). So the question is: does RMAN still count this kind of backup as a valid backup to satisfy the retention policy and may deletes older backup this way loosing the possibility of using the block recovery?

Hey, the blog is new and I haven’t yet gotten used to it, therefore I absolutely don’t know what you would like to read about :) But it’s also good because I can choose the topics freely. This one will be about monitoring the Workflow Agent Listeners or how to make sure Agent listeners are really doing their job.