Infrastructure at your Service
Introduction Oracle & Linux is a great duet. Very powerfull, very scriptable. Here are several commands that make my life easier. These tools seems to be widespread on most of the Linux distributions. watch with diff It’s my favorite tool since a long time. watch can repeat a command indefinitely until you stop it with Ctrl+C. And it’s even more useful with the – -diff parameter. All the differences since last run are highlighted. For…
At one client’s site, I had to restore a table someone had partially deleted one week before. Before Oracle 12c, we had to duplicate the target database to another server, and then to export and import data to the target database. But depending on the database size, it could cost a lot of time, and as nobody knew when the delete action happened, it was more practical to use the rman recover table command in…
One of our customer has been initially creating a RMAN catalog on an Oracle database release 12.1.0.2.0 and was now intending to register new Oracle 12.2.0.1.0 databases. Registering the databases will be failing with errors : PL/SQL package RCAT.DBMS_RCVCAT version 12.01.00.02 in RCVCAT database is too old RMAN-06429: RCVCAT database is not compatible with this version of RMAN
It should never happen but sometimes it happens. You just lost your datafiles as well as your fast recovery area (probably because most of the time these areas are on the same disks despite the recommendations). Normal restore operations with RMAN are quite easy and secure as far as you have backupsets for database, archivelogs, and spfile/controlfile: Step 1 – restore the spfile and start the instance Step 2 – restore the controlfile and mount…
Backup on disk with RMAN is great. It’s fast, you can set as many channels as your platform can handle for faster backups. And you can restore as fast as you can read and write files on disk with these multiple channels. As far as you’re using Enterprise Edition because Standard Edition is stuck to a single channel. Disk space is very often limited and you’ll probably have to find another solution to keep backups…
With Oracle 18c, it is possible to use PDB rman backups created on the source CDB (they are called PREPLUGIN backups) when the PDB has been relocated to a target CDB. In my environment, my original CDB is DB18, with the PDB named pdborig. The target CDB is PSI18. The first step consist in running a rman backup on pdborig: [email protected]:/u00/app/oracle/ [DB18] rman target sys/[email protected] Recovery Manager: Release 18.0.0.0.0 – Production on Tue May 15…
When RMAN backups archivelogs, it does a logswitch before backing up all archivelogs. In some cases this log switching should be suppressed. This can be done with expression “until time ‘sysdate’”, which actually filters nothing. For example: backup archivelog until time ‘sysdate’;
In this post I would like to share how I have been able to troubleshoot and solve a catalog import issue using RMAN debug function. As we can see, the error message provided by RMAN is not very helpful. [email protected]:/home/oracle/ [RCAT12C] rman catalog rcat/manager Recovery Manager: Release 12.2.0.1.0 connected to recovery catalog database RMAN> import catalog rcat/[email protected]; Starting import catalog at 05-JAN-2018 14:11:45 connected to source recovery catalog database RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE…
This is a small migration demo of a 11g catalog (RCAT11G) to a new 12c catalog (RCAT12c). Demo databases environments have been easily managed thanks to DBI DMK tool. [email protected]:/home/oracle/ [RCAT11G] sqh SQL*Plus: Release 11.2.0.4.0 [email protected]:/home/oracle/ [RCAT12C] sqh SQL*Plus: Release 12.2.0.1.0 Current configuration Displaying the list of databases registered in the RCAT11g catalog. SQL> select instance_name from v$instance; INSTANCE_NAME —————- RCAT11G SQL> select * from rcat.rc_database; DB_KEY DBINC_KEY DBID NAME RESETLOGS_CHANGE# RESETLOGS ———-…
In a project I have to move an Oracle 11.2.0.4-DB (around 7TB in size) from Sparc Solaris (called Source in the remainder of this Blog) to Linux x86-64 (called Target in the remainder of the Blog). I.e. a platform migration from Big Endian to Little Endian. A good method to do that is described in My Oracle Support Note 1389592.1: 11G – Reduce Transportable Tablespace Downtime using Cross Platform Incremental Backup Basically I copy the…
