Wednesday, July 29, 2015
Tuesday, July 14, 2015
Oracle EBS apache issue/error : 500 Internal Server Error
Oracle EBS 12.x apache issue/error : 500 Internal Server Error
Fix/Solution:
cd $INST_TOP/ora/10.1.3/j2ee/oacore/config
vi oc4j.properties
Fix/Solution:
cd $INST_TOP/ora/10.1.3/j2ee/oacore/config
vi oc4j.properties
| LONG_RUNNING_JVM=false >>> Change the Value to false |
Monday, July 13, 2015
RMAN-06094: datafile must be restored // RMAN-06094: datafile 50 must be restored
RMAN-06094: datafile <dbfNo.> must be restored
Error Message:
RMAN> RECOVER DATABASE NOREDO;
Starting recover at 13-JUL-15
using channel ORA_DISK_1
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 07/13/2015 05:27:38
RMAN-06094: datafile 50 must be restored
CAUSE:
Backup of datafile <dbf> not available in RMAN catalog.
Solution:
Take fresh backup and restore by below comamnd,
RMAN>RECOVER DATAFILE 15;
Example:
RMAN> restore datafile 50;
Starting restore at 13-JUL-15
using channel ORA_DISK_1
channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00050 to /prod/data/data01/a_txn_data11.dbf
channel ORA_DISK_1: reading from backup piece /prod/backup/standby/Jul_13/FORSTANDB_dbf5028qbu25o_1_1
channel ORA_DISK_1: piece handle=/prod/backup/standby/Jul_13/FORSTANDB_dbf5028qbu25o_1_1 tag=DBF15
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:02:25
Finished restore at 13-JUL-15
RMAN duplicate failing with Error RMAN-05001: auxiliary file name '' conflicts with a file used by the target database
RMAN duplicate failing
RMAN-05001: auxiliary file name '<dbfile>' conflicts with a file used by the target database
Error Message:
RMAN-05001: auxiliary file name /prod/data/data02/a_uie_uid57.dbf conflicts with a file used by the target database
RMAN-05001: auxiliary file name /prod/data/data02/a_uie_uid56.dbf conflicts with a file used by the target database
RMAN-05001: auxiliary file name /prod/data/data01/maximo_interfaz_03.dbf conflicts with a file used by the target database
RMAN-05001: auxiliary file name /prod/data/data02/a_uie_data74.dbf conflicts with a file used by the target database
RMAN-05001: auxiliary file name /prod/data/data02/a_uie_data73.dbf conflicts with a file used by the target database
RMAN-05001: auxiliary file name /prod/data/data02/a_uie_data72.dbf conflicts with a file used by the target database
...
CAUSE:
Production and Auxiliary have same directory structure and are running on two different machines.
RMAN must be told not check that the target datafiles are sharing the same names as the duplicated files being created.
Otherwise, the following errors will be returned:
Solution :
User CLAUSE "NOFILENAMECHECK" in Rman Duplicate command before parameter 'DB_FILE_NAME_CONVERT' and 'LOG_FILE_NAME_CONVERT'
Example:
DUPLICATE TARGET DATABASE FOR STANDBY FROM ACTIVE DATABASE
NOFILENAMECHECK
PARAMETER_VALUE_CONVERT '/prod/data','/prod/data','/prod/data','/prod/data'
SET "db_unique_name"="prod1stby" COMMENT "Is a duplicate"
set db_file_name_convert='/prod/oracle/','/prod/oracle/','/prod/oracle/','/prod/oracle/'
NOTE: Do not use NOFILENAMECHECK when target and destination database are on the same box because datafiles from target database will be overwritten !!
RMAN-05001: auxiliary file name '<dbfile>' conflicts with a file used by the target database
Error Message:
RMAN-05001: auxiliary file name /prod/data/data02/a_uie_uid57.dbf conflicts with a file used by the target database
RMAN-05001: auxiliary file name /prod/data/data02/a_uie_uid56.dbf conflicts with a file used by the target database
RMAN-05001: auxiliary file name /prod/data/data01/maximo_interfaz_03.dbf conflicts with a file used by the target database
RMAN-05001: auxiliary file name /prod/data/data02/a_uie_data74.dbf conflicts with a file used by the target database
RMAN-05001: auxiliary file name /prod/data/data02/a_uie_data73.dbf conflicts with a file used by the target database
RMAN-05001: auxiliary file name /prod/data/data02/a_uie_data72.dbf conflicts with a file used by the target database
...
CAUSE:
Production and Auxiliary have same directory structure and are running on two different machines.
RMAN must be told not check that the target datafiles are sharing the same names as the duplicated files being created.
Otherwise, the following errors will be returned:
Solution :
User CLAUSE "NOFILENAMECHECK" in Rman Duplicate command before parameter 'DB_FILE_NAME_CONVERT' and 'LOG_FILE_NAME_CONVERT'
Example:
DUPLICATE TARGET DATABASE FOR STANDBY FROM ACTIVE DATABASE
NOFILENAMECHECK
PARAMETER_VALUE_CONVERT '/prod/data','/prod/data','/prod/data','/prod/data'
SET "db_unique_name"="prod1stby" COMMENT "Is a duplicate"
set db_file_name_convert='/prod/oracle/','/prod/oracle/','/prod/oracle/','/prod/oracle/'
NOTE: Do not use NOFILENAMECHECK when target and destination database are on the same box because datafiles from target database will be overwritten !!
Saturday, July 11, 2015
Standby MRP crashing due to ORA-00379: no free buffers available in buffer pool DEFAULT for block size 16K
Cause :
SQL> show parameter 16k
NAME TYPE
------------------------------------ --------------------------------
VALUE
------------------------------
db_16k_cache_size big integer
0 <<<<<<<<<<< Not set value
Cause :
SQL> show parameter 16k
NAME TYPE
------------------------------------ --------------------------------
VALUE
------------------------------
db_16k_cache_size big integer
0 <<<<<<<<<<< Not set value
SQL>
Solution :
1.)
SQL> alter system set db_16k_cache_size=512M scope=SPFILE;
System altered.
Note: value of this parameter must in multiple of 16k.
2.)Restart DB
>>>> Note : To take effect of this parameter value, DB restart is required.
Solution :
1.)
SQL> alter system set db_16k_cache_size=512M scope=SPFILE;
System altered.
Note: value of this parameter must in multiple of 16k.
2.)Restart DB
>>>> Note : To take effect of this parameter value, DB restart is required.
Friday, July 3, 2015
ORA-20011: Approximate NDV failed: ORA-16532: Data Guard broker configuration does not exist
ORA-20011: Approximate NDV failed: ORA-16532: Data Guard broker configuration does not exist
Oracle DB : Release 11.2
Oracle DB : Release 11.2
% dgmgrl
DGMGRL> connect /
DGMGRL> show configuration
ORA-16532: Data Guard broker configuration does not exist
Solution :
Disable the DataGuard broker:
SQL> alter system set dg_broker_start=false scope=both;
SQL> > exec dbms_stats.gather_fixed_objects_stats;
PL/SQL procedure successfully completed.
SQL> > exec dbms_stats.gather_fixed_objects_stats;
PL/SQL procedure successfully completed.
Thursday, July 2, 2015
EBS 12.x Linux, MT Services(oacore) not comping on 2nd host (MYHOST03), but was fine on Host : MYHOST02
| On EBS 12.x Linux, MT Services(oacore) not comping on 2nd host (MYHOST03), but was fine on Host : MYHOST02 |
| Issue : oacore not coming up |
| MSG_TEXT>Error reading config file {0}</MSG_TEXT> |
| <SUPPL_DETAIL><![CDATA[java.io.IOException: No locks available |
| at sun.nio.ch.FileDispatcherImpl.lock0(Native Method) |
| at sun.nio.ch.FileDispatcherImpl.lock(FileDispatcherImpl.java:90) |
| MSG_TEXT>Failed to acquire lock for /prod/product/1013/j2ee/home/applications/dms.war. It may fail to share the application with multiple oc4j instances.</MSG_TEXT> |
| >>> |
| Cause: /prod/product >>> Not mounted with lock option, So it was failing to lock above file : dms.war( By using this configuration file oacore was deployed) |
| Fix/Solution : Get it mounted with lockoption. |
| and after reboot host, issue got fixed & MT services started normally. |
Ebusiness12.1.x : Apache startup issue on Linux OS // Apache not coming up on EBS
| Ebusiness 12.1.x : Apache startup issue on Linux OS. Issue : Apache not coming up |
| Executing service control script: |
| /prod/inst/apps/PROD_MYHOST02/admin/scripts/adapcctl.sh start |
| script returned: |
| **************************************************** |
| ERROR : Timed out( 100000 ): Interrupted Exception |
| You are running adapcctl.sh version 120.7.12010000.2 |
| Starting OPMN managed Oracle HTTP Server (OHS) instance ... |
| 06/26/15-05:57:13 :: Removing gantt cache directory |
| **************************************************** |
| Fix/Solution : |
Login to apps(MT) node using applmgr user cd /prod/applmgr/common/webapps/oacore/html/cabo/images/cache |
mv gantt gantt.26June2015 |
Monday, June 15, 2015
SQL> startup ORA-29702: error occurred in Cluster Group Service operation
Issue while startup database:
SQL> startup mount
ORA-29702: error occurred in Cluster Group Service operation
SQL> Disconnected
bash-3.2$
1> If already RAC and cluster service not running then
Solution-1 :
check if cluster services are up and running, if not please start the cluster services.
2> If it's non-RAC / after cloning /after copied binary to new(to configure standby) database.
Solution-2:
$ cd $ORACLE_HOME/rdbms/lib
$ make -f ins_rdbms.mk rac_off
$make -f ins_rdbms.mk ioracle
Above will resolved issue for sure.
SQL> startup mount
ORA-29702: error occurred in Cluster Group Service operation
SQL> Disconnected
bash-3.2$
1> If already RAC and cluster service not running then
Solution-1 :
check if cluster services are up and running, if not please start the cluster services.
2> If it's non-RAC / after cloning /after copied binary to new(to configure standby) database.
Solution-2:
$ cd $ORACLE_HOME/rdbms/lib
$ make -f ins_rdbms.mk rac_off
$make -f ins_rdbms.mk ioracle
Above will resolved issue for sure.
Friday, January 23, 2015
ORA-27101: Shared Memory Realm Does Not Exist
Cause: Unable to locate shared memory realm
Action: Verify that the realm is accessible
Solution:
As root user allow the oracle user to lock the SGA into memory by typing: "setprivgrp dba MLOCK
Thursday, January 22, 2015
Procedure To Restore The Weblogic User Password On EBS 12.2 In Case Of Lost Or Forgotten Password
Applies to: Oracle Applications DBA - Version 12.2 to 12.2.4 [Release 12.2]
"If the Admin Password of an EBS WebLogic Domain is lost or forgotten"
Please follow the below steps:
An EBS WebLogic domain uses NodeManager to control AdminServer and managed server startup. For an EBS WebLogic domain, the NodeManager and WebLogic AdminServer passwords should be same. When changing the password for an EBS domain, care has to be taken to ensure that both the passwords remain the same, or the AD control scripts will not work properly.
If the AdminServer password has been lost or forgotten, it can be reset by carrying out the following steps should be carried out on the run file system. As described in the final step, an fs_clone operation should then be performed to bring the patch file system into sync.
1. Shut down all running services. Since the AdminServer password is not known, the servers cannot be stopped from the console and so must be killed as follows.
A. Connect to the Oracle E-Business Suite instance and source the application tier environment file.
B. Identify the PIDs of NodeManager, AdminServer, and all running managed servers:
ps -ef | grep "NodeManager"
ps -ef | grep "weblogic.Name=AdminServer"
ps -ef | grep "weblogic.Name=forms-c4ws_server"
ps -ef | grep "weblogic.Name=forms_server"
ps -ef | grep "weblogic.Name=oafm_server"
ps -ef | grep "weblogic.Name=oacore_server"
C. Kill all these processes, starting with NodeManager and followed by the servers.
2. Back up these folders, then delete them:
<EBS_DOMAIN_HOME>/security/ DefaultAuthenticatorInit.ldift
<EBS_DOMAIN_HOME>/servers/<server_name>/data/ldap
<EBS_DOMAIN_HOME>/servers/<server_name>/security/boot.properties
<EBS_DOMAIN_HOME>/servers/<server_name>/data/nodemanager/boot.properties
Please follow the below steps:
An EBS WebLogic domain uses NodeManager to control AdminServer and managed server startup. For an EBS WebLogic domain, the NodeManager and WebLogic AdminServer passwords should be same. When changing the password for an EBS domain, care has to be taken to ensure that both the passwords remain the same, or the AD control scripts will not work properly.
If the AdminServer password has been lost or forgotten, it can be reset by carrying out the following steps should be carried out on the run file system. As described in the final step, an fs_clone operation should then be performed to bring the patch file system into sync.
1. Shut down all running services. Since the AdminServer password is not known, the servers cannot be stopped from the console and so must be killed as follows.
A. Connect to the Oracle E-Business Suite instance and source the application tier environment file.
B. Identify the PIDs of NodeManager, AdminServer, and all running managed servers:
ps -ef | grep "NodeManager"
ps -ef | grep "weblogic.Name=AdminServer"
ps -ef | grep "weblogic.Name=forms-c4ws_server"
ps -ef | grep "weblogic.Name=forms_server"
ps -ef | grep "weblogic.Name=oafm_server"
ps -ef | grep "weblogic.Name=oacore_server"
C. Kill all these processes, starting with NodeManager and followed by the servers.
2. Back up these folders, then delete them:
<EBS_DOMAIN_HOME>/security/ DefaultAuthenticatorInit.ldift
<EBS_DOMAIN_HOME>/servers/<server_name>/data/ldap
<EBS_DOMAIN_HOME>/servers/<server_name>/security/boot.properties
<EBS_DOMAIN_HOME>/servers/<server_name>/data/nodemanager/boot.properties
Where:
<EBS_DOMAIN_HOME> is the absolute path of the EBS WebLogic domain
<server_name> is the name of the server directory under <EBS_DOMAIN_HOME>.
If the password is not reset correctly, the backed up files and folders can be restored.
Note: For certain servers, the boot.properties file may be present in only one location of the two specified above. In such a case, back it up and then delete it.
<server_name> is the name of the server directory under <EBS_DOMAIN_HOME>.
If the password is not reset correctly, the backed up files and folders can be restored.
Note: For certain servers, the boot.properties file may be present in only one location of the two specified above. In such a case, back it up and then delete it.
3. Set up a new environment to change the WLS AdminServer password.
A. Start a new session and connect to the Oracle E-Business Suite instance.
B. Do NOT source the application tier environment file.
C. Source the WebLogic domain environment as per the following command:
$ cd <EBS_DOMAIN_HOME>/bin
$ source setDomainEnv.sh
A. Start a new session and connect to the Oracle E-Business Suite instance.
B. Do NOT source the application tier environment file.
C. Source the WebLogic domain environment as per the following command:
$ cd <EBS_DOMAIN_HOME>/bin
$ source setDomainEnv.sh
D. Run the following commands:
$ cd <EBS_DOMAIN_HOME>/security
$ java weblogic.security.utils.AdminAccount <wls_adminuser> <wls_admin_new_password> .
Note: Do not omit the trailing period ('.') in the above command, to specify the current domain directory.
Where:
<wls_adminuser> is the same as the value of context variable s_wls_admin_user
<wls_admin_new_password> is the new WLS AdminServer password you wish to set.
4. Start AdminServer from the command line. You will be prompted for the WebLogic Server username and password, so that the AdminServer boot.properties file can be generated.
A. Go to the EBS Domain Home:
$ cd <EBS_DOMAIN_HOME>
B. Start AdminServer:
$ java <s_nm_jvm_startup_properties> -Dweblogic.system.StoreBootIdentity=true -Dweblogic.Name=AdminServer weblogic.Server
$ cd <EBS_DOMAIN_HOME>/security
$ java weblogic.security.utils.AdminAccount <wls_adminuser> <wls_admin_new_password> .
Note: Do not omit the trailing period ('.') in the above command, to specify the current domain directory.
Where:
<wls_adminuser> is the same as the value of context variable s_wls_admin_user
<wls_admin_new_password> is the new WLS AdminServer password you wish to set.
4. Start AdminServer from the command line. You will be prompted for the WebLogic Server username and password, so that the AdminServer boot.properties file can be generated.
A. Go to the EBS Domain Home:
$ cd <EBS_DOMAIN_HOME>
B. Start AdminServer:
$ java <s_nm_jvm_startup_properties> -Dweblogic.system.StoreBootIdentity=true -Dweblogic.Name=AdminServer weblogic.Server
Where:
<s_nm_jvm_startup_properties> is the same as the value of context variable ss_nm_jvm_startup_properties
The above command prompts for the WebLogic Server username and password:
Enter username to boot WebLogic server:
Enter password to boot WebLogic server:
Provide the same credentials as you provided in Step 3.
5. Change NodeManager password
A. Log in to the WebLogic Administration console.
B. Click the Lock & Edit button.
C. In the left panel, click on the EBS Domain link.
D. Select the Security tab.
E. Click on the 'Advanced' link.
F. Edit the 'Node Manager password' field and set it to the new WebLogic Server password. The password should be same as set in Step 3.
G. Edit the 'Confirm NodeManager Password' field and set it to the new WebLogic Server password. The password should be same as set in Step 3.
The above command prompts for the WebLogic Server username and password:
Enter username to boot WebLogic server:
Enter password to boot WebLogic server:
Provide the same credentials as you provided in Step 3.
5. Change NodeManager password
A. Log in to the WebLogic Administration console.
B. Click the Lock & Edit button.
C. In the left panel, click on the EBS Domain link.
D. Select the Security tab.
E. Click on the 'Advanced' link.
F. Edit the 'Node Manager password' field and set it to the new WebLogic Server password. The password should be same as set in Step 3.
G. Edit the 'Confirm NodeManager Password' field and set it to the new WebLogic Server password. The password should be same as set in Step 3.
H. Save and activate the changes.
6. Shut down AdminServer from the console. For the first time, AdminServer has to be stopped from the Admin console. Follow these steps:
6. Shut down AdminServer from the console. For the first time, AdminServer has to be stopped from the Admin console. Follow these steps:
A. Log in to the WebLogic Administration console.
B. Shut down AdminServer.
B. Shut down AdminServer.
7. Set up your environment to start AdminServer again. AdminServer should now be started using the normal AD script, which will also start NodeManager using the new password.
A. Launch a new session and connect to the Oracle E-Business Suite instance.
B. Source the application tier environment file.
C. Start AdminServer with the following command:
$ $ADMIN_SCRIPTS_HOME/adadminsrvctl.sh start
8. Start the managed servers. For the first time, all managed servers should be started from the WebLogic Server Admin console. This step will create boot.properties for the respective managed servers. Follow these steps:
A. Log in to the WebLogic Server Administration Console
B. Start all managed servers, one at a time
9. Shut down all the managed servers. This is so the new credentials will be picked up at the next startup. Follow these steps:
A. Log in to the WebLogic Administration Server console.
B. Shut down all managed servers.
C. Shut down AdminServer.
10. Shut down NodeManager using the normal AD script.
$ $ADMIN_SCRIPTS_HOME/adnodemgrctl.sh stop
11. Copy the boot.properties file for all managed servers.
WebLogic Server native scripts use the boot.properties file from the the folder. The above steps have created the boot.properties file under, which is used by NodeManager. Copy the newly-generated boot.properties file from <EBS_DOMAIN_HOME>/servers/<server_name>/data/nodemanager to <EBS_DOMAIN_HOME>/ servers/<server_name>/security.
The EBS WebLogic Server domain password has now been changed, and all servers can now be started using the normal AD scripts.
To start AdminServer:
$ADMIN_SCRIPTS_HOME/adadminsrvctl.sh start
To start the managed servers:
$ $ADMIN_SCRIPTS_HOME/admanagedsrvctl.sh start
12. The above steps have changed the Oracle WebLogic AdminServer password on the run file system. You now need to perform an fs_clone operation, to change the WebLogic EBS domain password on the patch file system:
A. Launch a new session and connect to the Oracle E-Business Suite instance.
B. Source the application tier environment file.
C. Run the command:
$ adop phase=fs_clone
A. Launch a new session and connect to the Oracle E-Business Suite instance.
B. Source the application tier environment file.
C. Start AdminServer with the following command:
$ $ADMIN_SCRIPTS_HOME/adadminsrvctl.sh start
8. Start the managed servers. For the first time, all managed servers should be started from the WebLogic Server Admin console. This step will create boot.properties for the respective managed servers. Follow these steps:
A. Log in to the WebLogic Server Administration Console
B. Start all managed servers, one at a time
9. Shut down all the managed servers. This is so the new credentials will be picked up at the next startup. Follow these steps:
A. Log in to the WebLogic Administration Server console.
B. Shut down all managed servers.
C. Shut down AdminServer.
10. Shut down NodeManager using the normal AD script.
$ $ADMIN_SCRIPTS_HOME/adnodemgrctl.sh stop
11. Copy the boot.properties file for all managed servers.
WebLogic Server native scripts use the boot.properties file from the the folder. The above steps have created the boot.properties file under, which is used by NodeManager. Copy the newly-generated boot.properties file from <EBS_DOMAIN_HOME>/servers/<server_name>/data/nodemanager to <EBS_DOMAIN_HOME>/ servers/<server_name>/security.
The EBS WebLogic Server domain password has now been changed, and all servers can now be started using the normal AD scripts.
To start AdminServer:
$ADMIN_SCRIPTS_HOME/adadminsrvctl.sh start
To start the managed servers:
$ $ADMIN_SCRIPTS_HOME/admanagedsrvctl.sh start
12. The above steps have changed the Oracle WebLogic AdminServer password on the run file system. You now need to perform an fs_clone operation, to change the WebLogic EBS domain password on the patch file system:
A. Launch a new session and connect to the Oracle E-Business Suite instance.
B. Source the application tier environment file.
C. Run the command:
$ adop phase=fs_clone
Known Issues
This section lists any known issues with the AutoConfig-related configuration management of Oracle E-Business Suite Release 12.2 environments.
Problem: On a multi-node installation with the Forms Services and Batch Processing Services enabled on separate nodes, OAM fails to update the context variables on the Batch Processing Services node.
Solution: Check whether the Listener Service is up on the Forms Services node.If the service is down, start the service using one of the following options:
Start the TNS listener service manually using the following command:
$ $INST_TOP/admin/scripts/adalnctl.sh start <TWO_TASK>
1. Enable the TNS Listener Service by following the steps mentioned earlier.
2. Stop all the application tier services using adstpall.sh
3. Start all the application tier services using adstrtal.sh
3. Start all the application tier services using adstrtal.sh
RMAN-06429 TARGET Database is not Compatible with this Version of RMAN
RMAN-06438: error executing package DBMS_RCVMAN in TARGET database
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============
RMAN-00571: ===========================================================
RMAN-00554: initialization of internal recovery manager package failed
RMAN-06429: TARGET database is not compatible with this version of RMAN
Cause:
The relevant message in this case is RMAN-06438 because package DBMS_RCVMAN in target database is invalid
Solution:
SQL>@?/rdbms/admin/dbmsrman.sql
SQL>@?/rdbms/admin/prvtrmns.plb
RMAN upgrade catalog failed with RMAN-06429
Run RMAN command 'upgrade catalog' to upgrade the RMAN recovery catalog schema from 11.2.0.2 to 11.2.0.3, but experienced the following errors, as shown here.
RMAN-06429: RCVCAT database is not compatible with this version of RMAN
RMAN> upgrade catalog;
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-06441: cannot upgrade catalog - catalog is already newer than this RMAN
RMAN> upgrade catalog;
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-06441: cannot upgrade catalog - catalog is already newer than this RMAN
Reason: The 'DBMS_RCVMAN' body package is invalid, because there are two synonyms, namely, TDATT and TFATT, that points to two non-existing RMAN tables.
Solution:
Dropped the two synonyms, namely, TDATT and TFATT, and the RMAN command "upgrade catalog" is successfully completed without any errors.
Friday, January 16, 2015
RMAN-06217
RMAN-06217
not connected to auxiliary database with a net service name
Cause: A command that moves files from the target instance to the
auxiliary instance was requested. Such a command requires a
net service name be present in the connect string used to
connect to the auxiliary instance.
Action: Issue a CONNECT AUXILIARY command and include a net serice name
in the connect string. That service name must be valid on
the target instance.
Solution:
rman target sys/<syspwd>@<OrclDBNameCaps>prim1 auxiliary sys/<syspwd>@<OrclDBNameCaps>stby
not connected to auxiliary database with a net service name
Cause: A command that moves files from the target instance to the
auxiliary instance was requested. Such a command requires a
net service name be present in the connect string used to
connect to the auxiliary instance.
Action: Issue a CONNECT AUXILIARY command and include a net serice name
in the connect string. That service name must be valid on
the target instance.
Solution:
rman target sys/<syspwd>@<OrclDBNameCaps>prim1 auxiliary sys/<syspwd>@<OrclDBNameCaps>stby
Subscribe to:
Posts (Atom)