Skip to content

18c New Feature

1. New Feature Private Temporary Tables

 

What are private temporary tables?

Private temporary tables are temporary database objects that are dropped at the end of a transaction or session.
Private temporary tables are stored in memory and each one is visible only to the session that created it.The metadata and content of a private temporary table is visible only within the session that created it.

How to create private temporary tables?

Below syntax can be used to create private temporary table

SQL> conn c##test
Connected.
SQL> CREATE PRIVATE TEMPORARY TABLE ORA$ptt_session
(time_id DATE,
amount_sold NUMBER(10,2))
ON COMMIT PRESERVE DEFINITION; 2 3 4

Table created.

SQL> show user
USER is “C##TEST”
SQL> select table_name
from user_tables
where TEMPORARY = ‘Y’ 2 3
4 ;

TABLE_NAME
——————————————————————————–
MY_TEMP_TABLE  =============> ORA$ptt_session is not displayed

SQL> select dbms_metadata.get_ddl(‘TABLE’,’ORA$ptt_session’) from dual;
ERROR:
ORA-31603: object “ORA$ptt_session” of type TABLE not found in schema “C##TEST”
ORA-06512: at “SYS.DBMS_METADATA”, line 6681
ORA-06512: at “SYS.DBMS_SYS_ERROR”, line 105
ORA-06512: at “SYS.DBMS_METADATA”, line 2582
ORA-06512: at “SYS.DBMS_METADATA”, line 2821
ORA-06512: at “SYS.DBMS_METADATA”, line 3602
ORA-06512: at “SYS.DBMS_METADATA”, line 4960
ORA-06512: at “SYS.DBMS_METADATA”, line 5288
ORA-06512: at “SYS.DBMS_METADATA”, line 6652
ORA-06512: at “SYS.DBMS_METADATA”, line 9672
ORA-06512: at line 1

no rows selected

SQL> select dbms_metadata.get_ddl(‘TABLE’,’ORA$PTT_SESISSION’) from dual;
ERROR:
ORA-31603: object “ORA$PTT_SESISSION” of type TABLE not found in schema
“C##TEST”
ORA-06512: at “SYS.DBMS_METADATA”, line 6681
ORA-06512: at “SYS.DBMS_SYS_ERROR”, line 105
ORA-06512: at “SYS.DBMS_METADATA”, line 2582
ORA-06512: at “SYS.DBMS_METADATA”, line 2821
ORA-06512: at “SYS.DBMS_METADATA”, line 3602
ORA-06512: at “SYS.DBMS_METADATA”, line 4960
ORA-06512: at “SYS.DBMS_METADATA”, line 5288
ORA-06512: at “SYS.DBMS_METADATA”, line 6652
ORA-06512: at “SYS.DBMS_METADATA”, line 9672
ORA-06512: at line 1

 

SQL> insert into ORA$ptt_session values(sysdate,1000);

1 row created.

SQL> commit;

Commit complete.

 

Open new session as the same user.

sqlplus c##test

Connected to:
Oracle Database 18c Enterprise Edition Release 18.0.0.0.0 – Development
Version 18.1.0.0.0

SQL> insert into ORA$ptt_session values(sysdate,1000);
insert into ORA$ptt_session values(sysdate,1000)
*
ERROR at line 1:
ORA-00942: table or view does not exist  <===============This indicates the existence of private temporary table is only for the session which created

 

Names of private temporary tables must be prefixed according to the initialization parameter private_temp_table_prefix.Default value is ORA$PTT_.

SQL> show parameter private_temp_table_prefix

NAME TYPE VALUE
———————————— ———– ——————————
private_temp_table_prefix string ORA$PTT_

This parameter is not dynamic and value can be changed as

SQL> alter system set private_temp_table_prefix=’ORA$MINE’ scope=spfile;

System altered.

 

Note : The feature is not available for SYS user. Error ORA-14451: unsupported feature with temporary table when we try to create PTT as SYS user.

Related views:

