Archive

Archive for June, 2011

Oracle: “ORA-12545: Connect failed because target host or object does not exist” when trying to connect through SCAN-Listeners

Problem description:

You are trying to connect to a database and are receiving the following error message:

[oracle@ls01 admin]$ sqlplus system@racdb
 
SQL*Plus: Release 10.2.0.5.0 - Production on Sat Jun 18 08:47:47 2011
 
Copyright (c) 1982, 2010, Oracle.  All Rights Reserved.
 
Enter password: 
ERROR:
ORA-12545: Connect failed because target host or object does not exist
 
 
Enter user-name:

 
Cause:

Normally this error is generated by specifying a wrong hostname with the ADDRESS parameters or by specifying a hostname which can not be looked up:

12545, 00000, "Connect failed because target host or object does not exist"
// *Cause: The address specified is not valid, or the program being 
// connected to does not exist.
// *Action: Ensure the ADDRESS parameters have been entered correctly; the
// most likely incorrect parameter is the node name.  Ensure that the 
// executable for the server exists (perhaps "oracle" is missing.)
// If the protocol is TCP/IP, edit the TNSNAMES.ORA file to change the
// host name to a numeric IP address and try again.

 
In this case, we have a tnsnames.ora-entry working fully functional on the database servers and even using IP-addresses:

RACDB =
  (DESCRIPTION =
    (ADDRESS_LIST =
     (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.200.101)(PORT = 1521))
     (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.200.102)(PORT = 1521))
     (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.200.103)(PORT = 1521))
    )
    (LOAD_BALANCE = yes)
    (CONNECT_DATA =
      (SERVICE_NAME = app199.db.initso.at)
      (SERVER = DEDICATED)
      (FAILOVER_MODE=
        (TYPE=select)
        (METHOD=basic)
        (RETRIES=20)
        (DELAY=15)
      )
    )
  )

 
Above mentioned tnsnames.ora-entry is used to connect to a remote 11g Release 2 RAC-database by utilizing the newly introduced SCAN-Listeners (IP-addresses necessary for clients < 11.2). The tnsnames.ora-entry works fine for clients in the local area network, but if you are trying to connect from another location, you are receiving an ORA-12545 (even though you are not using any hostname).

This is caused by making use of the SCAN-Listeners from a remote site. The SCAN-Listeners will route you to a “normal” VIP-Listener in order to spawn the connection. This routing is based on hostnames and not IP-addresses. If the client receives the hostname for the VIP-Listener to connect to and it is unable to resolve it, you will also see the ORA-12545.

 
Problem resolution:

Enter all Oracle 11g Release 2 RAC relevant IP-addresses and hostnames in your DNS server or your hosts-file.

Example for hosts-file:

192.168.200.201		rac01.initso.at rac01
192.168.200.202		rac02.initso.at rac02
192.168.200.203		rac03.initso.at rac03
 
192.168.200.211		rac01-vip.initso.at rac01-vip
192.168.200.212		rac02-vip.initso.at rac02-vip
192.168.200.213		rac03-vip.initso.at rac03-vip
 
192.168.200.101		rac-scan.initso.at
192.168.200.102		rac-scan.initso.at
192.168.200.103		rac-scan.initso.at

 
After configuring all appropriate hosts-file entries, you should be able to connect without any issue:

[oracle@ls01 admin]$ sqlplus username/password@RACDB
 
SQL*Plus: Release 10.2.0.5.0 - Production on Sat Jun 18 09:01:38 2011
 
Copyright (c) 1982, 2010, Oracle.  All Rights Reserved.
 
 
Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - 64bit Production
With the Partitioning, Real Application Clusters, OLAP, Data Mining
and Real Application Testing options
 
SQL> select instance_number, instance_name from v$instance;
 
INSTANCE_NUMBER INSTANCE_NAME
--------------- ----------------
	      1 rac1
 
SQL> exit
Disconnected from Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - 64bit Production
With the Partitioning, Real Application Clusters, OLAP, Data Mining
and Real Application Testing options
[oracle@ls01 admin]$
Categories: Uncategorized Tags:

Oracle RMAN: Duplicate database fails with “RMAN-06457: UNTIL scn (4321) is ahead of last scn in archived logs (1234)” or provides an old image of the database

June 16th, 2011 Matthias Pölzinger 1 comment

Problem description:

You are trying to duplicate a database and you are always ending up with the same old image or you are receiving the following error message during restore:

