ALTER DATABASE DEFAULT TEMPORARY TABLESPACE temp2;
3. Make sure No sessions are using your Old Temp tablespace
a. Find Session Number from V$SORT_USAGE: SELECT USERNAME, SESSION_NUM, SESSION_ADDR FROM V$SORT_USAGE;
b. Find Session ID from V$SESSION:
If the resultset contains any tows then your next step will be to find the SID from the V$SESSION view. You can find session id by using SESSION_NUM or SESSION_ADDR from previous resultset.
SELECT SID, SERIAL#, STATUS FROM V$SESSION WHERE SERIAL#=SESSION_NUM; OR SELECT SID, SERIAL#, STATUS FROM V$SESSION WHERE SADDR=SESSION_ADDR;
c. Kill Session:
Now kill the session with IMMEDIATE.
ALTER SYSTEM KILL 'SID,SERIAL#' IMMEDIATE;
4. Drop temp tablespace
DROP TABLESPACE temp INCLUDING CONTENTS AND DATAFILES;
6 Move Tablespace Temp, back to new temp tablespace
ALTER DATABASE DEFAULT TEMPORARY TABLESPACE temp;
7. Drop temporary for tablespace temp
DROP TABLESPACE temp2 INCLUDING CONTENTS AND DATAFILES;
No need to do shutdown when drop temp tablespace and the recreate it. If something happen with temp tablespaces e.g. : crash, corrupt, etc. Oracle database will ignore the error, but DML (insert,update,delete) and SELECT Query will suffer.
Error :
SQL> select TABLESPACE_NAME, FILE_NAME from
dba_temp_files ;
select TABLESPACE_NAME, FILE_NAME from dba_temp_files
*
ERROR at line 1:
ORA-01157: cannot identify/lock data file 513 - see DBWR
trace file
Check Context Files Version are the same in Database
select path,status,serial_number,version
from apps.fnd_oam_context_files
where name not in ('TEMPLATE','METADATA') and (status is null or status !='VALID')
order by path, version;
Check Ports in Run Edition
SELECT extractValue(XMLType(TEXT),'//host[@oa_var="s_hostname"]'),
extractValue(XMLType(TEXT),'//oacore_server_ports'),
extractValue(XMLType(TEXT),'//forms_server_ports'),
extractValue(XMLType(TEXT),'//oafm_server_ports'),
extractValue(XMLType(TEXT),'//forms-c4ws_server_ports'),
extractValue(XMLType(TEXT),'//oaea_server_ports')
from apps.fnd_oam_context_files
where name not in ('TEMPLATE','METADATA')
and (status is null or status !='H')
and EXTRACTVALUE(XMLType(TEXT),'//file_edition_type')='run'
and CTX_TYPE = 'A';
Check Ports in Patch Edition
SELECT extractValue(XMLType(TEXT),'//host[@oa_var="s_hostname"]'),
extractValue(XMLType(TEXT),'//oacore_server_ports'),
extractValue(XMLType(TEXT),'//forms_server_ports'),
extractValue(XMLType(TEXT),'//oafm_server_ports'),
extractValue(XMLType(TEXT),'//forms-c4ws_server_ports'),
extractValue(XMLType(TEXT),'//oaea_server_ports')
from apps.fnd_oam_context_files
where name not in ('TEMPLATE','METADATA')
and (status is null or status !='H')
and EXTRACTVALUE(XMLType(TEXT),'//file_edition_type')='patch'
and CTX_TYPE = 'A';
The online patching cycle consists of five phases which are executed in order. Example of a typical online patching cycle:
source /EBSapps.env run adop phase=prepare adop phase=apply patches=123456 adop phase=finalize adop phase=cutover source /EBSapps.env run adop phase=cleanup
Note that after cutover the command line environment should be re-loaded as the run edition file system has changed.
In a multi-node deployment, adop commands are only executed from the primary node. The primary adop session uses remote execution to automatically perform required actions on any secondary node.
Multiple phases of adop can be executed in a single line command. Example of combined finalize/cutover/cleanup:
adop phase=finalize,cutover,cleanup
Prior to cutover, it is possible to execute additional “apply” and “finalize” phases as needed. Example of applying multiple patches using separate apply commands:
Note that it is possible to apply additional patches after running the finalize phase, but if you do so then you will need to run the finalize phase again. Finalize must always be run immediately prior to cutover.
ADOP Common Parameters
workers= [default: computed]
Number of parallel workers used to execute tasks. Default value is computed principally according to number of available CPU cores.
input_file=
adop parameters can be specified in a text file, with one
=
on each line of the file. Command line parameters override input file parameters.
Controls the level of diagnostic log detail displayed on the console output. Each log message is tagged with a level:
1) statement – is only used for debugging. 2) procedure – is only used for debugging high level procedures. 3) event – is used to display informational messages in normal processing. This is the default value. 4) warning – is used to indicate an internal error that is handled by the system and does not affect processing. 5) error – indicates an action failed and will need to be reviewed by the user, but the system was able to continue processing. 6) unexpected – indicates an unrecoverable error that halts processing and requires user intervention before processing can continue.
Setting loglevel will display messages at that level and higher.
prompt=(yes|no) [default: yes]
Specifies whether adop should prompt for user input on warnings. By default adop will ask user whether to continue or exit on some warning messages. If this parameter is set to “no” adop will remain fully non-interactive, and will continue past any warning messages without user confirmation.
Below is the list of Diagnostic Parameters. Normally these parameters are not used, until unless directed by Oracle Support:
allowcoredump=(yes|no) [default: no]
Specifies whether adop should create a core dump if it crashes. This option should only be used if directed by support.
analytics=(yes|no) [default: no]
Controls whether adop writes additional reports with information that might be helpful in some diagnostic situations. This option should not be used unless directed by Support.
defaultsfile= [default: adalldefaults.txt]
Name of the response file providing default parameter values for non-interactive execution of adadmin and adop. The file must be in the$APPL_TOP/admin/$TWO_TASK directory in both run edition and patch edition file systems. The default file “adalldefaults.txt” is maintained by AutoConfig and normally you should not need to change any values.
ADOP Prepare Phase
Prepare phase will be create a new Online Patching Cycle ID and start with Syncronizing the File System of Run into Patch. This will be followed by creation of Patch Edition in database.
The phase has below specific parameter:
skipsyncerror=(yes|no) [default: no]
It specifies whether to ignore errors that may occur during incremental file system synchronization. This might happen if you applied a patch in the previous patching cycle that had errors but decided to continue with the cutover. When the patch is synchronized on the next patching cycle, the apply errors may occur again, but can be ignored.
After complition of Prepare Phase you can start with migration of customization to the Patch Edition File System and you can apply Application Technology Stack Patches i.e. Oracle Home (10.1.2) Patches and Weblogic Patches. This can be done until you are completed with Cutover Phase.
ADOP Apply Phase
This is the phase where in patches are actully applied.
The phase has below specific parameters:
apply=(yes|no) [default: yes]
Controls whether adop actually applies the patch. You can specify “apply=no” to run adop in test mode, where the patch will not actually be applied, and adop will record what it would have done in the log.
patches=[,…] patches=:[,:…]
This parameter specifies a comma-separated list of patches to be applied. Patches can be specified either as the patch number or by the patch directory and driver file. All patches are expected to be in the $PATCH_TOP directory on all tiers. Patches are applied serially unless the merge=yes parameter is specified.
patchtop= [default: $PATCH_TOP]
Path to a user-specified directory where patches are unzipped. The default and recommend location is the $PATCH_TOP directory automatically created by the install. When using an alternate patchtop you must ensure that the location is not within the editioned file systems (fs1, fs2) and is accessible by the same path for all nodes of a multi-node deployment.
It is used to specify how the patch will be applied. There 3 option can be explained as below:
online – It will apply a patch to the patch edition during an online patching cycle. downtime – It will apply a patch to the run edition when application services are down. When using this mode, you only run the apply phase. hotpatch – apply a patch to the run edition when application services are up. When using this mode, you only run the apply phase
In downtime mode, adop will validate that application services are shutdown before apply the patch. The patch will be applied to the run edition of the system. Downtime mode patching does not use an online patching cycle and hence if there is an online patching cycle in progress. The process of applying a patch in downtime mode completes more quickly than in online mode, but at the cost of increased system downtime.
In hotpatch mode, adop will apply the patch to the run edition of the system while application services are still running. Patches that can be safely applied in hotpatch mode (such as NLS and Online Help patches) will document this in the patch readme. Hotpatch mode cannot be used if there is an online patching cycle in progress.
merge=(yes|no) [default: no]
Indicates whether adop should merge a list of patches before applying. By default, adop will apply a list of patches serially in the order specified. You can also use AD Merge Patch to merge multiple patches ahead of the apply command.
restart=(yes|no) [default: no]
Use restart=yes to resume the previous failed apply command from where processing terminated. If an apply command fails, check the log files for further information. If the problem can be corrected, you can then restart the apply command where it left off using the restart parameter.
When restarting a failed apply it is important to use the same parameters as the failed command, with only the addition of the restart=yes parameter.
abandon=(yes|no) [default: no]
Use abandon=yes to abandon the previous failed apply command and start a new apply command. Note that any changes made to the system by the failed command will remain in effect. The abandon flag is most useful when applying a replacement patch for the failing patch. If a patch fails to apply and there is no replacement patch, you may also abort the online patching cycle. See abort phase later in this blog.
options=[,…]
Options can be specified in a comma-separated list to control advanced features when a patch is applied. These options are normally not needed unless specified by documentation or support. Note that these options can be prefixed with “no”, e.g. “nocheckfile”, to disable the behavior, and for some options “no” is the default.
checkfile [default: checkfile] – Skip running exec, SQL, and exectier commands if they are recorded as already run.
compiledb [default: compiledb] – Compile invalid objects in the database after running actions in the database driver.
compilejsp [default: compilejsp] – Compile out-of-date JSP files, if the patch has copy actions for at least one JSP file.
copyportion [default: copyportion] – Run commands found in a copy driver.
databaseportion [default: databaseportion] – Run commands found in a database driver.
generateportion [default: generateportion] – Run commands found in a generate driver.
validate [default: novalidate] – Connect to all registered Oracle E-Business Suite schemas at the start of patch application.
phtofile [default: nophtofile] – Save patch history to file
forceapply [default: noforceapply] – Reapply a patch that has already been applied. Useful in combination with “nocheckfile” option to rerun files that have already been executed.
flags=[,…]
Flags can be specified in a comma-separated list to control advanced features when applying a patch. Note that these flags can be prefixed with “no”, e.g. “nologging”, to disable the behavior and for some flags “no” is the default.
hidepw [default: hidepw] – Omit the “HIDEPW:” comments in the log file.
trace [default: notrace] – Log all database operations to a trace file.
logging [default: nologging] – Create indexes in LOGGING or NOLOGGING mode.
autoskip [default: noautoskip] – To proceed with adpatch execution even if some driver actions failed. Failed actions are recorded in a log file.
preinstall=(yes|no) [default: no]
Allows a patch to be applied to the file system without connecting to the database. Do not use this parameter unless directed by Oracle.
wait_on_failed_job=(yes|no) [default: no]
Controls whether adop apply command exits when all workers have failed. Instead of exiting, you can force adop to wait, and use the “adctrl” to retry failed jobs.
printdebug=(yes|no) [default: no]
Controls whether to display additional debugging information.
uploadph=(yes|no) [default: yes]
Controls whether to upload patch history information to database after applying the patch.
ADOP Finalize Phase
Finalize Phase is performed to keep the system ready for Cutover phase. This phase perform various activities like:
1. Compiling Invalid Objects 2. Generating driverd objects 3. Pre-compute DDL to be run during Cutover
Finalize Phase have below specific parameters:
finalize_mode=(full|quick) [default: quick]
Quick mode will provide the shortest execution time, by skipping non-essential actions. Full mode performs additional actions such as gathering statistics that may improve performance after cutover.
ADOP Cutover Phase
Cutover phase perform below activities:
1. Bring down Application services 2. Promote Patch File System to the Run File System. 3. Promote Patch Database Edition to the Run Database Edition. 4. Perform Maintenance task 5. Bring up application services
Cutover Phase have below specific parameters:
mtrestart=(yes|no) [default: yes]
Specifies whether to restart application tier servers after cutover. Leave at default unless you need to perform any manual steps during downtime.
cm_wait= [default: forever]
Specifies the number of minutes to wait for Concurrent Manager shutdown. Adop cutover starts by requesting a concurrent manager shutdown and then waits for in-progress requests to complete. If Concurrent Manager does not shutdown within the specified time limit, remaining concurrent requests will be killed and cutover will proceed.
Note that any concurrent requests killed during forced shutdown may need to be manually re-submitted after cutover. To avoid killing concurrent requests, schedule cutover at a time of minimal user activity or manually shutdown Concurrent Manager in advance of cutover.
ADOP Cleanup Phase
This phase will cleanup the Application and Database for the next Patching Cycle.
Quick mode provides the shortest execution time, by skipping non-essential actions. Standard mode performs additional processing to drop obsolete code objects from old editions. Full mode performs additional processing to drop empty database editions and unused table columns.
Cloning the Patch Edition File System
The patch edition file system is normally synchronized with the run edition file system during the prepare phase. There are some cases where it is helpful or required to manually re-clone the patch edition file system from the run edition.
1) After aborting an online patching cycle. 2) After manually changing the run edition file system. 3) After patching middle-tier technology components. 4) After applying an EBS RUP.
By re-cloning the patch edition file system, you can be certain that it is correctly synchronized, and also minimize any synchronization delay that would normally occur on the next prepare command. This can be down by below command:
adop phase=fs_clone
If there is any error you must examine log files and correct the problem, then restart the fs_clone by running the command again. User below command if fs_clone does not restart correctly and you want to force the process to restart from the beginning.
adop phase=fs_clone force=yes
Aborting an online patching cycle
If an online patching cycle encounters problems that cannot be fixed immediately you can abort the patching cycle and return to normal runtime operation. Aborting an online patching cycle can be issue as below:
adop phase=abort
Note that once you are done with Cutover phase, you can abort ADOP Cycle.
The abort command drops the database patch edition and returns the system to normal runtime state. Immediately following abort, you must also run a full cleanup and fs_clone operation to fully remove effects of the failed online patching cycle.
Dropping old database editions
As online patching cycles are completed, the system will build up a number of old database editions. When the number of old database editions reaches about 25, you should consider running a special maintenance operation to drop old database editions. This can be down as below:
This maintenance operation will take much longer than a typical online patching cycle, and should only be performed when there is no immediate need to start a new online patching cycle. The actualize all and full cleanup can be done separately as shown above, or can be executed in conjunction with an online patching cycle.
Log File Location
The adop log files are located on the non-editioned file system (fs_ne), under:
$NE_BASE/EBSapps/log/adop//__
Session
The adop utility maintains a session for each online patching cycle. A new session is created when you run the prepare phase. Each session is given a numeric ID number. The session is used to maintain the state of the online patching cycle across the various adop phases and commands. You can only run one adop session at a time on a particular Oracle E-Business Suite system
SQL> select process,status,sequence# from v$managed_standby;
PROCESS STATUS SEQUENCE#
--------- ------------ ----------
ARCH CLOSING 1030
ARCH CLOSING 1007
ARCH CLOSING 1028
ARCH CLOSING 1029
LNS WRITING 1031 Example result on Standby:
SQL> select thread#,max(sequence#) from v$archived_log where applied='YES' group by thread#;
SQL> select process,status,sequence# from v$managed_standby;
PROCESS STATUS SEQUENCE#
--------- ------------ ----------
ARCH CONNECTED 0
ARCH CONNECTED 0
ARCH CONNECTED 0
ARCH CONNECTED 0
RFS IDLE 0
RFS IDLE 0
RFS IDLE 0
MRP0 APPLYING_LOG 1971 ß Current shipping log a Standby
To Identify real gap between Primary & Standby use below query on Standby:
SQL> SELECT ARCH.THREAD# "Thread", ARCH.SEQUENCE# "Last Sequence Received", APPL.SEQUENCE# "Last Sequence Applied", (ARCH.SEQUENCE# - APPL.SEQUENCE#) "Difference" FROM (SELECT THREAD# ,SEQUENCE# FROM V$ARCHIVED_LOG WHERE (THREAD#,FIRST_TIME ) IN (SELECT THREAD#,MAX(FIRST_TIME) FROM V$ARCHIVED_LOG GROUP BY THREAD#)) ARCH, (SELECT THREAD# ,SEQUENCE# FROM V$LOG_HISTORY WHERE (THREAD#,FIRST_TIME ) IN (SELECT THREAD#,MAX(FIRST_TIME) FROM V$LOG_HISTORY GROUP BY THREAD#)) APPL WHERE ARCH.THREAD# = APPL.THREAD# ORDER BY 1;
Thread Last Sequence Received Last Sequence Applied Difference
---------- ---------------------- --------------------- ----------
1 3936 3936 0
2 4127 4127 0
3 4089 4088 1
To Identify where the SYNC stuck, use below query on Standby:
SQL> set lines 400
SQL> select sequence#,process,pid,status,client_process,block#, active_agents, known_agents,BLOCKS FROM gv$managed_standby ORDER BY thread#, pid;
Utility /Script To Check The Techstack Component Versions (Forms, Http Server, JDK, Framework, Database, etc
Oracle Applications Technology Stack - Version 11.5.10.0 to 12.2.3 [Release 11.5 to 12.2]
Information in this document applies to any platform.
GOAL
How to find the versions of technology stack components (Forms, iAS, Framework, JDK, OJSP, Database, etc.)?
SOLUTION
On Application Tier
Establish the needed environment parameters by sourcing the Applications environment file as the owner of the application tier file system.
Ensure "APPLRGF" variable is set in environment. If not, set it to the same value as "APPLTMP".
Navigate to /patch/115/bin. Run the utility/command as follows :
Operation System Command Line
Unix or Linux$ADPERLPRG $FND_TOP/patch/115/bin/TXKScript.pl \
-script=$FND_TOP/patch/115/bin/txkInventory.pl -txktop=$APPLTMP \
-contextfile=$CONTEXT_FILE \
-appspass=apps \
-outfile=$APPLTMP/Report_App_Inventory.html
Note:
- Run the above command in single line
- Remove the '\' after each parameter while you run this command in a single line
- Supply the apps user password as is applicable for parameter "-appspass"
Windows
%ADPERLPRG% %FND_TOP%\patch\115\bin\TXKScript.pl
-script=%FND_TOP%\patch\115\bin\txkInventory.pl
-txktop=%APPLTMP% -contextfile=%CONTEXT_FILE%
-appspass=apps
-outfile=%APPLTMP%\Report_App_Inventory.html
Note:
- Run the above command in single line
- Remove the '\' after each parameter while you run this command in a single line
- Supply the apps user password as is applicable for parameter "-appspass"
Where:
txktopTemporary working directory use by Perl Modules. Should not be an empty string.
contextfileLocation of the context file. If not passed, default is picked from the environment.
appspassAPPS schema password. If not passed, default password is used.
outfileLocation for the report being generated. If not passed, the default location is /TXK
To generate the report in text format, the parameter "-reporttype=text" needs to be passed to the above commands. For example:
outfile=$APPLTMP/Report_App_Inventory.html -reporttype=text
Once the command executes successfully, it should generate the report file in the location specified for "outfile" parameter in above script
Incase you have more than one application tier's (multi-node architecture), follow the steps 1-4 on each of the Application tiers
Upload the report output file (default: $APPLTMP/Report_App_Inventory.html )to Oracle Support for review
On Database Tier
Establish the needed environment parameters by sourcing the Database environment file as the owner of the Database tier file system. |
Ensure "ORACLE_HOME" variable is set in environment and correctly pointing to your database ORACLE_HOME.
Navigate to /appsutil/bin. Run the utility/command as below (all on a single line):
Operation System Command Line
Unix or Linux
$ADPERLPRG $ORACLE_HOME/appsutil/bin/TXKScript.pl
-script=$ORACLE_HOME/appsutil/bin/txkInventory.pl -txktop=$ORACLE_HOME/appsutil/temp
-contextfile=$CONTEXT_FILE
-appspass=apps
-outfile=$ORACLE_HOME/appsutil/temp/Report_DB_Inventory.html
Note:
- Run the above command in single line
- Supply the apps user password as is applicable for parameter "-appspass"
Windows
%ADPERLPRG% %ORACLE_HOME%/appsutil/bin/TXKScript.pl
-script=%ORACLE_HOME%/appsutil/bin/txkInventory.pl -txktop=%ORACLE_HOME%/appsutil/temp
-contextfile=%CONTEXT_FILE%
-appspass=apps
-outfile=%ORACLE_HOME%/appsutil/temp/Report_DB_Inventory.html
Note:
- Run the above command in single line
- Supply the apps user password as is applicable for parameter "-appspass"
Where
txktopTemporary working directory use by Perl Modules. Should not be an empty string.
contextfileLocation of the context file.
appspassAPPS schema password.
outfileLocation for the report being generated.
To generate the report in text format, the parameter "-reporttype=text" needs to be passed to the above commands. For example:
outfile=$ORACLE_HOME/appsutil/temp/Report_DB_Inventory.html -reporttype=text
Once the command executes successfully, it should generate the report file in the location specified for "outfile" parameter in above script
Upload the report output file (default: $ORACLE_HOME/appsutil/temp/Report_DB_Inventory.html ) to Oracle Support for review
RMAN
11GR2 : DUPLICATE Without Target And Recovery Catalog Connection
APPLIES
TO:
Oracle
Database - Enterprise Edition - Version 11.2.0.1 and later
Information
in this document applies to any platform.
***Checked
for relevance on 10-Dec-2015***
GOAL
Rman
11g release 2 provides us the flexibility of creating the rman duplicate
without connecting to the target database and recovery catalog.
All
rman needs here is the location of the backup pieces which is accessible and
rman reads the backup pieces and restores the spfile,controlfile,datafiles and
archivelog files to perform the duplicate operation.
An
example for this kind of duplicate operation is:
RMAN>
DUPLICATE DATABASE TO dup11r2
UNTIL TIME
"TO_DATE('29-MAY-2010 14:16:42','DD-MON-YYYYHH24:MI:SS')"
SPFILE
set
control_files='D:\dup11r2\c1.ctl'
set
db_file_name_convert='D:\Database\Ora11g2\ora11g2','d:\dup11r2'
set
log_file_name_convert='D:\Database\Ora11g2\ora11g2','d:\dup11r2'
BACKUP LOCATION 'D:\dup11r2';
#
Here use of the BACKUP LOCATION clause identifies the type of duplication as
having no target connection, no recovery catalog and being backup-based.
Process
involved in this type of duplicate database
++
Rman restores the spfile from the backup pieces located in the mentioned
location.
++
Once the spfile is restored, rman sets appropriate values to the parameters
mentioned the duplicate command. For example:
db_name
control_files
db_file_name_convert
log_file_name_convert
etc
...
Once
done, rman restarts the instance to no mount so that the changes can take
effect.
++
Rman now changes the value of the parameter db_name to the target database name
to achieve the restore of the controlfile. The restored controlfile will have
the db_name as of the target database name and since we cannot have a different
db_name in the spfile and in the controlfile, rman will have to set the
parameter db_name to the target database name and perform the restore of the
datafiles and controlfiles.
Also
here if the duplicate is happening on the same machine, then 2 controlfiles
with the same db_name cannot be mounted. In order to achieve this the auxiliary
instance will have the parameter db_unique_name set to a unique value. Rman
takes care of this sets the db_uniqiue_name to the database name specified for
the auxiliary database.
++
After the above operation,controlfile is restored from the backup piece to the
location provided for the parameter control_files.
++
Now Rman restores the datafiles to the locations specified by the parameter
log_file_name_convert.
++
Recovery of the datafiles are performed.
++
Once the recovery is completed, rman shuts down the database to reset the value
of db_name to the value provided for the auxiliary database.
++
Once this is done, the database is taken to no mount phase and the controlfile
is recreated to change the database name and the id.This is followed by the
database getting opened with resetlogs.
The
steps involved in creating the duplicate database are as follows
1)
Take a backup of the spfile, controlfile, database, and archivelogs as follows:
RMAN>
backup spfile ;
RMAN>
backup database include current controlfile plus archivelog ;
2)
Making the backup pieces available for duplicate operation.
++
If the duplicate is going to happen on different server, move the backup pieces
to a new server using commands like ftp,scp etc.
++
If the duplicate is going to happen on the same server as target, then you can
either retain them in the same location where the backup was done or copy it to
a required location.
3)
Create a password file for the auxiliary instance.
For
unix copy the password file from the target database to $ORACLE_HOME/dbs and
rename it.
For
windows copy the password file from the target database to
%ORACLE_HOME/database and rename it.
4)
Create a initialization parameter for the auxiliary instance with only one
parameter DB_NAME.
DB_NAME=dup11r2
5)
Now start the auxiliary instance to no mount mode.
Unix
Example
============
Just
set the environment variables and start the instance.
%
export ORACLE_SID=dup11r2
%
export ORACLE_HOME=/home/oracle/ora11g
%
export PATH=$ORACLE_HOME/bin:$PATH
%
sqlplus "/as sysdba"
SQL
> startup nomount
Windows
Example
===============
Create
a service and then set the necessary environment variables and start the
instance.
%
oradim -new -sid dup11r2
set
ORACLE_SID=dup11r2
set
ORACLE_HOME=D:\Orahome\Ora11gr2
set
PATH=D:\Orahome\Ora11gr2\bin;%PATH%
%
sqlplus "/as sysdba"
SQL
> startup nomount
6)
Connect to the auxiliary instance from RMAN and perform the rman duplicate as
follows:
EXAMPLE
=======
%
rman auxiliary /
RMAN
> DUPLICATE DATABASE TO dup11r2
UNTIL
TIME "TO_DATE('29-MAY-2010 14:16:42','DD-MON-YYYY HH24:MI:SS')"
SPFILE
set
control_files='D:\dup11r2\c1.ctl'
set
db_file_name_convert='D:\Database\Ora11g2\ora11g2','d:\dup11r2'
set
log_file_name_convert='D:\Database\Ora11g2\ora11g2','d:\dup11r2'
