In Oracle 10g there are two very different ways to configure TAF: with TNSNAMES (since 8.0, automatic generation new in 10g) and with DBMS_SERVICES (entirely new in 10g). They are very different approaches and it appears that the new DBMS_SERVICES method will be preferred moving forward since it has been given precedence and overrides whatever is in the client’s TNSNAMES.
The fundamental difference between these approaches is that the latter (preferred) method is truly centralized and much more manageable in an environment with many clients. The TAF settings are stored in only one place – on the server. There are a few disadvantages to this approach but overall the advantages seem to outweigh them. However before getting to that, 10g has also simplified management for the original TNSNAMES approach.
When TAF was introduced in Oracle 8.0 it was setup through the client’s TNSNAMES file. The syntax changed in 8i but it still went into the same file; and it has not changed much since then. But 10g did add a useful new TAF-related feature to two of its utilities: the ability to auto-generate a TAF TNSNAMES entry. This can not only save you a little time but can also help you avoid simple syntax mistakes.
Automatic TNSNAMES Generation With DBCA
The first tool that can auto-generate these entries is DBCA. In fact 10g added a whole new sub-section for Services management in RAC databases. There is a radio button at the bottom of the screen where you can set the “TAF Policy” to None, Basic, or Pre-connect. When you click finish DBCA will always create correct entries for each service and store them in the local TNSNAMES file. (It is nondestructive and will not change any of your other entries in the file.)
Here’s the entry that will be generated by the screenshot above:
DB2SVC2 =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = rh4lab15-vip)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = rh4lab16-vip)(PORT = 1521))
(LOAD_BALANCE = yes)
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = db2svc2.lab.ardentperf.com)
(FAILOVER_MODE =
(TYPE = SELECT)
(METHOD = BASIC)
(RETRIES = 180)
(DELAY = 5)
)
)
)
DBCA seems to create the entries correctly and completely. The only caveat is that it always creates them with SELECT failover; but most people seem to be using this anyway. If you want to use SESSION failover then you just need to update the entry before copying it into your master TNSNAMES for distribution to clients. Also, if there is a firewall between your database servers and clients then you may need to update hostnames to what the clients will see. But overall DBCA still can save you some time by giving you a head start on creating the entries. This approach seems to be the easiest and least error-prone way to manage TNSNAMES entries.
Automatic TNSNAMES Generation With srvctl
The second tool that can auto-generate these entries is srvctl. For example:
[oracle@rh4lab15 admin]$ srvctl modify service -d db2rac1 -s db2svc2 -P BASIC
[oracle@rh4lab15 admin]$ srvctl config database -d db2rac1 -t|grep db2svc2
Example client-side TNS entry for service db2svc2:
db2svc2 = (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=db_vip)(PORT=dedicated_port)
)(CONNECT_DATA=(SERVICE_NAME=db2svc2.lab.ardentperf.com)(FAILOVER_MODE=(TYPE=SEL
ECT)(METHOD=BASIC)))
That’s a little hard to decipher; here’s the same thing but more readable:
db2svc2 =
(DESCRIPTION=
(ADDRESS=
(PROTOCOL=TCP)(HOST=db_vip)(PORT=dedicated_port)
)
(CONNECT_DATA=
(SERVICE_NAME=db2svc2.lab.ardentperf.com)
(FAILOVER_MODE=
(TYPE=SELECT)
(METHOD=BASIC)
)
)
)
As you can see it’s not quite complete; you will need to add the VIP hostname and port number for each preferred host in your cluster. Also, the failover mode is always SELECT just like DBCA. But once again, this can help you remember the right syntax and save you a little time.
The first step to centralizing your TAF configuration is having an authoritative source for TNSNAMES entries. What better place then the TNSNAMES file of the database server? DBCA can automatically maintain these entries – and simplify your life as a DBA.
Stay tuned for part 2 and a discussion of DBMS_SERVICES and server-side TAF configuration!
—
Update: part 2 is now available.
Discussion
Trackbacks/Pingbacks
Pingback: Centralized TAF Configuration in 10g, Part 2 : Ardent Performance Computing - March 29, 2007