CHAPTER 27

Duplicating a Database

Exam Objectives

• 63.1.16.1    Describe and Use Transportable Tablespaces and Databases

• 63.1.17.1    Choose a Technique for Duplicating a Database

• 63.1.17.2    Create a Backup-Based Duplicate Database

• 63.1.17.3    Duplicate a Database Based on a Running Instance

The transportable tablespace feature can quickly copy one or more tablespaces from one database to another without using the much more time-consuming export/import. An extension to transportable tablespaces, transportable databases, makes it easy to create a new database and move all non-SYSTEM tablespaces to the new database. Related to this are techniques for duplicating an entire database. If you must have your source database open on a continuous basis, you can clone your database while it is open and available to users. Because you are copying from an open database, you don’t need an intermediate Recovery Manager (RMAN) backup, which can save a lot of time and disk space.

Describe and Use Transportable Tablespaces and Databases

There are many ways to move data from one database to another, such as database links, Data Pump export/import, and transportable tablespaces. For large volumes of data, using transportable tablespaces is by far the fastest method. In a nutshell, you export just the metadata for the objects in the tablespace using Data Pump, copy the datafiles comprising the tablespace to the destination database, and import the tablespace’s metadata into the destination database. Even platforms with different hardware architectures are candidates for transportable tablespaces.

Configuring Transportable Tablespaces

The tablespace transport feature has many uses, such as quickly distributing data from a data warehouse to data marts in other databases or converting an entire database from one platform to another. When transporting between platforms, both the source and destination platforms must be on Oracle’s list of supported platforms. All commonly used 64-bit server platforms running on Intel, SPARC, or PowerPC hardware are supported.

Determining Compatibility Requirements

Oracle Database feature compatibility is controlled by the COMPATIBLE initialization parameter, which enables or disables the use of certain features in the database. For the purposes of discussing transportable tablespaces, these are features that require specific structures within the datafiles. For example, if you want to upgrade to Oracle Database 12c from Oracle Database 11g R2, you may want to set COMPATIBLE to 11.2.0 for a short time. Thus, you can downgrade to version 11g R2 if you encounter problems in production, without requiring a restore and recover from backup because the datafile formats for version 12c are not usable on version 11g R2. Even though you may have tested the upgrade on a backup server, problems might not arise for some time.

When you create a transportable tablespace set, Oracle determines the minimum compatibility level of the target database and stores this value in the metadata for the transportable tablespace set. Starting with Oracle Database 11g, you can always transport a tablespace to another database with the same or higher compatibility level, regardless of the target platform.

In other words, even if you are running Oracle Database 12c with COMPATIBLE set to 11.0.0, you can transport in a tablespace from a database on a different platform that has COMPATIBLE set to 10.0.0.

Determining Endian Requirements

Oracle’s transportable tablespace feature may require an extra step depending on the underlying hardware platform. For example, on systems based on Intel processors, the value 2 is stored as 0x0200. This byte ordering is known as little-endian because the least significant byte is first. In contrast, a big-endian system stores bytes in order of most significant to least significant byte. Therefore, on a big-endian hardware platform, such as Oracle SPARC or IBM PowerPC, the value 2 is stored as 0x0002. Understandably, a conversion must be done on column data transported between platforms with different endian formats.

To determine the endian formats of all supported platforms, you can query the dynamic performance view V$TRANSPORTABLE_PLATFORM, as in this example:

This query also shows you all supported platforms for transportable tablespaces. If the value of ENDIAN_FORMAT is different, then you must use RMAN commands at the source or target database to convert the datafiles to the target database’s endian format. The required RMAN commands will be discussed later in this chapter. To determine the endian format of your platform, you can join V$DATABASE to V$TRANSPORTABLE_PLATFORM.

To convert datafiles from one endian format to the other, use the RMAN command CONVERT. This example, run in a Windows system, will read a datafile and write it out to a new name with an endian format appropriate for the named platform:

The converted file would then be manually copied to the destination system. Alternatively, files can be copied using procedures in the DBMS_FILE_TRANSFER package. This will detect the endian rules for the source and destination platforms and convert the files as they are copied.

The Tablespace Transport Set Must Be Self-Contained

All objects in the tablespaces to be copied from one database to another must be complete. If the object includes references to other objects, they must all be included. The supplied procedure DBMS_TTS can test for this. Examples of possible violations of this rule would be partitioned tables that are distributed across several tablespaces or indexes that are meaningless unless the table to which they refer is also included.

Transporting Tablespaces

