CHECKPOINT_CHANGE# at Physical Standby is Higer then Primary

Question

CHECKPOINT_CHANGE# at Physical Standby is Higer then Primary
Hello, We have hot backup Physical standby implementation (8.1.X way to implement the Standby). Now one thing i saw which i could not understand.. The CHECKPOINT_CHANGE# at Standby is coming out to be higer then the one at the Primary.. After i give ALTER SYSTEM SWITCH LOGFILE on the primary..
ON PRIMARY:-
EVT SQL> select distinct checkpoint_change#/100 from v$database;
CHECKPOINT_CHANGE#/100
139305020
Elapsed: 00:00:00.01
ON STANDBY:-
1* select distinct checkpoint_change#/100 from v$datafile_header
SQL>
SQL> /
CHECKPOINT_CHANGE#/100
139305283
Elapsed: 00:00:01.20
Did any one of you saw that before or can you explain it, why this must be happening or how it is possible.
Thanks,
Sameer Zai.

Answer 1

If Data Guard is setup correctly the application is not losing data, you cannot read from it, but it will apply logs:
Ex.
/home/oracle:STANDBY >sqlplus "/ as sysdba"
SQL> select * from BIGSHOW.CUSTOMER;
select * from BIGSHOW.CUSTOMER
ERROR at line 1:
ORA-01219: database not open: queries allowed on fixed tables/views only
So even as the SYS user I cannot read from my test user's tables.
ORA-01219 is expected when the standby is in this state.
You can open READ ONLY if you have Active Data Guard, but generally that will cost you extra.
OR, you can do thing to check your data:
To open a standby database for read-only access when it is currently performing managed recovery:
Cancel log apply services:
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
Open the database for read-only access:
SQL> ALTER DATABASE OPEN READ ONLY;
At some point you have start the recovery again, you probably don't have an issue.
If you want more peace of mind on this you have to setup a test Data Guard system and bang on it.
Best Regards
mseberg