Starting Duplicate Db at 05-JUN-2011 22:50:27
released channel: stb1
released channel: stb2
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure OF Duplicate Db command at 06/05/2009 22:51:26
RMAN-06457: UNTIL scn (4321) IS ahead OF LAST scn IN archived logs (1234)

 
Cause:

You are duplicating a RAC database with more than one redo log threads. If one of the threads is in “CLOSED”-state you will either receive above mentioned error message or end up with an old duplicated image (because duplicate database will use an scn <= the latest changes from the closed thread).

Example output from v$log:

SQL> SELECT thread#, STATUS, instance FROM v$thread ORDER BY 1;
 
   THREAD# STATUS INSTANCE
---------- ------ --------------------
	 1 OPEN   rac1
	 2 CLOSED rac2
	 3 OPEN   rac3
	 4 OPEN   rac4
 
SQL>

 
Problem resolution:

Either

  1. drop the closed thread if it is no longer needed.

    Example:

    SQL> ALTER DATABASE disable thread 2;
     
    DATABASE altered.
     
    SQL>
    SQL> ALTER DATABASE DROP logfile GROUP 201;
     
    DATABASE altered.
     
    SQL> ALTER DATABASE DROP logfile GROUP 202;
     
    DATABASE altered.
     
    SQL> ALTER DATABASE DROP logfile GROUP 203;
     
    DATABASE altered.
     
    SQL>

     
    v$thread will now no longer list the thread:

    SQL> SELECT thread#, STATUS, instance FROM v$thread ORDER BY 1;
     
       THREAD# STATUS INSTANCE
    ---------- ------ --------------------
    	 1 OPEN   rac1
    	 3 OPEN   rac3
    	 4 OPEN   rac4
     
    SQL>

     

  2. open the thread by starting the currently stopped RAC database instance and perform a log switch

    Example:

    [oracle@rac1 ~]$ srvctl start instance -d rac -i rac2
    [oracle@rac1 ~]$

     
    v$thread will now list the thread as open:

    SQL> SELECT thread#, STATUS, instance FROM v$thread ORDER BY 1;
     
       THREAD# STATUS INSTANCE
    ---------- ------ --------------------
    	 1 OPEN   rac1
     	 2 OPEN   rac2
    	 3 OPEN   rac3
    	 4 OPEN   rac4
     
    SQL>

     
    After archiving the redo logs, reperform your duplicate database.

Categories: Uncategorized Tags:

Oracle: ORA-01775: looping chain of synonyms when querying a public synonym

Problem description:
You are trying to execute a query which raises the error ORA-01775:

SQL> SELECT * FROM mytestname;
SELECT * FROM mytestname
              *
ERROR at line 1:
ORA-01775: looping chain OF synonyms
 
 
SQL>

 
Cause:
If a synonym is unable to translate to the described object, because it is missing, Oracle normally would raise an “ORA-00980: synonym translation is no longer valid” error.

Example:

SQL> CREATE public synonym pubsynonym10 FOR system.asdfasdasdf;
 
Synonym created.
 
SQL> SELECT * FROM pubsynonym10;
SELECT * FROM pubsynonym10
              *
ERROR at line 1:
ORA-00980: synonym translation IS no longer valid
 
 
SQL>

 
But with 10.1 onwards, Oracle raises an “ORA-01775: looping chain of synonyms” if the accessed public synonym and the missing base table share the same name.

Example:

SQL> SHOW USER
USER IS "SYS"
SQL> 
SQL> CREATE public synonym mytestname FOR system.mytestname;
 
Synonym created.
 
SQL> 
SQL> SELECT * FROM mytestname;
SELECT * FROM mytestname
              *
ERROR at line 1:
ORA-01775: looping chain OF synonyms
 
 
SQL>

 
Problem resolution:

Check the existance of the base object referenced and fix the no longer valid translation.

Categories: Uncategorized Tags:

Oracle: HOWTO delete a service which is not configured by Oracle Clusterware

Problem description:

You are running a Real Application cluster database and Grid Control reports that one of your database services is down, but all your database services managed by Oracle Clusterware are up and running.

Cause:

Maybe a no longer used service has still an entry in dba_services (that’s one of the views which Grid Control will check). This for example can happen if you change the database domain parameter after installation.

Problem resolution:

Check all database service entries in dba_services:

SQL> SELECT service_id, name, creation_date, enabled FROM dba_services ORDER BY 1;
 