Whether you use SQL commands or Cloud Control to transport a tablespace, the general steps are the same:

1.  Make the tablespace (or tablespaces) read-only on the source database.

2.  Use Data Pump export to extract the tablespace metadata from the source database.

3.  If the target does not have the same endian format, convert the datafiles. This can be done on either the source or destination platform.

4.  Copy the tablespace datafiles and metadata dump file from the source to the destination.

5.  Use Data Pump to import tablespace metadata into the target tablespace.

6.  Make the tablespace (or tablespaces) read-write on both the source and target databases.

Step 4 in the previous list can be accomplished with the DBMS_FILE_TRANSFER package. This contains procedures that can copy files between file systems, between ASM disk groups, between file systems and ASM disk groups, and from one server to another. A particular advantage in the context of tablespace transport is that if endian conversion is needed when copying from one server to another, the DBMS_FILE_TRANSFER procedures GET_FILE and PUT_FILE detect this and perform the conversion while copying the files.

Exercise 27-1: Transport a Tablespace Using SQL and PL/SQL    In this exercise, you will simulate transporting a tablespace by creating a tablespace, copying it, dropping it, and transporting it back into the database. You will need to connect with SYSDBA privileges.

1.  Create a tablespace and some objects within it. Name the datafile (in this case, a Windows filename; adjust this accordingly for Linux) rather than using Oracle Managed Files (OMF).

2.  Check for tablespace self-consistency and query the transport violations view.

The view is populated every time the check is run, reporting any issues such as dependent objects in other tablespaces. If there are no rows, then the transport can proceed.

3.  Make the tablespace read-only.

4.  Use the expdp utility to export the metadata describing the tablespace and its contents. You will need to provide a username and password of a highly privileged user, such as SYSTEM. The dump file will go to the default DATA_PUMP_DIR directory.

5.  Drop the tablespace (without deleting the datafile).

6.  Rename the datafile to make the simulation more realistic. Examples for Windows and Linux are as follows, respectively:

7.  Transport the tablespace into the database using the impdp utility from the operating system command line. This example uses a Linux path for the datafile:

8.  Confirm that the tablespace has been transported in and make it usable.

Transporting a Database

It is possible to transport an entire database. Conceptually, the technique is the same as tablespace transport: You copy the datafiles, converting them if necessary to take into account platform variations. The difference is that there is no preexisting destination database into which to import the transported tablespace. A limitation of this technique is that it cannot function across platforms with different endian-ness. The conversion method can handle the logical differences in structures between Oracle implementations on different platforms but not the physical difference of endian-ness.

These are the high-level steps:

1.  Open the source database in read-only mode.

The database must be consistent, with no incomplete transactions, and all datafiles must be synchronized to the same system change number (SCN). To ensure this state, the database must be shut down cleanly and then opened in read-only mode. Note that it is not possible to open in read-only mode following a SHUTDOWN ABORT.

2.  Copy the full set of datafiles.

A decision must be made on whether to convert the files on the source system or the destination system. For conversion on the source, the conversion process will create a new set of files in the new format, which will then be copied to the destination. For conversion on the destination, they will be copied before conversion. Note that the controlfile and the online log files must not be copied because new ones will be created at the destination.

3.  Convert the files to the destination format.

RMAN will perform the conversion. If the conversion is at the source, RMAN will use channels against the running source instance to write out the converted files. If the conversion is to be at the destination, this must be done after the following step.

4.  Start an instance for the destination database.

An instance requires a parameter file and a password file. Once these are created, the instance can be started in NOMOUNT mode. It is possible at this point to convert the datafiles, if that has not already been done.

5.  Create a controlfile for the destination instance.

The CREATE CONTROLFILE command will specify the names and locations of all the converted datafiles, the characteristics of the destination database’s online redo log, and the new database name. Then it will mount the newly created controlfile.

6.  Open the destination database with RESETLOGS.

Initialize the online redo log with ALTER DATABASE OPEN RESETLOGS.

This process can be accomplished manually, but RMAN provides a facility that may help: the CONVERT command. This command, to be run against the source, generates scripts for steps 3 and 5 and generates a parameter file for step 4. There are variations depending on whether the conversion is to be done on the source or the destination.

Exercise 27-2: Generate Database Transport Scripts    In this exercise, generate the scripts for transporting a database to another platform. It is assumed that the source platform (and therefore destination platform) is little-endian.

1.  Open the database in read-only mode.

Using SQL*Plus, connect AS SYSDBA.

