Friday, June 20, 2014

Potential cause of ORA-12547: TNS:lost contact

I was running a script against the database directly on the host, when the script timed out with:

ERROR:
 ORA-12547: TNS:lost contact

After a search on Oracle's support site I found doc 555565.1: Troubleshooting ORA-12547 TNS: Lost Contact

One potential cause was incorrect permissions on the oracle binary in the $ORACLE_HOME/bin directory. I checked my old OH and compared it with the new OH:

server1>cd $ORACLE_HOME
server1>pwd
 /u01/oracle/product/11204
server1>ls -latr bin/oracle
 -rwxr-x--x    1 ora11g   dba       309704130 Jun 11 11:00 bin/oracle
server1>ls -latr /u01/oracle/product/11.2.0.2/bin/oracle
 -rwsr-s--x    1 ora11g   dba       279291858 Mar 12 13:42 /u01/oracle/product/11.2.0.2/bin/oracle
As can be seen from the above statement, the oracle server executable was lacking the setuid bit

This bit is needed, since we need to make sure that any user who runs the executable file will inherit the user ID of the owner (or group) of the executable file. Note that LOCAL connections would work just fine, even if the permissions on the oracle executable is set incorrectly; only connections that are passed from the listener to the Oracle server are affected. These sessions must be able to spawn a new server process.

Oracle points out that this error is commonly seen "in environments where the listener is running in the GRID home and servicing connections to an instance in a different $ORACLE_HOME."

Connections via the listener are failing with ORA-12547. It is likely in this scenario that LOCAL or BEQ connections to the instance are successful.

Solution to my particular problem this time was to give $ORACLE_HOME/bin/oracle the proper permissions:
server1> sqlplus / as sysdba
SQL> shutdown immediate

server1>chmod 6751 oracle
server1>ls -latr oracle
 -rwsr-s--x    1 ora11g   dba       309704130 Jun 11 11:00 oracle

server1> sqlplus / as sysdba
SQL> startup

After this change the script ran through with no ORA-12547 errors.

Sources: Oracle System Administration Guide

Thursday, June 19, 2014

How to disable or drop an SQL Profile

Find the profiles currently saved in the database:
SELECT NAME, CREATED,LAST_MODIFIED,TYPE,STATUS,FORCE_MATCHING
FROM DBA_SQL_PROFILES
ORDER BY CREATED DESC;


NAME CREATED LAST_MODIFIED TYPE STATUS FORCE_MATCHING
SYS_SQLPROF_0146b2c081f9011a 19.06.2014 08:11:39,000000 19.06.2014 08:11:39,000000 MANUAL ENABLED NO
SYS_SQLPROF_0146b2bf0d430118 19.06.2014 08:10:03,000000 19.06.2014 08:10:03,000000 MANUAL ENABLED NO
SYS_SQLPROF_0146af25274a0117 18.06.2014 15:23:06,000000 18.06.2014 15:23:06,000000 MANUAL ENABLED NO
SYS_SQLPROF_0146af1a61f40116 18.06.2014 15:11:20,000000 18.06.2014 15:11:20,000000 MANUAL ENABLED NO
SYS_SQLPROF_0146af18d0960115 18.06.2014 15:09:37,000000 18.06.2014 15:09:37,000000 MANUAL ENABLED NO
SYS_SQLPROF_0146af150fc30114 18.06.2014 15:05:31,000000 18.06.2014 15:05:31,000000 MANUAL ENABLED NO
SYS_SQLPROF_01462313623f0113 22.05.2014 10:36:51,000000 22.05.2014 10:36:51,000000 MANUAL ENABLED NO
SYS_SQLPROF_01461857e9680112 20.05.2014 08:35:53,000000 20.05.2014 08:35:53,000000 MANUAL ENABLED NO
SYS_SQLPROF_014614c584ab0111 19.05.2014 15:57:07,000000 19.05.2014 15:57:07,000000 MANUAL ENABLED NO

To disable the profile, which means they will not any longer be considered by the CBO until you once again accept them:
set serveroutput on
 begin
   dbms_sqltune.alter_sql_profile(name=>'SYS_SQLPROF_0146af25274a0117', attribute_name=>'STATUS',value=>'DISABLED');
 end;
/
To completely drop the profile:
set serveroutput on
 begin
   dbms_sqltune.drop_sql_profile(name=>'SYS_SQLPROF_0146af25274a0117');
end;
/

What does the TERRITORY component of the NLS_LANG parameter control?

From OTN:

"The territory component of the NLS_LANG parameter controls the operation of a subset of globalization support features.
It specifies conventions such as the default date, monetary, and numeric formats. Each supported territory has a unique name, for example, AMERICA, FRANCE, or CANADA.
If the territory is not specified, then the value is derived from the language value."


For examples please see the Globalization Support Guide