USER_PRIVATE_TEMP_TABLES
DBA_PRIVATE_TEMP_TABLES
CDB_PRIVATE_TEMP_TABLES

2. Datapatch New Features And Changes

 

Overview:

In 12.1  we have two different types of patches – Bundle patch /PSU patches and interim patches (non bundles) :

  The versioning scheme up until 12.2.0.1 splits the patch metadata into 2 places :

  1. The XML patch descriptor found under $ORACLE_HOME/sqlpatch/bug id/bug uid/bug id.xml  
  2. bundledata_<series>.xml found under $ORACLE_HOME/rdbms/admin.

datapatch uses the metadata from both locations to determine if a given SQL file should be run for a particular install

They have three important pieces of metadata as described below :

 Metadata Location in Patch Metadata Location in dba_registry_sqlpatch
Bundle Series (i.e. DBBP or DBPSU) bundleSeries  attribute of XML descriptor bundle_series column
Bundle ID (i.e. 170116 or 170416) bundleID  attribute of XML descriptor bundle_id column
Bundles in which a given file has been included bundle and file attributes of bundledata_<series>.xml NA

 

Bundle patches are marked with ‘B’ in the flags column of dba_registry_sqlpatch.

Change in 18c :

With the new model, there are still 2 main types of patches – release updates/release update revision and interim patches.

Patch Type  Description Update version in v$instance
Interim Patch One-off or MLR on top of a particular release No
Release Update(RU) Cumulative containing security and other fixes Yes,second digit(i.e 18.2.0.0.0)
Release Update Revision(RUR) Cumulative containing security and regressions on top of an RU or prior RUR Yes,third digit (i.e. 18.2.1.0.0)

 

 

 

 

To migrate to a new release update or revision, we will use the patching process (opatch for binary changes, datapatch for SQL changes).

This implies that, like our current bundle patches, a release update or revision must be RAC rolling, and can therefore be installed with zero down time.

The bundle series/bundle ID metadata which we have currently in 12.1.0.2 and 12.2.0.1 will not work for this new model. Hence we will have instead the following new metadata:

From the file : $ORACLE_HOME/sqlpatch/28090523/22329768/28090523.xml

Metadata Location in Patch Metadata Location in dba_registry_sqlpatch
Build timestamp buildTimestamp  attribute of XML  descriptor build_timestamp
Build description buildDescription  attribute  of  XML  descriptor Encoded in target_version
Patch type patchType  attribute of XML descriptor patch_type column
RUs and RURs in which a given file has been included ruData  element of XML descriptor N/A

 

 

 

 

 

 

 

The source_* and target_* columns of dba_registry_sqlpatch will encode the full version information .

bundledata.xml is no longer needed as the XML descriptor includes all the patch specific and RU metadata

 

Complete Version Description:

In order to completely describe a given release update, all 3 components of the version are needed:

  • 5 digit version string (i.e. 18.3.2.0.0). Although this string includes 5 digits, currently only the first 3 will be updated with this model.
  • Patch type (i.e. RU)
  • Release_Update_Revision

Collectively these 3 pieces of metadata are known as a version description.

The oraversion executable can be used to determine the current version description of the binaries in a given oracle home:

$ORACLE_HOME/bin/oraversion -baseVersion
18.0.0.0.0$ORACLE_HOME/bin/oraversion -buildDescription
Release_Update$ORACLE_HOME/bin/oraversion -h
This program prints release version information.These are its possible arguments:-compositeVersion: Print the full version number: a.b.c.d.e.
-baseVersion: Print the base version number: a.0.0.0.0.
-majorVersion: Print the major version number: a.
-buildStamp: Print the date/time associated with the build.
-buildDescription: Print a description of the build.
-help: Print this message.

Binary patching can be accomplished with opatch inplace operations, or out of place patching between two homes/containers at different releases. SQL patching may require more than one operation to complete, depending on the binary and SQL versions when datapatch is invoked, as described below.

