Multiple Dbspaces for Logical Logs, Established Round Robin Style ...

Some three or four years ago, I started using multiple dbspaces for logical logs. I would add the logical logs to these dbspaces in round robin format. On some systems I have used as little as three and as many as eight, dependent upon how many logs it took to contain at least 24 - 48 hours worth of logical logs without overwriting any log (in case the storage manager went offline and our SLA to get it fixed. When I first started using 9.4 and was introduced to DYNAMIC LOGGING, I started creating one additional dbspace, containing the last logical log added to the system. In this manner, dynamic logging is to use this last dbspace first before going out and about in the other dbspaces looking for log space. At my current location, I have been asked to supply documentation as to the benefits of what I have described, other than my own thoughts. Not knowing now whether the idea was mine or whether I read or learned it from either the general IDS world or from SAP or SAPMIXers, I have cross-posted this email to see who might have some documentation from some "authorative" source. From my increasingly old memory, I recall that the benefit was the multiple threads being available to read from the logical logs, for copying data to tape while other processes are writing logcal log information to disk. It also tended to relieve the bottleneck of all of the I/O coming and going from the same dbspace and hard drives. Is this a creation of my own imagination? Is it a benefit for standard hard drive configurations? For instances on SAN?

There are two advantages on log spread on several dbspaces: 1. After one log became full, the logbackup reads from the dbspace where the old log was located, not the new one where you write on. 2. If you ever need to restore your system, after the physical restore and the logrestore, all unused logfiles are filled up with nulls. This action takes place in parallel in all dbspaces, that contain log. If all logs are in one dbspce, than this is done serial on the logs and can span a lot of time (up to half an hour with many logs). best regards, gerd "Clifton M. Bean" <cmbean@sbcglobal.net> schrieb am 01.03.05 18:43:57: > > Some three or four years ago, I started using multiple dbspaces for logical logs. I would add the logical logs to these dbspaces in round robin format. On some systems I have used as little as three and as many as eight, dependent upon how many logs it took to contain at least 24 - 48 hours worth of logical logs without overwriting any log (in case the storage manager went offline and our SLA to get it fixed. > > When I first started using 9.4 and was introduced to DYNAMIC LOGGING, I started creating one additional dbspace, containing the last logical log added to the system. In this manner, dynamic logging is to use this last dbspace first before going out and about in the other dbspaces looking for log space. > > At my current location, I have been asked to supply documentation as to the benefits of what I have described, other than my own thoughts. Not knowing now whether the idea was mine or whether I read or learned it from either the general IDS world or from SAP or SAPMIXers, I have cross-posted this email to see who might have some documentation from some "authorative" source. > > From my increasingly old memory, I recall that the benefit was the multiple threads being available to read from the logical logs, for copying data to tape while other processes are writing logcal log information to disk. It also tended to relieve the bottleneck of all of the I/O coming and going from the same dbspace and hard drives. > > Is this a creation of my own imagination? Is it a benefit for standard hard drive configurations? For instances on SAN? > > __________________________________________________________ Mit WEB.DE FreePhone mit hoechster Qualitaet ab 0 Ct./Min. weltweit telefonieren! http://freephone.web.de/?mc=021201