Wednesday, June 18, 2014

How to work around ORA-12705 when connecting to your database

You get:

ERROR:
 ORA-12705: Cannot access NLS data files or invalid environment specified
Solution:
Incorrect or misspelled NLS_LANG.

For example
NLS_LANG=AMERICAN_NORWAY.UTF-8
is incorrect.

However
export NLS_LANG=AMERICAN_NORWAY.UTF8
is correct.

How to install the instant client from Oracle on a Linux application server

This is how I quite quickly installed sqlplus on a Linux appserver on request from my customer:

1. Download the two files
instantclient-basic-linux.x64-11.2.0.4.0.zip
instantclient-sqlplus-linux.x64-11.2.0.4.0.zip
from the otn network.


2. Create Directory for the installation files
mkdir  /u01/oracle/product/admin/install

3. Ftp the files over to the server

4. Put the installation files in the install Directory:
mv /tmp/instantclient*.zip /u01/oracle/product/admin/install

5. Unzip the files:
unzip instantclient-basic-linux.x64-11.2.0.4.0.zip -d /u01/oracle/product
unzip instantclient-sqlplus-linux.x64-11.2.0.4.0.zip -d /u01/oracle/product
The files will be unzipped to the Directory /u01/oracle/Product/instantclient_11_2

6. Create a Directory for networking:
mkdir $ORACLE_HOME/network/admin

7. set up the .bash_profile:
export ORACLE_BASE=/u01/oracle
export ORACLE_HOME=/u01/oracle/product/instantclient_11_2
export PATH=$PATH:$HOME/bin:$ORACLE_HOME
export LD_LIBRARY_PATH=/u01/oracle/product/instantclient_11_2
export NLS_LANG=NORWEGIAN_NORWAY.UTF8
export TNS_ADMIN=$ORACLE_HOME/network/admin

8. Create file tnsnames.ora, add an entry for each of the databases you'd like to Access via sqlplus.

All done!


Note that you do need *both* the basic and the sqlplus instantclient zip files to be unpacked into the same directory. If not, you will be missing Libraries in your installation and you'll receive the following error when launching sqlplus:

sqlplus: error while loading shared libraries: libclntsh.so.11.1: cannot open shared object file: No such file or Directory

Friday, June 13, 2014

Workaround for RMAN-11003 and ORA-32010 during cloning



At the end of the duplication procedure, my script threw the following error:

RMAN-06162: sql statement: alter system reset  db_unique_name scope=spfile
 RMAN-08031: released channel: c1
 RMAN-08031: released channel: c2
 RMAN-00571: ===========================================================
 RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
 RMAN-00571: ===========================================================
 RMAN-03002: failure of Duplicate Db command at 06/12/2014 17:40:14
 RMAN-05501: aborting duplication of target database
 RMAN-03015: error occurred in stored script Memory Script
 RMAN-03009: failure of sql command on clone_default channel at 06/12/2014 17:40:14
 RMAN-11003: failure during parse/execution of SQL statement: alter system reset  db_unique_name scope=spfile
 ORA-32010: ORA-32010: cannot find entry to delete in SPFILE 

 Recovery Manager complete.

After a brief search I found that my init.ora was the culprit: I had accidently left out single quotes in the db_file_name_convert parameter:

*.db_file_name_convert=('/u02/oradata/proddb01/datafile','/u02/oradata/testdb01','/u02/oradata/proddb01/tempfile',/u02/oradata/testdb01')

Oracle Support Dok ID 1384262.1 "ORA-32010: cannot find entry to delete in SPFILE" points this out.

The spfile was not in $OH/dbs physically, although Oracle believes it does:
SQL> show parameter spfile

NAME        TYPE        VALUE
 ---------- ----------- ---------------------------------------------
 spfile     string      /u01/oracle/product/11204/dbs/spfiletestdb01.ora

To prove it, I attempted to create an spfile:
SQL> create spfile from pfile;
 create spfile from pfile
 *
 ERROR at line 1:
 ORA-32002: cannot create SPFILE already being used by the instance 
When attempting to mount:
SQL> alter database mount;
 alter database mount
 *
 ERROR at line 1:
 ORA-01103: database name PRODDB01 in control file is not TESTDB01
So the control files are incorrect, written to during the duplication, and RMAN was unfortunately interrupted before the duplication procedure completed.

Solution:
Recreate the controlfile from the Source database, and open the auxiliary database with this new controlfile instead of the one that was generated during duplication.


1. Log onto the source server on which the PRODDB01 database is hosted, and execute
SQL> alter database backup controlfile to trace as '/tmp/proddb01_cntrfile.sql';
2. Transfer the file /tmp/proddb01_cntrfile.sql to the testserver
3. Shutdown the auxiliary database
4. Edit the script:
* Go to the section that says "Set #2. RESETLOGS case". You can strip away anything above this section, as you won't be needing it.
* Use the physical paths valid on the auxiliary server
* Exchange "REUSE DATABASE" with "SET DATABASE"
From Source database:
STARTUP NOMOUNT
 CREATE CONTROLFILE REUSE DATABASE "PRODDB01" RESETLOGS  ARCHIVELOG
     MAXLOGFILES 16
     MAXLOGMEMBERS 3
     MAXDATAFILES 200
     MAXINSTANCES 8
     MAXLOGHISTORY 1168
 LOGFILE
   GROUP 1 '/u02/oradata/proddb01/redo1.log'  SIZE 1000M BLOCKSIZE 512,
   GROUP 2 '/u02/oradata/proddb01/redo2.log'  SIZE 1000M BLOCKSIZE 512,
   GROUP 3 '/u02/oradata/proddb01/redo3.log'  SIZE 1000M BLOCKSIZE 512,
   GROUP 4 '/u02/oradata/proddb01/redo4.log'  SIZE 1000M BLOCKSIZE 512
 -- STANDBY LOGFILE
 DATAFILE
   '/u02/oradata/proddb01/datafile/system.428.688578763',
   '/u02/oradata/proddb01/datafile/undotbs1.489.688574787',
   '/u02/oradata/proddb01/datafile/sysaux.436.688579377'
.
.
.
CHARACTER SET AL32UTF8
;
The new edited version:
STARTUP NOMOUNT
 CREATE CONTROLFILE REUSE
 SET DATABASE "TESTDB01" RESETLOGS  ARCHIVELOG
     MAXLOGFILES 16
     MAXLOGMEMBERS 3
     MAXDATAFILES 200
     MAXINSTANCES 8
     MAXLOGHISTORY 1168
 LOGFILE
   GROUP 1 '/u02/oradata/testdb01/redo1.log'  SIZE 1024M BLOCKSIZE 512,
   GROUP 2 '/u02/oradata/testdb01/redo2.log'  SIZE 1024M BLOCKSIZE 512,
   GROUP 3 '/u02/oradata/testdb01/redo3.log'  SIZE 1024M BLOCKSIZE 512,
   GROUP 4 '/u02/oradata/testdb01/redo4.log'  SIZE 1024M BLOCKSIZE 512
 -- STANDBY LOGFILE
 DATAFILE
  '/u02/oradata/testdb01/system.428.688578763',
   '/u02/oradata/testdb01/undotbs1.489.688574787',
   '/u02/oradata/testdb01/sysaux.436.688579377',
   '/u02/oradata/testdb01/users.476.688577593',
   '/u02/oradata/testdb01/undotbs1.510.688564845',
   '/u02/oradata/testdb01/sl_part_data_2006.473.688577939',
.
.
.
CHARACTER SET AL32UTF8
;
5. Run the script on the newly cloned database:
SQL> sqlplus / as sysdba @proddb01_cntrfile.sql
Oracle instance started

 Total System Global Area    5344731136 bytes

 Fixed Size                     2255784 bytes
 Variable Size               1459618904 bytes
 Database Buffers            3875536896 bytes
 Redo Buffers                   7319552 bytes

Control file created.

6. Mount the database
SQL> alter database mount;

Database mounted.
7. Open the database
SQL> alter database open resetlogs;

Database opened.


Finally I had to handle TEMP tablespaces, as the alert log would tell you:
Dictionary check beginning
 Tablespace 'TEMP' #3 found in data dictionary,
 but not in the controlfile. Adding to controlfile.
 *********************************************************************
 WARNING: The following temporary tablespaces contain no files.
          This condition can occur when a backup controlfile has
          been restored.  It may be necessary to add files to these
          tablespaces.  That can be done using the SQL statement:

          ALTER TABLESPACE  ADD TEMPFILE

          Alternatively, if these temporary tablespaces are no longer
          needed, then they can be dropped.
            Empty temporary tablespace: TEMP

Add a file to the temporary tablespace using the REUSE clause:
SQL> alter tablespace temp add tempfile '/u02/oradata/testdb01/temp01.dbf' size 1024M reuse autoextend on next 32M maxsize unlimited;

Thursday, June 12, 2014

How to solve RMAN-06217 during cloning from active database


RMAN-03002: failure of Duplicate Db command at 06/12/2014 12:28:00
 RMAN-05501: aborting duplication of target database
 RMAN-06217: not connected to auxiliary database with a net service name

Workaround is to connect to the auxiliary database using username and password, followed by the TNS alias.
So instead of
 connect target sys/<password>@PRODDB01
 connect rmanuser/<password>@RMANCAT
 connect auxiliary /
use
 connect target sys/<password>@PRODDB01
 connect rmanuser/<password>@RMANCAT
 connect auxiliary sys/<password>@AUX01