Return-Path: <oracle-l-bounce@freelists.org>
X-Original-To: oracle-l@orafaq.com
Delivered-To: oracle-l@orafaq.com
Received: from turing.freelists.org (turing.freelists.org [206.53.239.180])
 by malta2546.startdedicated.com (Postfix) with ESMTPS id E03E01002FA2FC
 for <oracle-l@orafaq.com>; Wed, 10 Oct 2018 22:40:14 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1])
 by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 702DA2C78D;
 Wed, 10 Oct 2018 16:40:13 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=freelists.org;
 s=turing; t=1539204013;
 bh=r5dFO331pkLWDHjIglI3krlNCrozGBoCRyY01z1lzJM=;
 h=Date:From:To:Subject:In-Reply-To:References:Reply-To:List-help:
	 List-unsubscribe:List-Id:List-subscribe:List-owner:List-post:
	 List-archive;
 b=npSD00Svnp5Q1LdqRtzcMNup9nsv4Pb5R/ADkHMmtetOQOT89Bb1UTDpUuC2ZZikl
	 4z1gt4KR1BlAIKunx+3UwRxX0gXb29TNeirSBAykIqqpC1LFVLN9v7FPh/lFIFz3Ti
	 3zF1Fg4VRh+yA5lwlgbpn/TMFGrpMOLoeGu+nB30=
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 WS_RKWFzHptW; Wed, 10 Oct 2018 16:40:13 -0400 (EDT)
Received: from turing.freelists.org (localhost [127.0.0.1])
 by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 7F71D2C702;
 Wed, 10 Oct 2018 16:40:00 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=freelists.org;
 s=turing; t=1539204012;
 bh=r5dFO331pkLWDHjIglI3krlNCrozGBoCRyY01z1lzJM=;
 h=Date:From:To:Subject:In-Reply-To:References:Reply-To:List-help:
	 List-unsubscribe:List-Id:List-subscribe:List-owner:List-post:
	 List-archive;
 b=fhUlgsIEPfr1zNW9wiaGYk0dTwQXm7moB3wbmXuYygfoA+OTJuxBQRbxALq5vYdNT
	 6WlUXNXxR76v5Qf02KuSaqv0hvmi16SB34rBmfG37R3Rp5tkFjlhw2NWGOgPepzLjr
	 L9RqMvgXQmyw11I0/lsNNC2gnSRM58sA71VRSPRE=
Received: with ECARTIS (v1.0.0; list oracle-l); Wed, 10 Oct 2018 16:38:38 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
 by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id AA6992C556
 for <oracle-l@freelists.org>; Wed, 10 Oct 2018 16:38:38 -0400 (EDT)
Authentication-Results: turing.freelists.org; dkim=pass
 reason="2048-bit key; unprotected key"
 header.d=yahoo.com header.i=@yahoo.com header.b=b37sb2S9;
 dkim-adsp=none (unprotected policy); dkim-atps=neutral
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 E0fu_gxyx7e3 for <oracle-l@freelists.org>;
 Wed, 10 Oct 2018 16:38:38 -0400 (EDT)
Received: from sonic309-14.consmr.mail.bf2.yahoo.com (sonic309-14.consmr.mail.bf2.yahoo.com [74.6.129.124])
 by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 6C7642C03E
 for <oracle-l@freelists.org>; Wed, 10 Oct 2018 16:38:38 -0400 (EDT)
Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.bf2.yahoo.com with HTTP; Wed, 10 Oct 2018 20:38:37 +0000
Received: from 107-133-111-0.lightspeed.oshkwi.sbcglobal.net (EHLO society.servebeer.com) ([107.133.111.0])
          by smtp412.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 448dff3ab3f4fa2379ecf00f2f21471a
          for <oracle-l@freelists.org>;
          Wed, 10 Oct 2018 20:38:33 +0000 (UTC)
Received: from 107.133.111.0 (localhost [127.0.0.1])
 by society.servebeer.com (Postfix) with ESMTP id 567A1C1977
 for <oracle-l@freelists.org>; Wed, 10 Oct 2018 15:38:32 -0500 (CDT)
MIME-Version: 1.0
Content-Type: multipart/alternative;
 boundary="=_4b95142449831392a12702038edc4d82"
Date: Wed, 10 Oct 2018 15:38:32 -0500
From: Rich J <rjoralist3@society.servebeer.com>
To: oracle-l@freelists.org
Subject: Re: Flashback guaranteed restore point with ADG for DB upgrade
 fallback
