Database recovery in Inconsistent mode

Hi,
We have mirroring at 24:00 on one of the mount point in Solaris which copy all oracle datafiles,redo files and control files and create a replica of all these files in a separate folder. But my database is running in NOARCHIVELOG mode.I am assuming it would be an inconsistent backup.
I am wondering if in case of any failure can we recover with these replica files created on 24:00.
My query is if the database is in NOARCHIVELOG mode, Can we use the command "recover database until time" and recover database till 23:55.
Thanks,
Vaibhav

user10624526 wrote:
Hi,
We have mirroring at 24:00 on one of the mount point in Solaris which copy all oracle datafiles,redo files and control files and create a replica of all these files in a separate folder. But my database is running in NOARCHIVELOG mode.I am assuming it would be an inconsistent backup.
I am wondering if in case of any failure can we recover with these replica files created on 24:00.
My query is if the database is in NOARCHIVELOG mode, Can we use the command "recover database until time" and recover database till 23:55.
Thanks,
Vaibhavno & no
For you to obtain a consistent backup, the DB must first be cleanly shutdown.
Consider changing into ARCHIVE MODE

Similar Messages

Database Recovery in NOARCHIVELOG Mode

Hi All,
I was trying to 'startup' my database & encountered the following error in the alert.log
ORA-01242: data file suffered media failure: database in NOARCHIVELOG mode
ORA-01122: database file 469 failed verification check
ORA-01110: data file 469: '/ora/ctcm_uat02/CMOLP1/undo/CMOLP1_undots_30.dbf'
ORA-01209: data file is from before the last RESETLOGS
I then looked up on the internet and since the error was related to the UNDO TABLESPACE, i did the following:
sql>startup mount
sql>alter database datafile '/ora/ctcm_uat02/CMOLP1/undo/CMOLP1_undots_30.dbf' offline drop;
sql>alter database open
Thereafter the database kept on erroring on all the datafiles belonging to the undo tablespaces and i dropped all the datafiles belonging to the undo tablespace using the above command. (alter database datafile ....offline drop).
Next, i tried to open the database and got the following error from the alert log:
Tue May 12 18:15:24 2009
alter database open
Tue May 12 18:15:33 2009
Beginning crash recovery of 1 threads
Tue May 12 18:15:33 2009
Started redo scan
Tue May 12 18:15:33 2009
Completed redo scan
21 redo blocks read, 3 data blocks need recovery
Tue May 12 18:15:33 2009
Started recovery at
Thread 1: logseq 252, block 2, scn 1917.14626262
Tue May 12 18:15:33 2009
Recovery of Online Redo Log: Thread 1 Group 3 Seq 252 Reading mem 0
Mem# 0 errs 0: /ora/ctcm_dev/CMOLP1/redo/CMOLP1_redo03a.dbf
Tue May 12 18:15:33 2009
Completed redo application
Tue May 12 18:15:33 2009
Ended recovery at
Thread 1: logseq 252, block 23, scn 1917.14646284
3 data blocks read, 3 data blocks written, 21 redo blocks read
Crash recovery completed successfully
Tue May 12 18:15:35 2009
Thread 1 advanced to log sequence 253
Thread 1 opened at log sequence 253
Current log# 4 seq# 253 mem# 0: /ora/ctcm_dev/CMOLP1/redo/CMOLP1_redo04a.dbf
Successful open of redo thread 1
Tue May 12 18:15:38 2009
LOG_CHECKPOINT_INTERVAL was set when MTTR advisory was switched on.
Tue May 12 18:15:38 2009
SMON: enabling cache recovery
Tue May 12 18:15:38 2009
Successfully onlined Undo Tablespace 1.
Tue May 12 18:15:39 2009
SMON: enabling tx recovery
Tue May 12 18:15:39 2009
Database Characterset is US7ASCII
Tue May 12 18:15:39 2009
SMON: about to recover undo segment 1
Can someone please help me on this issue? Thanks and Regards

Hi ERROR,
I think i figured out the hidden parameter that you were referring to.
(1) I set the allowresetlogs_corruption=TRUE and commented undo_management. Then opened the database using--> alter database open resetlogs;
But still was not able to start the database. The alert log entries are as below:
ALTER DATABASE MOUNT
Thu May 14 18:11:56 2009
Successful mount of redo thread 1, with mount id 4113112614
Thu May 14 18:11:56 2009
Database mounted in Exclusive Mode.
Completed: ALTER DATABASE MOUNT
Shutting down instance: further logons disabled
Shutting down instance (immediate)
License high water mark = 2
Thu May 14 18:12:05 2009
ALTER DATABASE CLOSE NORMAL
ORA-1109 signalled during: ALTER DATABASE CLOSE NORMAL...
Thu May 14 18:12:05 2009
ALTER DATABASE DISMOUNT
Completed: ALTER DATABASE DISMOUNT
ARCH: Archiving is disabled
Shutting down archive processes
Archiving is disabled
Archive process shutdown avoided: 0 active
ARCH: Archiving is disabled
Would be great if you can help me further on this.
Regards,
Fuzzy

Oracle recovery in noarchivelog mode

Hello,
SAP Release : ECC6
Oracle 10G
Solaris 10g
Our SAP system is in noarchivelog mode (formation environnement, with frequent client copies).
We frequently perform an offline backup.
The solaris server that is hosting our Sap system, has been brutally shutdown this morning,
due to a network issue.
Afterwards, we had to restart the sap system.
A fisrt error occured ; inconsistency between the control files ...
ORA-00205: error in identifying control file, check alert log for more info
In alert log :
ORA-00202: control file: '/oracle/ZMA/origlogA/cntrl/cntlrZMA.dbf'
ORA-27037: unable to obtain file status
We regenerated a new control file and replaced it.
The error was solved.
Then a second error occured :
SQL> startup
ORACLE instance started.
Total System Global Area 1660944384 bytes
Fixed Size                  2268216 bytes
Variable Size             851207112 bytes
Database Buffers          805306368 bytes
Redo Buffers                2162688 bytes
Database mounted.
ORA-01589: must use RESETLOGS or NORESETLOGS option for database open
SQL> alter database open resetlogs ;
alter database open resetlogs
ERROR at line 1:
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: '/oracle/ZMA/sapdata1/system_1/system.data1'
SQL> recover database using backup controlfile until cancel ;
ORA-00279: change 647063400 generated at 04/28/2008 11:10:01 needed for thread
1
ORA-00289: suggestion : /oracle/ZMA/oraarch/ZMAarch1_76005_618576658.dbf
ORA-00280: change 647063400 for thread 1 is in sequence #76005
The redo log #76005 is no more available; I tried to apply the online redo logs, but it didn't help.
We had to restore the whole database from the offline backup.
1/ I still have problems understanding why Oracle is asking for a recovery, when we tried to reopen the database ? The database was consistent this morning, how is it that the file '/oracle/ZMA/sapdata1/system_1/system.data1' became inconsistent ?
2/ In sap note 863417 "If the database operates in NOARCHIVELOG mode, the database can ONLY be completely recovered from instance failure but not from media failure. "
What is exactly the difference between media failure and instance failure ?
Does a network problem and then a reboot of the host is considered a media failure ?
Best Regards.
thank you for your help .

