Shutting Down a Database - Firebird - Firebird

Database shutdown is not the same as shutting down the server. The server stays running when a database is shut down.

A database is implicitly “in a shutdown state” when no connections are active. An explicit shutdown condition can be imposed, using gbak with the –sh[ut] switch, to enable the SYSDBA or the database owner to get exclusive access. Once this explicit shutdown state is achieved, it remains until explicitly deactivated by gbak –o[nline].

The two operations are referred to as “shutting down a database” and “putting a database online.”

Database Shutdown Before Server Shutdown

Whenever you need to shut down the server in a production environment, you will normally want to use gfix –shut to shut down individual databases in a controlled way first.

The gfix –shut Command

The syntax pattern for gfix –sh[ut] is as follows. POSIX:

./gfix -sh[ut] {-at n |-t n |-f n } db_name

Windows:

gfix -sh[ut] {-at n |-t n |-f n } db_name

Qualifying Arguments

The gfix –shut switch comes with a choice of three qualifiers to qualify the strategy for the shutdown: –at[tach] n, –tr[an] n, and –f[orce] n. In each case, n sets a timeout period in seconds. You must use one argument.

–at[tach] n is used to prevent new database connections. It doesn’t force existing connections off, but it blocks any new ones. If no processes are still connected when the timeout period of n seconds expires, the database will be in the shutdown state. If there are still processes connected, the shutdown is cancelled.

–tr[an] n is used to prevent new transactions from starting. It doesn’t forcibly end existing transactions, but it disallows any new ones from being started. If no processes are connected when the timeout period of n seconds expires, the database will be in the shutdown state. If there are still transactions active, the shutdown is cancelled.

–f[orce] n will force the database into a shutdown state after n seconds, regardless of any connected processes or active transactions. This is a drastic operation that could cause users to lose their work. It should be used with caution.

Examples:

gfix -sh -at 300

initiates a shutdown that will take effect in 5 minutes, if all users detach from the database.

gfix -sh -f 600

will force all users off the system in 10 minutes. Any transactions still running will be rolled back and users will lose their uncommitted work.

Exclusive Access

When a database is in a shutdown state, SYSDBA or the owner can log in and have exclusive access. However, watch out for these “gotchas”:

  • If either the owner or SYSDBA was already logged in when the shutdown took effect, the server will not block the other from logging in once the shutdown is in effect.
  • Once either SYSDBA or the owner logs in after the shutdown, the other will be blocked from logging in. That’s good. If the same user wants to log in again, it will be permitted. That’s not so good.

This puts the onus on the SYSDBA or owner user who needs exclusive access to ensure that either itself or the other is not logged in somewhere, using a visual admin tool, an SQL monitor, another command-line tool, or even another gfix option, for example. Once you get exclusive access, keep it exclusive—don’t start up more than one application.

Terminating a Shutdown

Use gfix –o[nline] to cancel a shutdown and put the database back online for multipleuser access. You can also use it to cancel a scheduled shutdown (i.e. one that has not completed its timeout).

Server Shutdowns and Restarts

Be aware that shutting down or restarting the server does not have any effect on the shutdown state of any databases. If a database is in a shutdown state when the server is stopped, it will still be in a shutdown state when the server is next started. Shutting down the server does not put any database into a shutdown state.


All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

Firebird Topics