|
You are correct in your assumption. The Log Buffer space (determined by the LOG_BUFFER parameter) in your instance's SGA is a finite size.
Typically, this SGA memory component is not large compared to other memory structures in the SGA. If a transaction is sufficiently large, then there is no way the Log Buffer can accomodate all of the redo information. When this happens, data must be written to the online redo logs before the transaction is committed. If LGWR was not allowed to write to the online redo logs until a transaction is committed, then your transactions would have a finite size to them (in terms of redo bytes).
Your assumption focuses on the effects of one large transaction on the Log Buffer and LGWR. Now focus on many transactions. What if many, small transactions fill the Log Buffer? LGWR has no choice but to write the transactions, even though they are uncommitted, to the online redo log files.
The statement from the Oracle documentation is somewhat misleading.
When I read that statement, I get the sense that transactions that are rolled back are not written to the online redo logs. This is not true.
All transactions, committed or rolled back, are written to the online redo logs. At the end of each transaction is a marker to indicate if the transaction was committed or rolled back. So to make a transaction "not permanent", a rollback marker is written to the online redo logs.
When LGWR gets the signal to write to the online redo logs, it will typically write many transactions at once. Each transaction has its own SCN. While group commits may occur at what seems like the same time, they are not the same time. The SCN of each individual transaction denotes the relative time the individual transaction committed.
Your final question on restoring to a particular SCN is not a valid thought because each individual transaction has their own SCN, regardless of whether or not it participated in a group commit or not.
|
