HS: Created new FDS class definition in server DD

今天發現ALERT.LOG 中一些莫名其妙的資訊,於是發TAR 給ORACLE ,終於明白了什麼原因了

The meaning of alert.log entries:
HS: Created new FDS class definition in server DD
HS: Class id = 21, class name = ODBC10.1.0.4.0_177
HS: Created new FDS class definition in server DD
HS: Class id = 22, class name = ODBC
HS: Created new FDS instance definition in server DD
HS: Instance id = 1, instance name =

DB2 (class ODBC10.1.0.4.0_177)
HS: Error in server DD access for FDS capabilities
Fri Jan 26 17:00:06 2007
HS: Created new FDS class definition in server DD
HS: Class id = 23, class name = ODBC10.1.0.4.0_177
HS: Created new FDS class definition in server DD
HS: Class id = 24, class name = ODBC
HS: Created new FDS instance definition in server DD
HS: Instance id = 2, instance name =

DB2 (class ODBC10.1.0.4.0_177)
HS: Agent updated DD with class capabilities
HS: uploaded from instance DB2
HS: FDS class = 'ODBC10.1.0.4.0_177'

HS: Instance id = 2, instance name =

DB2 (class ODBC10.1.0.4.0_177)
HS: Agent updated DD with class capabilities
HS: uploaded from instance TEST
HS: FDS class = 'ODBC10.1.0.4.0_177'
HS: Agent updated DD with class DD translations
HS: uploaded from instance DB2
HS: FDS class = 'ODBC10.1.0.4.0_177'

[@more@]SOLUTION / ACTION PLAN
=======================
Let me go here into more details and explain you what's going on:

You (or somebody else) configured a connection to a foreign database (for example DB2) and uses GENERIC CONNECTIVITY (somet
imes also called HSODBC). You can verify this by checking out the listener.ora h
aving an entry in the SID section with the key words (PROGRAM=HSODBC).

Somebody used the database link and the HSODBC agent is frequently uploading its capabil
ities into the HS data dictionary of the Oracle database.
Those uploads are logged in the alert.log.


The first time the agent tried to upload its capabilities into the data dictionary it failed (HS: Error in server DD access for FDS capa
bilities). This could happen if the class is already used by another class_name
and thus it retried the operation; so nothing to worry for now.

Here the successfull upload and some more explanations:
Fri Jan 26 17:00:06 2007
HS: Created new FDS class definition in server DD
HS: Class id = 23, class name = ODBC10.1.0.4.0_177
HS: Created new FDS class definition in server DD

=> you are using HSODBC release 10.1.0.4.0 (BTW, according to the service request the database re
lease is 10.2 and using a 10.2 database with 10.1 HSODBC release is NOT supporte
d; but maybe the db release in the service request header is not correctly fille
d).

HS: Class id = 24, class name = ODBC
HS: Created new FDS instance definition in server DD

=> default class for HSODBC for internal use/tracking.

HS: Instance id = 2, instance name = PRDMDMDB2 (class ODBC10.1.0.4.0_177)
HS: Agent updated DD with class capabilities
HS: uploaded from instance PRDMDMDB2

=> the database link to the foreign database is called: PRDMDMDB2

HS: FDS class = 'ODBC10.1.0.4.0_177'

HS: Instance id = 2, instance name = PRDMDMDB2 (class ODBC10.1.0.4.0_177)
HS: Agent updated DD with class capabilities
HS: uploaded from instance PRDMDMDB2
HS: FDS class = 'ODBC10.1.0.4.0_177'
HS: Agent updated DD with class DD translations
HS: uploaded from instance PRDMDMDB2
HS: FDS class = 'ODBC10.1.0.4.0_177'

Above the HSODBC agent uploaded its capabilities (the functions like to_number, not null and how to translate them to
an ODBC language that the remote DB2 database can interprete...) permanently i
nto the data dictionary.

If you want to check out what was going on, you can for example ahve a look at the HS views described in the Generic Connectivity manu
al:

SQL> select * from hs_fds_class;

FDS_CLASS_NAME
------------------------------
FDS_CLASS_COMMENTS
------------------------------------------
FDS_CLASS_ID
------------

ODBC10.2.0.3.0_250
self-registered FDS class
4
ODBC
self-registered FDS class
5

My CLASS_NAME is ODBC_10.2.0.3.0_250 and the class_id is 4.
The class ID varies as is a simple counter and increased as soon as another class registers at the database; so the next agent that automaticall
y registers at the database will get the get the next class ID; in my case 5; FD
S_CLASS_ID=5 points to the CLASS_NAME ODBC which is an internal class needed by
HSODBC.

.
SUMMARY
========
The entries in the alert.log are nothing to worry; the entries are just LOG entries from the HSODBC agent notifying in the alert.log
that it tries to update the HS data dictionary and that it finally successfully
uploaded its capabilities.






29-JAN-07 07:06:58 GMT

.
FEEDBACK
=========
These details can be found in the GENERIC CONNECTIVITY manual as well;


Please let me know if you need more details; else fell free to close the service request.
Best regards,
Klaus Gronau
Oracle Support Services


29-JAN-07 07:07:07 GMT

Email Update button has been pressed: Sending email to longchun.zhu@gmail.com.