Unisoft Technologies Nagpur

We have Target Database name as TECH And we are creating a duplicate database using RMAN Auxiliary Instance with name as AUXDB by using the backup location but without making connection to target database but we will be accessing Recovery Catalog DB. Note :- This practical assume you have same directory structures and it is performed on same server. Just the database name is different so we are converting the path with respect to dbname only.   Check log_mode of Target Database. Target must be in archivelog mode. Otherwise put the database in archivelog mode. Now create a new database manually or via DBCA say CATDB. Then run the below command on CATDB to set this as the new Recovery Catalog for our Use. Connect to the newly created Recovery Catalog Via RMAN Now register your target database (tech) with newly created recovery catalog database (catdb) On Windows Platform You need to Create a new Instance for auxdb which also creates a password file for the...

   REMAP_DATA Default: There is no default Purpose The REMAP_DATA parameter allows you to specify a remap function that takes as a source the original value of the designated column and returns a remapped value that will replace the original value in the dump file. A common use for this option is to mask data when moving from a production system to a test system. For example, a column of sensitive customer data such as credit card numbers could be replaced with numbers generated by a REMAP_DATA function. This would allow the data to retain its essential formatting and processing characteristics without exposing private data to unauthorized personnel. The same function can be applied to multiple columns being dumped. This is useful when you want to guarantee consistency in remapping both the child and parent column in a referential constraint. Syntax and Description REMAP_DATA=[ schema .] tablename . column_name :[ schema .] pkg . function The descri...

Table Compression: Overview Oracle Database supports three methods of table compression: • Basic table compression • OLTP table compression Oracle Corporation recommends to compress all data to reduce storage costs. The Oracle database can use table compression to eliminate duplicate values in a data block. For tables with highly redundant data, compression saves disk space and reduces memory use in the database buffer cache. Table compression is transparent to database applications. • The table_compression clause is valid only for heap-organized tables. The COMPRESS keyword enables table compression. The NOCOMPRESS keyword disables table compression. NOCOMPRESS is the default. • With basic compression, the Oracle database compresses data at the time of performing bulk load using operations such as direct loads or CREATE TABLE AS SELECT . • With COMPRESS FOR OLTP , the Oracle database compresses data during all DML operations on the table. 

Understand Deferred Segment Creation Beginning with Oracle Database 11 g Release 2, when you create heap-organized tables in a locally managed tablespace, the database defers table segment creation until the first row is inserted. In addition, segment creation is deferred for any LOB columns of the table, any indexes created implicitly as part of table creation, and any indexes subsequently explicitly created on the table. Note: In Release 11.2.0.1, deferred segment creation is not supported for partitioned tables. This restriction is removed in release 11.2.0.2 and later. The advantages of this space allocation method are the following: It saves a significant amount of disk space in applications that create hundreds or thousands of tables upon installation, many of which might never be populated. It reduces application installation time. There is a small performance penalty when the first row is inserted, because the new segment must be created at that ...

Purpose of RMAN TSPITR Recovery Manager (RMAN) TSPITR enables quick recovery of one or more tablespaces in a database to an earlier time without affecting the rest of the tablespaces and objects in the database. RMAN TSPITR is most useful for the following situations: To recover a logical database to a point different from the rest of the physical database, when multiple logical databases exist in separate tablespaces of one physical database. For example, you maintain logical databases in the orders and personnel tablespaces. An incorrect batch job or data manipulation language (DML) statement corrupts the data in only one tablespace. To recover data lost after data definition language (DDL) operations that change the structure of tables. You cannot use Flashback Table to rewind a table to before the point of a structural change such as a truncate table operation. To recover a table after it has been dropped with the PURGE option. To recover from the logi...

RMAN has the ability to duplicate, or clone, a database from an active database. I t is possible to create a duplicate database on a remote server with the same file structure, a remote server will a different file structure or the local server with a different file structure.

Purpose of the Recovery Catalog A recovery catalog is a database schema used by RMAN to store metadata about one or more Oracle databases. Typically, you store the catalog in a dedicated database. A recovery catalog provides the following benefits: A recovery catalog creates redundancy for the RMAN repository stored in the control file of each target database . The recovery catalog serves as a secondary metadata repository. If the target control file and all backups are lost, then the RMAN metadata still exists in the recovery catalog. A recovery catalog centralizes metadata for all your target databases. Storing the metadata in a single place makes reporting and administration tasks easier to perform. A recovery catalog can store metadata history much longer than the control file. This capability is useful if you must do a recovery that goes further back in time than the history in the control file. The added complexity of managing a recovery catal...