Path: text.usenetserver.com!out01b.usenetserver.com!news.usenetserver.com!in02.usenetserver.com!news.usenetserver.com!postnews.google.com!h1g2000prh.googlegroups.com!not-for-mail From: joel garry Newsgroups: comp.databases.oracle.server Subject: Re: DBPITR and ORA-16005 Error: database requires recovery. Date: Mon, 5 May 2008 10:05:17 -0700 (PDT) Organization: http://groups.google.com Lines: 82 Message-ID: <7e88ec44-ddd2-476f-a320-196830b41eb8@h1g2000prh.googlegroups.com> References: <51518103-278f-4f70-bb89-988de6428cc4@f36g2000hsa.googlegroups.com> <74a86d1f-d8d1-4ee3-97ad-6e3f12a2a9b5@56g2000hsm.googlegroups.com> <39062a59-1636-4236-99c1-2d9e9a19fc69@25g2000hsx.googlegroups.com> <0548e94a-51cc-4094-8af7-fa0479e06d25@27g2000hsf.googlegroups.com> NNTP-Posting-Host: 75.49.200.201 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1210007117 26873 127.0.0.1 (5 May 2008 17:05:17 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Mon, 5 May 2008 17:05:17 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: h1g2000prh.googlegroups.com; posting-host=75.49.200.201; posting-account=tpQovAkAAABNoH5bwsZAiff2L0zxGwdv User-Agent: G2/1.0 X-HTTP-Via: 1.0 ISA2K4-OC1 X-HTTP-UserAgent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1),gzip(gfe),gzip(gfe) Xref: usenetserver.com comp.databases.oracle.server:444345 X-Received-Date: Mon, 05 May 2008 13:05:17 EDT (text.usenetserver.com) On May 5, 7:25=A0am, tim2bo...@gmail.com wrote: > On May 5, 4:00=A0am, "gba...@ravenpack.com" > wrote: > > > > > > > > Where have you read you can open the database in READONLY mode without= > > > any resetlogs in this situation? > > > Oracle=AE Database Backup and Recovery Basics:http://download.oracle.com= /docs/cd/B19306_01/backup.102/b14192/toc.htm > > > Sections 7.6.4 and 7.6.5. > > > =A07.6.4 Database Point-in-Time Recovery Within the Current Incarnation.= > > > "If the operation completes without errors, then your DBPITR has > > succeeded. You can open the database read-only and perform queries as > > needed to ensure that the effects of the logical corruption have been > > reversed. If not, you may have chosen the wrong target SCN." > > > 7.6.5 Options After Database Point-in-Time Recovery. > > > "After a successful DBPITR, your choices are: > > > =A0 =A0 * =A0Export one or more objects from your database using an Orac= le > > export utility such as Data Pump Export. You can then recover the > > database to the current point in time and re-import the exported > > objects, as a way to return these objects to their state prior to the > > unwanted change without abandoning all other changes. > > =A0 =A0 * =A0 Open your database for read-write, abandoning all changes > > after the target SCN. In such a case, you must open the database with > > the RESETLOGS option, as shown here: > > =A0 =A0 =A0 RMAN> ALTER DATABASE OPEN RESETLOGS; " > > I am not sure where your system stands at current. =A0It would seem to > me that you followed the instructions perfectly as described in the > Database Backup and Recovery Basics. > > A few things to check. > 1) =A0Before you can do ALTER DATABASE OPEN READ ONLY, your database > needs to be in a mounted state. > 2) =A0Have you tried to do ALTER DATABASE OPEN READ ONLY from a sql > prompt and not from within RMAN (I know it sounds crazy but I have > seen stranger things work.) > > Lastly I don't think the documentation is correct. =A0I really believe > that you have to tell it to restore using a backup controlfile (even > if it is the "current" controlfile) RECOVER DATABASE USING BACKUP > CONTROLFILE. =A0If you are using "RECOVER DATABASE" then RMAN is > expecting the end of recovery marker. =A0Well if you are doing a point > in time recovery then you are doing and "incomplete" recovery and > therefore it can not reach the recovery marker. =A0I may be wrong but > that is my view point. > > Regards > Tim- Like David, I'm also flying blind here, but I'm not so sure the docs are wrong, as they do specifically state using the current controlfile. I'm guessing the OP's problem comes from using the current SCN, he needs to try an older one. There must be some conceptual fuzziness required, henc the docs say "...you may have chosen the wrong target SCN. In such a case, investigate the unwanted change further and determine a new target SCN, then repeat the DBPITR process." Makes me wonder if there are various system-related SCN's that get posted, which are kind of iffy in the sense of being a complete transaction in the sense we are used to. I know how weird that sounds and don't even want to speculate on what I mean. Maybe one of the authors of books on RMAN might be the one to ask. jg -- @home.com is bogus. http://timesofindia.indiatimes.com/China_mounts_cyber_attacks_on_Indian_site= s/articleshow/3010288.cms