Re: Recovery Question.

Hi

Yes backup there redo logs is nice but when opening with reset loges they are not used !

Gram/

On Wed, 26 Jul 2023 at 00.22, Mark W. Farnham <mwf_at_rsiz.com> wrote:

> Don’t forget the online redo logs. The first step of recovery is to make a
> safe copy of the ONLINE redo logs. (You can argue til the cows come home
> about whether to back up the online redo any other time (the best candidate
> being a full cold backup), but every time before you do RECOVER, get a copy
> of the online logs.
>
>
>
> mwf
>
>
>
> *From:* oracle-l-bounce_at_freelists.org [mailto:
> oracle-l-bounce_at_freelists.org] *On Behalf Of *Peter Gram
> *Sent:* Tuesday, July 25, 2023 5:35 PM
> *To:* Niklas Iveslatt
> *Cc:* oracle-l_at_freelists.org; satalabaha.oracle_at_gmail.com
> *Subject:* Re: Recovery Question.
>
>
>
> Hi
>
>
>
> Before you set any off this type of underscore parameters please make a
> full backup or if that is not possible take offline backup of the control
> files, system and undo datafiles since you only have one try with this type
> off unsupported parameters !
>
>
>
> Gram/
>
>
>
> On Tue, 25 Jul 2023 at 16.54, Niklas Iveslatt <niklas.iveslatt_at_arisant.com>
> wrote:
>
> You can set:
>
>
>
> _allow_resetlogs_corruption=true
>
> undo_management=manual
>
>
>
> and then startup force
>
>
>
> But you should do this on a copy of that database (or do a full cold
> backup) - once you open the database with that option it is irreversible so
> you want to preserve what you have while you work with Oracle support. If
> it opens and sort of functions try to do a full export and hope you can get
> as much as possible and then create a new database and do import. No
> guarantees here and this is at your own risk.
>
>
>
> Good luck!
>
>
>
> Niklas Iveslatt
> Senior Partner
>
>
>
> Arisant LLC ~ http://www.arisant.com
> 44 Inverness Dr. E Bldg. C Suite 2 ~ Englewood, CO 80112
> <https://www.google.com/maps/search/44+Inverness+Dr.+E+Bldg.+C+Suite+2+~+Englewood,+CO+80112?entry=gmail&source=g>
> mobile: 303.882.4461 ~ main: 303.330.4065 ~ fax: 888.889.0155
>
> Need to send me something securely? *Click here*
> <https://arisant.sendsafely.com/u/niklas.iveslatt>
>
>
>
>
>
> On Tue, Jul 25, 2023 at 8:27 AM Peter Gram <peter.m.gram_at_gmail.com> wrote:
>
> Hi
>
>
>
> You need to open at SR with Oracle support to get the underscore parameter
> to set before it is possible to open a database with inconsistent data
> files.
>
>
>
> Gram/
>
>
>
> On Tue, 25 Jul 2023 at 05.08, Satalabaha Oracle <
> satalabaha.oracle_at_gmail.com> wrote:
>
> Hi All,
>
>
>
>
>
> I have an Oracle recovery related question..
>
>
>
> Environment: Oracle 12.1 running on RHEL 7.
>
>
>
> We performed incomplete recovery for a set of datafiles (646 datafiles) as
> we lost the mount point that had those datafiles. After the recovery, below
> is the status of checkpoint for both datafile header and checkpoint
> information in controlfile. If we notice the checkpoint_change# for all the
> datafiles are in consistent state and checkpoint_change_change# of datafile
> header matches with the controlfile too. But Oracle was not allowing to
> open the database [1] using resetlogs as the SYSTEM datafile requires more
> recovery.
>
>
>
> Q1) Why would Oracle still report FUZZINESS for the rest of the 2635 odd
> datafiles?
>
> Q2) What other conditions should be met before we can make sure that the
> database can be opened?
>
>
>
> [1]
>
> ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error
> below
> ORA-01196: file 1 is inconsistent due to a failed media recovery session
> ORA-01110: data file 1: '/u01/xxxx/xxxxx/xxxxx_system01.dbf'
>
>
>
> Details:
>
> ============
>
>
>
> SQL> ALTER SESSION SET NLS_DATE_FORMAT='DD-MON-RR HH24:MI:SS';
>
> Session altered.
>
> SQL> select checkpoint_change#,checkpoint_time,fuzzy,count(1) from
> v$datafile_header group by checkpoint_change#,fuzzy,checkpoint_time;
>
> CHECKPOINT_CHANGE# CHECKPOINT_TIME FUZZY COUNT(1)
> -------------------- --------------------------- ---------
> --------------------
> 48336396202 28-JAN-23 11:02:52 NO 2
> 78233391650 23-JUL-23 08:57:11 NO 646
> 78233391650 23-JUL-23 08:57:11 YES 2635
>
> SQL> select checkpoint_change#,checkpoint_time,count(1) from v$datafile
> group by checkpoint_change#,checkpoint_time;
>
> CHECKPOINT_CHANGE# CHECKPOINT_TIME COUNT(1)
> -------------------- --------------------------- --------------------
> 48336396202 28-JAN-23 11:02:52 2
> 78233391650 23-JUL-23 08:57:11 3281
>
>
>
>
>
> --
>
> Thanks,
>
> Satalabaha
>
> --
>
> Best regards/Venlig hilsen
>
> Peter Gram
> Sæbyholmsvej 18 DK-2500 Valby
> <https://www.google.com/maps/search/S%C3%A6byholmsvej+18+DK-2500+Valby?entry=gmail&source=g>
>
> Mobile: (+45) 5374 7107
>
> Email: peter.m.gram_at_gmail.com
>
>
> <http://oaktable.net/members>
>
> --
>
> Best regards/Venlig hilsen
>
> Peter Gram
> Sæbyholmsvej 18 DK-2500 Valby
> <https://www.google.com/maps/search/S%C3%A6byholmsvej+18+DK-2500+Valby?entry=gmail&source=g>
>
> Mobile: (+45) 5374 7107
>
> Email: peter.m.gram_at_gmail.com
>
>
> <http://oaktable.net/members>
>

-- 
Best regards/Venlig hilsen

Peter Gram
Sæbyholmsvej 18 DK-2500 Valby

Mobile: (+45) 5374 7107
Email: peter.m.gram_at_gmail.com

<http://oaktable.net/members>

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