Return-Path: <oracle-l-bounce@freelists.org>
X-Original-To: oracle-l@orafaq.com
Delivered-To: oracle-l@orafaq.com
Received: from puck1183.startdedicated.com (localhost [127.0.0.1])
 by puck1183.startdedicated.com (Postfix) with ESMTP id 42EB81960200
 for <oracle-l@orafaq.com>; Tue, 30 Dec 2014 10:33:13 +0100 (CET)
Received: from turing.freelists.org (freelists-180.iquest.net [206.53.239.180])
 by puck1183.startdedicated.com (Postfix) with ESMTP
 for <oracle-l@orafaq.com>; Tue, 30 Dec 2014 10:33:13 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
 by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 7749E34977;
 Tue, 30 Dec 2014 04:33:12 -0500 (EST)
X-Virus-Scanned: Debian amavisd-new at turing.freelists.org
Received: from turing.freelists.org ([127.0.0.1])
 by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id uQiIVZtrM0SS; Tue, 30 Dec 2014 04:33:12 -0500 (EST)
Received: from turing.freelists.org (localhost [127.0.0.1])
 by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 4EBB734971;
 Tue, 30 Dec 2014 04:32:57 -0500 (EST)
Received: with ECARTIS (v1.0.0; list oracle-l); Tue, 30 Dec 2014 04:31:35 -0500 (EST)
Received: from localhost (localhost [127.0.0.1])
 by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 27A5B34922
 for <oracle-l@freelists.org>; Tue, 30 Dec 2014 04:31:35 -0500 (EST)
Received: from turing.freelists.org ([127.0.0.1])
 by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 22Qnjk2gMdps for <oracle-l@freelists.org>;
 Tue, 30 Dec 2014 04:31:35 -0500 (EST)
Received: from wp021.webpack.hosteurope.de (wp021.webpack.hosteurope.de [80.237.132.28])
 by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 4B5A634919
 for <oracle-l@freelists.org>; Tue, 30 Dec 2014 04:31:06 -0500 (EST)
Received: from app09.ox.hosteurope.de ([92.51.170.23]); authenticated
 by wp021.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.0:RSA_ARCFOUR_MD5:16)
 id 1Y5t8r-0001dP-45; Tue, 30 Dec 2014 10:31:05 +0100
Date: Tue, 30 Dec 2014 10:31:05 +0100 (CET)
From: Stefan Koehler <contact@soocs.de>
To: Michael Cunningham <napacunningham@gmail.com>
Cc: "oracle-l@freelists org" <oracle-l@freelists.org>
Message-ID: <500102266.7349.1419931865118.open-xchange@app09.ox.hosteurope.de>
In-Reply-To: <CAPt39tv5pF-MR5893ZL029LksqVA4Ft8vWS_fuKq6NfJ-hfPiQ@mail.gmail.com>
References: <CAPt39tv5pF-MR5893ZL029LksqVA4Ft8vWS_fuKq6NfJ-hfPiQ@mail.gmail.com>
Subject: Re: Data Guard - Checking Current Status
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-bounce-key: webpack.hosteurope.de;contact@soocs.de;1419931894;69f7af3b;
X-archive-position: 57956
X-ecartis-version: Ecartis v1.0.0
Sender: oracle-l-bounce@freelists.org
Errors-to: oracle-l-bounce@freelists.org
X-original-sender: contact@soocs.de
Precedence: normal
Reply-To: contact@soocs.de
List-help: <mailto:ecartis@freelists.org?Subject=help>
List-unsubscribe: <oracle-l-request@freelists.org?Subject=unsubscribe>
List-software: Ecartis version 1.0.0
List-Id: oracle-l <oracle-l.freelists.org>
X-List-ID: oracle-l <oracle-l.freelists.org>
List-subscribe: <oracle-l-request@freelists.org?Subject=subscribe>
List-owner: <mailto:mark.bobak@proquest.com>
List-post: <mailto:oracle-l@freelists.org>
List-archive: <http://www.freelists.org/archives/oracle-l>
X-list: oracle-l

Hi Michael,
i hope you are using DGMGRL and if not i highly recommend it :-))

In case of that Oracle 12c has a new DGMGRL command called "VALIDATE DATABASE" ( http://docs.oracle.com/database/121/DGBKR/dgmgrl.htm#DGBKR3877 ). It
includes information about the transfer and apply lag (not SCN based, but time based) and does several checks before a fail over (or switch over).

You can also dump the current standby log and check for the latest committed (and received) data (OP code 5.4 = commit record) that should be
available after fail over including rolling forward and rolling back. You can also get the latest received SCN from that redo dump (maybe for manual
verification). However i can not see any great benefit from that information, beside you want to validate the redo entry with the corresponding block
content (rba) right after the fail over.

Best Regards
Stefan Koehler

Freelance Oracle performance consultant and researcher
Homepage: http://www.soocs.de
Twitter: @OracleSK

> Michael Cunningham <napacunningham@gmail.com> hat am 30. Dezember 2014 um 00:03 geschrieben:
> 
>  Hello, we are looking for the best way to check if the standby is up-to-date (or at least how up-to-date it really is) when it is necessary to fail
> over.
> 
>  Oracle 12cR1 on Linux
> 
>  The scenario is the primary server has crashed and we are faced with finding out how up-to-date the standby is.  It would be nice to know the scn
> if possible.
> 
>  We are configured with standby redo logs in Maximum Performance mode.  If this is not enough info please let me know.
> 
>  P.S. We are currently querying v$dataguard_stats and we can see the datum info, but we are curious if there is better info we could/should be
> looking at.
> 
>  --
>  Michael Cunningham
--
http://www.freelists.org/webpage/oracle-l