2.  Generate the scripts for conversion at the destination.

Using RMAN, connected as SYS, run this command:

The suggested path assumes that the source is a Windows system. Study the output of the command. It is very instructive.

3.  Study the generated scripts.

In the nominated directory, you will find the scripts crdb_sundb.sql and cnvt_sundb.sql and a pfile. Study them carefully. They would, of course, need substantial editing to match the destination file system.

4.  Prepare for transport with conversion on the source.

This command (which assumes a Linux source system) will write out converted datafiles to the nominated directory:

Study the command’s output closely.

5.  Study the generated scripts.

In the nominated directory, you will find copies of the datafiles converted for use at the destination site, a parameter file for starting the destination instance, and the crdb_sundb.sql script. Study them closely.

Duplicate a Database

You can use several methods to duplicate an entire database on the same server or to a different server. The method you use depends on several factors, including the destination for the database copy, whether the target server is of the same operating system (OS) and endian-ness, and the requirements for database availability. The methods are to duplicate by copying datafiles or to duplicate by using backupsets. The duplication can rely on existing backups or image copies, or it can create the duplicate from the active source database. In contrast to the database transport method, there is no requirement for any downtime on the source system. Using a recovery catalog is not essential but may make the process easier.

The terminology is that the source database is known as the target, and the duplicate database to be created is the auxiliary.

Using a Duplicate Database

A duplicate database can be used for many things, including the following:

•  Testing backup and recovery procedures without disrupting the production database.

•  Testing a database upgrade.

•  Testing the effect of application upgrades on database performance.

•  Generating reports that would otherwise have a detrimental effect on the response time for an online transaction processing (OLTP) production system.

•  Exporting a table from a duplicate database that was inadvertently dropped from the production database and then importing it back into the production database; this assumes that the table is static or read-only. As of Oracle Database 12c, you can recover a single table from RMAN backups, but this method is preferable if you need more than just a few individual tables.

At a high level, these are the five possibilities for database duplication:

The choice of technique is dependent on the availability of a preexisting backup (which must be visible at the auxiliary site) and the availability of network connectivity between the target and the auxiliary.

Duplicate from the Active Database

This method requires a connection from the RMAN executable to both the target database and the auxiliary database. Connection to a recovery catalog is optional. There is no requirement for a backup to exist. The duplicate is created by copying the target datafiles to the auxiliary over Oracle Net.

The “push” method is based on image copies; the actual datafiles are copied from target to auxiliary. The “pull” method creates a backupset that is copied to the auxiliary. Generally, the push method requires more resources on the target, and the volume of data transferred is greater than when using a pull method. When you use one of these clauses in the DUPLICATE command, RMAN uses the “pull” method:

•  USING BACKUPSET

•  SECTION SIZE

•  Encryption clause

•  Compression clause

The following are the high-level steps to create a duplicate database on another host from the active database:

1.  Create a password file for the auxiliary instance.

2.  Create an initialization parameter file for the auxiliary instance.

3.  Start the auxiliary instance in NOMOUNT mode.

4.  Configure network connectivity between the target and the auxiliary.

5.  Run the RMAN DUPLICATE command.

Configure the Auxiliary Instance

Some preparation on the destination server is required before you perform the database duplication. First, you must create a password file for the auxiliary instance. Create the password file with the same SYS password as the target database (or simply copy the target password file) and name it according to the necessary convention with the auxiliary database name embedded within the password filename.

The next step is to create an initialization parameter file for the auxiliary instance. Only the DB_NAME parameter is required; all other parameters are theoretically optional. In most cases, you will create a parameter file based on a copy of the target parameter file and edit it according to the auxiliary environment. Table 27-1 lists the parameters you can specify in the auxiliary initialization file along with their descriptions and under what circumstances they are required; these are the parameters you would usually consider carefully.

Table 27-1    The Minimum Parameters that will Usually be Specified for an Auxiliary Instance

Note that the DB_FILE_NAME_CONVERT options for generating filenames at the auxiliary can also be specified when you run the DUPLICATE command, which will take precedence over any values in the parameter file.

Using the initialization parameter file just created, create an spfile and start the instance in NOMOUNT mode. If working on Windows, it will be necessary to use the ORADIM utility to create the Windows service under which the instance will run.

Establish Network Connectivity

The target database will (you can assume) already be registered with the database listener on the target’s host. The auxiliary host must also run a database listener, which will need to be configured with a static registration for the auxiliary instance. You cannot rely on dynamic instance registration because RMAN may have to stop and start the auxiliary. Both target and auxiliary servers will need a TNS resolution mechanism, usually a tnsnames.ora file with entries for both the target and the auxiliary instances.