Scenario SQL Version Binary Version Datapatch Operations
1 18.1.0.0.0 18.3.0.0.0 RU Apply from binary to SQL using 18.3.0.0.0 RU apply script
2 18.2.2.0.0 RUR 18.3.0.0.0 RU Rollback from SQL to common version 18.2.0.0.0 RU using 18.2.2.0.0 RUR rollback script
Apply from common version 18.2.0.0.0 RU to binary using 18.3.0.0.0 RU apply script
3 18.3.2.0.0 RUR 18.2.1.0.0 RU Rollback from SQL to common version 18.2.0.0.0 RU using 18.3.2.0.0 RUR rollback script
Apply from common version 18.3.2.0.0 RUR to 18.2.1.0.0 RU using 18.2.1.0.0 RU apply script

 

 

 

 

 

 

The recommended action for customers is to stay on the RU branch unless they only want security and regression fixes.

SQL Registry Changes :

The structure of registry$sqlpatch and dba_registry_sqlpatch in 18c is as follows. Columns in bold are new in 18c.

Column Type Description
action VARCHAR2(15) APPLY, ROLLBACK
status VARCHAR2(25) BEGIN, END, SUCCESS, WITH ERRORS, WITH ERRORS (RETRYABLE)
target_build_description VARCHAR2(80) Build description after the patch is installed
source_build_description VARCHAR2(80) Build description on which the patch will be installed
target_build_timestamp TIMESTAMP Build timestamp after the patch is installed
source_build_timestamp TIMESTAMP Build timestamp on which the patch will be installed
target_version VARCHAR2(15) Five digit version after the patch is installed
source_version VARCHAR2(15) Five digit version on which the patch will be installed
logfile VARCHAR2(500) Full path to logfile
ru_logfile VARCHAR2(500) Full path to logfile for RU specific operations
patch_type VARCHAR2(10) INTERIM, RU, RUR
flags VARCHAR2(10) One or more of the following characters. Either N or U will always be present.N: Normal modeU: Upgrade mode

J: Patch updates Java (and hence should be run first)

A: Application patch

R: Patch installation attempt retried

M: Patch installation was done at the same time as another installation

description VARCHAR2(100) Patch description (typically the same as the bug subject)
patch_id NUMBER Patch ID (typically the same as the bug ID)
patch_uid NUMBER Patch UID (universal patch identifier)
action_time TIMESTAMP Time of installation attempt
install_id NUMBER Unique ID per datapatch invocation
patch_descriptor XMLType XML descriptor for this patch
patch_directory BLOB Zipped contents of patch directory

 

Note the following about this table structure:

  • The bundle_series, bundle_id, and bundle_descriptor columns (present in 12.2) have been removed.
  • As in 12.2 and earlier, each row in the SQL registry represents one install attempt for one patch.
  • As in 12.2 and earlier, each PDB will have its own SQL registry.
  • The source_* and target_* columns, along with the patch_type column, encode the complete version information for the environment on which the patch is installed, as well as the environment after patch is (successfully) installed.
  • The build description may be empty. Since interim patches do not change the version information, source_* and target_* will both have the same value, namely the version on which the patch is applied

We introduce a second SQL registry table registry$sqlpatch_ru_info, with associated view dba_registry_sqlpatch_ru_info, with the following structure:

Column Type Description
ru_build_description VARCHAR2(80) Build description for this RU patch
ru_build_timestamp TIMESTAMP Build timestamp for this RU patch
ru_version VARCHAR2(15) Five digit version for this RU patch
patch_id NUMBER Patch ID (typically the same as the bug ID)
patch_uid NUMBER Patch UID (universal patch identifier)
patch_descriptor XMLType XML descriptor for this patch
patch_directory BLOB Zipped contents of patch directory

 

 

 

 

 

 

 

 

Each row in dba_registry_sqlpatch_ru_info will contain the metadata associated with an RU patch.

Following files used by Datapatch :

