About Log Buffer writhing..

Question

Hi,
Wondering how Log Buffer behaves...
1. If timesten is configured as single node(no replication and cache option), When does log buffer data write to log file?
By running some test, it seems like only at checkpoint action it is being write.
Is there any other way to write log buffer data beside with checkpoint action?
2. Which process is doing writing action from log buffer to log file?
Is it the same process that uses with replication and cache option?
3. In TimesTen Manual ...
asynchronous replication "TimesTen Data Manager writes the transaction update records to the transaction log buffer."
Return Twosafe "The master replication agent writes the transaction records to the log and inserts a special precommit log record before the commit record."
Then ... does it mean that log buffer write process is different according to replication type?
4. I am assuming Log_Buffer_Wait from 'monitor;' output is the waiting time of Log Buffer writing time to logfile...
If it is correct, is the possibility of Log_Buffer_Wait occurance increases when log buffer size is large with no replication option?
w
I am willing to hear for above.
Thank you,

Answer 1

TimesTen generates log records for the purposes of redo and undo. Log records are generated for pretty much any change to persistent recoverable data within TimesTen. Log records are first written into the in memory log buffer and then are written to disk by a dedicated flusher thread that runs within the sub-daemon process that is assigned to the datastore. The log flusher thread runs continuously when there is data to be flushed and when there is any significant write workload on the system log data will reach disk very shortly after it has been placed in the buffer. Under very light write workload it may talke a little longer for the data to reach disk.
There is a single logical log buffer (size determined by LogBufMB) which in TimesTen 11g, is divided into multiple physical buffers (strands) for increased concurrency of logging operations ( number of strands determined by LogBufParallelism).
Several of your observations are not correct; I would like to understand hwat tests you performed to arrive at these conclusions:
1. Yes, the log buffer is flushed during a checkpoint operation but in fact it is also being flushed continuously at all times by the log flusher thread.
2. You can force the buffer to be flushed at any time simply by executing a durable commit within the datastore. A durable commit flushes all log starnds synchronously to disk and does not return until the writes have completed successfully and been acknowledged by the storage hardware.
3. The text that you quote from the replication guide is ambiguous and could be better phrased. When it talks about 'writing to the log' it means placing records in the in-memory log buffer. The presence or absence of replication does not fundamentally change the way logging works though the replication agent, when active, typically perfoms a durable commit every 100 ms. Also, in some replication modes, additional durable commits may be executed by the replication agent before sending a block of replicated transactions.
4. The LOG_BUFFER_WAITS field in SYS.MONITOR counts the number of times that application transactions have been blocked due to there being no free space in the log buffer to receive their log records. This is due to some form of logging bottleneck. By far the most common reason is that the log buffer is undersized. the default size if only 64 MB and this is far too small for any kind of write intensive workload. For write intensive workloads a significantly larger log buffer size is needed (max size allowed is 1 GB).
5. The field LOG_FS_WRITES in SYS.MONITOR counts the number of physical writes that the log flusher thread has performed to the logs on disk. The flusher will typically write a lot of data in a single write (when under heavy load). Flusher writes are filesystem block aligned.
Hope that helps clarify things.
Chris