Las herramientas como SQL Server Management Studio facilitan mucho la administración y el desarrollo con SQL Server con multitud de funciones, asistentes y exploradores que permiten realizar fácilmente muchas de las tareas del día a día de administradores y desarrolladores de SQLServer..

El error ADM6044E “DMS Container space full” durante un rebalancing de un tablespace con autoresize después de añadir un container puede llegar a suponer un grave problema en tablespaces grandes, puesto que en teoria una operación de rebalanceo se puede realizar online sin afectación a la base de datos, pero en el caso de este error, no se puede escribir en el tablespaces hasta que finaliza la operación de rebalanceo. Por lo que, de “online” nada de nada.

En este artículo muestro un método para ver los índices no-usados de nuestra base de datos desde el último reinicio.

Ya traté este tema en el artículo Detección de índices, tablas y packages no usados en DB2 9.7, pero dicho artículo utiliza la columna LASTCOLUMN incluida en la versión 9.7. Si tienes otra versión, o incluso la 9.7, este artículo te permitirá conocer que índices no están siendo usados, con el desperdicio de recursos que conlleva.

En este artículo podrás consultar los estados más habituales de los tablespaces en DB2.

Estos estados pueden ser consultados de distintas formas, aunque la más habitual desde la linea de comandos en la siguiente.

Aunque seguro que hay otros métodos, en este pequeño artículo, una manera sencilla de conocer el puerto por el que da servicio el servidor DB2.

Obtenemos el nombre del servicio TCP/IP:

> db2 get dbm cfg | grep SVCENAME

Capturamos el resultado:

TCP/IP Service name (SVCENAME) = db2TRP

Lo buscamos en /etc/services:

> cat /etc/services | grep sapdb2QRP

db2TRP 5912/tcp # DB2 Communication Port

El puerto de escucha es el 5912.

Disaster recovery is a set of processes, techniques, and tools used to swiftly and smoothly recover vital IT infrastructure and data when an unforeseen event causes an outage.

The statistics tell the best story about the importance of disaster recovery—98 percent of organizations reported that a single hour of downtime costs over $100,000, while 81 percent indicated that an hour of downtime costs their business over $300,000...

In order to access to the same database where are you working outside the database server you must activate the service called listener, it has to be listening.

It can happens that the database is properly raised and can not connect from other servers, which are also set correctly (correct TNSNAMES, etc.).. 

In these cases could be that the listener has a problem, or simply has not been initiated.

To Check the status, start or stop it is very simple. Just open a command line session (console terminal, etc..) with the user that has installed the database, and run the lsnrctl command with the following parameters:

• Check your state:
    > lsnrctl status

• Stop the listener:
    > lsnrctl stop

• Start the listener:
    > lsnrctl start

Keep in mind that when you stop the listener, the connections that are already in the database won't be closed, so a short stop is not very traumatic, only connections trying to enter while the listener is stopped are rejected, should not affect anyone who already has an opened session.

If you have the system user who installed the database you can enter SQL Plus as DBA user, without entering a password as follows:

1. Enters the system with this user. 
2. From the command line, go into SQLPlus typing:

> sqlplus "/as sysdba"

If you need to enter using this way because you forgot the password of a user, you can easily change it: 

SQL> alter user user_name identified by new_password;

It can be more than one Database installed on the server, so you have to validate that the environment variables of the Oracle's user are pointing to your database.

For verifying that you has login into the correct database you can execute this statement: 

SQL> select name from v$database;