Return-Path: Delivered-To: 2-oracle-l@orafaq.com Received: (qmail 29899 invoked from network); 10 Oct 2008 16:21:28 -0500 Received: from freelists-180.iquest.net (HELO turing.freelists.org) (206.53.239.180) by air964.startdedicated.com with SMTP; 10 Oct 2008 16:21:28 -0500 Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 451C0A3B3DA; Fri, 10 Oct 2008 17:21:28 -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 20390-09; Fri, 10 Oct 2008 17:21:28 -0400 (EDT) Received: from turing.freelists.org (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id A8F1EA3B39F; Fri, 10 Oct 2008 17:21:27 -0400 (EDT) Received: with ECARTIS (v1.0.0; list oracle-l); Fri, 10 Oct 2008 17:19:27 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 014BEA3B351 for ; Fri, 10 Oct 2008 17:19:27 -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 19817-04 for ; Fri, 10 Oct 2008 17:19:26 -0400 (EDT) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.231]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 9EB33A3B360 for ; Fri, 10 Oct 2008 17:19:26 -0400 (EDT) Received: by wx-out-0506.google.com with SMTP id r21so357131wxc.25 for ; Fri, 10 Oct 2008 14:19:26 -0700 (PDT) Received: by 10.70.116.14 with SMTP id o14mr2208817wxc.31.1223673565966; Fri, 10 Oct 2008 14:19:25 -0700 (PDT) Received: from dn-macbook.dannorris.net (d53-64-191-237.nap.wideopenwest.com [64.53.237.191]) by mx.google.com with ESMTPS id i33sm3221060wxd.38.2008.10.10.14.19.24 (version=SSLv3 cipher=RC4-MD5); Fri, 10 Oct 2008 14:19:25 -0700 (PDT) Message-ID: <48EFC6DB.6030909@dannorris.com> Date: Fri, 10 Oct 2008 16:19:23 -0500 From: Dan Norris User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Mark.Bobak@proquest.com CC: "Chris.Taylor@ingrambarge.com" , ORACLE-L Subject: Re: Sanity Check References: <17E4CDE8F84DC44A992E8C00767402E0861896@spobmexc02.adprod.directory> <667C10D184B2674A82068E06A78382B5282DAE8D@AAPQMAILBX01V.proque.st> In-Reply-To: <667C10D184B2674A82068E06A78382B5282DAE8D@AAPQMAILBX01V.proque.st> Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 11578 X-ecartis-version: Ecartis v1.0.0 Sender: oracle-l-bounce@freelists.org Errors-to: oracle-l-bounce@freelists.org X-original-sender: dannorris@dannorris.com Precedence: normal Reply-to: dannorris@dannorris.com 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 Chris,

I can attest that I did this successfully. It was a long time ago, on 9i, but it worked fine. It's essentially the same as manually archiving the log. Just to be specific, Mark said to "copy on-line redo" from prod, but you only need to copy the *current* online redo log (that was current at time of shutdown) and apply it. Basically, just rename it to the next archived redo log in your log sequence (since that will likely avoid confusion).

I also agree that a standby database and a switchover would be better, but if you're using standard edition, that won't be an option.

Dan

Bobak, Mark wrote:

Chris,

To be sure, after copying all the archivelogs from the old server to the new server and applying all of them, take copies of the online redo logs, and apply them in the recovery process as well. This will guarantee no data loss.

So, set up copy of prod on new hardware. Start copying archive logs from prod to copy on new hardware and applying. At cut over time, shutdown prod, copy remaining archive logs, apply them. Then copy on-line redo from prod over to new hardware, and apply them as if they were archived logs (Oracle will not know the difference). That will guarantee every last transaction will be applied to the new database. Then just open w/ resetlogs and be on your way.

Hope that helps,

-Mark

--
Mark J. Bobak
Senior Database Administrator, System & Product Technologies
ProQuest
789 E. Eisenhower, Parkway, P.O. Box 1346
Ann Arbor MI 48106-1346
+1.734.997.4059 or +1.800.521.0600 x 4059
mark.bobak@proquest.com
www.proquest.com
www.csa.com

ProQuest...Start here.

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