Currently it’s about 2,800 scripts, 800 text and miscellaneous files.

I have a simple catalogue text file which gives the name and one-line description of content, with critical key word in the description.

I also try to create a name which implies the topic of the file, then if I can’d find the script I want from the catalogue I use grep or find to search for keywords in files with the right sort of name – then I escalate that to the entire set of files. (And if that doesn’t work I load the whole lot into an Oracle database and create a context index over the files to search).

Apart from the general notes I then put into the script files, I also keep myself aware of version dependencies by including a standard header that looks like this:

rem	Last tested 
rem		11.2.0.3
rem		11.1.0.7
rem		10.2.0.3
rem		 9.2.0.8
rem	Not tested
rem		10.1.0.4
rem	Not relevant	-- CTE not implemented
rem		 8.1.7.4

Thanks for the link – amongst other details I hadn’t realised that there was a way to dump the redo for a list of blocks (now I have to uncover the syntax).

I think your underlying issue appears in Bug 9385758: “Database hang caused by automatic REDO DUMP”. The patch mentions an optional feature for stopping the dump even in foreground processes.

Just curious to know,how did you organize your documents?When I attended your training class in NY last year,I noticed that you have 1000s of documents in your monster laptop.It would really help me to learn and follow your foot step.

Thanks
Antony

So any process may, in conditions that shouldn’t happen often (we hope), identify an in-memory corrupt, read a block from disc, then go backwards in time in the redo logs and start walking the redo logs to find the redo needed to bring the block up to date

several sessions seemed to go into a frenzied attempt to do cache recovery at the same time, going back several hours into the archived redo logs

There are two options of in-memory corrupted block with correct on-disk version I can think of: 1) the block was unchanged but in-memory version has been corrupted by external forces (broken memory for example) 2) the block was really modified and in-memory version is corrupted
In the first case redo is unnecessary. In the second case how it is possible to reconstruct a corrupted in-memory block from the correct on-disk block version with the help of archived redo? This would mean the block was checkpointed at least once so on-disk block would have been corrupted too. It’s only possible with help of a backup, so Oracle can start with a backed up version of the block and then apply necessary redo from archived & online logs.
11g also introduced something sophisticated for automatic block recovery using standby database.

Relevant note in the associated trace file in this particular incident: “*** time cost of this redo dump is 3067 seconds”

The Oracle documentation states the following about this process:
“Ships redo from current online redo logs to remote standby destinations configured for ASYNC transport”
which suggests the process is reading from the redo log file.

On a production database during peek load I found the NSA processes to be responsible for more reads from the redo logs than the archiver processes.