Oracle Observations

March 20, 2007

Oracle Names troubleshooting

Filed under: Oracle Names — bigdaveroberts @ 5:22 pm

As described previously, you can check the database entries and the cache entries for your databases.
If the data in the database and the cache file (ckpreg.ora) is correct, then restart the names server.

E.g.

Restarting the names demon:

/usr/home/oracle O>namesctl

Oracle Names Control for IBM/AIX RISC System/6000: Version 8.1.7.0.0 – Production on 03-FEB-2003 15:20:29

(c) Copyright 1997 Oracle Corporation.  All rights reserved.

Currently managing name server “NameServer.world”
Version banner is “Oracle Names for IBM/AIX RISC System/6000: Version 8.1.7.4.0
- Production”

Welcome to NAMESCTL, type “help” for information.

NAMESCTL> stop
Confirm [yes or no]: yes
Server shutting down
NAMESCTL> start
Starting “/opt/app/oracle/8.1.7/bin/names”…server successfully started

Etc….
If the data in the database is incorrect, unregister the database and reregister it.

E.g.

Take the entry in the database that includes the characters: ‘(TYPE=a.smd.)’ in the ZD_VALUE1_P column:

(DATA_LIST=(FLAGS=0×1)(DATA=(TYPE=a.smd.)(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=tplive)(PORT=1521))(CONNECT_DATA=(SID=TPLIVE2))))) Remove the text in red and unregister the database using the remaining text as the address:Eg:NAMESCTL> unregister testdb -t database -d (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=testsvr)(PORT=1521))(CONNECT_DATA=(SID=TESTDB)))
Total response time:   0.09 seconds
Response status:       normal, successful completion
NAMESCTL>

If there are multiple entries, unregister them all.

Then register the correct address.

NAMESCTL> register testdb -t database -d (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=testsvr)(PORT=1521))(CONNECT_DATA=(SID=TESTDB)))
Total response time:   0.07 seconds
Response status:       normal, successful completion
NAMESCTL>

If the data in the cache is incorrect, stop the names server, move or remove all the .ora files in the $ORACLE_HOME/network/names directory. Finally restart the names server.

The $ORACLE_HOME/network/names is the default location for the cache files.

Theoretically the location could be changed by the following parameters in the names.ora file that is normally located in the $ORACLE_HOME/network/admin directory. The names.ora file should never be deleted!

Names.ora file parameters that specify the location of the names cache files:

NAMES.CACHE_CHECKPOINT_FILE
NAMES.CONFIG_CHECKPOINT_FILE
NAMES.REGION_CHECKPOINT_FILE

Frequently the data will be corrupt in more than one place, in that case, re register the data in the database, and when that is correct, stop the names server and remove the cached files.

If you suspect that the incorrect data is being passed to the names server from another names server, then you should configure your own sqlnet.ora file to use oracle names name resolution, and you should list only one names server at a time and verify what is being returned by using tnsping to connect to the database.

Eg:

NAMES.DIRECTORY_PATH = (ONAMES)
NAMES.PREFERRED_SERVERS =
  (ADDRESS_LIST =
    (ADDRESS = (COMMUNITY = TCP.world)(PROTOCOL = TCP)(Host = namesvr1)(Port = 1527))
  )

If it is not possible to change the configuration to verify the data returned from the names server, then the same information can be gained by switching on tracing.

If the data returned from multiple names servers is incorrect, and attempts to correct the data one server at a time is unsuccessful, then you will need to stop all the names servers, then individually start each one up, correct the data and shut it down. When all the servers are fixed then they can all be restarted. It should be noted that during this period access to all the databases will be restricted.

The primary repository for names configuration data is the database, which can be checked while the names demon is stopped. After starting the names demon, the data is read from the database, and is then saved to the cache files. I am not aware of any documentation that indicates what source the names demon will use as a primary source of information when multiple sources are available.

March 1, 2007

First Oracle tip!

Filed under: Oracle Names — bigdaveroberts @ 1:34 pm

Oracle Names was one of those products which never met its promise, I suspect largely because of a lack of a ‘point one’ release.

