DB2 Version 10.1 for Linux, UNIX, and Windows

DISABLE DATABASE command

Undoes Net Search Extender changes to a database.

Authorization

A user must have DBADM privilege to execute the DISABLE DATABASE command.

Prerequisite

Instance owner must hold DBADM with DATAACCESS authority. The SYSADM no longer holds SECADM nor DBADM privilege in Version 9.7. SECADM must explicitly grant DBADM with DATAACCESS to instance owner before running the DISABLE DATABASE command.

Command syntax


>>-DISABLE DATABASE FOR TEXT--+-------+------------------------->
                              '-FORCE-'   

>--+----------------------+------------------------------------><
   '-|connection-options|-'   

connection-options

|--+--------------------------------------------------------------+--|
   '-CONNECT TO--database-name--+-------------------------------+-'   
                                '-USER--userid--USING--password-'

Command parameters

CONNECT TO database-name: The name of the database that is a target for this command. You can omit this parameter, if DB2DBDFT is set and the user is running the command under a user ID with the necessary DB2® authorizations.
USER userid USING password: Use a userid and password to connect to the database.
FORCE: Forces the dropping of all Net Search Extender indexes in the database.

Usage notes

This command resets the connected database, so that it can no longer be used by other Net Search Extender commands. If full-text indexes exist in the database, this command fails unless the FORCE option is used.

This command does not remove DBADM authority from the DB2 instance owner.

Note: Disabling a database will fail if there are any text indexes defined in the database. It is recommended to remove these indexes one by one and then check if any problems occur. If you use the disable database for text force command, it only guarantees that Net Search Extender catalog tables in the database are removed.

However, if some of the indexes can not be completely dropped, there may still be resources that need to be manually cleaned up. These include:

Files in the index, work and cache directory
Scheduler entries in ctedem.dat
Where an index was created using the replication capture option, the IBMSNAP_SIGNAL, IBMSNAP_PRUNE_SET, and IBMSNAP_PRUNCNTL entries in the tables of the remote database must be manually deleted. These entries can be easily identified using APPLY_QUAL="NSE"||<instance name> and TARGET_SERVER= database_name command.
In the following example, the instance is DB2 and the database is SAMPLE.
```
DELETE FROM <ccSchema>.IBMSNAP_SIGNAL
WHERE SIGNAL_INPUT_IN IN
        (SELECT MAP_ID FROM <ccSchema>.IBMSNAP_PRUNCNTL
        WHERE APPLY_QUAL= 'NSEDB2' AND TARGET_SERVER= 'SAMPLE');

DELETE FROM <ccSchema>.IBMSNAP_PRUNCNTL
WHERE APPLY_QUAL= 'NSEDB2' AND TARGET_SERVER= 'SAMPLE';

DELETE FROM <ccschema>.IBMSNAP_PRUNE_SET
WHERE APPLY_QUAL= 'NSEDB2' AND TARGET_SERVER= 'SAMPLE';
```

Changes to the database

The following modifications made in the database to enable Net Search Extender are deleted:

The Net Search Extender catalog views in the database.
All the database objects created by Net Search Extender.

Changes to the file system and shared memory

If you use the FORCE option, the index files are deleted.

If you use the FORCE option, the cache is deleted for any activated cache of indexes.