Data Backup and Recovery
Data Backup and Recovery
Hello,
I tried to configure an Oracle-Plugin on a Solaris Host and get the following error when I try to perform a backup:
SQL*Plus command /oracle/11g/bin/sqlplus /nolog @/tmp/STKpy4ZOBw.sc
ORA-12162: TNS:net service name is incorrectly specified
I understand that this is normally pointing to missing or wrong ORACLE_SID. but tis is set in the login script for the "oracle" user.I verified the DBname and User etc. it should be fine.
Any hints for me?
(My SnapCreator Server is installed on Windows 2012 and my Agent is on Solaris where the Oracle DB resides)
Helmut
Solved! See The Solution
The problem here is that when SC is called, it sets the environment parameters which are promptly overwritten by the login script. With configurations using bash, there must be no overrides. For csh, you're stuck having to use .login to set variables, which means the ORACLE_HOME, ORACLE_SID and other parameters have no effect.
We're looking at options to allow both csh and bash to be used. This would still prohibit any use of login scripts that alter ORACLE_HOME or ORACLE_SID.
Hi,
Identified the problem by myself:
I had to restart the scagent after setting the ORACLE_SID!
Conclusion:
the Oracle Environmant Variables are read in by the agent when it starts up. Changing them later does not help.
Question:
Whats now unclear to me is: What if you have multible oracle instances on the same host? Then I can not set the ORACLE_SID !
Helmut
Thanks much for the update Helmut.
What is your shell environment for the Oracle user?
(echo $0)
The Installation and Administration Guide has a specific requirement for C Shell with the Oracle Plugin.
ORACLE_SID and ORACLE_HOME needs to be in .cshrc (shell startup file)
I believe you can also customize the .cshrc to accommodate multiple Oracle database instances.
Hi,
We use tcsh shell.
the 4.0 Installation Guide tells:
"To use C Shell (CSH) with the Oracle plug-in on UNIX or Linux platforms, the following conditions
should be met:
Snap Creator Agent must be started as the Oracle user, instead of the root user.
• The Oracle user must have the proper environmental variables (ORACLE_HOME and
ORACLE_SID) set in order for the plug-in driven SQL*Plus commands to work.
This can be done with a shell startup file, such as ~/.cshrc."
We did this , for tcsh we use the .login to set ORACLE_SID for the oracle user.
We also had to restart the agent after the ORACLE_SID was set.
No the problem I have on systems with multible SIDs:
the Plugin always uses the same SID to perform the "alter database backup" operation.
independet from what dbname I specify in the configuration file (ORACLE_DATABASES)
e.g.: I have two SIDs on onw system: ABC and CDE
ORACLE_SID is set to ABC (.login script for user "oracle")
in the config-file I specify: ORACLE_DATABASES=CDE:oracle
If I perform a backup it runs without error messages but monitoring the alert-files of bith instances in parallel I see that it performs "alter database backup" on ABC instead of CDE
I don't know whats the recommended way to handle this, I can only specify one value for ORACLE_SID in the .login , but it would have to be changed depending on which database I want to perform a backup for - How is this recommended?
should have mentioned that we use SnapCreator 4.0
Helmut,
Have you tried creating additional configuration files, one per database or SID?
This will allow you to have a configuration file for each Oracle instance.
You can then individually schedule the different databases at different times for backup or other actions.
You can have as many configuration files as you need.
So maybe a config for ABC and a second config for CDE.
You can download the existing config to your local system (from the GUI right-click and select download), make any necessary changes (config name and SID) and right-click on the profile to upload the new config.
Hope this helps,
John
Hi,
Thats exactly what I did, two different configs, one for ABC one for CDE.
But in the config-file there is not "SID", all you have is the parameter "ORACLE_DATABASES"
Config-File entries look like this
ABC.conf: ORACLE_DATABASES=ABC:oracle
CDE.conf: ORACLE_DATABASES=CDE:oracle
in the .login script for user "oracle" i have "setenv ORACLE_SID ABC"
If I perform a backup of ABC - all works fine.
If I perform a backup of CDE - it still connects to ABC (because auf evironment variable ORACLE_SID) and performs the "alter database backup" on the wrong instance!
This is what I have found out.
1) Snap Creator Framework supports Oracle Plugin on bash only
2) From the IAG,
" The Oracle plug-in supports Oracle 10g database or later versions. The Oracle plug-in uses SQL*Plus to communicate with the database.
To use C Shell (CSH) with the Oracle plug-in on UNIX or Linux platforms, the following conditions
should be met:
• Snap Creator Agent must be started as the Oracle user, instead of the root user.
• The Oracle user must have the proper environmental variables (ORACLE_HOME and ORACLE_SID) set in order for the plug-in driven SQL*Plus commands to work.
This can be done with a shell startup file, such as ~/.cshrc
If your cshrc is not customized to pass different ORACLE_SID, this might inadvertently backup the wrong SID (as in your case, since the shell environmental variables are wrong).
A possible workaround is to set ORACLE_SID from the shell and restarting the scAgent
example
#!/bin/sh
export ORACLE_SID=CDE
$SC_AGENT_HOME/bin/scAgent restart
Note: You may also be able to run Snap Creator agent on different port with the above ORACLE_SID and use that to communicate to CDE.
or, you may be able to use different UNIX user login whose .cshrc is customized for the second ORACLE_SID
Please check if the below information can help as well.
Multiple-Instance System
On a multiple-instance System, include a list of instance names and commands necessary to initialize the oraenv
script at the end of the startup file of the oracle
user account.
Table 4-3 shows the required Bourne or Korn shell commands for initializing the oraenv script on UNIX platforms.
Table 4-3 Bourne/Korn Commands to Initialize the oraenv Script on Multiple-Instance Systems
Solaris |
#!/bin/sh echo "The SIDs on this machine are:" cat /var/opt/oracle/oratab | awk -F: '{print $1}' |\ grep -v "#" ORAENV_ASK="YES" . /usr/local/bin/oraenv |
AIX, HP, Linux and Tru64 |
#!/bin/sh echo "The SIDs on this machine are:" cat /etc/oratab | awk -F: '{print $1}' | grep -v "#" ORAENV_ASK="YES" . /usr/local/bin/oraenv |
Table 4-4 describes the C shell commands for initializing the oraenv script on UNIX platforms.
Table 4-4 C Shell Commands to Initialize the oraenv Script on Multiple-Instance Systems
Solaris |
#!/usr/bin/csh echo "The SIDs on this machine are:" cat /var/opt/oracle/oratab | awk -F: '{print $1}' |\ grep -v "#" set ORAENV_ASK="YES" source /usr/local/bin/coraenv |
AIX, HP, Linux and Tru64 |
#!/usr/bin/csh echo "The SIDs on this machine are:" cat /etc/oratab | awk -F: '{print $1}' | grep -v "#" set ORAENV_ASK="YES" source /usr/local/bin/coraenv |
On a multiple-instance System, include a list of instance names and commands necessary to initialize the oraenv
script at the end of the startup file of the oracle
user account.
Table 4-3 shows the required Bourne or Korn shell commands for initializing the oraenv script on UNIX platforms.
Table 4-3 Bourne/Korn Commands to Initialize the oraenv Script on Multiple-Instance Systems
Solaris |
#!/bin/sh echo "The SIDs on this machine are:" cat /var/opt/oracle/oratab | awk -F: '{print $1}' |\ grep -v "#" ORAENV_ASK="YES" . /usr/local/bin/oraenv |
AIX, HP, Linux and Tru64 |
#!/bin/sh echo "The SIDs on this machine are:" cat /etc/oratab | awk -F: '{print $1}' | grep -v "#" ORAENV_ASK="YES" . /usr/local/bin/oraenv |
Table 4-4 describes the C shell commands for initializing the oraenv script on UNIX platforms.
Table 4-4 C Shell Commands to Initialize the oraenv Script on Multiple-Instance Systems
Solaris |
#!/usr/bin/csh echo "The SIDs on this machine are:" cat /var/opt/oracle/oratab | awk -F: '{print $1}' |\ grep -v "#" set ORAENV_ASK="YES" source /usr/local/bin/coraenv |
AIX, HP, Linux and Tru64 |
#!/usr/bin/csh echo "The SIDs on this machine are:" cat /etc/oratab | awk -F: '{print $1}' | grep -v "#" set ORAENV_ASK="YES" source /usr/local/bin/coraenv |
The problem here is that when SC is called, it sets the environment parameters which are promptly overwritten by the login script. With configurations using bash, there must be no overrides. For csh, you're stuck having to use .login to set variables, which means the ORACLE_HOME, ORACLE_SID and other parameters have no effect.
We're looking at options to allow both csh and bash to be used. This would still prohibit any use of login scripts that alter ORACLE_HOME or ORACLE_SID.
Thanks a lot guys! - That clarifies it all!
So the problem is caused by using the csh or tcsh!
I did not figure out that using bash was a prerequisite, it is not mentioned in the IAG or Release Notes. (would be a good idea to put it in under Preinstallation or somewhere)
Thanks for the explaination, I will have the customer to switch to bash and then we should be fine!
cheers,
Helmut