- Log on to the Teradata Database computer from the operator's console, another network-attached host, or a mainframe. If the logon succeeds, the Teradata Database is operational. If you are unable to log on, contact a field representative.
- Have a field representative verify that the adaptor cable is connected.
- Have a field representative check the Multibus Adaptor Board (MAB).
Perform the following tests for all entries in CopInfoTbl on the Teradata Database.
- Check for incorrect, missing, or duplicate cabinet and processor numbers (ccc_p).
- Check for incorrect, missing, or duplicate network addresses.
- Check for the correct network protocol type (CopKind) for each COP.
- Check for the correct host number for each COP, AP, or node.
- Verify that the entries in CopInfoTbl match the entries in the /etc/hosts file (on the client) or the hosts file on the NIS master. Use the CopUpdate macro to change CopInfoTbl.
If a COP, AP, or node is added to or removed from the Teradata Database or if the network address a COP is
changed, execute the CopUpdate macro so the Teradata Database can determine changes to network
Restart the Teradata Database for the changes to take effect.
If using Internet routing (routers), perform the following tests for
- Check for incorrect or missing network addresses of destinations.
- Check for incorrect or missing network addresses of routes.
- Verify that each router is identified by two (or more) Internet addresses, one for each network on which it resides. Use the TcpRoute macro to change CopRoutesTbl.
- If a subnet outing (subnetting) is used, check CopOptionsTbl for incorrect or missing subnet masks.
- Use the AddOption macro to change CopOptionsTbl.
If the Teradata Database goes down and then
comes back up, its sessions table still contains information about the sessions generated by
hosts. The Teradata Database expects to receive
reconnect messages from hosts.
If the Teradata Database does not receive the reconnect messages within 20 minutes after it comes back up, it removes the sessions that were generated by hosts that have not reconnected from the sessions table. This implies that for 20 minutes after the Teradata Database comes back up, some sessions are being kept that may not be used.
If use of the Teradata Database is heavy, users unable to log on during that 20 minute period (because the maximum number of sessions has been reached) can try again after the unclaimed sessions are cleared away.
Teradata Database problems should be diagnosed with the assistance of a field service representative.