SERVICE_ID NAME                                                             CREATION_DATE   ENA
---------- ---------------------------------------------------------------- --------------- ---
         1 SYS$BACKGROUND                                                   20-MAY-11       NO
         2 SYS$USERS                                                        20-MAY-11       NO
         3 O11GXDB                                                          20-MAY-11       NO
         4 O11G                                                             20-MAY-11       NO
         5 O11G.oracle.initso.at                                            23-MAY-11       NO
         6 O11GFAIL                                                         25-MAY-11       NO
 
6 ROWS selected.
 
SQL>

In my case, O11G was the service Grid Control reported as down, as after changing the database domain to “oracle.initso.at”, the service was no longer used.

If you want to remove a service which is no longer used by Oracle Clusterware or database connections, you can remove it by using the following commands (if the service was configured using srvctl/Oracle Clusterware, please use srvctl to remove the service!):

SQL> EXEC dbms_service.delete_service('O11G');
 
PL/SQL PROCEDURE successfully completed.
 
SQL>

Grid Control will now no longer report the service as down, because it’s no longer known by the database:

SQL> SELECT service_id, name, creation_date, enabled FROM dba_services ORDER BY 1;
 
SERVICE_ID NAME                                                             CREATION_DATE   ENA
---------- ---------------------------------------------------------------- --------------- ---
         1 SYS$BACKGROUND                                                   20-MAY-11       NO
         2 SYS$USERS                                                        20-MAY-11       NO
         3 O11GXDB                                                          20-MAY-11       NO
         5 O11G.oracle.initso.at                                            23-MAY-11       NO
         6 O11GFAIL                                                         25-MAY-11       NO
 
5 ROWS selected.
 
SQL>
Categories: Uncategorized Tags:

Oracle: impdp raises ORA-39083: Object type PROCOBJ failed to create with error: ORA-01843: not a valid month

Problem description:

You are importing a data pump dumpfile and impdp raises the following error(s) when trying to create a job or schedule:

ORA-39083: Object TYPE PROCOBJ failed TO CREATE WITH error:
ORA-01843: NOT a valid MONTH
Failing SQL IS:
BEGIN
... dbms_scheduler commands ...
COMMIT;
END;

Cause:

The exporting data pump session used different NLS-settings than your currently importing one.

DBMS_SCHEDULER invokes your current NLS-settings when creating jobs/schedules. For instance, if your environment variable NLS_LANG was set to AMERICAN_AMERICA.WE8ISO8859P1 for your export, you should use the same setting during import. Otherwise creating scheduler jobs/schedules will raise above mentioned error messages.

Problem resolution:

You should use equivalent NLS_LANG settings in your environment when performing expdp and impdp. This will workaround the issue.

Categories: Uncategorized Tags:

Oracle Grid Control: /secFarm_GCDomain/GCDomain/EMGC_ADMINSERVER/FMW Welcome Page Application(11.1.0.0.0) down

Problem description:

After installing Grid Control 11.1.0.1, you may see the target “/secFarm_GCDomain/GCDomain/EMGC_ADMINSERVER/FMW Welcome Page Application(11.1.0.0.0)” reported as DOWN:



Cause:

This issue is caused by unpublished bug “BROKEN ‘FMW WELCOME PAGE APPLICATION’ APPLICATION DISCOVERED OUT-OF-BOX”.

Problem resolution:

Patch 9431704 fixes this issue and is available via Oracle My Support.