File or Directory Description
sqlpatch/sqlpatch Shell wrapper script for datapatch
sqlpatch/sqlpatch.bat Windows wrapper script for datapatch
sqlpatch/sqlpatch.pl Entry datapatch Perl script
sqlpatch/sqlpatch.pm Main datapatch Perl script
sqlpatch/sqlpatch_bootstrap.sql Datapatch bootstrap script
sqlpatch/lib Directory with datapatch Perl libraries
rdbms/admin/dbmssqlpatch.sql dbms_sqlpatch package header
rdbms/admin/prvtsqlpatch.plb dbms_sqlpatch package body
rdbms/admin/dbmsqopi.sql dbms_qopatch package header
rdbms/admin/prvtqopi.plb dbms_qopatch package body
rdbms/admin/catconst.pm Perl version constants
rdbms/admin/dbms_registry_basic.sql dbms_registry constants
rdbms/admin/preupgrade.jar pre upgrade utility

 

 

 

 

 

 

 

 

 

 

 

 

Simpler call to patch_initialize:

Currently the call to patch_initialize in the apply or rollback script looks as follows:

BEGIN
dbms_sqlpatch.patch_initialize(p_patch_id => patch ID,
p_patch_uid => patch UID,
p_flags => ‘&flags’,
p_description => ‘&description’,
p_action => ‘APPLY’,
p_logfile => ‘&full_logfile’,
p_bundle_series => ‘&bundle_series’);
END;
/

The flags, description, action, and bundle series parameters are no longer needed, so the call starting in 18.1 should look as follows:

BEGIN
dbms_sqlpatch.patch_initialize(p_patch_id => patch ID,
p_patch_uid => patch UID,
p_logfile => ‘&full_logfile’);
END;
/

 

Procedure Changes :

The following table summarizes the changes to each of the main routines within datapatch.

Routine Changes
initialize Removal of obsolete command line arguments such as -bundle_series
bootstrap No change
get_current_patches XML descriptor is required, read and store new metadata into the patch descriptors
add_to_queue Support new queue definition and perform logic to determine starting and ending RU version
install_patches Support new queue definition and new install script format
validate_logfiles No change

 

 

 

 

 

 

 

 

 

Addional Logfile :

sqlpatch_debug.log  === > Starting from 18c this logfile will be created for each invocation of datapatch .

Location : $ORACLE_BASE/cfgtoollogs/sqlpatch_pid_<timestamp>

 

3. New Memoptimized Rowstore

 

Feature Summary

The memoptimized rowstore provides the capability of fast lookup of data for the tables that are mainly queried based on primary key columns.
The memoptimized rowstore uses a memory area in the system global area (SGA) called the memoptimize pool that stores the hash indexes of the tables when enabled for fast lookup.

Fast lookup is enabled by a hash index structure in the memoptimize pool that provides fast access to the blocks of a given table permanently pinned in the buffer cache to avoid disk I/O.
This hash index is created when the Memoptimized Rowstore is configured and is maintained automatically by Oracle Database.
When a table is enabled for fast lookup, the table’s blocks are pinned in the buffer cache, and queries on the table use the hash index in the memoptimize pool to improve performance.

To enable the memoptimize pool:

Set the MEMOPTIMIZE_POOL_SIZE initialization parameter to a non-zero value. The minimum setting is 100M.

SQL> ALTER SYSTEM SET MEMOPTIMIZE_POOL_SIZE = 2G SCOPE=SPFILE;

 

To enable a Table for Fast Lookup

Specify MEMOPTIMIZE FOR READ in CREATE TABLE or ALTER TABLE statements.
The memoptimize pool is should first be enabled.

SQL> CREATE TABLE fast_lookup (id NUMBER(5) PRIMARY KEY, test_col VARCHAR2(15)) MEMOPTIMIZE FOR READ;

SQL> ALTER TABLE sh.products MEMOPTIMIZE FOR READ;

 

To populate a Table in the Memoptimize Pool

SQL> execute DBMS_MEMOPTIMIZE.POPULATE(‘SH’,’PRODUCTS’);

 