> 1/ I still have problems understanding why Oracle is asking for a recovery, when we tried to reopen the database ? The database was consistent this morning, how is it that the file '/oracle/ZMA/sapdata1/system_1/system.data1' became inconsistent ?
Because the database was not shut down cleanly. An open database is by definition "inconsistent" without the proper logfiles.
> 2/ In sap note 863417 "If the database operates in NOARCHIVELOG mode, the database can ONLY be completely recovered from instance failure but not from media failure. "
> What is exactly the difference between media failure and instance failure ?
Media = File/Raw-Device. If you database is crashing due to a software error it can be recovered, if a file is corrupt it can't be (since you have no redo logs).
> Does a network problem and then a reboot of the host is considered a media failure ?
A corrupt control file (e. g.) is a media failure.
Markus

Recovery in noarchive mode

My oracle database 11g running in no archive mode, Accidently some of the user datafiles move to some other location
and them move back to same location with os command while database running in open mode , at that point in time redo log files changing frequently , Currently database is in open mode and can not be shutdown because of those files which have different version than other file and controlfile ,No backup is available , Is there any way to recover these files
Regards
obaid

Hi,
(1) As db is in no archive mode so you wont be able to apply redo and do recovery.since redo log file gets written in cyclic order after each switch log.
(2) now replaced files are inconsistent with other files and recovery is not possible to make files consistent.
i guess u r db corrupt. take help of oracle support OR
Now one way u can offline replaced files using following command and keep running the database for other schema which are working file.
alter database datafile 'location' offline ;
Edited by: Rajesh.Rathod on Oct 3, 2012 5:20 AM
Edited by: Rajesh.Rathod on Oct 3, 2012 5:38 AM

Switching database to archive log mode

1.When I switch the database to archive log mode,
I have to do full offline(consistent) backup.
2.When the database is working in archive log mode
I can do inconsistent(online) backups.
Why is there consistent backup needed after swiching
to archive log mode, is there not inconsistent backup
enough after switching (the databease operates
in archive log mode and as in point 2 I can make inconsistent backups).

Hello,
Oracle recommands to do offline backup after switching to archivelog as an immediate crash-recovery procedure. Look at the following example:
1/ You switch your base to archivelog.
2/ Work is started right away.
3/ Your DB crashes => You got your archived redo logs, but none of the other files.
Now, let's put a
1b/ Backup (offline) your database.
Now, in 3, youg got everything you need to restore the base, because 3 can happen WHILE your are ONLINE Backing up the base.
That's the point.
Regards,
Yoann.

Database Started In Restricted Mode...

