What is a lag?
In the replication world, we aspire to reach RPO=0, which means zero data loss, but due to network, infrastructure, distance and other technical difficulties, the DR site will always be “behind” the Primary site. This gap in time and data is referred to as the lag.
What information does Oracle provide?
Oracle provides the lag in units of time via the V$DATAGUARD_STATS view.
Oracle distinguishes between APPLY and TRANSPORT lags.
APPLY lag is the delay in time between the last applied SCN in the primary database to the last applied SCN in the standby database.
TRANSPORT lag is the delay in time between the last redo entry available on the standby database and the last redo entry generated on the primary database (in case of a gap, the last redo entry on the standby database is the last continuous redo entry).
What’s the importance of “lag in size”?
Lag in time gives you an idea of how far behind your DR site is from your primary.
This is an important measurement.
The best way to use it is to sample the lag every few seconds (as consecutive as possible) and follow any irregularities that are observed.
Whereas lag in time can help you learn about Data Guard irregularities and trends, it cannot actually tell you how much data will be lost if a disaster struck your primary data center at any given time. Do you know how much data you may lose as a result of a one second lag between primary and DR sites?
You will most probably say it depends on the specific second you lost. For most systems, each second is unique, affected by the time of day, week, month, special events, etc.
So that a second can possibly treasure as many transactions as your system supports, translated to 1 GB, 10 GB, 100 GB…
How can we calculate lag in size?
Axxana developed a silent tool based on a “Redo Size” (redo generated) metric.
The principle is simple. We sample the Redo size on the primary database and the lag in time on the standby database, at a specific point in time.
Let’s say, for example, that the standby database is 5,400 seconds behind. Now, imagine that we had a time machine and we could go back in time to exactly 5,400 seconds ago and check the primary Redo size value (what other use would anyone have for a time machine, than to check your Data Guard lag… J). Then, we would have all the information we needed to calculate the lag in size, since the Redo size in the present minus the Redo size in the past would give us what we are looking for.
Here is an example:
At 11:30:00 AM, I discover a lag of 5,400 seconds. 5,400 seconds is precisely one hour and 30 minutes. I therefore take the Redo size from 10:00:00 AM and subtract it from the current Redo size.
Redo size samples on the primary
In the case above, the lag in size would be precisely 787-180 = 607 Bytes.
So what we did at Axxana was to build a time machine… 🙂
Instead, we built the Axxana Lag Analyzer. A tool that saves almost consecutive Redo size (v$sysstat) and lag in time information (v$dataguard_stats).
In order to see the full picture, the Axxana Lag Analyzer tool also checks for errors, verifies connectivity, checks for restarts and much more. After analyzing all the data, we can provide you with a detailed report of your lag status.
What’s even more important?
When we first started building this tool, our main focus was the “lag in size” metric.
After presenting it to some of our customers, we discovered that what interests them even more was to know the lag in number of transactions.
Lag in number of transactions gives a wider perspective, since transactions to a DBA are like bricks to a builder.
To achieve that, we added the relevant counters from v$sysstat to the sampling routine.
The analyzer report gives you a max value summary and the ability to easily generate graphs. From it you’ll learn all you need to know about your lag behavior and your RPO prospectus.
Wouldn’t you like to know how much data and how many transactions you are likely to lose in a case of disaster? The Axxana Lag Analyzer tool is the perfect solution.
Can you afford not to know?!