Hot answers tagged

12

No, you still need archived redo logs. An RMAN backup is not the same as a cold backup; when you restore it you need to apply all the redo generated from the time you started the backup until the time the backup completed in order to get the SCN consistent across all the datafiles and the controlfile. Let us consider the old fashioned hot backup. In this ...


7

Backing up Archive logs is only necessary when running in Archive log mode, so the question comes back to whether the database should do this or not. This is covered in the same document you reference under the heading Deciding Between ARCHIVELOG and NOARCHIVELOG Mode. Here is an excerpt: Deciding Between ARCHIVELOG and NOARCHIVELOG Mode The redo ...


5

Each redo log file (and archived redo log file) contains starting SCN and ending SCN. In case it is a last redo, the ending SCN is 0xffffffffffff. nap01:~/oradata/jt10g$ strings redo01.log|head -3 z{|} JT10G Thread 0001, Seq# 0000000004, SCN 0x0000000b05b5-0x0000000bd34f nap01:~/oradata/jt10g$ strings redo02.log|head -3 z{|} JT10G Thread 0001, Seq# ...


5

Query this table in order for you to see the platforms to which rman can convert your SYS@EMR> select * from V$DB_TRANSPORTABLE_PLATFORM; PLATFORM_ID PLATFORM_NAME ENDIAN_FORMAT ----------- ...


4

In short - yes, there are standard operating procedures for doing all of this with Oracle. You should start by looking into RMAN (Recovery MANager). I have put together a high level overview of RMAN as well as an introduction to Oracle backups for SQL Server DBAs. I suggest watching both of those and then heading over to the Oracle Database Backup and ...


4

Maybe those files are not cataloged by RMAN? I would CATALOG them and then DELETE OBSOLETE once again.


4

The first thing RMAN does it automatically perform an ALTER SYSTEM ARCHIVE LOG CURRENT to switch logfiles so that the active log at the point the backup was started will be included. It doesn't do this in all backup situations, but this answers your question.


4

If I correctly understand your question as: "I want to create a standby database and later on take backups on the primary like if there would be no standby present" In this case, you do not need a recovery catalog: quote "An RMAN recovery catalog is required so that backups taken on one database server can be restored to another database server. It is not ...


4

A Cold Backup is making a copy of the files with the database closed. These commands are both for hot backups using RMAN. They are both preferred over cold backups due to their flexibility. The difference between the two commands is whether or not archive logs are backed up. If you need be able to recover to any point between your backups or anytime ...


4

Issue switch to copy, then crosscheck.


4

If my source database uses SPFILE then do I have create a PFILE from the SPFILE? Yes, you need to create a temporary PFILE to use while duplicating the database. You will later switch the new instance to use the SPFILE. Use CREATE PFILE = 'path/to/pfile' FROM SPFILE; You only need to create directories that are referenced in the PFILE or SPFILE. ...


4

The duplicate database ... from active database is designed to work without any existing backup. I would expect Oracle to clean up the archivelogs which were used during the clone process. So I would say this is an unexpected behavior. Try to log a Service Request at Oracle. I cannot recall if I had to clean up archivelogs after a clone processes. Well, I ...


3

In the simplest case, when you restore a database, you tell RMAN to recover it to the most recent point in time by applying all the redo (archived and online) that is available. That will re-apply any statements that were executed during normal database operations including things like dropping tables and deleting data. If you want to restore a database to ...


3

You should be able to resolve this by copying CONTROL01.CTL over CONTROL02.CTL since the first one has a higher version number. Make a copy of CONTROL02.CTL in case it does not work


3

This can be done in a few minutes with storage snapshots/cloning. If you can't do that, just go for RMAN duplicate. Both method can be scripted and scheduled to run automatically.


3

Lets see the information provided by oerr utility. ORA-01152: file 1 was not restored from a sufficiently old backup Cause: An incomplete recovery session was started, but an insufficient number of logs were applied to make the database consistent. This file is still in the future of the last log applied. The most likely cause of this error is ...