In-Reply-To: <CAGV8MGqijSJ0JakLg1Laa83x0i7abEBBhaRwsCFR5trzhc5_OQ@mail.gmail.com>
References: <b02b36585ef1bf38bd21e91b4de7e523@society.servebeer.com>
 <CABe10saNZYSTBMWc8=rTTWhzhH=dH+Kanb_v_DkRnPUFkRKjSw@mail.gmail.com>
 <CAGV8MGqijSJ0JakLg1Laa83x0i7abEBBhaRwsCFR5trzhc5_OQ@mail.gmail.com>
Message-ID: <6587960a4d99a355ca5a2c49f9aa7507@society.servebeer.com>
X-Sender: rjoralist3@society.servebeer.com
User-Agent: Roundcube Webmail/1.3.7
X-archive-position: 72459
X-ecartis-version: Ecartis v1.0.0
Sender: oracle-l-bounce@freelists.org
Errors-to: oracle-l-bounce@freelists.org
X-original-sender: rjoralist3@society.servebeer.com
Precedence: normal
Reply-To: rjoralist3@society.servebeer.com
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:>
List-post: <mailto:oracle-l@freelists.org>
List-archive: <http://www.freelists.org/archives/oracle-l>
X-list: oracle-l
--=_4b95142449831392a12702038edc4d82
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII

On 2018/10/10 13:11, Jose Rodriguez wrote:

> I've recently used the exact same approach for an ADG upgrade. This was 11.2.0.3 to 11.2.0.4, but the idea is the same. 
> As Niall says, just enable flashback database on both sides, create a GRP on the standby first and then on the primary, so you have an older SCN on the standby in case of a rollback. 
> Bear in mind the required FRA space for the flashback logs, not much for the upgrade itself, but this will be recording the applied redo on the standby as well if I recall correctly. 
> I tested it and it worked like a charm. 
> I am not at my desk right now, so I can't share any docs, but I'll take a look tomorrow.

I'm testing this now, and have gotten further than I did before, but am
getting ORA-19909 starting MRP on the standby.  Looking at V$INSTANCE,
the instance_role is "PRIMARY_INSTANCE".  It appears someone forgot to
use the "STANDBY" keyword when doing the flashback.  Doh.  At least that
sounds like it could be the cause. 

I don't want to spend the amount of time it would take to properly test
the effects of enabling flashback on the databases, which appears to be
necessary to flashback to an SCN on the standby.  Creating a guaranteed
restore point on the standby seems to be the way to go here, as Oracle
allowed it, even if I...erm, "someone"...forgot the proper keyword. 

More testing tomorrow -- thanks all for the replies! 

Rich
--=_4b95142449831392a12702038edc4d82
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; charset=
=3DUTF-8" /></head><body style=3D'font-size: 10pt; font-family: Verdana,Gen=
eva,sans-serif'>
<p>On 2018/10/10 13:11, Jose Rodriguez wrote:</p>
<blockquote type=3D"cite" style=3D"padding: 0 0.4em; border-left: #1010ff 2=
px solid; margin: 0"><!-- html ignored --><!-- head ignored --><!-- meta ig=
nored -->
<div dir=3D"auto">I've recently used the exact same approach for an ADG upg=
rade. This was 11.2.0.3 to 11.2.0.4, but the idea is the same.
<div dir=3D"auto">As Niall says, just enable flashback database on both sid=
es, create a GRP on the standby first and then on the primary, so you have =
an older SCN on the standby in case of a rollback.</div>
<div dir=3D"auto">Bear in mind the required FRA space for the flashback log=
s, not much for the upgrade itself, but this will be recording the applied =
redo on the standby as well if I recall correctly.</div>
<div dir=3D"auto">I tested it and it worked like a charm.</div>
<div dir=3D"auto">I am not at my desk right now, so I can't share any docs,=
 but I'll take a look tomorrow.</div>
</div>
</blockquote>
<p>I'm testing this now, and have gotten further than I did before, but am =
getting ORA-19909 starting MRP on the standby.&nbsp; Looking at V$INSTANCE,=
 the instance_role is "PRIMARY_INSTANCE".&nbsp; It appears someone forgot t=
o use the "STANDBY" keyword when doing the flashback.&nbsp; Doh.&nbsp; At l=
east that sounds like it could be the cause.</p>
<p>I don't want to spend the amount of time it would take to properly test =
the effects of enabling flashback on the databases, which appears to be nec=
essary to flashback to an SCN on the standby.&nbsp; Creating a guaranteed r=
estore point on the standby seems to be the way to go here, as Oracle allow=
ed it, even if I...erm, "someone"...forgot the proper keyword.</p>
<p>More testing tomorrow -- thanks all for the replies!</p>
<p>Rich</p>
</body></html>

--=_4b95142449831392a12702038edc4d82--
--
http://www.freelists.org/webpage/oracle-l