Dear Exports,
We are using Oracle 10gR2 on Windows server 2008. My database size is approximately 2tb. Now we are going to setup Dataguard for our primary. We started the database with the changer parameters for dataguard and create spfile from pfile. And started the database with Spfile. But after some time i noticed that the database started automatically in Restricted mode. As in our database Previously dataguard was configured, due to the some problem that setup is not working and the logs are not applied in Standby server. I thought may be for this reason database going to restricted mode automatically so i set the log_archive_dest_state_2='DEFFER' and Now I scanned the whore alert.log file and found the same situation of restricted is happening from Jan 2010. Please Suggest some solution how i can over come the problem.
The alertlog when i started the database recently...
ALTER DATABASE CLOSE NORMAL
ORA-1507 signalled during: ALTER DATABASE CLOSE NORMAL...
ARCH: Archival disabled due to shutdown: 1089
Shutting down archive processes
Archiving is disabled
Archive process shutdown avoided: 0 active
ARCH: Archival disabled due to shutdown: 1089
Shutting down archive processes
Archiving is disabled
Archive process shutdown avoided: 0 active
Fri Apr 12 19:12:39 2013
Starting ORACLE instance (normal)
LICENSE_MAX_SESSION = 0
LICENSE_SESSIONS_WARNING = 0
Picked latch-free SCN scheme 3
Autotune of undo retention is turned on.
IMODE=BR
ILAT =97
LICENSE_MAX_USERS = 0
SYS auditing is disabled
ksdpec: called for event 13740 prior to event group initialization
Starting up ORACLE RDBMS Version: 10.2.0.4.0.
System parameters with non-default values:
processes = 800
sessions = 885
sga_max_size = 10737418240
__shared_pool_size = 1325400064
__large_pool_size = 16777216
__java_pool_size = 16777216
__streams_pool_size = 0
sga_target = 8589934592
control_files = G:\ORADATA\CONTROL01.CTL, G:\ORADATA\CONTROL02.CTL, G:\ORADATA\CONTROL03.CTL
db_block_size = 8192
__db_cache_size = 7214202880
compatible = 10.2.0.3.0
log_archive_config = DG_CONFIG=(orcl,stdby)
log_archive_dest_1 = LOCATION=I:\archive_log VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=orcl
log_archive_dest_2 = SERVICE=stdby NOAFFIRM ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=stdby
log_archive_dest_state_1 = enable
log_archive_max_processes= 30
log_archive_format = ARC%D_%s_%R.%T
fal_client = orcl
fal_server = stdby
db_file_multiblock_read_count= 16
db_recovery_file_dest = D:\oracle\product\10.2.0\flash_recovery_area
db_recovery_file_dest_size= 2147483648
standby_file_management = AUTO
undo_management = AUTO
undo_tablespace = UNDOTBS1
undo_retention = 5400
remote_login_passwordfile= EXCLUSIVE
db_domain =
dispatchers = (PROTOCOL=TCP) (SERVICE=orclXDB)
local_listener = (ADDRESS=(PROTOCOL=TCP)(HOST=192.168.12.86)(PORT=1521))
job_queue_processes = 10
audit_file_dest = D:\ORACLE\PRODUCT\10.2.0\ADMIN\ORCL\ADUMP
background_dump_dest = D:\ORACLE\PRODUCT\10.2.0\ADMIN\ORCL\BDUMP
user_dump_dest = D:\ORACLE\PRODUCT\10.2.0\ADMIN\ORCL\UDUMP
core_dump_dest = D:\ORACLE\PRODUCT\10.2.0\ADMIN\ORCL\CDUMP
db_name = orcl
open_cursors = 500
pga_aggregate_target = 10737418240
PMON started with pid=2, OS id=14328
PSP0 started with pid=3, OS id=15420
MMAN started with pid=4, OS id=9092
DBW0 started with pid=5, OS id=12360
DBW1 started with pid=6, OS id=18112
LGWR started with pid=7, OS id=18360
CKPT started with pid=8, OS id=18448
SMON started with pid=9, OS id=17160
RECO started with pid=10, OS id=18512
CJQ0 started with pid=11, OS id=19324
MMON started with pid=12, OS id=14380
Fri Apr 12 19:12:40 2013
starting up 1 dispatcher(s) for network address '(ADDRESS=(PARTIAL=YES)(PROTOCOL=TCP))'...
MMNL started with pid=13, OS id=2996
Fri Apr 12 19:12:40 2013
starting up 1 shared server(s) ...
Fri Apr 12 19:12:41 2013
ALTER DATABASE MOUNT
Fri Apr 12 19:12:45 2013
Setting recovery target incarnation to 2
Fri Apr 12 19:12:45 2013
Successful mount of redo thread 1, with mount id 1340307369
Fri Apr 12 19:12:45 2013
Allocated 15937344 bytes in shared pool for flashback generation buffer
Starting background process RVWR
RVWR started with pid=17, OS id=5524
Fri Apr 12 19:12:45 2013
Database mounted in Exclusive Mode
Completed: ALTER DATABASE MOUNT
Fri Apr 12 19:12:46 2013
ALTER DATABASE OPEN
Fri Apr 12 19:12:46 2013
LGWR: STARTING ARCH PROCESSES
ARC0 started with pid=18, OS id=11964
ARC1 started with pid=19, OS id=13472
ARC2 started with pid=20, OS id=17960
ARC3 started with pid=21, OS id=18548
ARC4 started with pid=22, OS id=15660
ARC5 started with pid=23, OS id=15548
ARC6 started with pid=24, OS id=14720
ARC7 started with pid=25, OS id=15780
ARC8 started with pid=26, OS id=17992
ARC9 started with pid=27, OS id=17988
ARCa started with pid=28, OS id=19436
ARCb started with pid=29, OS id=16104
ARCc started with pid=30, OS id=6656
ARCd started with pid=31, OS id=6900
ARCe started with pid=32, OS id=10568
ARCf started with pid=33, OS id=16992
ARCg started with pid=34, OS id=14372
ARCh started with pid=35, OS id=18084
ARCi started with pid=36, OS id=5788
ARCj started with pid=37, OS id=4940
ARCk started with pid=38, OS id=18816
ARCl started with pid=39, OS id=14588
ARCm started with pid=40, OS id=16820
ARCn started with pid=41, OS id=8068
ARCo started with pid=42, OS id=18736
ARCp started with pid=43, OS id=8316
ARCq started with pid=44, OS id=5952
ARCr started with pid=45, OS id=16304
ARCs started with pid=46, OS id=14884
Fri Apr 12 19:12:46 2013
ARC0: Archival started
ARCt started with pid=47, OS id=19408
Fri Apr 12 19:12:46 2013
ARC1: Archival started
ARC2: Archival started
ARC3: Archival started
ARC4: Archival started
ARC5: Archival started
ARC6: Archival started
ARC7: Archival started
ARC8: Archival started
ARC9: Archival started
ARCa: Archival started
ARCb: Archival started
ARCc: Archival started
ARCd: Archival started
ARCe: Archival started
ARCf: Archival started
ARCg: Archival started
ARCh: Archival started
ARCi: Archival started
ARCj: Archival started
ARCk: Archival started
ARCl: Archival started
ARCm: Archival started
ARCn: Archival started
ARCo: Archival started
ARCp: Archival started
ARCq: Archival started
ARCr: Archival started
ARCs: Archival started
ARCt: Archival started
LGWR: STARTING ARCH PROCESSES COMPLETE
Thread 1 opened at log sequence 117446
Current log# 10 seq# 117446 mem# 0: G:\ORADATA\REDO10A.LOG
Current log# 10 seq# 117446 mem# 1: H:\ORADATA\REDO10B.LOG
Fri Apr 12 19:12:46 2013
ARC0: Becoming the 'no FAL' ARCH
Fri Apr 12 19:12:46 2013
ARC0: Becoming the 'no SRL' ARCH
Fri Apr 12 19:12:46 2013
ARC8: Becoming the heartbeat ARCH
Fri Apr 12 19:12:47 2013
Successful open of redo thread 1
Fri Apr 12 19:12:47 2013
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
Fri Apr 12 19:12:47 2013
SMON: enabling cache recovery
Fri Apr 12 19:12:48 2013
Successfully onlined Undo Tablespace 1.
Fri Apr 12 19:12:48 2013
SMON: enabling tx recovery
Fri Apr 12 19:12:48 2013
Database Characterset is WE8MSWIN1252
Opening with internal Resource Manager plan
where NUMA PG = 1, CPUs = 16
replication_dependency_tracking turned off (no async multimaster replication found)
Starting background process QMNC
QMNC started with pid=48, OS id=10048
Fri Apr 12 19:12:51 2013
Completed: ALTER DATABASE OPEN
Fri Apr 12 19:12:51 2013
Errors in file d:\oracle\product\10.2.0\admin\orcl\bdump\orcl_mmon_14380.trc:
ORA-19815: WARNING: db_recovery_file_dest_size of 2147483648 bytes is 99.56% used, and has 9486336 remaining bytes available.
Fri Apr 12 19:12:51 2013
You have following choices to free up space from flash recovery area:
1. Consider changing RMAN RETENTION POLICY. If you are using Data Guard,
then consider changing RMAN ARCHIVELOG DELETION POLICY.
2. Back up files to tertiary device such as tape using RMAN
BACKUP RECOVERY AREA command.
3. Add disk space and increase db_recovery_file_dest_size parameter to
reflect the new space.
4. Delete unnecessary files using RMAN DELETE command. If an operating
system command was used to delete files, then use RMAN CROSSCHECK and
DELETE EXPIRED commands.
Dump file d:\oracle\product\10.2.0\admin\orcl\bdump\alert_orcl.log
Fri Apr 12 19:13:26 2013
ORACLE V10.2.0.4.0 - 64bit Production vsnsta=0
vsnsql=14 vsnxtr=3
Windows NT Version V6.0 Service Pack 1
CPU : 16 - type 8664, 16 Physical Cores
Process Affinity : 0x0000000000000000
Memory (Avail/Total): Ph:55999M/65533M, Ph+PgF:183151M/193356M
Fri Apr 12 19:13:26 2013
Starting ORACLE instance (restrict)
LICENSE_MAX_SESSION = 0
LICENSE_SESSIONS_WARNING = 0
Picked latch-free SCN scheme 3
Autotune of undo retention is turned on.
IMODE=BR
ILAT =97
LICENSE_MAX_USERS = 0
SYS auditing is disabled
ksdpec: called for event 13740 prior to event group initialization
Starting up ORACLE RDBMS Version: 10.2.0.4.0.
System parameters with non-default values:
processes = 800
sessions = 885
sga_max_size = 10737418240
__shared_pool_size = 1325400064
__large_pool_size = 16777216
__java_pool_size = 16777216
__streams_pool_size = 0
sga_target = 8589934592
control_files = G:\ORADATA\CONTROL01.CTL, G:\ORADATA\CONTROL02.CTL, G:\ORADATA\CONTROL03.CTL
db_block_size = 8192
__db_cache_size = 7214202880
compatible = 10.2.0.3.0
log_archive_config = DG_CONFIG=(orcl,stdby)
log_archive_dest_1 = LOCATION=I:\archive_log VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=orcl
log_archive_dest_2 = SERVICE=stdby NOAFFIRM ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=stdby
log_archive_dest_state_1 = enable
log_archive_max_processes= 30
log_archive_format = ARC%D_%s_%R.%T
fal_client = orcl
fal_server = stdby
db_file_multiblock_read_count= 16
db_recovery_file_dest = D:\oracle\product\10.2.0\flash_recovery_area
db_recovery_file_dest_size= 2147483648
standby_file_management = AUTO
undo_management = AUTO
undo_tablespace = UNDOTBS1
undo_retention = 5400
remote_login_passwordfile= EXCLUSIVE
db_domain =
dispatchers = (PROTOCOL=TCP) (SERVICE=orclXDB)
local_listener = (ADDRESS=(PROTOCOL=TCP)(HOST=192.168.12.86)(PORT=1521))
job_queue_processes = 10
audit_file_dest = D:\ORACLE\PRODUCT\10.2.0\ADMIN\ORCL\ADUMP
background_dump_dest = D:\ORACLE\PRODUCT\10.2.0\ADMIN\ORCL\BDUMP
user_dump_dest = D:\ORACLE\PRODUCT\10.2.0\ADMIN\ORCL\UDUMP
core_dump_dest = D:\ORACLE\PRODUCT\10.2.0\ADMIN\ORCL\CDUMP
db_name = orcl
open_cursors = 500
pga_aggregate_target = 10737418240
PMON started with pid=2, OS id=18668
PSP0 started with pid=3, OS id=17668
MMAN started with pid=4, OS id=16896
DBW0 started with pid=5, OS id=18204
DBW1 started with pid=6, OS id=16976
LGWR started with pid=7, OS id=14552
CKPT started with pid=8, OS id=4480
SMON started with pid=9, OS id=10236
RECO started with pid=10, OS id=11832
CJQ0 started with pid=11, OS id=18844
MMON started with pid=12, OS id=15320
Fri Apr 12 19:13:27 2013
starting up 1 dispatcher(s) for network address '(ADDRESS=(PARTIAL=YES)(PROTOCOL=TCP))'...
MMNL started with pid=13, OS id=14944
Fri Apr 12 19:13:27 2013
starting up 1 shared server(s) ...
Fri Apr 12 19:13:27 2013
alter database orcl mount exclusive
Fri Apr 12 19:13:31 2013
Setting recovery target incarnation to 2
Fri Apr 12 19:13:31 2013
Successful mount of redo thread 1, with mount id 1340305111
Fri Apr 12 19:13:31 2013
Allocated 15937344 bytes in shared pool for flashback generation buffer
Starting background process RVWR
RVWR started with pid=17, OS id=12880
Fri Apr 12 19:13:31 2013
Database mounted in Exclusive Mode
Completed: alter database orcl mount exclusive
Fri Apr 12 19:13:31 2013
alter database open
Fri Apr 12 19:13:31 2013
Beginning crash recovery of 1 threads
parallel recovery started with 15 processes
Fri Apr 12 19:13:31 2013
Started redo scan
Fri Apr 12 19:13:31 2013
Completed redo scan
735 redo blocks read, 211 data blocks need recovery
Fri Apr 12 19:13:31 2013
Started redo application at
Thread 1: logseq 117446, block 97761
Fri Apr 12 19:13:31 2013
Recovery of Online Redo Log: Thread 1 Group 10 Seq 117446 Reading mem 0
Mem# 0: G:\ORADATA\REDO10A.LOG
Mem# 1: H:\ORADATA\REDO10B.LOG
Fri Apr 12 19:13:31 2013
Completed redo application
Fri Apr 12 19:13:32 2013
Completed crash recovery at
Thread 1: logseq 117446, block 98496, scn 7310601900
211 data blocks read, 211 data blocks written, 735 redo blocks read
Fri Apr 12 19:13:33 2013
LGWR: STARTING ARCH PROCESSES
ARC0 started with pid=33, OS id=18508
ARC1 started with pid=34, OS id=14692
ARC2 started with pid=35, OS id=17728
ARC3 started with pid=36, OS id=12476
ARC4 started with pid=37, OS id=19228
ARC5 started with pid=38, OS id=11552
ARC6 started with pid=39, OS id=7576
ARC7 started with pid=40, OS id=6244
ARC8 started with pid=41, OS id=18468
ARC9 started with pid=42, OS id=18492
ARCa started with pid=43, OS id=10352
ARCb started with pid=44, OS id=15516
ARCc started with pid=45, OS id=18216
ARCd started with pid=46, OS id=5660
ARCe started with pid=47, OS id=18756
ARCf started with pid=48, OS id=17828
ARCg started with pid=49, OS id=8696
ARCh started with pid=50, OS id=17736
ARCi started with pid=51, OS id=16736
ARCj started with pid=52, OS id=13208
ARCk started with pid=53, OS id=12012
ARCl started with pid=54, OS id=19180
ARCm started with pid=55, OS id=16632
ARCn started with pid=56, OS id=17588
ARCo started with pid=57, OS id=11948
ARCp started with pid=58, OS id=18416
ARCq started with pid=59, OS id=17888
ARCr started with pid=60, OS id=2144
ARCs started with pid=61, OS id=14392
Fri Apr 12 19:13:33 2013
ARC0: Archival started
ARCt started with pid=62, OS id=19264
Fri Apr 12 19:13:33 2013
ARC1: Archival started
ARC2: Archival started
ARC3: Archival started
ARC4: Archival started
ARC5: Archival started
ARC6: Archival started
ARC7: Archival started
ARC8: Archival started
ARC9: Archival started
ARCa: Archival started
ARCb: Archival started
ARCc: Archival started
ARCd: Archival started
ARCe: Archival started
ARCf: Archival started
ARCg: Archival started
ARCh: Archival started
ARCi: Archival started
ARCj: Archival started
ARCk: Archival started
ARCl: Archival started
ARCm: Archival started
ARCn: Archival started
ARCo: Archival started
ARCp: Archival started
ARCq: Archival started
ARCr: Archival started
ARCs: Archival started
ARCt: Archival started
LGWR: STARTING ARCH PROCESSES COMPLETE
Fri Apr 12 19:13:33 2013
Thread 1 advanced to log sequence 117447 (thread open)
Thread 1 opened at log sequence 117447
Current log# 8 seq# 117447 mem# 0: G:\ORADATA\REDO08A.LOG
Current log# 8 seq# 117447 mem# 1: H:\ORADATA\REDO08B.LOG
Successful open of redo thread 1
Fri Apr 12 19:13:33 2013
ARC3: Becoming the 'no FAL' ARCH
Fri Apr 12 19:13:33 2013
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
Fri Apr 12 19:13:33 2013
ARC3: Becoming the 'no SRL' ARCH
Fri Apr 12 19:13:33 2013
ARCr: Becoming the heartbeat ARCH
Fri Apr 12 19:13:33 2013
SMON: enabling cache recovery
Fri Apr 12 19:13:33 2013
Successfully onlined Undo Tablespace 1.
Fri Apr 12 19:13:33 2013
SMON: enabling tx recovery
Fri Apr 12 19:13:33 2013
Database Characterset is WE8MSWIN1252
Opening with internal Resource Manager plan
where NUMA PG = 1, CPUs = 16
replication_dependency_tracking turned off (no async multimaster replication found)
Starting background process QMNC
QMNC started with pid=63, OS id=14896
Fri Apr 12 19:13:34 2013
Completed: alter database open
Fri Apr 12 19:13:34 2013
ALTER SYSTEM disable restricted session;
Fri Apr 12 19:13:35 2013
Errors in file d:\oracle\product\10.2.0\admin\orcl\bdump\orcl_mmon_15320.trc:
ORA-19815: WARNING: db_recovery_file_dest_size of 2147483648 bytes is 99.56% used, and has 9486336 remaining bytes available.
Fri Apr 12 19:13:35 2013
You have following choices to free up space from flash recovery area:
1. Consider changing RMAN RETENTION POLICY. If you are using Data Guard,
then consider changing RMAN ARCHIVELOG DELETION POLICY.
2. Back up files to tertiary device such as tape using RMAN
BACKUP RECOVERY AREA command.
3. Add disk space and increase db_recovery_file_dest_size parameter to
reflect the new space.
4. Delete unnecessary files using RMAN DELETE command. If an operating
system command was used to delete files, then use RMAN CROSSCHECK and
DELETE EXPIRED commands.
Fri Apr 12 19:13:36 2013
Error 12514 received logging on to the standby
Fri Apr 12 19:13:36 2013
Errors in file d:\oracle\product\10.2.0\admin\orcl\bdump\orcl_arc0_18508.trc:
ORA-12514: TNS:listener does not currently know of service requested in connect descriptor
FAL[server, ARC0]: Error 12514 creating remote archivelog file 'stdby'
FAL[server, ARC0]: FAL archive failed, see trace file.
Fri Apr 12 19:13:36 2013
Errors in file d:\oracle\product\10.2.0\admin\orcl\bdump\orcl_arc0_18508.trc:
ORA-16055: FAL request rejected
ARCH: FAL archive failed. Archiver continuing
Fri Apr 12 19:19:33 2013
Error 12514 received logging on to the standby
Fri Apr 12 19:19:33 2013
Errors in file d:\oracle\product\10.2.0\admin\orcl\bdump\orcl_arcr_2144.trc:
ORA-12514: TNS:listener does not currently know of service requested in connect descriptor
PING[ARCr]: Heartbeat failed to connect to standby 'stdby'. Error is 12514.
Fri Apr 12 19:22:52 2013
PING[ARCr]: Heartbeat failed to connect to standby 'stdby'. Error is 12514.
Fri Apr 12 20:09:34 2013
Error 12514 received logging on to the standby
Fri Apr 12 20:09:34 2013
Errors in file d:\oracle\product\10.2.0\admin\orcl\bdump\orcl_arcr_2144.trc:
ORA-12514: TNS:listener does not currently know of service requested in connect descriptor
PING[ARCr]: Heartbeat failed to connect to standby 'stdby'. Error is 12514.
Fri Apr 12 20:13:50 2013
Sat Apr 13 01:54:52 2013
Error 12514 received logging on to the standby
Sat Apr 13 01:54:52 2013
Errors in file d:\oracle\product\10.2.0\admin\orcl\bdump\orcl_arcr_2144.trc:
ORA-12514: TNS:listener does not currently know of service requested in connect descriptor
PING[ARCr]: Heartbeat failed to connect to standby 'stdby'. Error is 12514.
Sat Apr 13 12:35:12 2013
Error 12514 received logging on to the standby
Sat Apr 13 12:35:12 2013
Errors in file d:\oracle\product\10.2.0\admin\orcl\bdump\orcl_arcr_2144.trc:
ORA-12514: TNS:listener does not currently know of service requested in connect descriptor
PING[ARCr]: Heartbeat failed to connect to standby 'stdby'. Error is 12514.
Sat Apr 13 12:37:01 2013
ALTER SYSTEM SET log_archive_dest_state_2='DEFER' SCOPE=MEMORY;
Sat Apr 13 12:38:23 2013
Unable to allocate flashback log of 1946 blocks from
current recovery area of size 2147483648 bytes.
Current Flashback database retention is less than target
because of insufficient space in the flash recovery area.
Flashback will continue to use available space, but the
size of the flash recovery area must be increased to meet
the Flashback database retention target
Use ALTER SYSTEM SET db_recovery_file_dest_size command
to add space. DO NOT manually remove flashback log files
to create space.
Sat Apr 13 12:38:41 2013
ALTER SYSTEM SET db_recovery_file_dest_size='5G' SCOPE=MEMORY;
Sat Apr 13 12:38:41 2013
db_recovery_file_dest_size of 5120 MB is 39.82% used. This is a
user-specified limit on the amount of space that will be used by this
database for recovery-related files, and does not reflect the amount of
space available in the underlying filesystem or ASM diskgroup.
Sat Apr 13 15:42:21 2013
ORA-01555 caused by SQL statement below (SQL ID: 2zb70pwz9p06q, Query Duration=1365847941 sec, SCN: 0x0001.b3c0f735):
Sat Apr 13 15:42:21 2013
SELECT * FROM RELATIONAL("ORISSA_TRANSACTION"."SELLER_BIOMETRICS_TBL")
Sat Apr 13 15:48:37 2013
Thread 1 advanced to log sequence 117452 (LGWR switch)
Current log# 10 seq# 117452 mem# 0: G:\ORADATA\REDO10A.LOG
Current log# 10 seq# 117452 mem# 1: H:\ORADATA\REDO10B.LOG
Sat Apr 13 20:31:00 2013
The value (30) of MAXTRANS parameter ignored.
kupprdp: master process DM00 started with pid=31, OS id=16196
to execute - SYS.KUPM$MCP.MAIN('SYS_EXPORT_SCHEMA_30', 'ORISSA_TRANSACTION', 'KUPC$C_1_20130413203100', 'KUPC$S_1_20130413203100', 0);
kupprdp: worker process DW01 started with worker id=1, pid=66, OS id=16200
to execute - SYS.KUPW$WORKER.MAIN('SYS_EXPORT_SCHEMA_30', 'ORISSA_TRANSACTION');
Sun Apr 14 00:00:11 2013
Thread 1 advanced to log sequence 117453 (LGWR switch)
Current log# 8 seq# 117453 mem# 0: G:\ORADATA\REDO08A.LOG
Current log# 8 seq# 117453 mem# 1: H:\ORADATA\REDO08B.LOG
Sun Apr 14 00:00:52 2013
Thread 1 advanced to log sequence 117454 (LGWR switch)
Current log# 9 seq# 117454 mem# 0: G:\ORADATA\REDO09A.LOG
Current log# 9 seq# 117454 mem# 1: H:\ORADATA\REDO09B.LOG

