|
Change the topic when you respond to a digest. On 28/06/2006, at 7:58 AM, msmith6@xxxxxxxxxxxx wrote:
Isn't that only for the system auditing journal?
Yes, it has no effect on database journalling.
I'm looking for what 'trigger' (perhaps a poor term) the journal record still in memory to be staged to the journal receiver?
On OS/400 journal writes are synchronous. That is, they are guaranteed to be written to the journal before the application continues. The actual database change itself may not be written to the file until much later. Why anyone would want to delay the journal writes is beyond me--the whole point of journalling is for recovery. It's a bit hard to recover if you haven't got the recovery data. Although I guess others don't see this the same way given that IBM is offering a journal caching feature for OS/400.
If you use commitment control (as you should) then journal writes can be cached until the COMMIT occurs at which point any outstanding journal changes are written to disk. The database changes may still be delayed until much later. This makes sense because commitment control tells the system that uncommitted changes can be ignored during recovery. There is no practical difference between rolling-back uncommitted changes and not recording them in the first place.
Would the same scenerio happen as Sql Server?
Who knows? Who cares? SQL Server is toy!
That is, say I coded the FRCRATIO on my table to be 3. Before the three records are written to my PF, the journal images would be written to the receiver?
This would be a dumb thing to do. You use either FRCRATIO or journalling--not both. The journal changes would be written synchronously and then every 3rd change to that file would cause a synchronous write of the database changes. This could contribute to a performance problem by increasing synchronous I/O. Forcing database changes to disk in this way is unnecessary because you already have the journal changes from which a recovery can be made. If the system does not crash then forcing database updates is unnecessary. If it does crash the system still has to synchronise the journal changes with the file. There may possibly be some slight improvement in recovery time if the record is found to be already in the database but I doubt that outweighs the benefits of allowing asynchronous I/O during normal operations.
What it you didn't specify the FRCRATIO on the table? What then?
FRCRATIO doesn't affect journal writes.
Or if you had more than one table journaled to the same receiver?
Doesn't matter. Why do you think it would? Regards, Simon Coulter. -------------------------------------------------------------------- FlyByNight Software AS/400 Technical Specialists http://www.flybynight.com.au/ Phone: +61 3 9419 0175 Mobile: +61 0411 091 400 /"\ Fax: +61 3 9419 0175 \ / X ASCII Ribbon campaign against HTML E-Mail / \ --------------------------------------------------------------------
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
