Return-Path: Delivered-To: 2-oracle-l@orafaq.com Received: (qmail 13084 invoked from network); 14 Jul 2007 09:38:47 -0500 Received: from freelists-180.iquest.net (HELO turing.freelists.org) (206.53.239.180) by 69.64.49.119 with SMTP; 14 Jul 2007 09:38:42 -0500 Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 3F6EA712E5A; Sat, 14 Jul 2007 10:36:33 -0400 (EDT) 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 17688-05; Sat, 14 Jul 2007 10:36:33 -0400 (EDT) Received: from turing (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id AD25C7128BA; Sat, 14 Jul 2007 10:36:32 -0400 (EDT) Received: with ECARTIS (v1.0.0; list oracle-l); Sat, 14 Jul 2007 09:55:23 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id A44EA7131AD for ; Sat, 14 Jul 2007 09:55:23 -0400 (EDT) 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 05898-03 for ; Sat, 14 Jul 2007 09:55:23 -0400 (EDT) Received: from tornado.rdtex.ru (tornado.rdtex.ru [82.149.210.248]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id F223E7131ED for ; Sat, 14 Jul 2007 09:55:22 -0400 (EDT) Received: by tornado.rdtex.ru (Postfix, from userid 3000) id A3A8632E2C; Sat, 14 Jul 2007 17:57:28 +0400 (MSD) Received: from orff.int.rdtex.ru (orff.int.rdtex.ru [192.168.30.225]) by tornado.rdtex.ru (Postfix) with ESMTP id DD69A32E2C; Sat, 14 Jul 2007 17:57:13 +0400 (MSD) Received: from [192.168.30.129] by orff.int.rdtex.ru (8.11.6/8.11.2/Nix) with ESMTP id l6EDvCt31419; Sat, 14 Jul 2007 17:57:12 +0400 Message-ID: <4698D68F.2010706@rdtex.ru> Date: Sat, 14 Jul 2007 17:58:39 +0400 From: Andrey Kriushin Organization: RDTEX J.S.C. User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: bdbafh@gmail.com Cc: sbecker6925@gmail.com, Neil Overend , oracle-l Subject: Re: Standard Edition standby database References: <3c5f7820707060750h39960f6fj9aa6fec3ca1488ff@mail.gmail.com> <5acbeade0707060814xb73a674y34d4e1dd8790195c@mail.gmail.com> <3c5f7820707111137u215c8218j4b31e51094d09944@mail.gmail.com> <5acbeade0707111231v29a16df7o45c7d04ee6a59dac@mail.gmail.com> <3c5f7820707111257k56e5bbf9g58021eaf73cf537a@mail.gmail.com> <910046b40707111407v7889af80k804c7ba59ab1bf45@mail.gmail.com> In-Reply-To: <910046b40707111407v7889af80k804c7ba59ab1bf45@mail.gmail.com> Content-Type: text/plain; charset=KOI8-R; format=flowed X-ClamAv-RD-Scan: PASSED [by tornado.rdtex.ru] X-archive-position: 50883 X-ecartis-version: Ecartis v1.0.0 Sender: oracle-l-bounce@freelists.org Errors-to: oracle-l-bounce@freelists.org X-original-sender: Andrey.Kriushin@rdtex.ru Precedence: normal Reply-to: Andrey.Kriushin@rdtex.ru List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: oracle-l X-List-ID: oracle-l List-subscribe: List-owner: List-post: List-archive: X-list: oracle-l X-Virus-Scanned: Debian amavisd-new at localhost.localdomain Hi, One warning about copying the current controlfile: There was a bug (not very critical and thus a good candidate for the reinvention in a version or two timeframe :-)). The bug was related to the checkpoint number(s) in the controlfile and datafile headers. That number may be different due to incremental checkpoints on the primary which are absent on the "standby". So in some cases in was not possible to open the database with such a copy of current controlfile from production database. The walkaround is trivial - recreate the controlfile. My 2 kopejka Andrey -- Disclaimer: Opinions are of my own and not necessar[-il]y... Paul Drake wrote: > Sandra, > > "Graceful Switchover" refers to a term in a paper by Lawrence To back > in the 7.3.4 days. > > Both the online redo log and current controlfile had to be copied to > the new location of the primary database (as well as any archived redo > logs that were not applied). > Basically, the standby is no longer a standby database. It is not > activated. It simply is recovered and opened at the primary database, > albeit on the server that used to house the standby database. > > Paul -- http://www.freelists.org/webpage/oracle-l