I have no experience of the first release of Oracle Names, but I was surprised by the substantive change in the product between releases 2 and 3. (The versions that came with Oracle 7.3 and the version that came with Oracle8.1.7).

This first entry on Oracle names will cover general names advice, with troubleshooting and upgrading being covered later.

 1) You should not be considering rolling out new installations of Oracle Names! The product has been superseded by Oracles implementation of LDAP.

2) The commands for registering and unregistering nodes are very syntactically intolerant. It is very easy by mistyping a single character in a command to produce significant dilatory effects.

Specifically there must be a space between -t and the following argument, and the -d and the following argument, and the arguments can contain no spaces. Also no new lines are allowed!

E.g.:

register testdb -t database -d (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=testsvr)(PORT=1521))(CONNECT_DATA=(SID=TESTDB)))

Additionally, the unregister command is case-sensitive. If the description is not identical (including case) to the description used to register the database, the unregister command will fail:

E.g.:

unregister testdb -t database -d (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=testsvr)(PORT=1521))(CONNECT_DATA=(SID=TESTDB)))

The address used to register the database with the -d parameter is the same as the data that would have been used to set up a database in the tnsnames.ora file, except for the fact that the whole entry must be on one line and contain no spaces.

3) When an oracle client contacts a names server, that data returned can be from 1 of 4 places.

1 In the names executable memory
2 From another names server on another machine.
3 From a cached file in the $ORACLE_HOME/network/names directory
4 From the database (the main repository for names data)

When incorrect data is returned, the data is wrong in 1 or more of the above locations!

4) While I know of no method of checking what the names server has in its process space, it is possible to check what is in the cache and the database.

To find out what is stored in the cache file go to the names directory and grep for the database name.

Eg:

$ cd $ORACLE_HOME/network/names
$ grep -i testdb *.ora
ckpreg.ora: (DATA=(TYPE=a.smd.)(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=testsvr)(PORT=1521))(CONNECT_DATA=(SID=TESTDB))) )
ckpreg.ora:testdb.world. = (DATA_LIST=(FLAGS=0×1)(TTL=20864)
ckpreg.ora: (DATA=(TYPE=a.smd.)(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=testsvr)(PORT=1521))(CONNECT_DATA=(SID=TESTDB))) )
$

To find out what is stored in the database, connect to the database and perform the following query:

1 select * from onrs_region
  2 where upper( name_p ) like ‘%TESTDB%’
  3* and ZD_VALUE1_P is not null
SQL > /

DOMAIN_NAME_P
——————————————————————————–
NAME_P
——————————————————————————–
ZD_VALUE1_P
——————————————————————————–
(root)
testdb.world
(DATA_LIST=(FLAGS=0×1)(DATA=(TYPE=a.smd.)(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=testsvr)(PORT=1521))(CONNECT_DATA=(SID=TESTDB)))))

(root)
testdb.world
(DATA_LIST=(FLAGS=0×1)(DATA=(TYPE=v1addr.npd.omd.)TION=(ADDRESS=(PROTOCOL=TCP)(HOST=testsvr)(PORT=1521))(CO))

It can be seen in the above example that the information in both locations (database and cache) are similar.

5) I believe that if the database and cache were wrong, it would still be possible that the names server could be returning data from another names server. I.e. even though 2 servers are defined at the client end, and the names client will transparently contact the second names server if the first server doesn’t respond, there are also mechanisms in names where the names server on machine B with transparently contact the names server on machine A to resolve a TNS name, in this case the database and cache could both be wrong, while the correct data could be returned to the client!

If you suspect that the incorrect data is being passed to the names server from another names server, then you should configure your own sqlnet.ora file to use oracle names name resolution, and you should list only one names server at a time and verify what is being returned by using tnsping to connect to the database.

Eg:

NAMES.DIRECTORY_PATH = (ONAMES)
NAMES.PREFERRED_SERVERS =
  (ADDRESS_LIST =
  (ADDRESS = (COMMUNITY = TCP.world)(PROTOCOL = TCP)(Host = onamessvr)(Port = 1527))
  )

Blog at WordPress.com.