Run the RMAN DUPLICATE Command

Here is the moment you’ve been waiting for: starting RMAN and performing the duplication process. There are variations in syntax for connecting concurrently to the target and the auxiliary and (optionally) to the catalog. This would be a typical connect string:

This example uses Oracle Net and password file authentication to connect to both the target and the auxiliary and to a catalog. Alternatively, you could use operating system authentication to connect to one of the databases and perhaps not use a catalog.

The DUPLICATE command can be simple. Here’s an example:

This command will create the duplicate and name it dupdb by copying the target’s datafiles as image copies. It says nothing about what filenames should be used at the auxiliary and will succeed only if one of these circumstances applies:

•  Oracle Managed Files are used to generate filenames.

•  The *_FILE_NAME_CONVERT parameters can generate meaningful names.

•  The directory structures are identical at both sites.

If none of these conditions applies, then the duplicate command will need to be more complex. Here’s an example:

In summary, here is what the DUPLICATE command does:

1.  Creates a controlfile for the duplicate database, using the names specified in the CONTROL_FILES instance parameter

2.  Copies the target datafiles to the auxiliary database from the running database

3.  Recovers the auxiliary using the target’s online (and if necessary archived) redo

4.  Opens the auxiliary database with the RESETLOGS option

5.  Generates a new DBID for the auxiliary database

Here are some other options available with the DUPLICATE command:

•  SKIP READONLY    Exclude read-only tablespaces from the copy operation.

•  SKIP TABLESPACE    Exclude specific tablespaces, except for SYSTEM and UNDO.

•  NOFILENAMECHECK    Don’t check for duplicate filenames between the source and destination databases.

•  OPEN RESTRICTED    When the destination database is ready, open it immediately with the RESTRICTED SESSION option.

•  NOOPEN    Do not open the auxiliary after creation

Active Duplication Using Backupsets

To enable the “pull” method, you must instruct RMAN to generate and transfer a backupset from the target, rather than transferring image copies of datafiles. This requires adding one or more keywords to the duplicate command. Here’s an example:

This example connects to the databases with the SYSBACKUP privilege rather than SYSDBA, using password file authentication. Then it specifies that the transfer of data should be encrypted, the key being protected by a password. The backupset will be compressed and divided into sections no larger than 10GB. The transfer of sections will be parallelized according to the number of configured channels on the target.

Duplicate from Backup

The key to backup-based duplication is that all necessary backups of datafiles and archive log files must be visible to the auxiliary instance, ideally in the same path as on the target. If the backups are stored in a network-attached device, this should be no problem. Otherwise, they must be copied to the auxiliary server. If it is not possible to expose the backups in the same path, the syntax does permit nominating the path where they exist.

If a target connection is possible, then RMAN can interrogate the target for all necessary information about the location of backups and the structure and state of the database. If a target connection is not possible but a catalog connection is possible, then RMAN can retrieve this information from the catalog. If neither a target nor a catalog connection is possible, then all this information must be provided in the duplicate command. When using backups for the duplication process, you need to configure RMAN channels to be used on the auxiliary database instance. The channel on the auxiliary instance restores the backups, so you need to specify the ALLOCATE command in the run block, as in this example:

Exercise 27-3: Duplicate a Database    This exercise assumes that you have a database named orcl that is running in archivelog mode and that it is an OMF database, which includes all datafiles, online log files, and controlfile copies named by OMF. It will be duplicated to a database named dupdb, running on the same server. Be aware of variations for Linux and Windows, and, of course, substitute names and paths and other literals as necessary.

1.  Create a password file for the auxiliary by copying the target password file.

Here’s how to do it on Linux:

Here’s how to do it on Windows:

2.  Create a dummy parameter file, with these parameters:

Here’s the Linux filename:

Here’s the Windows filename:

3.  Start the auxiliary instance.

Here’s how to do it on Linux:

Here’s how to do it on Windows:

4.  Configure Oracle Net.

Add this entry to the listener.ora file:

Restart the listener.

Add these entries to the tnsnames.ora file:

Test the configuration.

5.  Connect to the target and auxiliary with RMAN.

6.  Duplicate the database.

Observe the manner in which memory scripts are generated and executed. The scripts are instructive.