like you show in the alert.log:
PROBLEM
Unable to allocate flashback log of 1946 blocks from
current recovery area of size 2147483648 bytes.
Current Flashback database retention is less than target
because of insufficient space in the flash recovery area.
Flashback will continue to use available space, but the
size of the flash recovery area must be increased to meet
the Flashback database retention target
Use ALTER SYSTEM SET db_recovery_file_dest_size command
to add space. DO NOT manually remove flashback log files
to create space.
SOLUTION
Fri Apr 12 19:12:51 2013
You have following choices to free up space from flash recovery area:
1. Consider changing RMAN RETENTION POLICY. If you are using Data Guard,
then consider changing RMAN ARCHIVELOG DELETION POLICY.
2. Back up files to tertiary device such as tape using RMAN
BACKUP RECOVERY AREA command.
3. Add disk space and increase db_recovery_file_dest_size parameter to
reflect the new space.
4. Delete unnecessary files using RMAN DELETE command. If an operating
system command was used to delete files, then use RMAN CROSSCHECK and
DELETE EXPIRED commands.
************************************************************************choose one and try again. Post if you have more issues.

Cannot open the database, stuck in mount mode

Someone please shed some lights on this problem.
I ran into some media failure, and ended up restoring the database from the offline whole backup.
The database is in the nonarchivelog mode (I know, it is not good), so there is no archive log files and
restore database is the only solution.
. startup mount
. restore database <== ran ok
. ALTER DATABASE CLEAR LOGFILE GROUP 1 <== ran ok
. ALTER DATABASE CLEAR LOGFILE GROUP 2 <== alter failed
ORA-01624: log 2 needed for crash recovery of instance orcl (thread 1)
Alter failed with group 2 and 3 because one was CURRENT,
and one was ACTIVE.
SQL> select group#, sequence#, members, status from v$log;
GROUP# SEQUENCE# MEMBERS STATUS
1 0 2 UNUSED
3 189 2 CURRENT
2 188 2 ACTIVE
I also tried 'alter database open resetlogs', and got:
ORA-01139: RESETLOGS option only valid after an incomplete database recovery
I don't think I can recover the datafile since there is no archive log file here.
Besides, if the restore database ran fine, why did I get SYSTEM01.DBF datafile needs media recovery message?
Right now, the database is in mount mode, and I cannot open it. How do I solve the problem with
ALTER DATABASE CLEAR LOGFILE GROUP for group 2 and 3?
Any suggestion? Thank you for the input.
The database is 11G running on Window.