3

Since you've done an open resetlogs, you've changed the incarnation and are now trying to restore to a previous incarnation. From the Backup and Recovery User's Guide: The procedure for DBPITR within the current incarnation is different from DBPITR to an SCN in a noncurrent incarnation. In the latter case, you must explicitly execute the RESET ...


3

I always believe that the output given by oerr utility helps alot to resolve the problem. Oerr: Oerr is an Oracle utility that extracts error messages with suggested actions from the standard Oracle message files. ORA-01190: control file or data file string is from before the last RESETLOGS Cause: Attempting to use a data file when the log ...


3

If the database does not know about those files, you should catalog them in RMAN: catalog start with '/path/to/files'; After that you can use your above commands for identifying or deleting these files. Deleting old backups in a safe way is achieved by running DELETE OBSOLETE, with the required retention set in configuration or specified in the command ...


3

Oracle, in contrast with the name, can not predict the future. If you have a retention policy configured as recovery window of 14 days or redundancy 2, the database does not know when your next full backup will succeed. Just because you have a full backup scheduled on every Saturady, that does not necessarily mean that backup will succeed and old backups ...


3

RMAN only works at the block level & has no idea about the contents of a given block, and therefore cannot do this. You need to use expdp with the query parameter: expdp phil/phil directory=myexportdir dumpfile=yourtable.dmp query=yourtable:\"where groupid in (1,2,3)\" tables=yourtable Obviously, this isn't incremental. There's no really easy way of ...


3

The answer to your question is no, however.... It sounds like a flashback query is what you need. Query the data as of a time when it existed and when it returns the correct data, insert it into the current table. This solution does require space in the UNDO tablespace sufficient to meet your UNDO_RETENTION requirements. It also doesn't use RMAN, but is ...


3

You need to use the catalog command in RMAN to make the file known to the database (don't worry, this does not depend on a recovery catalog!)


3

The "device" in RMAN is a misnomer, it should be really called "storage". The "sbt" (synonym of "sbt_tape") is a misnomer again, as it has NOTHING to do with any tapes, it should be simply called "non-rman". This is just an empty placeholder, to be filled with any "plugin"; the plugin is called by Oracle either the "Media Manager library" or SBT_LIBRARY. ...


3

Oracle Support closed bug 14226856 as "not a bug" and said it will be fixed in 12c.


3

Figured out the problem. Simply changing the Autobackup Format back to the default '%F' is not viewed as the default. In order to truly have the default value you must use the clear command. CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK CLEAR; RMAN behaivor returned to normal. Thanks to all who viewed my question!


3

In case you specify COPIES 2 each block is read once and written two times to backupset copies. The two backupset copies are supposed to be bit-to-bit identical. Both copies have the same backupset key (BS_key) in RMAN. You cannot mix tape and disk copies - either both copies go to DEVICE DISK or both to DEVICE SBT.


3

You're issuing a "recover database" command, which will recover the database as far as possible. If that includes the archivelogs/redo logs which contain your "truncate" command, then this will also be re-played and the table truncated again. Try doing the restore on it's own, or recovering to a specific time using RECOVER UNTIL... then opening the DB ...


3

Depending on your requirements and what other backups you have done since then, you could use (from http://docs.oracle.com/cd/B28359_01/backup.111/b28270/rcmreprt.htm#BRADV89594): REPORT NEED BACKUP RECOVERY WINDOW OF n DAYS Displays objects requiring backup to satisfy a recovery window-based retention policy. REPORT NEED BACKUP REDUNDANCY n Displays ...


3

Use expdp with the flashback_scn or flashback_time parameters, along with SCHEMAS= to export the schema at a consistent point in time. This is the same as using CONSISTENT=Y in the legacy exp utility. Examples here. If the data for the schema in question is in a tablespace of its own with no other objects from other schemas, you can use rman to do a ...



Only top voted, non community-wiki answers of a minimum length are eligible