7.  It is almost inevitable that you will need several tries to get this exercise completed successfully. That is part of a database administrator’s life! Following a failed attempt, be aware that the duplication may have partially succeeded, and you may therefore need to delete various files before trying again, as well as restart the auxiliary instance.

Two-Minute Drill

Describe and Use Transportable Tablespaces and Databases

•  When transporting between platforms, both the source and destination platforms must be on Oracle’s list of supported platforms.

•  Oracle Database feature compatibility is controlled by the COMPATIBLE initialization parameter.

•  When you create a transportable tablespace set, Oracle determines the minimum compatibility level of the target database and stores this value in the metadata for the transportable tablespace set.

•  A conversion process must be performed for data columns transported between platforms with different endian formats.

•  To determine the endian formats of all supported platforms, you can query the dynamic performance view V$TRANSPORTABLE_PLATFORM.

•  When transporting a tablespace, the source tablespace must be read-only during the copy process and changed to read-write after import to the target database.

•  You use expdp and impdp to copy metadata describing a tablespace from one database to another.

•  The DBMS_FILE_TRANSFER PL/SQL package can perform endian conversion as it copies files.

Choose a Technique for Duplicating a Database

•  Cross-platform data transport requires tablespaces to be in READ ONLY mode to copy the tablespaces’ datafiles to the target system.

•  Only the metadata for a tablespace or entire database needs to be created for Data Pump export/import since the image copies themselves will be copied to the target database.

•  Use RMAN backupsets for file transfer speed, compression, and minimal downtime of the source tablespace or database.

Create a Backup-Based Duplicate Database

•  When you duplicate a database, the source database is copied to the duplicate database.

•  The source database is also known as the target database.

•  The duplicate database is also known as the auxiliary database.

•  Preparing to create a duplicate database includes creating a password file, ensuring network connectivity, and creating an initialization parameter file for the auxiliary instance.

•  At a minimum, you need to specify the DB_NAME value in the auxiliary instance’s initialization parameter file. You must also specify DB_BLOCK_SIZE if it is set explicitly in the target database.

•  The initialization parameter DB_FILE_NAME_CONVERT specifies the file system mapping for datafile and tempfile names.

•  The initialization parameter LOG_FILE_NAME_CONVERT specifies the file system mapping for online redo log files.

•  The initialization parameter CONTROL_FILES specifies the new names for all controlfiles, unless you are using Oracle Managed Files because OMF will name files for you.

•  The RMAN command for performing database duplication is DUPLICATE TARGET DATABASE.

•  The duplicate database has a new DBID, even if it has the same database name as the source database.

Duplicate a Database

•  You use the RMAN DUPLICATE command to duplicate a database.

•  You can use the “push” method to duplicate the database, which is based on image copies.

•  The “pull” method generates an RMAN backupset that permits use of compression and encryption.

•  You can specify FROM ACTIVE DATABASE in the DUPLICATE command to create the copy from an online database instead of from a database backup.

Self Test

1.  You are running Oracle Database 12c with the COMPATIBLE initialization parameter set to 12.0.0. What is the minimal compatibility level for transporting a tablespace from a database on a different platform? (Choose the best answer.)

A.  8.0

B.  10.0

C.  12.0

D.  11.0

E.  All of the above

2.  When transporting a tablespace, what is the purpose of DBMS_TTS.TRANSPORT_SET_CHECK? (Choose the best answer.)

A.  It ensures that the COMPATIBILITY level is high enough for the transport operation.

B.  It compares the endian level for the source and target databases and runs RMAN to convert the datafiles before transportation.

C.  It validates that the metadata for the tablespace does not have any naming conflicts with the target database schemas.

D.  It checks for tablespace self-consistency.

3.  You want to duplicate a database but maximize availability for the source database and all its tablespaces. What is the best method to use for this type of database duplication? (Choose the best answer.)

A.  Image copies

B.  Data Pump export with FULL=Y

C.  RMAN backupsets because then the downtime will be zero

D.  RMAN backupsets because then the downtime will be close to zero

4.  Identify the correct statement regarding duplicate databases created with RMAN. (Choose the best answer.)

A.  RMAN copies the source database to the target database, and both can have the same name.

B.  RMAN creates an auxiliary instance for the duration of the copy operation and drops it after the copy operation is complete.

C.  The auxiliary database is the same as the target database.

D.  RMAN copies the database from the target to the duplicate database, and both can have the same name.

E.  The source database must be shut down before you can start up the destination database.

5.  To create a duplicate database, put the following steps in the correct order:

1.  Start the auxiliary instance as NOMOUNT.