I would think the cold backup ran successfully. Here is the backup record:
RMAN> run {
2> shutdown immediate;
3> startup mount;
4> allocate channel c1 type disk;
5> backup as backupset database;
6> alter database open;
7> }
8>
using target database control file instead of recovery catalog
database closed
database dismounted
Oracle instance shut down
connected to target database (not started)
Oracle instance started
database mounted
Total System Global Area 535662592 bytes
Fixed Size 1348508 bytes
Variable Size 331353188 bytes
Database Buffers 197132288 bytes
Redo Buffers 5828608 bytes
allocated channel: c1
channel c1: SID=156 device type=DISK
Starting backup at 29-NOV-09
channel c1: starting full datafile backup set
channel c1: specifying datafile(s) in backup set
input datafile file number=00002 name=C:\APP\DAVECW\ORADATA\ORCL\SYSAUX01.DBF
input datafile file number=00001 name=C:\APP\DAVECW\ORADATA\ORCL\SYSTEM01.DBF
input datafile file number=00003 name=C:\APP\DAVECW\ORADATA\ORCL\UNDOTBS01.DBF
input datafile file number=00005 name=C:\APP\DAVECW\ORADATA\ORCL\EXAMPLE01.DBF
input datafile file number=00006 name=C:\APP\DAVECW\ORADATA\ORCL\INVENTORY01.DBF
input datafile file number=00004 name=C:\APP\DAVECW\ORADATA\ORCL\USERS01.DBF
channel c1: starting piece 1 at 29-NOV-09
channel c1: finished piece 1 at 29-NOV-09
piece handle=C:\APP\DAVECW\FLASH_RECOVERY_AREA\ORCL\BACKUPSET\2009_11_29\O1_MF_NNNDF_TAG20091129T230
632_5K6VQY0W_.BKP tag=TAG20091129T230632 comment=NONE
channel c1: backup set complete, elapsed time: 00:01:55
channel c1: starting full datafile backup set
channel c1: specifying datafile(s) in backup set
including current control file in backup set
including current SPFILE in backup set
channel c1: starting piece 1 at 29-NOV-09
channel c1: finished piece 1 at 29-NOV-09
piece handle=C:\APP\DAVECW\FLASH_RECOVERY_AREA\ORCL\BACKUPSET\2009_11_29\O1_MF_NCSNF_TAG20091129T230
632_5K6VVNJR_.BKP tag=TAG20091129T230632 comment=NONE
channel c1: backup set complete, elapsed time: 00:00:03
Finished backup at 29-NOV-09
database opened
released channel: c1
Recovery Manager complete.

