NOTE: The following three scripts are used only during the modular method of packaging.
Table 4 Modular Package Scripts
Script Name | Description |
Attribute Definition File (oracle.1) For every parameter in the legacy toolkit user configuration file, there is an attribute in the ADF. It also has an additional attribute TKIT_DIR which is analogous to the package directory in the legacy method of packaging. The ADF is used to generate a package ASCII template file.
Module Script (tkit_module.sh) | This script is called by the Master Control Script and acts as an interface |
| between the Master Control Script and the Toolkit interface script |
| (toolkit.sh). It is also responsible for calling the Toolkit Configuration File |
| Generator Script (described below). |
Toolkit Configuration File Generator | This script is called by the Module Script when the package configuration is |
Script (tkit_gen.sh) | applied using cmapplyconf to generate the user configuration file in the |
| package directory (TKIT_DIR). |
Support for multiple listeners
This feature provides support for multiple listeners with the ECM Oracle Toolkit. It enables the user to configure:
1.Single service to monitor all the listeners together. This is the default behavior. To enable single service to monitor all listeners, the listener name must not be passed to the service command. The service_cmd in the package configuration file would appear as service_name Oracle_listener_monitor service_cmd "$SGCONF/scripts/ecmt/Oracle/tkit_module.sh Oracle_monitor_listener" service_restart none service_fail_fast_enabled no service_halt_timeout 300.
2.A separate service to monitor each listener. In this case, the default service_cmd in the package configuration file has to be changed to include the listener name.
For example: service_name Oracle_listener_monitor_1 service_cmd
"$SGCONF/scripts/ecmt/Oracle/tkit_module.sh Oracle_monitor_listener <listener_name1>" service_restart none service_fail_fast_enabled no service_halt_timeout 300 The above lines have to be repeated for each listener. The user should ensure that the listener name passed to this service_cmd, must match to one of those specified in the LISTENER_NAME array.
NOTE: It is not recommended to combine these two configurations together, that is, it is not allowed to configure some listeners in a single service and the others in a separate service. The user should either configure all the listeners in a single service or in a separate service for each of them but not both together.
The user should ensure that the elements in LISTENER_RESTART array and LISTENER_PASS array correspond to those in LISTENER_NAME array in the package configuration file. When some listeners do not require a restart value and some do not require a password, ordering the elements in the arrays becomes difficult. In such cases, to avoid confusion, it is recommended that LISTENER_RESTART is set to '0' and LISTENER_PASS to 'empty quotes'(""), if they are not required.
Support for database hang detection
This feature enables the user to configure a separate service which will detect the database hang and then take appropriate action if a hang is detected. Database hang is detected by connecting to the database and checking its status. If this process takes an unusually long time or if toolkit is unable to retrieve the database status, then it is assumed that the database is hung. The user has the option to configure two attributes when configuring this service:
1.TIMEOUT: This attribute defines how long the script should wait for the database hang check to return success. If the database health cannot be determined within this time after connecting