To disable an Existing Table for Fast Lookup

SQL> ALTER TABLE sh.products NO MEMOPTIMIZE FOR READ;

 

NOTE

This feature is allowed on Engineered systems and Oracle Cloud, and disabled for non-Engineered systems and non-Oracle Cloud.
The error ORA-12754 error is expected for  non-Engineered systems and non-Oracle Cloud.

SQL> alter table test memoptimize for read;
*
ERROR at line 1:
ORA-12754: Feature ‘Memoptimized Rowstore’ is disabled due to missing capability ‘Runtime Environment’.

Workaround : Set the init.ora parameter _exadata_feature_on=true, restart the database with memoptimize_pool_size > 0.

 

Restrictions

Tables enabled for fast lookup cannot be compressed.
Tables enabled for fast lookup must have a primary key constraint enabled.

 

4. Scalable Sequences

 

Starting 18.1 database, “Scalable Sequences” have been introduced.

The ability to create Scalable Sequences has been added to improve the performance of data loading into tables having sequence values as keys. This feature provides the option to add instance and session offsets to significantly reduce the possibility of sequence and index block contention when loading data across RAC instances and multiple loading processes within single instances.

The new business benefit is that it further enhances the Oracle Database data loading capabilities by reducing contention when loading data into tables that use sequence values as keys. By adding the ability to create sequences with instance and session ids added to the sequence value, contention on sequence value generation and index blocks inserts for the key values is significantly reduced. This means that Oracle Database is even more scalable for data loading and can support even higher data loading rates.

SQL Statement:

CREATE | ALTER SEQUENCE [ schema. ]sequence
[ { INCREMENT BY | START WITH } integer
| { MAXVALUE integer | NOMAXVALUE }
| { MINVALUE integer | NOMINVALUE }
| { CYCLE | NOCYCLE }
| { CACHE integer | NOCACHE }
| { ORDER | NOORDER }
| { SCALE {EXTEND | NOEXTEND} | NOSCALE}
]

 

SCALE/NOSCALEWhen SCALE is specified, a numeric offset is affixed to the beginning of the sequence.This offset is of the form iii||sss||, where,
iii denotes a three digit instance offset given by (instance_id % 100) + 100,
sss denotes a three digits session offset given by (session_id % 1000), and
|| is the concatenation operator

 

EXTEND/NOEXTENDWhen EXTEND is specified with the SCALE keyword, the generated sequence values are all of length (x+y), where x is the length of the scalable offset (default 6), and y is the maximum number of digits in the sequence maxvalue/minvalue. Thus, for an ascending sequence with maxvalue 100 and SCALABLE EXTEND specified, the generated sequence values are of the form iii||sss||001, iii||sss||002, …,iii||sss||100The default setting for the SCALE clause is NOEXTEND. With the NOEXTEND setting, the generated sequence values are at most as wide as the maximum number of digits in the sequence maxvalue/minvalue. This setting is useful for integration with existing applications where sequences are used to populate fixed width columns. On invocation of NEXTVAL on a sequence with SCALABLE NOEXTEND specified, a user error is thrown if the generated value requires more digits of representation than the sequence’s maxvalue/minvalue.

 

The addition of 100 in generating iii ensures that all generated values are of the same length, and consequently, there will be no duplicates in the generated values across all instances.

The default length of the scalable sequence offset is 6.

 

SQL> select instance_number from v$instance;INSTANCE_NUMBER
—————
1SQL> select sys_context(‘userenv’,’sid’) from dual;SYS_CONTEXT(‘USERENV’,’SID’)
————————————————————————————————————————————
22SQL> create sequence seq_extend start with 1 increment by 1 minvalue 1 maxvalue 100 scale extend;

Sequence created.

SQL> select seq_extend.nextval from dual;

NEXTVAL
———-
101022001

SQL> create sequence seq_noextend start with 1 increment by 1 minvalue 1 maxvalue 100 scale noextend;