Recovery in NOARCHIVELOG mode. A Sybex Study GUide quibble

Hi.
Actually, this is much more than a quibble as its a crucial point vis a vis the exam.
To perform a recovery in noarchivelog mode, we have to restore the db from the last backup.
I was under the impression that a backup of the database should NOT include the online redo logs.
But, to quote this Sybex book (p291 for Exam 032):
"To perform the database restore, you will need to copy all the data files, online redo logs, and controlfiles from the last backup and perform a full database restore" .
I understand that if we do a closed backup (as we would do if the db is in noarchivelog mode) then the redo logs are not available to be backed up and therefore are not included.
I just need this detail ironed out once and for all!
Thanks.
DA

When you restore the redo log file, you are basically defining the most recent time to which the restore can occur.
In a noarchivelog restore (of a proper clean backup), the most recent possible time is the time when the database was shut down and thus there are no redo entries to roll forward. Therefore, functionally, it really does not matter whether the redo log is restored or not. However, if the redo log file is not restored, you have two situations that must be managed: redo is much newer than the rest of the database, or redo is totally missing. Since you are in learning mode, I'll leave it to you to describe how to handle those two cases.
In an archivelog environment, restoring the redo log will severely limit the ability to restore to point-in-time as you can not move forward from the redo log's time. Therefore the recommendation is to not bother backing up the redo log file at all, so it can not be accidently restore. RMAN enforces this.
Personal 'best practice' is to make a safety copy of the redo log files before any restore. That way if an old set of redo is accidently copied or if the restore/recovery needs to be restarted, the environment can be reset to the start of the restore.