Steps to fix this issue:

  • Stop all Oracle Management Server processes:

    oracle@gc01:/u01/app/middleware/oms11g/bin> ./emctl stop oms -all
    Oracle Enterprise Manager 11g Release 1 Grid Control
    Copyright (c) 1996, 2010 Oracle Corporation.  All rights reserved.
    Stopping WebTier...
    WebTier Successfully Stopped
    Stopping Oracle Management Server...
    Oracle Management Server Successfully Stopped
    Oracle Management Server is Down
    oracle@gc01:/u01/app/middleware/oms11g/bin>

  • Unzip patch 9431704:

    oracle@gc01:/u01/INSTALL> unzip p9431704_111120_Generic.zip
    Archive:  p9431704_111120_Generic.zip
       creating: 9431704/
       creating: 9431704/etc/
       creating: 9431704/etc/config/
      inflating: 9431704/etc/config/deploy.xml
      inflating: 9431704/etc/config/actions.xml
      inflating: 9431704/etc/config/inventory.xml
       creating: 9431704/etc/xml/
      inflating: 9431704/etc/xml/ShiphomeDirectoryStructure.xml
      inflating: 9431704/etc/xml/GenericActions.xml
      inflating: 9431704/README.txt
       creating: 9431704/files/
       creating: 9431704/files/modules/
       creating: 9431704/files/modules/oracle.wsm.common_11.1.1/
      inflating: 9431704/files/modules/oracle.wsm.common_11.1.1/wsm-dependencies.jar
    oracle@gc01:/u01/INSTALL>

  • Set ORACLE_HOME to Middleware oracle_common directory and apply patch:

    oracle@gc01:/u01/INSTALL/9431704> export ORACLE_HOME=/u01/app/middleware/oracle_common
    oracle@gc01:/u01/INSTALL/9431704> /u01/app/middleware/oracle_common/OPatch/opatch apply
    Invoking OPatch 11.1.0.8.4
     
    Oracle Interim Patch Installer version 11.1.0.8.4
    Copyright (c) 2011, Oracle Corporation.  All rights reserved.
     
     
    Oracle Home       : /u01/app/middleware/oracle_common
    Central Inventory : /u01/app/oraInventory
       from           : /etc/oraInst.loc
    OPatch version    : 11.1.0.8.4
    OUI version       : 11.1.0.7.0
    OUI location      : /u01/app/middleware/oracle_common/oui
    Log file location : /u01/app/middleware/oracle_common/cfgtoollogs/opatch/opatch2011-06-08_23-25-29PM.log
     
    Patch history file: /u01/app/middleware/oracle_common/cfgtoollogs/opatch/opatch_history.txt
     
     
    OPatch detects the Middleware Home as "/u01/app/middleware"
     
    ApplySession applying interim patch '9431704' to OH '/u01/app/middleware/oracle_common'
     
    Running prerequisite checks...
    Provide your email address to be informed of security issues, install and
    initiate Oracle Configuration Manager. Easier for you if you use your My
    Oracle Support Email address/User Name.
    Visit http://www.oracle.com/support/policies.html for details.
    Email address/User Name:
     
    You have not provided an email address for notification of security issues.
    Do you wish to remain uninformed of security issues ([Y]es, [N]o) [N]:  y
     
    OPatch detected non-cluster Oracle Home from the inventory and will patch the local system only.
     
     
    Please shutdown Oracle instances running out of this ORACLE_HOME on the local system.
    (Oracle Home = '/u01/app/middleware/oracle_common')
     
     
    Is the local system ready for patching? [y|n]
    y
    User Responded with: Y
    Backing up files and inventory (not for auto-rollback) for the Oracle Home
    Backing up files affected by the patch '9431704' for restore. This might take a while...
    Backing up files affected by the patch '9431704' for rollback. This might take a while...
     
    Patching component oracle.jrf.j2ee, 11.1.1.2.0...
    Copying file to "/u01/app/middleware/oracle_common/modules/oracle.wsm.common_11.1.1/wsm-dependencies.jar"
    ApplySession adding interim patch '9431704' to inventory
     
    Verifying the update...
    Inventory check OK: Patch ID 9431704 is registered in Oracle Home inventory with proper meta-data.
    Files check OK: Files from Patch ID 9431704 are present in Oracle Home.
     
    The local system has been patched and can be restarted.
     
     
    OPatch succeeded.
    oracle@gc01:/u01/INSTALL/9431704>

  • Start OMS processes:

    oracle@gc01:/u01/app/middleware/oms11g/bin> ./emctl start oms
    Oracle Enterprise Manager 11g Release 1 Grid Control
    Copyright (c) 1996, 2010 Oracle Corporation.  All rights reserved.
    Starting WebTier...
    WebTier Successfully Started
    Starting Oracle Management Server...
    Oracle Management Server Successfully Started
    Oracle Management Server is Up
    oracle@gc01:/u01/app/middleware/oms11g/bin>

After applying this one-off patch, FMW Welcome Page Application should no longer be reported as down:


Categories: Uncategorized Tags:

Oracle Grid Control: “error: invalid compressed data to inflate” when trying do unzip Grid Control installation zip-file

Problem description:

When trying to extract the downloaded file GridControl_11.1.0.1.0_Linux_x86-64_2of3.zip for a Grid Control intallation on Linux x86_64, you are receiving an error:

gc01:/INSTALL # unzip GridControl_11.1.0.1.0_Linux_x86-64_2of3.zip
Archive:  GridControl_11.1.0.1.0_Linux_x86-64_2of3.zip
   creating: oms/Disk1/stage/Components/oracle.sysman.ocamm/
   creating: oms/Disk1/stage/Components/oracle.sysman.ocamm/11.1.0.1.0/
   creating: oms/Disk1/stage/Components/oracle.sysman.ocamm/11.1.0.1.0/1/
   creating: oms/Disk1/stage/Components/oracle.sysman.ocamm/11.1.0.1.0/1/DataFiles/
  inflating: oms/Disk1/stage/Components/oracle.sysman.ocamm/11.1.0.1.0/1/DataFiles/filegroup1.jar
  inflating: oms/Disk1/stage/Components/oracle.sysman.ocamm/11.1.0.1.0/1/DataFiles/filegroup2.jar
   creating: oms/Disk1/stage/Components/oracle.sysman.paf/
   creating: oms/Disk1/stage/Components/oracle.sysman.paf/11.1.0.1.0/
   creating: oms/Disk1/stage/Components/oracle.sysman.paf/11.1.0.1.0/1/
   creating: oms/Disk1/stage/Components/oracle.sysman.paf/11.1.0.1.0/1/DataFiles/
  inflating: oms/Disk1/stage/Components/oracle.sysman.paf/11.1.0.1.0/1/DataFiles/filegroup5.jar
  inflating: oms/Disk1/stage/Components/oracle.sysman.paf/11.1.0.1.0/1/DataFiles/filegroup9.jar
  inflating: oms/Disk1/stage/Components/oracle.sysman.paf/11.1.0.1.0/1/DataFiles/filegroup3.jar
  inflating: oms/Disk1/stage/Components/oracle.sysman.paf/11.1.0.1.0/1/DataFiles/filegroup1.jar
  inflating: oms/Disk1/stage/Components/oracle.sysman.paf/11.1.0.1.0/1/DataFiles/filegroup2.jar
  inflating: oms/Disk1/stage/Components/oracle.sysman.paf/11.1.0.1.0/1/DataFiles/filegroup11.jar
  inflating: oms/Disk1/stage/Components/oracle.sysman.paf/11.1.0.1.0/1/DataFiles/filegroup12.jar
  inflating: oms/Disk1/stage/Components/oracle.sysman.paf/11.1.0.1.0/1/DataFiles/filegroup7.jar
  inflating: oms/Disk1/stage/Components/oracle.sysman.paf/11.1.0.1.0/1/DataFiles/filegroup8.jar
  inflating: oms/Disk1/stage/Components/oracle.sysman.paf/11.1.0.1.0/1/DataFiles/filegroup4.jar
  inflating: oms/Disk1/stage/Components/oracle.sysman.paf/11.1.0.1.0/1/DataFiles/filegroup10.jar
  inflating: oms/Disk1/stage/Components/oracle.sysman.paf/11.1.0.1.0/1/DataFiles/filegroup6.jar
   creating: oms/Disk1/stage/Components/oracle.sysman.agent.download/
   creating: oms/Disk1/stage/Components/oracle.sysman.agent.download/11.1.0.1.0/
   creating: oms/Disk1/stage/Components/oracle.sysman.agent.download/11.1.0.1.0/1/
   creating: oms/Disk1/stage/Components/oracle.sysman.agent.download/11.1.0.1.0/1/DataFiles/
  inflating: oms/Disk1/stage/Components/oracle.sysman.agent.download/11.1.0.1.0/1/DataFiles/filegroup5.1.1.jar
  error:  invalid compressed data to inflate
  inflating: oms/Disk1/stage/Components/oracle.sysman.agent.download/11.1.0.1.0/1/DataFiles/filegroup4.1.1.jar
  inflating: oms/Disk1/stage/Components/oracle.sysman.agent.download/11.1.0.1.0/1/DataFiles/filegroup1.1.1.jar
  inflating: oms/Disk1/stage/Components/oracle.sysman.agent.download/11.1.0.1.0/1/DataFiles/filegroup2.jar
  inflating: oms/Disk1/stage/Components/oracle.sysman.agent.download/11.1.0.1.0/1/DataFiles/filegroup6.1.1.jar
  inflating: oms/Disk1/stage/Components/oracle.sysman.agent.download/11.1.0.1.0/1/DataFiles/filegroup3.1.1.jar