Sequence created.

SQL> select seq_noextend.nextval from dual;
select seq_noextend.nextval from dual
*
ERROR at line 1:
ORA-64603: NEXTVAL cannot be instantiated for SEQ_NOEXTEND. Widen the sequence by 4 digits or alter sequence with SCALE EXTEND.

 

5. Termination of Run-away SQL

 

Manage runaway queries in the database , for versions 18c and above.

From 11g onwards, you can use the Resource Manager plan directives :

SWITCH_GROUP     => ‘CANCEL_SQL’

OR

SWITCH_GROUP     => ‘KILL_SESSION’

to cancel the SQL or kill the session respectively. You can also change the consumer group for the runaway queries. For details, refer to the document:

Managing and Monitoring Runaway Query Using Resource Manager Note 1600965.1

 

Along with these, you could kill the session using the ALTER SYSTEM KILL SESSION command.

From 18c onwards, you can manually cancel any runaway query using “ALTER SYSTEM CANCEL SQL” statement, instead of killing the session. Please note this is in addition to the options available through the Resource Manager.

 

The following clauses are required in an ALTER SYSTEM CANCEL SQL statement:

SID – Session identifier

SERIAL – Session serial number

SQL_ID – SQL ID of the SQL statement (optional)

INST_ID – Instance ID (optional)

If the SQL_ID is not provided, the currently running statement will be cancelled.

Cancelling a DML will result in implicit rollback of that statement.

For Example:

 

Session 1

SQL> select sid, serial# from v$session where audsid = userenv(‘SESSIONID’);

SID SERIAL#

———- ———-

275 41479

SQL> create table t_source as select * from dba_source where 1=2;

Table created.

SQL> select count(*) from t_source;

COUNT(*)

———-

0

SQL> insert into t_source select * from dba_source;

296264 rows created.   <========================== Note the count here.

SQL> insert into t_source select * from dba_source;

 

While this is executing, Cancel the SQL from another session

 

 

Session 2

<< Killed the statement from Session1>>

SQL> alter system cancel sql ‘275,41479’;

System altered.

 

Check the INSERT statement in the first session

Session 1

 

SQL> insert into t_source select * from dba_source;

insert into t_source select * from dba_source

*

ERROR at line 1:

ORA-01013: user requested cancel of current operation

 

SQL> select count(*) from t_source;

COUNT(*)

———-

296264  <============================

Here, we can see, only the second Insert statement (which was cancelled) got rolled back

 

6. Roll Forward Physical Standby

 

Typically, when rolling forward a physical standby database using primary incremental backup, multiple steps are required:

  1. Identify the Start SCN on Standby for performing incremental backup on primary
  2. Perform incremental backup on primary with FROM SCN clause
  3. Move the backup-pieces from primary to standby
  4. Catalog the backup-piece on Standby
  5. Perform recovery on standby using recover database noredo
  6. Refresh standby controlfile again from primary

Starting from 12.1, we could use “RECOVER DATABASE FROM SERVICE”command which will automate a few steps like performing incremental backup on primary, transfer the backup-pieces to standby over network and perform recovery on standby. However, we still had to manually refresh the standby controlfile and manually restore newly-added datafiles. These steps required manual efforts and are error prone especially when standby files are physically located in a path different to that of primary.

Starting with 18.1, we can use a single command to refresh the standby with changes made on primary:

RMAN> RECOVER STANDBY DATABASE FROM SERVICE primary_connect_identifier;

This command will internally keep track of standby file locations, refresh standby controlfile from primary, update the new standby controlfile with standby file names, perform incremental backup on primary, transfer the backup-pieces over network to standby and perform recovery on standby

1. To refresh the standby, ensure that managed recovery is stopped on standby:

SQL> recover managed standby database cancel;

NOTE: If you do not stop managed recovery, you will get RMAN-05150 error during execution:

RMAN> RECOVER STANDBY DATABASE FROM SERVICE PRM180;
RMAN-03090: Starting recover at 03-AUG-18
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 08/03/2018 12:33:05
RMAN-05150: Managed Recovery Process must be disabled before running RECOVER STANDBY DATABASE.

2. Ensure that Oracle Net connectivity is established between the physical standby database and the primary database by adding an entry corresponding to the primary database in the tnsnames.ora file of the physical standby database. In below example, PRM180 is the connect identifier for primary.

3. Connect RMAN to standby as target and run “RECOVER STANDBY DATABASE FROM SERVICE” command. Find below an example run for the command:

[oracle@ora18DbSrv ~]$ export ORACLE_SID=SBY180
[oracle@ora18DbSrv ~]$ rman target /RMAN> RECOVER STANDBY DATABASE FROM SERVICE PRM180;RMAN-03090: Starting recover at 03-AUG-18
RMAN-06009: using target database control file instead of recovery catalog
RMAN-06196: Oracle instance startedTotal System Global Area 671086904 bytes

Fixed Size 8661304 bytes
Variable Size 188743680 bytes
Database Buffers 465567744 bytes
Redo Buffers 8114176 bytes

RMAN-08161: contents of Memory Script:
{
restore standby controlfile from service ‘PRM180’;
alter database mount standby database;
}
RMAN-08162: executing Memory Script

RMAN-03090: Starting restore at 03-AUG-18
RMAN-08030: allocated channel: ORA_DISK_1
RMAN-08500: channel ORA_DISK_1: SID=141 device type=DISK

RMAN-08016: channel ORA_DISK_1: starting datafile backup set restore
RMAN-08169: channel ORA_DISK_1: using network backup set from service PRM180
RMAN-08021: channel ORA_DISK_1: restoring control file
RMAN-08180: channel ORA_DISK_1: restore complete, elapsed time: 00:00:01
RMAN-08505: output file name=/u01/app/oracle/oradata/SBY180/control01.ctl
RMAN-03091: Finished restore at 03-AUG-18

RMAN-08031: released channel: ORA_DISK_1
RMAN-06986: Statement processed
RMAN-06958: Executing: alter system set standby_file_management=manual

RMAN-08161: contents of Memory Script:
{
recover database from service ‘PRM180’;
}
RMAN-08162: executing Memory Script

RMAN-03090: Starting recover at 03-AUG-18
RMAN-08030: allocated channel: ORA_DISK_1
RMAN-08500: channel ORA_DISK_1: SID=149 device type=DISK
RMAN-06179: datafile 4 not processed because file is read-only
RMAN-08039: channel ORA_DISK_1: starting incremental datafile backup set restore
RMAN-08169: channel ORA_DISK_1: using network backup set from service PRM180
RMAN-08509: destination for restore of datafile 00001: /u01/app/oracle/oradata/SBY180/system01.dbf
RMAN-08180: channel ORA_DISK_1: restore complete, elapsed time: 00:00:03
RMAN-08039: channel ORA_DISK_1: starting incremental datafile backup set restore
RMAN-08169: channel ORA_DISK_1: using network backup set from service PRM180
RMAN-08509: destination for restore of datafile 00002: /u01/app/oracle/oradata/SBY180/sysaux01.dbf
RMAN-08180: channel ORA_DISK_1: restore complete, elapsed time: 00:00:07
RMAN-08039: channel ORA_DISK_1: starting incremental datafile backup set restore
RMAN-08169: channel ORA_DISK_1: using network backup set from service PRM180
RMAN-08509: destination for restore of datafile 00003: /u01/app/oracle/oradata/SBY180/undotbs01.dbf
RMAN-08180: channel ORA_DISK_1: restore complete, elapsed time: 00:00:03

RMAN-08054: starting media recovery

RMAN-08181: media recovery complete, elapsed time: 00:00:00
RMAN-03091: Finished recover at 03-AUG-18
RMAN-06958: Executing: alter system set standby_file_management=auto
RMAN-03091: Finished recover at 03-AUG-18

No comments yet

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: