Despite of seeking help from different websites I am unable to find the answer of few questions that are very confusing for me. I am recently being involve in creating and managing Logical and Physical Standbys in 10gR2 on Windows platforms as discussed above.

Question # 1: Its the same when I query DBA_LOGSTDBY_PROGRESS most of the time the applied time and newest time have difference in seconds, sometime even 1 or 2 seconds. But when i see the last archived log shipped from production database it is 15-20 minutes to the current time. So how come my lag is just in seconds?

Question # 2: To my understanding I haven't implement any data guard between primary and logical standby. How to check if the data guard is enabled? or it is just log shipping and applying process as what is ment by Logical Standby?

Question # 3: Why in Logical standby the date and time of data and index files is like 20 days to current day, where as the number of records are the same in production and logical?

Question # 4: How to manage archive log deletion in production? if lag is in seconds as per query from DBA_LOGSTDBY_PROGRESS so i can delete all logs completed before 'sysdate-1'? OR I have to keep all archivelogs since that are on production after the date & time in datafile of standby?

These might seem stupid questions... But these are going in my mind and I am unable to find answers after reading so many documents.

Kindly help me to clear logic. I have studied and created physical and logical database both and they are working fine. But these are kind of post creation questions that will clear the concept.

Despite of seeking help from different websites I am unable to find the answer of few questions that are very confusing for me. I am recently being involve in creating and managing Logical and Physical Standbys in 10gR2 on Windows platforms as discussed above.

Question # 1: Its the same when I query DBA_LOGSTDBY_PROGRESS most of the time the applied time and newest time have difference in seconds, sometime even 1 or 2 seconds. But when i see the last archived log shipped from production database it is 15-20 minutes to the current time. So how come my lag is just in seconds?

IT could be little bit different if the applying process is in working. Shipped time and applied will be different as shipped archived log will take to time to be applied. Time taken depends upon the size of the logfile or it could also depends upon your speed of logical standby database.

Question # 2: To my understanding I haven't implement any data guard between primary and logical standby. How to check if the data guard is enabled? or it is just log shipping and applying process as what is ment by Logical Standby?

I don't understand the question properly. Logical standby database is a type of dataguard. Let me assume you are either talking about data guard broker or guard status in logical standby database.

For Data guard Broker: It automates the creation and monitoring of the DG configurations. Switchover and failover becomes very easy if you use dgmgrl. You can check if in your init file you have "dg_broker_start=true".

For guard_status: select name,guard_status from v$database;

Question # 3: Why in Logical standby the date and time of data and index files is like 20 days to current day, where as the number of records are the same in production and logical?

Question # 4: How to manage archive log deletion in production? if lag is in seconds as per query from DBA_LOGSTDBY_PROGRESS so i can delete all logs completed before 'sysdate-1'? OR I have to keep all archivelogs since that are on production after the date & time in datafile of standby?

You can simply define RMAN retention and deletion policy on production. RMAN on production will not delete the archive file if it is not shipped and needed to recover(apply) on logical standby database. RMAn knows if the files are needed in logical standby database and won't delete.

These might seem stupid questions... But these are going in my mind and I am unable to find answers after reading so many documents.

Kindly help me to clear logic. I have studied and created physical and logical database both and they are working fine. But these are kind of post creation questions that will clear the concept.

"It could be little bit different if the applying process is in working. Shipped time and applied will be different as shipped archived log will take to time to be applied. Time taken depends upon the size of the logfile or it could also depends upon your speed of logical standby database."

My confusion is that applied time is newer than the shipped time, if it was opposite, I would have thought ok file is transfers and now it is being processed by the apply processes. In this case applied time should be either equal or less than the last shipped file. This sounds logical. But why Applied Time is alsmost equal to the current time while the last file shipped is 20 minutes old?

Regarding Question # 2, People say that Logical Standby Database is not data guard. Data guard is a process on top of production and standby databases that manages and monitor them. Yes Data Guard Broker is a different thing and needs to be implement. But even if data guard broker is not implemented we can still say log shipping and appliying process is a part of data guard?

Regarding Question # 3, that you missed I can see that the actual data files and index files that are part of different tablespaces, there update date and time is the time when I created this Logical Standby Setup. Why the time is not chnaging as logs are being applied to these files, though the standby is in sync with production.

I really appreciate giving your time for reading and replying this thread.

Answer#1: You seems to contradicting yourself. Applied time will always be newer than log shipped time. This is what you are also saying "Time is alsmost equal to the current time while the last file shipped is 20 minutes old"

Your above statement is a true statement. Files will be shipped first and then the apply process will apply the logs.

Answer2#: Ok, I think this is what you want to know. Dataguard is an automatic way to transfer and apply logs to the standby database using log_archive_dest parameters or FAL_CLIENT or FAL_SERVER. In standby database(like for standard edition), you cannot use this automation because it is an enterprise option, so in that case you will be writing your own scripts to transfer and apply logs and checking gaps.

Answer3#: I honestly do not know. This could be the OS specially windows thing. I have both primary and logical standby database on unix. I do not see any time difference, it is always current. Sorry.

We will discuss only question # 1 now still confused, lets make it simple.

Lets say a file is shipped from production to standby at 9:00 AM today, obviously it will be containing data from the production database untill 9:00 AM.

Now its 9:13 AM, no file has been shipped after the last file that was shipped at 9:00 AM. Now the apply process is working on the last file, its time will be newer than 9:00 AM since its started applying after the file was shipped, like the time could be current time. This is what you are saying.

BUT it means that the lag... the actual time difference between primary and standby database is NOT the time difference between applied_time and newest_time, BUT it is the difference between time stamp of last shipped file and newest_time. In the case above since file was shipped at 9:00 and now its 9:13, applied time is also 9:13 but the time lag between production and standby is 13 minutes.

This is confusing for me. Other then the last shipped log file where else the data can come from?

I still do not understand. Time lag is the difference between the redo log received and redo applied on a standby database.

Newest_time: Estimate of the time and date of the NEWEST_SCN. This will always before archived log timestamp on standby. It means the latest scn time in the archived file on the primary and then only it will start transferring to standby destination and then it will be applied.

What I have found is that, if i start the apply services using ALTER DATABASE START LOGICAL STANDBY APPLY; it works exactly like you mentioned. Applied time is equal to the archive log file received and there will be a gap in applied_time and newest_time until and unless a new archivelog file is recived from primary.

BUT when i start the apply service ALTER DATABSE START LOGICAL STANDBY APPLY IMMEDIATE; it enables the real time apply and redo data is applied directly from the standby redo log files as they are being filled, without requiring the redo data to be filled and archived.

If the real-time apply feature is enabled, log apply services can apply redo data as it is received, without waiting for the current standby redo log file to be archived. This results in faster switchover and failover times because the standby redo log files have been applied already to the standby database by the time the failover or switchover begins.