Christoph Lutz
@christophlutz.bsky.social
My drinking club has a skydiving problem
1/11
Everything changes... turns out the age-old rule that lgwr writes out the log buffer when it's 1/3 full no longer applies in recent Oracle versions.
Observations below from 19.26 (with RAC on Exadata). 👇
Everything changes... turns out the age-old rule that lgwr writes out the log buffer when it's 1/3 full no longer applies in recent Oracle versions.
Observations below from 19.26 (with RAC on Exadata). 👇
November 5, 2025 at 6:48 AM
1/11
Everything changes... turns out the age-old rule that lgwr writes out the log buffer when it's 1/3 full no longer applies in recent Oracle versions.
Observations below from 19.26 (with RAC on Exadata). 👇
Everything changes... turns out the age-old rule that lgwr writes out the log buffer when it's 1/3 full no longer applies in recent Oracle versions.
Observations below from 19.26 (with RAC on Exadata). 👇
October 31, 2025 at 8:06 PM
This, so much! 👇
Java devs, please instrument your code 🧠
Have you ever struggled tracing SQL back to the app? Use setClientInfo(...) to add meaningful metadata to your JDBC queries. It makes tracing and perf debugging way easier.
New blog post with real code & tips:
🔗 martincarstenbach.com/2025/10/16/j...
Have you ever struggled tracing SQL back to the app? Use setClientInfo(...) to add meaningful metadata to your JDBC queries. It makes tracing and perf debugging way easier.
New blog post with real code & tips:
🔗 martincarstenbach.com/2025/10/16/j...
Java devs, please instrument your code 🥺
While preparing a talk for Java developers I revisited the topic of code instrumentation. Within the database, for example when writing PL/SQL or MLE/JavaScript code, you would use DBMS_APPLICATION…
martincarstenbach.com
October 16, 2025 at 2:17 PM
This, so much! 👇
When you plan to geek out over some oracle internals, but end up ftrace’ing bpf the entire week end to chase a funny bug that only occurs on exadata with capacity on demand ...
October 5, 2025 at 5:30 PM
When you plan to geek out over some oracle internals, but end up ftrace’ing bpf the entire week end to chase a funny bug that only occurs on exadata with capacity on demand ...
Reposted by Christoph Lutz
There's a problem on the oracle-l listserver at present about an insert taking far too much time (and CPU). It's a known issue and there are 47 statistics in v$sysstat (19.11) with names like 'ASSM%' to help diagnose it.
How many do you think are described in the database reference manual?
None.
How many do you think are described in the database reference manual?
None.
September 28, 2025 at 9:31 PM
There's a problem on the oracle-l listserver at present about an insert taking far too much time (and CPU). It's a known issue and there are 47 statistics in v$sysstat (19.11) with names like 'ASSM%' to help diagnose it.
How many do you think are described in the database reference manual?
None.
How many do you think are described in the database reference manual?
None.
Yet another adaptive lgwr optimization: on Exadata X10+, pipelined log writes may defer redo writes until a suitably sized write batch has accumulated in the log buffer.
The deferral can involve spinning in a tight loop up to 25 times (maximum hard-coded in kcrfw_defer_write).
The deferral can involve spinning in a tight loop up to 25 times (maximum hard-coded in kcrfw_defer_write).
September 21, 2025 at 12:09 PM
Yet another adaptive lgwr optimization: on Exadata X10+, pipelined log writes may defer redo writes until a suitably sized write batch has accumulated in the log buffer.
The deferral can involve spinning in a tight loop up to 25 times (maximum hard-coded in kcrfw_defer_write).
The deferral can involve spinning in a tight loop up to 25 times (maximum hard-coded in kcrfw_defer_write).
Nested loops, baby 😜
September 18, 2025 at 8:40 AM
Nested loops, baby 😜
Reposted by Christoph Lutz
In den nächsten Tagen veröffentlichen wir nicht nur die Agenda, sondern am Tag nach dem SOUG Day planen wir noch ein Special für Euch! Schaut rein und meldet Euch an unter soug.ch.
September 10, 2025 at 11:26 AM
In den nächsten Tagen veröffentlichen wir nicht nur die Agenda, sondern am Tag nach dem SOUG Day planen wir noch ein Special für Euch! Schaut rein und meldet Euch an unter soug.ch.
So glad that all new features are documented so well... NOT 😜
Manually enabling and disabling adaptive lgwr evaluation trace for pipelined / overlapped redo writes:
Manually enabling and disabling adaptive lgwr evaluation trace for pipelined / overlapped redo writes:
September 4, 2025 at 4:35 PM
So glad that all new features are documented so well... NOT 😜
Manually enabling and disabling adaptive lgwr evaluation trace for pipelined / overlapped redo writes:
Manually enabling and disabling adaptive lgwr evaluation trace for pipelined / overlapped redo writes:
POUG journey started… not even at the airport and lufthansa’s delay notification leaves no hope of making the connecting flight in MUC 🙈
September 3, 2025 at 6:50 AM
POUG journey started… not even at the airport and lufthansa’s delay notification leaves no hope of making the connecting flight in MUC 🙈
So 23ai replaces ksesecl0(func, loc, err) with kseseclv(err, func, loc, ...) ... Why is it always just a few days before POUG that this kind of low-level discoveries surface? 🙄
August 31, 2025 at 12:18 PM
So 23ai replaces ksesecl0(func, loc, err) with kseseclv(err, func, loc, ...) ... Why is it always just a few days before POUG that this kind of low-level discoveries surface? 🙄
Reposted by Christoph Lutz
A new tool in 0x.tools family:
xtop - Top for Wall-Clock Time. It uses eBPF/xcapture v3 and gives you "x-ray vision" into Linux system activity.
It will be available on next Tuesday 19 Aug at 1pm EDT when I also run a live demo webinar!
tanelpoder.com/posts/xtop-t...
xtop - Top for Wall-Clock Time. It uses eBPF/xcapture v3 and gives you "x-ray vision" into Linux system activity.
It will be available on next Tuesday 19 Aug at 1pm EDT when I also run a live demo webinar!
tanelpoder.com/posts/xtop-t...
August 13, 2025 at 5:24 AM
A new tool in 0x.tools family:
xtop - Top for Wall-Clock Time. It uses eBPF/xcapture v3 and gives you "x-ray vision" into Linux system activity.
It will be available on next Tuesday 19 Aug at 1pm EDT when I also run a live demo webinar!
tanelpoder.com/posts/xtop-t...
xtop - Top for Wall-Clock Time. It uses eBPF/xcapture v3 and gives you "x-ray vision" into Linux system activity.
It will be available on next Tuesday 19 Aug at 1pm EDT when I also run a live demo webinar!
tanelpoder.com/posts/xtop-t...
"Slide n of 142".. this is getting out of control... 🙈
August 12, 2025 at 7:57 PM
"Slide n of 142".. this is getting out of control... 🙈
Today's discovery (19.26): Oracle derives different log parallelism defaults, depending on platform. Max number of public redo strands is:
Exadata:
CPU_COUNT <= 256: 16
CPU_COUNT> 256: CPU_COUNT/16
Non-Exadata:
CPU_COUNT <= 32: 2
CPU_COUNT > 32: CPU_COUNT/16
Max limit: 256
Exadata:
CPU_COUNT <= 256: 16
CPU_COUNT> 256: CPU_COUNT/16
Non-Exadata:
CPU_COUNT <= 32: 2
CPU_COUNT > 32: CPU_COUNT/16
Max limit: 256
August 6, 2025 at 5:07 PM
Today's discovery (19.26): Oracle derives different log parallelism defaults, depending on platform. Max number of public redo strands is:
Exadata:
CPU_COUNT <= 256: 16
CPU_COUNT> 256: CPU_COUNT/16
Non-Exadata:
CPU_COUNT <= 32: 2
CPU_COUNT > 32: CPU_COUNT/16
Max limit: 256
Exadata:
CPU_COUNT <= 256: 16
CPU_COUNT> 256: CPU_COUNT/16
Non-Exadata:
CPU_COUNT <= 32: 2
CPU_COUNT > 32: CPU_COUNT/16
Max limit: 256
Oh my, looks like the "ms" in "kso_sched_delay_avg_ms" actually means "microseconds" ... 🤷♂️
August 5, 2025 at 7:46 PM
Oh my, looks like the "ms" in "kso_sched_delay_avg_ms" actually means "microseconds" ... 🤷♂️
1/6
The "redo synch time overhead" in Oracle is the difference between a FG's log file sync (LFS) wait end time and LGWR's redo write completion time.
LGWR and LG workers track the redo write completion times in the "write info array" in the SGA.
The "redo synch time overhead" in Oracle is the difference between a FG's log file sync (LFS) wait end time and LGWR's redo write completion time.
LGWR and LG workers track the redo write completion times in the "write info array" in the SGA.
August 4, 2025 at 8:01 AM
1/6
The "redo synch time overhead" in Oracle is the difference between a FG's log file sync (LFS) wait end time and LGWR's redo write completion time.
LGWR and LG workers track the redo write completion times in the "write info array" in the SGA.
The "redo synch time overhead" in Oracle is the difference between a FG's log file sync (LFS) wait end time and LGWR's redo write completion time.
LGWR and LG workers track the redo write completion times in the "write info array" in the SGA.
lgwr: You have the control
gdb: I have the control
gdb: I have the control
August 3, 2025 at 4:45 PM
lgwr: You have the control
gdb: I have the control
gdb: I have the control
Over the past few weeks, my understanding of undocumented LGWR mechanics has improved quite a bit, and I'm now tempted to write a talk titled "LGWR beyond the docs - what Oracle didn't write to disk" 😉
Been digging into lgwr mechanics lately, and whew, have they become dynamic ...
log parallelism, adaptive log file sync, fast sync, adaptive scalable lgwr, pipelined log writes, ...
Wondering if anybody actually knows how all these features work and interact with each other 🤔
log parallelism, adaptive log file sync, fast sync, adaptive scalable lgwr, pipelined log writes, ...
Wondering if anybody actually knows how all these features work and interact with each other 🤔
July 30, 2025 at 8:15 PM
Over the past few weeks, my understanding of undocumented LGWR mechanics has improved quite a bit, and I'm now tempted to write a talk titled "LGWR beyond the docs - what Oracle didn't write to disk" 😉
1/4
In Adaptive Scalable mode, lgwr can dynamically assign multiple lg workers to process a redo write in parallel when these conditions are met:
- redo write size > KSFD_MAXIO (usually 1 MB)
- _max_log_write_parallelism > 1
- active public redo strands > 1
In Adaptive Scalable mode, lgwr can dynamically assign multiple lg workers to process a redo write in parallel when these conditions are met:
- redo write size > KSFD_MAXIO (usually 1 MB)
- _max_log_write_parallelism > 1
- active public redo strands > 1
July 29, 2025 at 12:18 PM
1/4
In Adaptive Scalable mode, lgwr can dynamically assign multiple lg workers to process a redo write in parallel when these conditions are met:
- redo write size > KSFD_MAXIO (usually 1 MB)
- _max_log_write_parallelism > 1
- active public redo strands > 1
In Adaptive Scalable mode, lgwr can dynamically assign multiple lg workers to process a redo write in parallel when these conditions are met:
- redo write size > KSFD_MAXIO (usually 1 MB)
- _max_log_write_parallelism > 1
- active public redo strands > 1
The trace below shows lg00 submitting a log write at T4 (lwn scn 0x70f14b55773) while lg04's earlier write submitted at T2 (lwn 0x70f14b55768) is still in flight, suggesting Pipelined Log Writes. But the trace is from an X8, not X10, where the feature is documented ...🤔 (I/Os throttled for testing)
July 27, 2025 at 2:36 PM
The trace below shows lg00 submitting a log write at T4 (lwn scn 0x70f14b55773) while lg04's earlier write submitted at T2 (lwn 0x70f14b55768) is still in flight, suggesting Pipelined Log Writes. But the trace is from an X8, not X10, where the feature is documented ...🤔 (I/Os throttled for testing)
1/7
On Exadata with pmemlog, the Fast Log File Sync dynamically tunes the log file sync sleep duration to balance responsiveness vs cpu ovherhead (spinning after wakeup).
Oracle tracks three wait variants via different session stat counters:
1. Sleep
2. Spin
3. Backoff Sleeps
On Exadata with pmemlog, the Fast Log File Sync dynamically tunes the log file sync sleep duration to balance responsiveness vs cpu ovherhead (spinning after wakeup).
Oracle tracks three wait variants via different session stat counters:
1. Sleep
2. Spin
3. Backoff Sleeps
July 24, 2025 at 8:51 AM
1/7
On Exadata with pmemlog, the Fast Log File Sync dynamically tunes the log file sync sleep duration to balance responsiveness vs cpu ovherhead (spinning after wakeup).
Oracle tracks three wait variants via different session stat counters:
1. Sleep
2. Spin
3. Backoff Sleeps
On Exadata with pmemlog, the Fast Log File Sync dynamically tunes the log file sync sleep duration to balance responsiveness vs cpu ovherhead (spinning after wakeup).
Oracle tracks three wait variants via different session stat counters:
1. Sleep
2. Spin
3. Backoff Sleeps
If you've ever felt the need to manually control adaptive lgwr features, this gdb script's got you covered: t.ly/lJIW1 😎
It lets you enable and disable adaptive scalable lgwr, fast log file sync, and log parallelism. Highly experimental, of course!
Example 👇
It lets you enable and disable adaptive scalable lgwr, fast log file sync, and log parallelism. Highly experimental, of course!
Example 👇
July 23, 2025 at 10:41 AM
If you've ever felt the need to manually control adaptive lgwr features, this gdb script's got you covered: t.ly/lJIW1 😎
It lets you enable and disable adaptive scalable lgwr, fast log file sync, and log parallelism. Highly experimental, of course!
Example 👇
It lets you enable and disable adaptive scalable lgwr, fast log file sync, and log parallelism. Highly experimental, of course!
Example 👇