2.  Allocate auxiliary channels if necessary.

3.  Run the RMAN DUPLICATE command.

4.  Create a password file for the auxiliary instance.

5.  Ensure network connectivity to the auxiliary instance.

6.  Open the auxiliary instance.

7.  Start the source database in MOUNT or OPEN mode.

8.  Create an initialization parameter file for the auxiliary instance.

9.  Create backups or copy existing backups and archived log files to a common location accessible by the auxiliary instance.

A.  5, 4, 8, 1, 7, 9, 3, 2, 6

B.  4, 5, 8, 1, 7, 9, 2, 3, 6

C.  4, 5, 8, 1, 7, 9, 3, 2, 6

D.  5, 4, 1, 8, 7, 9, 2, 3, 6

6.  Which of the following clauses is not valid for the RMAN DUPLICATE command? (Choose the best answer.)

A.  SKIP OFFLINE

B.  SKIP READONLY

C.  SKIP TABLESPACE

D.  NOFILENAMECHECK

E.  OPEN RESTRICTED

7.  Identify the true statement regarding the status of the source database and the auxiliary database instance when duplicating a database based on a running instance. (Choose the best answer.)

A.  The active database must be in MOUNT mode, and the auxiliary instance must be in MOUNT mode.

B.  The active database must be in MOUNT or OPEN mode, and the auxiliary instance must be in NOMOUNT mode.

C.  The active database must be in OPEN mode, and the auxiliary instance must be in NOMOUNT mode.

D.  The active database must be in NOMOUNT mode, and the auxiliary instance must be in MOUNT mode.

Self Test Answers

1.      B. If the source and target databases are on different platforms, both the source and target must have a compatibility level of at least 10.0.
    A, C, D, and E are incorrect. For transporting between identical platforms, you need only COMPATIBLE=8.0. For transporting between databases with different block sizes, you need only COMPATIBLE=9.0.

2.      D. DBMS_TTS.TRANSPORT_SET_CHECK checks to ensure that there are no objects in the tablespace to be transported that have dependencies on objects in other tablespaces in the source database.
    A, B, and C are incorrect. They are not valid uses for DBMS_TTS.TRANSPORT_SET_CHECK.

3.      D. Using RMAN for duplicating a database with backupsets has the advantage of keeping the tablespaces available as much as possible (in READ WRITE mode). Successive incremental backups will get smaller and smaller until the last backup in which you must make the tablespaces read-only to perform the last incremental backup to be applied to the target database.
    A, B, and C are incorrect. A is incorrect because image copies are a valid method for transporting a tablespace or database, but the tablespace’s datafiles must be in READ ONLY mode to perform the image copy. B is incorrect because Data Pump can back up an entire database, but it is a logical backup, not a physical backup. C is incorrect because there will still be some unavailability of the tablespace to perform the last incremental backup to be applied to the target database’s copy of the tablespace.

4.      D. You can keep the same name because RMAN creates a new DBID, and therefore you can use the same recovery catalog for both databases.
    A, B, C, and E are incorrect. A is incorrect because the target database is the same as the source database. B is incorrect because RMAN does not drop the auxiliary instance or database after the copy operation is complete. C is incorrect because the target database is the source database and the auxiliary database is the destination database. E is incorrect because both databases can be open at the same time, even on the same host and with the same recovery catalog.

5.      B. These steps are in the correct order.
    A, C, and D are incorrect because they are in the wrong order.

6.      A. The SKIP OFFLINE option is not valid for the DUPLICATE command.
    B, C, D, and E are incorrect. B is incorrect because the SKIP READONLY clause excludes read-only tablespaces. C is incorrect because SKIP TABLESPACE excludes one or more tablespaces from the copy operation; you cannot skip the SYSTEM or UNDO tablespace. D is incorrect because NOFILENAMECHECK doesn’t check for duplicate filenames between the source and destination. E is incorrect because OPEN RESTRICTED opens the destination database with the RESTRICTED SESSION option.

7.      B. To duplicate a database based on a running instance, the source database can be in either MOUNT or OPEN mode; since the auxiliary database does not yet have even a controlfile, it must be opened in NOMOUNT mode.
    A, C, and D are incorrect. A is incorrect because the auxiliary instance does not have a controlfile right away, so it cannot be started in MOUNT mode. C is incorrect because the active database can also be in MOUNT mode. D is incorrect because the database can’t be duplicated if the source database is in NOMOUNT mode, and the auxiliary instance can’t be in MOUNT mode either!