I'm running Oracle 9i on AIX 5.2. I'm not using a recovery catalog, nor am I using media management software. I perform a full, online rman backup of the database and archived redo logs daily to disk, then use operating system commands to copy the backup to tape. There is only space on disk for two days' backups, so I need to have a retention policy of "redundancy = 1", and run a "delete obsolete" prior to the backup. The problem is that I don't want to subject the archived redo logs to this retention policy.
I have two physical standby databases connected by WAN to the primary site, and I might need archived redo logs that are a few days (or more) old in the event of a prolonged WAN outage. I've read about the "keep forever" option, but apparently it isn't available without using a recovery catalog. Is there any way to spare the archived redo logs from my retention policy?
Note: I want to "protect" the actual archived redo logs from the retention policy, not the backups of the archived redo logs.
URL....I'm practicing for the OCP test and one of the questions is that there is a backup from yesterday and the last archived logs are from the day before yesterday not mentioned if it's cold or hot backup.
If its a cold backup - cant we recover it? is it a must to have the archived redo logs also when recovering a cold backup? That sounds not logical since those logs are made only for a hot backup. URL.....
How we can use RMAN backup to restore oracle database when the RMAN backup pushed to tape already and being a OLD backup ( before retention policy date).Just to elaborate a more.. Say my retention policy is 3 days. I want to restore from a old backup like 30 days old.So surely the requesting backup is behind retention date and has been pushed to tape.
Assuming you have a 9i database . where you have it enabled in archive mode , yet constantly deleting the archived redo logs , due to space constraints .
Will you be able to perform a full level 0 backup , and the following incremental backups , in the absence of the archived redo logs ? And are these incremental backups enough to recover the database or particular data files , to the point of the backup itself at least ?
here i have an question with oracle database backup strategy.my question is
how to backup my oracle database call DB11G without archived logs while the database is open for user activity and also this should be the base for an incremental backup strategy?
Backup your entire database, without archived logs, while the database is open for user activity. This backup should be the base for an incremental backup strategy
I got a database on dataguard and my primary (db1) is shipping files to my standby (db2) with no problems.However, when I query:
select sequence#, status, applied from v$archived_log;
I see this: SEQUENCE# S APP ---------- - --- 4 A YES 5 A YES 6 A YES 7 A YES 8 A YES 9 A YES 10 A YES 11 A YES 12 A YES 13 A YES 14 A YES [code]....
So I did an alter system switch logfile on db1 then looked again and I can see new archived logs being applied.I thought all archived logs had to be applied on the standby since this is the very foundation of the standby database.Am I going to run in trouble later if I have a failover (unsynchronized database)
The undo_retention is used for read consistency, to avoid snapshot too old.Flashback database is using files in the db_recovery_file_dest.But whether undo_retention has any influence on Flashback drop; Flashback table or Flashback query?Let's say we have set undo_retention = 3600 = 1 hour.And
db_flashback_retention_target = 1440 = 24 hours.
Will it work Flashback drop; Flashback table; Flashback query to get 12 hours back?Additional question. Why Oracle sets undo_retention in seconds and db_flashback_retention_target in minutes?To use the same measure would be more user-friendly to DBAs .
I got many times oracle ORA-00494 error and the database went down but since 29th of july the database have not been killed. The error message is below :
ORA-00494: mise en file d'attente [CF] d�tenue pendant trop longtemps ( (more than 900 seconds)) par inst 1, osid 176484 ORA-00028: votre session a �t� ferm�e
My database is used for datawarehouse of many terabytes.
Initially the redo log size was 500Mbytes and I've set it to 3Gbytes. The maximum log switch is after 5 minutes. I want log to be switched every 20 minutes or every 30 minutes.
To obtain the size of redo logs I've executed this query :
SQL> select OPTIMAL_LOGFILE_SIZE from v$instance_recovery;
OPTIMAL_LOGFILE_SIZE -------------------- 54763
53,5 Gbytes is it not very big as redo log size? What's the maximum size of redo log? To set very big redo log size what are the requirements? Which precautions should I take before? What are the risks? Are any other ways to change the log switch frequency?
I've got a legacy SAP system with oracle 8i on Tru64. No changes at all are made but for legal reasons we have to keep it up and running.
we currently do a full backup monthly by shutting down oracle and doing a backup of all the files to tape and that takes around 12 hours.
If I stop doing the full backup and I only backup the control file and the archived redo log files every month and I had to restore the full database years from now, would I be able to restore the database using the last full monthly backup and use the latest control file and archived redo log files?
I'm an Oracle novice and from what I've read so far, it seems that you should be able to do rollbacks and data recovery using the redo logs. I'm having a difficulty understanding the need for the undo tablespace.
it seems that you should be able to do rollbacks and data recovery using the redo logs. I'm having a difficulty understanding the need for the undo tablespace.
One of the Hitachi support guy has suggested to create a separate disk group for Online redo logs. His rationale was that ORLs was write only files and it would be better to put in a separate disk group.
This morning when I checked my archive logs, I suprised that the redo files are generating after every 3 min and each of file size is 50M, which is the actual size of both log members. I m using RAC database with DR server.Usally the total redo logs quantity for one day is 4 to 5. but since 10 pm of yesterday to 7 am today, the quantity of log files are 109, each of 50 M .
I've been using ASM for a few years now and have always installed a new system with 3 diskgroups
+DATA - for datafiles, control files, redo logs +FRA - for achive logs, flash recovery. RMAN backup
Those I guess are the standards, but I've always created an extra (very small) diskgroup, called +ONLINE where I keep multiplexed copies of the redo logs and control files.
My reasoning behind this is that if there are any issues with the +DATA diskgroup, the redo logs and control files can still be accessed.
In the olden days (all those 5 years ago!), on local storage, this was important, but is it still important now? With all the striping and mirroring going on (both at ASM and RAID level), am I just being overtly paranoid? Does this additional +ONLINE diskgroup actually hamper performance? (with dual write overheads that are not necessary)
Backup entire database, without archived logs, while the database is open for user activity and also This backup should be the base for an incremental backup strategy.
After much tedious mucking about in hyperspace, I'm back to tweaking my dataguard environment. I'm generating a lot of stored archive logs, this is causing problems with the backups, (since they live on the same drive, /u01 and also contain backups of the logs) I could move the logs onto /u02 but that's not dealing with the problem IMO.
This is the init script for the primary, (prod) CODE archive_lag_target=0 audit_file_dest='/u02/oradata/prod/dump/audit' compatible='10.2.0'
I have tried to implement RLS policy of oracle.I have two Schema X1 & X1_DBA.
I have created the emp table in X1_DBA create table emp(empid number,ename varchar2(10),deptno number) and inserted some rows into the Table. i have created the below function in X1_DBA schema & Given Select Privilege to X1.
CREATE OR REPLACE FUNCTION no_dept10( p_schema IN VARCHAR2, p_object IN VARCHAR2) RETURN VARCHAR2
[code]...
When i Add the Policy in X1_DBA.schema i am getting the Error as Table does not exist
NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ undo_management string AUTO undo_retention integer 96000 undo_tablespace string undo
Following are the details in AWR report (00:00 til 01:00 of 21-Apr-2013) .... not thet the error was produced at 00:42
Undo Segment Summary DB/Inst: DBCPY/dbcpy01 Snaps: 18853-18854 -> Min/Max TR (mins) - Min and Max Tuned Retention (minutes) -> STO - Snapshot Too Old count, OOS - Out of Space count -> Undo segment block stats: -> uS - unexpired Stolen, your - unexpired Released, uU - unexpired reUsed
[code]....
Undo Advisor information taken 'now' is as following
SQL> select dbms_undo_adv.longest_query(sysdate-2,sysdate) from dual; DBMS_UNDO_ADV.LONGEST_QUERY(SYSDATE-2,SYSDATE) ---------------------------------------------- 379650 SQL> select dbms_undo_adv.required_retention from dual;
[code]....
In above situation what should be my first choice (assuming increasing space is not an issue) - increase undo tablespace or increase undo retention?
If latter is the choice then what should be the value? Because as I understand present 96000 value is taken as lower limit and because of auto tuning the actual value (TUNED_UNDORETENTION) being used was 345600 In that case shall I set it to something > max(maxquerylen) i.e 379,650 + X?Or I shall increase the undo tablespace size?
From Undo Advisor output it looks to me that even if I increase the undo retention to 379650 current undo size will be able to support it (may be at the expense of DMLs)Is that right?
I'm on a Windows server 2003 R2 64 bit, database is 11.1.0.7. From RMAN connected to the target and the catalog, this is a show all;
RMAN> show all;
RMAN configuration parameters for database with db_unique_name ORCL are:
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 3 DAYS; CONFIGURE BACKUP OPTIMIZATION OFF; CONFIGURE DEFAULT DEVICE TYPE TO DISK; CONFIGURE CONTROLFILE AUTOBACKUP ON; CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO 'F:oracleadmin
[code]....
I'm running incremental backups, a level 0 on sunday and a level 1 the other days of the week, this is the ctl file:
LEVEL 0: connect target /@ORCL connect catalog rman/rmanpw@rmancat RUN {
[code]....
The level 0 does delete the archive logs (because of the delete input). Each backupset has two copies of the archive logs (which is what I want), and I expected the logs to be deleted after being backed up 2 days (each day is twice, 2 days = 4 times). But it's not deleting the logs, even after 6 runs.
I have a DR setup with the following configuration
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 30 DAYS; CONFIGURE BACKUP OPTIMIZATION OFF; # default CONFIGURE DEFAULT DEVICE TYPE TO DISK; CONFIGURE CONTROLFILE AUTOBACKUP ON; CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; # default CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default CONFIGURE MAXSETSIZE TO UNLIMITED; # default CONFIGURE ENCRYPTION FOR DATABASE OFF; # default CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # default CONFIGURE COMPRESSION ALGORITHM 'BASIC' AS OF RELEASE 'DEFAULT' OPTIMIZE FOR LOAD TRUE ; # default CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY
I dont want to backup the STDBY DB but I want the ARC files to be removed when applied so my flash area does not fill up. Is there some command(rman or not) that can fire off this policy?