Unable to open database in READ ONLY mode

When trying to open database in READ ONLY MODE it says needs recovery. How ever database opens succesfully in READ WRITE MODE.
1) Startup mount
2) SQL> ALTER DATABASE OPEN READ ONLY;
ALTER DATABASE OPEN READ ONLY
ERROR at line 1:
ORA-16005: database requires recovery
But database opens succesfully when opened in READ WRITE mode.

user12038051 wrote:
When trying to open database in READ ONLY MODE it says needs recovery. How ever database opens succesfully in READ WRITE MODE.
1) Startup mount
2) SQL> ALTER DATABASE OPEN READ ONLY;
ALTER DATABASE OPEN READ ONLY
ERROR at line 1:
ORA-16005: database requires recovery
But database opens succesfully when opened in READ WRITE mode.
sqlplus '/as sysdba'
shutdown imediate;
startup;
shutdown imediate;
startup mount;
recover database;
alter database open read only;

Database recovery (online redolog ?)

hi all,
Been awhile since i touch on oracle db, i have been reading around and the emphasis for recovery is always on the backup and archivelog, but i think its wrong.
can i check ->
q1) for full database recovery, do i need the online redo log as well ?
q2) if the answer to q1) is yes, how do i duplicate online redo log to standby site ? (i don't think rsync will work as it cannot sure consistency in the redolog)
will oracle dataguard sync online redolog as well ?
q3) for archivelog, beside manual rsyncing, LOG_ARCHIVE_DEST_2 = 'SERVICE=standby1'
do i need the enterprise edition for the above ?
Regards,
Alan

q1) For a complete recovery, yes you need online redolog as well. Without online redolog,its still considered incomplete recovery since u lose data resides in online redolog
q2) You no need to synch online redo log manually. Once the backup is restored to the DR dataguard site and MRP process initiated, Oracle will synch online redolog/archivelog automatically based on protection mode specified
q3) Oracle dataguard applies to Enterprise Edition only. Without Enterprise Edition, we can configure log shipping (manual way).
Regards,
Ilan

Full database recovery without redolog availability

Dear DBAs,
I performed full database backup using RMAN in catalog mode, then I physically removed the database, then using parameter file I started the database in nomount mode and recovered the control file using RMAN, after that I altered the database to mount mode and restored all the datafiles, now definetly I can not open the database untill it has not redo logs available in it which I removed early, the resetlogs option is also not working and I am stuck, tell me what I should do, the database is in archivelog mode and all archive files are available.
Kindly help,
Regards,
Asif

It sounds like, after you completed the RMAN backup, you didn't archive the current log file. That means that the last bit of redo you need to get your database consistent is in the online redo that's no longer available. I think you're screwed....
Yes, there are ways to open the database as is, but, before we go there, what situation are you in? Is this a database you need? were you practicing backup and recovery?
If you absolutely need to recover this database, let us know.
Otherwise, I recommend retrying the procedure, and this time, archiving the current log file after the RMAN backup completes, and before removing the online redo. If you do that, and make sure that last bit of redo gets archived, I think the procedure should work.
Hope that helps,
-Mark

Object Level Recovery or Whole Database recovery

I'm hoping someone may know how to advise me on the following;
On a datawarehouse db (10.2.0.1.0) a team member removed records from three tables, and I have since attempted flashback recovery without success. The database is in Archivelog mode, with Flashback enabled, but no Flashback logging enabled. The rows were removed on Friday afternoon (it is now Monday). I attempted to get flashback logging enabled by tagging the "Enable Flashback Database" tag in the Flash Recovery region of Recovery settings, and restarting the database. The database when restarted went into mount state, and subsequently on restarting (from mount - I did not dismount the db), it still has Flashback logging disabled. I attempted flashback again but the team member states the record stil arn't there. EM however had given the message 'The select tables...X X....have been flashed back'. However I can see also that Em says flashback logging is still disabled.
I now consider I might be better off to perform a 'Whole Database Recovery', as I simply want to get the tables recovered. I'm not sure if this will mean re-keying though. Can anyone advise? Thanks in advance. DW
Message was edited by:
David_W

The first step you should try is flashback query. Because using flashback query your database will remain intact, you don't lose anything from your database. Of course most likely it's too late for you now. Just for future reference.
Flashback database is only available after you configured Flash Recovery Area and turn it on. Sound like it's does apply here as well. Remember even you could successful flashback your database to the point before deletion, you will lost all data changes after that point. Flashback database only buy you sometime, because you don't need to restore datafile from backup.
The third option would be restore from your last backup, ( the latest one before deletion happen) and do incomplete restore to the point in time right before the incident.

Error: 1013231 Unable to update database while in readonly mode for backup

Hi all,
Wen im deleting the members for dimendsion , its giving error (hyperion 11.1 aso)
Error: 1013231 Unable to update database while in readonly mode for backup , how can i solve this problem ,plz can any one help on this
Thanks

Has somebody set the database ready for archiving, maybe some maxl has been run and the db has not been returned from read only mode.
Try running the following Maxl (change app.db to match your app/db)
alter database app.db end archive;
Cheers
John
http://john-goodwin.blogspot.com/

Questions About Database Recovery (-30975)

Hello,
In Berkeley 4.5.20, we are seeing the following error sporadically, but more frequently than we'd like (which is, to say, not at all): "BerkeleyDbErrno=-30975 - DbEnv::open: DB_RUNRECOVERY: Fatal error, run database recovery"
This exception is being thrown mostly, if not exclusively, during the environment open call. Still investigating.
I will post my environment below, but first some questions.
1. How often should a database become become corrupt?
2. What are the causes of this corruption? Can they be caused by "chance?" (I.e. app is properly coded.) Can they be caused by improper coding? If so, is there a list of common things to check?
3. Does Oracle expect application developers to create their own recovery handlers, especially for apps that require 100% uptime? E.g. using DB_ENV->set_event_notify or filtering on DB_RUNRECOVERY.
Our environment:
Windows Server 2003 SP2
Berkeley DB 4.5.20
set_verbose(DB_VERB_WAITSFOR, 1);
set_cachesize(0, 65536 * 1024, 1);
set_lg_max(10000000);
set_lk_detect(DB_LOCK_YOUNGEST);
set_timeout(60000000, DB_SET_LOCK_TIMEOUT);
set_timeout(60000000, DB_SET_TXN_TIMEOUT);
set_tx_max(100000);
set_flags(DB_TXN_NOSYNC, 1);
set_flags(DB_LOG_AUTOREMOVE, 1);
set_lk_max_lockers(10000);
set_lk_max_locks(10000);
set_lk_max_objects(10000);
open(sPath, DB_CREATE | DB_INIT_LOCK | DB_INIT_LOG | DB_INIT_MPOOL | DB_THREAD | DB_INIT_TXN | DB_RECOVER, 0);
set_pagesize (4096);
u_int32_t dbOpenFlags = DB_CREATE | DB_AUTO_COMMIT;
pDbPrimary->open(NULL, strFile, NULL, DB_HASH, dbOpenFlags, 0);
We also have a number of secondary databases.
One additional piece of information that might be relevant is that the databases where this happens (we have 8 in total managed by our process,) seem to be the two specific databases that at times aren't opened until well after the process is up and running due to the nature of their data. This is to say that 6 of the other databases are normally opened during startup of our service. We are still investigating this to see if this is consistently true.