gc01:/INSTALL # echo $?
2
gc01:/INSTALL #

Cause:

The file seems to be broken on the Oracle server since multiple downloads of the file always lead to a the same wrong checksum “3966614633″.

  • Checksum for downloaded file:

    oracle@gc01:/INSTALL> cksum GridControl_11.1.0.1.0_Linux_x86-64_2of3.zip
    3966614633 1589671704 GridControl_11.1.0.1.0_Linux_x86-64_2of3.zip
    oracle@gc01:/INSTALL>
  • Checksums listed by Oracle:

    GridControl_11.1.0.1.0_Linux_x86-64_1of3.zip (1,430,649,530 bytes) (cksum - 4223002664)
    GridControl_11.1.0.1.0_Linux_x86-64_2of3.zip (1,589,671,704 bytes) (cksum - 535544209)
    GridControl_11.1.0.1.0_Linux_x86-64_3of3.zip (1,408,054,645 bytes) (cksum - 2199662147)

Problem resolution:

Download the Enterprise Manager installation medias from edelivery.oracle.com. The zip-files from this installation source are not broken and will output the correct checksums:

oracle@gc01:/INSTALL> cksum V23674-01_2of3.zip
535544209 1589671704 V23674-01_2of3.zip
oracle@gc01:/INSTALL>

Extraction:

oracle@gc01:/INSTALL> unzip V23674-01_2of3.zip
Archive:  V23674-01_2of3.zip
replace oms/Disk1/stage/Components/oracle.sysman.ocamm/11.1.0.1.0/1/DataFiles/filegroup1.jar? [y]es, [n]o, [A]ll, [N]one, [r]ename: A
  inflating: oms/Disk1/stage/Components/oracle.sysman.ocamm/11.1.0.1.0/1/DataFiles/filegroup1.jar
  inflating: oms/Disk1/stage/Components/oracle.sysman.ocamm/11.1.0.1.0/1/DataFiles/filegroup2.jar
  inflating: oms/Disk1/stage/Components/oracle.sysman.paf/11.1.0.1.0/1/DataFiles/filegroup5.jar
  inflating: oms/Disk1/stage/Components/oracle.sysman.paf/11.1.0.1.0/1/DataFiles/filegroup9.jar
  inflating: oms/Disk1/stage/Components/oracle.sysman.paf/11.1.0.1.0/1/DataFiles/filegroup3.jar
  inflating: oms/Disk1/stage/Components/oracle.sysman.paf/11.1.0.1.0/1/DataFiles/filegroup1.jar
  inflating: oms/Disk1/stage/Components/oracle.sysman.paf/11.1.0.1.0/1/DataFiles/filegroup2.jar
  inflating: oms/Disk1/stage/Components/oracle.sysman.paf/11.1.0.1.0/1/DataFiles/filegroup11.jar
  inflating: oms/Disk1/stage/Components/oracle.sysman.paf/11.1.0.1.0/1/DataFiles/filegroup12.jar
  inflating: oms/Disk1/stage/Components/oracle.sysman.paf/11.1.0.1.0/1/DataFiles/filegroup7.jar
  inflating: oms/Disk1/stage/Components/oracle.sysman.paf/11.1.0.1.0/1/DataFiles/filegroup8.jar
  inflating: oms/Disk1/stage/Components/oracle.sysman.paf/11.1.0.1.0/1/DataFiles/filegroup4.jar
  inflating: oms/Disk1/stage/Components/oracle.sysman.paf/11.1.0.1.0/1/DataFiles/filegroup10.jar
  inflating: oms/Disk1/stage/Components/oracle.sysman.paf/11.1.0.1.0/1/DataFiles/filegroup6.jar
  inflating: oms/Disk1/stage/Components/oracle.sysman.agent.download/11.1.0.1.0/1/DataFiles/filegroup5.1.1.jar
  inflating: oms/Disk1/stage/Components/oracle.sysman.agent.download/11.1.0.1.0/1/DataFiles/filegroup4.1.1.jar
  inflating: oms/Disk1/stage/Components/oracle.sysman.agent.download/11.1.0.1.0/1/DataFiles/filegroup1.1.1.jar
  inflating: oms/Disk1/stage/Components/oracle.sysman.agent.download/11.1.0.1.0/1/DataFiles/filegroup2.jar
  inflating: oms/Disk1/stage/Components/oracle.sysman.agent.download/11.1.0.1.0/1/DataFiles/filegroup6.1.1.jar
  inflating: oms/Disk1/stage/Components/oracle.sysman.agent.download/11.1.0.1.0/1/DataFiles/filegroup3.1.1.jar
oracle@gc01:/INSTALL> echo $?
0
oracle@gc01:/INSTALL>
Categories: Uncategorized Tags:

Oracle RAC on Linux: PRVF-5449 and PRVF-5431 when executing addNode.sh

Problem description:

Executing addNode.sh in 11.2 results in PRVF-5449 and PRVF-5431 if Voting Disks are located on Oracle ASM Disks:

Checking Oracle Cluster Voting Disk configuration...
 
ERROR:
PRVF-5449 : Check of Voting Disk location "ORCL:GRID01(ORCL:GRID01)" failed on the following nodes:
Check failed on nodes:
        racn02
 
        racn02:No such file or directory
 
ERROR:
PRVF-5449 : Check of Voting Disk location "ORCL:GRID02(ORCL:GRID02)" failed on the following nodes:
Check failed on nodes:
        racn02
 
        racn02:No such file or directory
 
ERROR:
PRVF-5449 : Check of Voting Disk location "ORCL:GRID03(ORCL:GRID03)" failed on the following nodes:
Check failed on nodes:
        racn02
 
        racn02:No such file or directory
 
PRVF-5431 : Oracle Cluster Voting Disk configuration check failed
Time zone consistency check passed
 
 
 
[grid@racn01 bin]$

Although the Oracle ASM Disks are available on the node to add:

[root@racn02 ~]# service oracleasm listdisks | grep GRID
GRID01
GRID02
GRID03
[root@racn02 ~]#

Cause:

addNode.sh is checking Oracle ASM disks incorrectly and will cancel the node addition for Voting Devices on ASM disks.

Problem resolution:

Check manually if the Oracle ASM Disks are available on the nodes to add:

[root@racn02 ~]# service oracleasm listdisks | grep GRID
GRID01
GRID02
GRID03
[root@racn02 ~]#

If the voting disk locations check was the only one that failed, use the environment variable IGNORE_PREADDNODE_CHECKS and rerun addNode.sh. Otherwise resolve the other errors first before continuing.

Example usage of IGNORE_PREADDNODE_CHECKS:

[grid@racn01 bin]$ export IGNORE_PREADDNODE_CHECKS=Y
[grid@racn01 bin]$ ./addNode.sh "CLUSTER_NEW_NODES={racn02}" "CLUSTER_NEW_VIRTUAL_HOSTNAMES={racn02-vip}"
...
...
Categories: Uncategorized Tags:

SuSE/SLES: hostname does neither print domain name nor fully qualified hostname

Problem description:

The hostname command does not recognise the domainname and will not use it in its output formats:

sles01:~ # hostname
sles01
sles01:~ # hostname -f
sles01
sles01:~ # hostname -d
 
sles01:~ #

Although the configuration seems correct:

  • /etc/HOSTNAME:

    sles01:~ # cat /etc/HOSTNAME
    sles01.mydomain
    sles01:~ #
  • /etc/resolv.conf:

    sles01:~ # cat /etc/resolv.conf
    search mydomain
    nameserver 192.168.0.1
    sles01:~ #

Problem resolution:

Check your /etc/hosts file and the order of the entries for your host. The fully qualified domain name should be in first position. In my case, the hosts-file somehow contained an entry with a wrong order:

sles01:~ # cat /etc/hosts
#
# hosts         This file describes a number of hostname-to-address
#               mappings for the TCP/IP subsystem.  It is mostly
#               used at boot time, when no name servers are running.
#               On small systems, this file can be used instead of a
#               "named" name server.
# Syntax:
#
# IP-Address  Full-Qualified-Hostname  Short-Hostname
#
 
127.0.0.1       localhost
 
192.168.0.100   sles01 sles01.mydomain
sles01:~ #

Example for a correct order of the entries:

sles01:~ # cat /etc/hosts
#
# hosts         This file describes a number of hostname-to-address
#               mappings for the TCP/IP subsystem.  It is mostly
#               used at boot time, when no name servers are running.
#               On small systems, this file can be used instead of a
#               "named" name server.
# Syntax:
#
# IP-Address  Full-Qualified-Hostname  Short-Hostname
#
 
127.0.0.1       localhost
 
192.168.0.100   sles01.mydomain sles01
sles01:~ #
Categories: Uncategorized Tags: