Force Disconnect

Options

ttAdmin has these options for forced disconnect:

Option Description

Option	Description
`-connStr` `connection_string`	An ODBC connection string that specifies a database location, driver, and optionally other connection attribute settings.
`DSN`	An ODBC data source name of the database to be administered.
`-disconnect` `urgency` `[granularity]`	Asynchronously disconnects connected applications from the database, optionally including those that are idle or unresponsive. Acceptable values for `urgency` (required) are: `-transactional` - Allows any open transactions to be committed or rolled back before disconnecting. Does not affect idle connections. `-immediate` - Rolls back any open transactions before immediately disconnecting. This also disconnects idle connections. `-abort` - Aborts all direct mode application processes and client/server processes (`ttcserver`) in order to disconnect them. Note: A recommended best practice is to run `-disconnect` twice, as necessary. First run it in transactional urgency level. Then, after allowing some time, if not all connections have been closed yet, run it in immediate urgency level. Use `ttStatus` to confirm whether connections have been closed. Use abort urgency level only as a last resort if transactional and immediate levels do not result in all connections being closed. Abort may result in loss of data. Abort abruptly causes every user and `ttcserver` process connected to the database to exit. This may result in lost transactions. Acceptable values for `granularity` are: `-users` (default) - Disconnects every user connection to the database. This is useful for administrators who want to perform database maintenance. `-unload` - Disconnects every connection to the database, including the subdaemon. This cleanly unloads the database. Note: RAM policy `always`, described in Perform RAM Operations, conflicts with forced disconnect granularity `unload`. Using both simultaneously results in an error and the disconnect request being ignored.

-connStr connection_string

An ODBC connection string that specifies a database location, driver, and optionally other connection attribute settings.

DSN

An ODBC data source name of the database to be administered.

-disconnect urgency [granularity]

Asynchronously disconnects connected applications from the database, optionally including those that are idle or unresponsive.

Acceptable values for urgency (required) are:

-transactional - Allows any open transactions to be committed or rolled back before disconnecting. Does not affect idle connections.

-immediate - Rolls back any open transactions before immediately disconnecting. This also disconnects idle connections.

-abort - Aborts all direct mode application processes and client/server processes (ttcserver) in order to disconnect them.

Note: A recommended best practice is to run -disconnect twice, as necessary. First run it in transactional urgency level. Then, after allowing some time, if not all connections have been closed yet, run it in immediate urgency level. Use ttStatus to confirm whether connections have been closed.

Use abort urgency level only as a last resort if transactional and immediate levels do not result in all connections being closed. Abort may result in loss of data. Abort abruptly causes every user and ttcserver process connected to the database to exit. This may result in lost transactions.

Acceptable values for granularity are:

-users (default) - Disconnects every user connection to the database. This is useful for administrators who want to perform database maintenance.

-unload - Disconnects every connection to the database, including the subdaemon. This cleanly unloads the database.

Note: RAM policy always, described in Perform RAM Operations, conflicts with forced disconnect granularity unload. Using both simultaneously results in an error and the disconnect request being ignored.

Examples

This sample script uses -disconnect to disconnect all connections to database1, first using transactional urgency level then immediate urgency level:

#!/bin/sh
 
# close the databae
ttAdmin -close database1
 
# disconnect users and unload the database
ttAdmin -disconnect -transactional -unload database1
 
# wait 10 seconds for the disconnects to finish
COUNT = 0
while [ ttStatus | grep "pending disconnection" ] || [ $COUNT -ne 10 ]
do
  sleep 1
  COUNT=$((COUNT+1))
done
 
# increase urgency to immediate
if [ ttStatus | grep "pending disconnection" ]; then
  ttAdmin -disconnect -immediate -unload database1
fi

Use ttStatus to check progress. During forced disconnect, output indicates the pending disconnections:

TimesTen status report as of Wed Jul 18 09:55:20 2018
 
Daemon pid 10457 port 6627 instance user1
TimesTen server pid 10464 started on port 6629
------------------------------------------------------------------------
------------------------------------------------------------------------
Closed to user connections
Data store /databases/database1
Daemon pid 10457 port 6627 instance user1
TimesTen server pid 10464 started on port 6629
There are 14 connections to the data store, ***14 pending disconnection***
Shared Memory KEY 0x0210679b ID 949092358
PL/SQL Memory KEY 0x0310679b ID 949125127 Address 0x5000000000
Type            PID     Context             Connection Name              ConnID
Process         10484   0x00007f3ddfeb4010  database1 1
...

Notes

To enable the capability for forced disconnect, use the TimesTen connection attribute setting ForceDisconnectEnabled=1. See ForceDisconnectEnabled.

The -disconnect option is asynchronous. Control will quickly return to the command prompt, but the force disconnect operation may take multiple seconds or even minutes to complete. This is why the scripts above use ttStatus to monitor the status of the force disconnect operation.

The users granularity level includes all connections aside from the subdaemon. For example, in addition to user connections, this includes connections for ttcserver and ttstats.

Close the database before attempting a forced disconnect process. Any new connection request is rejected by the main daemon during the forced disconnect process. However, after completion of forced disconnect, connection requests are accepted again if the database is not in a closed state.