Here is the output from the error logs (we didn't have this properly set up until now) when this error opening the environment happens:
12/17/2007 17:18:12 (e64/518) 1024: Berkeley Error: CDbBerkeley MapViewOfFile: Not enough storage is available to process this command.
12/17/2007 17:18:12 (e64/518) 1024: Berkeley Error: CDbBerkeley PANIC: Not enough space
12/17/2007 17:18:12 (e64/518) 1024: Berkeley Error: CDbBerkeley DeleteFile: C:\xxxxxxxx\Database\xxxJOB_OAT\__db.003: Access is denied.
12/17/2007 17:18:12 (e64/518) 1024: Berkeley Error: CDbBerkeley MapViewOfFile: Not enough storage is available to process this command.
12/17/2007 17:18:12 (e64/518) 1024: Berkeley Error: CDbBerkeley PANIC: Not enough space
12/17/2007 17:18:12 (e64/518) 1024: Berkeley Error: CDbBerkeley PANIC: DB_RUNRECOVERY: Fatal error, run database recovery
12/17/2007 17:18:30 (e64/518) 1024: Berkeley Error: CDbBerkeley unable to join the environment
12/17/2007 17:18:30 (e64/518) 1024: Berkeley Error: CDbBerkeley DeleteFile: C:\xxxxxxxx\Database\xxxJOB_OAT\__db.003.del.0547204268: Access is denied.
12/17/2007 17:18:30 (e64/518) 1024: Berkeley Error: CDbBerkeley DeleteFile: C:\xxxxxxxx\Database\xxxJOB_OAT\__db.003: Access is denied.
12/17/2007 17:19:18 (e64/518) 1024: Database EInitialize failed. (C:\xxxxxxxx\Database\xxxJOB_OAT: BerkeleyDbErrno=-30975 - DbEnv::open: DB_RUNRECOVERY: Fatal error, run database recovery)
The last line is generated by a DbException and was all we were seeing up until now.
I also set_verbose(DB_VERB_RECOVERY, 1) and set_msgcall to the same log file. We get verbose messages on the 1st 7 database files that open successfully, but none from the last one, I assume because they output to set_errcall instead.
There is 67GB of free space on this disk by the way, so not sure what "Not enough space" means.
Thanks again for your help.

Problem in performing multiple Point-In-Time Database Recovery using RMAN

Hello Experts,
I am getting an error while performing database point in time recovery multiple times using RMAN. Details are as follows :-
Environment:
Oracle 11g, ASM,
Database DiskGroups : DG_DATA (Data files), DG_ARCH(Archive logs), DG_REDO(Redo logs Control file).
Snapshot DiskGroups :
Snapshot1 (taken at 9 am): SNAP1_DATA, SNAP1_ARCH, +SNAP1_REDO
Snapshot2 (taken at 10 am): SNAP2_DATA, SNAP2_ARCH, +SNAP2_REDO
Steps performed for point in time recovery:
1. Restore control file from snapshot 2.
     RMAN> RESTORE CONTROLFILE from '+SNAP2_REDO/orcl/CONTROLFILE/Current.256.777398261';
2. For 2nd recovery, reset incarnation of database to snapshot 2 incarnation (Say 2).
3. Catalog data files from snapshot 1.
4. Catalog archive logs from snapshot 2.
5. Perform point in time recovery till given time.
     STARTUP MOUNT;
     RUN {
          SQL "ALTER SESSION SET NLS_DATE_FORMAT = ''dd-mon-yyyy hh24:mi:ss''";
          SET UNTIL TIME "06-mar-2013 09:30:00";
          RESTORE DATABASE;
          RECOVER DATABASE;
          ALTER DATABASE OPEN RESETLOGS;
Results:
Recovery 1: At 10.30 am, I performed first point in time recovery till 9:30 am, it was successful. Database incarnation was raised from *2* to *3*.
Recovery 2: At 11:10 am, I performed another point in time recovery till 9:45 am, while doing it I reset the incarnation of DB to *2*, it failed with following error :-
Starting recover at 28-FEB-13
using channel ORA_DISK_1
starting media recovery
media recovery failed
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 03/06/2013 11:10:57
ORA-00283: recovery session canceled due to errors
RMAN-11003: failure during parse/execution of SQL statement: alter database recover if needed
start until time 'MAR 06 2013 09:45:00'
ORA-00283: recovery session canceled due to errors
ORA-00313: open failed for members of log group 1 of thread 1
ORA-00312: online log 1 thread 1: '+DG_REDO/orcl/onlinelog/group_1.257.807150859'
ORA-17503: ksfdopn:2 Failed to open file +DG_REDO/orcl/onlinelog/group_1.257.807150859
ORA-15012: ASM file '+DG_REDO/orcl/onlinelog/group_1.257.807150859' does not exist
Doubts:
1. Why did recovery failed 2nd time, but not 1st time and why is RMAN looking for online redo log group_1.257.807150859 in 2nd recovery ?
3. I tried restoring control file from AutoBackup, in that case both 1st and 2nd recovery succeeded.
However for this to work, I always need to keep the AutoBackup feature enabled.
How reliable is control file AutoBackup ? Is there any alternative to using AutoBackup, can I restore control file from snapshot backup only ?
4. If I restore control file from AutoBackup, then from what point of time/SCN does RMAN restores the control file ?
Please help me out in this issue.
Thanks.

992748 wrote:
Hello experts,
I'm little newbie to RMAN recovery. Please help me in these doubts:
1. If I have datafiles, archive logs & control files backup, but current online REDO logs are lost, then can I perform incomplete database recovery ?yes, if you have backups of everything else
2. Till what maximum time/scn can incomplete database recovery be performed ??Assuming the only thing lost is the redo logs, you can recover to the last scn in the last archivelog.
3. What is role of online REDO logs in incomplete database recovery ? They provide the final redo changes - the ones that have not been written to archivelogs
Are they required for incomplete recovery ?It depends on how much incomplete recovery you need to do.
Think of all of your changes as a constant stream of redo information. As a redolog fills, it is copied to archive, then (eventually) reused. over time, your redo stream is in archivelog_1, continuing into archvivelog_2, then to 3, and eventually, when you get to the last archivelog, into the online redo. A recovery will start with the oldest necessary point in the redo stream and continue forward. Whether or not you need the online redo for a PIT recovery depends on how far forward you need to recover.
But you should take every precaution to prevent loss of online redo logs .. starting with having multiple members in each redo group ... and keeping those multiple members on physically separate disks.

Database recovery in Inconsistent mode

Similar Messages

Maybe you are looking for