http://www.mtbase.com/contenido/documento.jsp?

id=10035

¿Cómo Evitar Desastres a Través de Buenas

Prácticas de Administración de Base de
Datos?

Introducción
Este documento técnico describe prácticas recomendadas que pueden ayudar al Administrador de
Adaptive Server Enterprise (ASE) a mantener el servidor de datos en buen funcionamiento y a
estar preparado para emergencias.

Recomendaciones de Administración del Sistema

Las siguientes prácticas le pueden ayudar a mantener su instalación de Adaptive Server
Enterprise trabajando al máximo. Al mantener estas prácticas, usted puede maximizar el tiempo
de disponibilidad del servidor, corregir problemas proactivamente y estar preparado para manejar
emergencias.

1. Mantenga copias de respaldo (backups) al día

El mantener copias de respaldo al día de sus datos es vital para cualquier plan de
recuperación. Mantenga múltiples generaciones de copias y mantenga algunas fuera de
sitio como precaución extra.

Realice backups regulares de:

o La base de datos master. Para asegurarse de que su copia de respaldo de master

está siempre actualizada, genere una copia de respaldo de master después de cada
comando de mantenimiento que afecte dispositivos de base de datos,
almacenamiento, bases de datos o segmentos. Por ejemplo, después de crear o
borrar bases de datos, inicializar nuevos dispositivos de base de datos y crear o
modificar segmentos.
o La base de datos model (si usted ha hecho modificaciones o ha agregado objetos a
esta base de datos).
o La base de datos sybsystemprocs (si usted ha hecho modificaciones o ha agregado
objetos a esta base de datos).
o Bases de datos de usuario
 Recuerde que las últimas versiones de ASE incorporan varias características adicionales,
como configuración de memoria compartida para el Backup Server y compresión de
Backups.

2. Mantenga copias de las tablas de datos y scripts de creación de objetos (DDL)

Mantenga copias actualizadas de las siguientes tablas:

o sysusages
o syslogins
o sysloginroles
o sysdatabases
o sysdevices
o syscharsets
o sysconfigures
o sysservers
o sysremotelogins
o sysresourcelimits (11.5 y posterior)
o systimeranges (11.5 y posterior)

Utilice el programa bcp de Sybase para copiar el contenido de estas tablas.

Adicionalmente, mantenga una copia escrita imprimiendo la salida de las siguientes
consultas:

select * from sysusages order by vstart

select * from sysusages order by dbid, lstart
select * from syslogins
select * from sysloginroles
select * from sysdatabases
select * from sysdevices
select * from syscharsets
select * from sysconfigures
select * from sysservers
select * from sysremotelogins
select * from sysresourcelimits (11.5 y posterior)
select * from systimeranges (11.5 y posterior)

También mantenga:

o Copias de su archivo de configuración, $SYBASE/

$SYBASE_ASE/nombre_del_servidor.cfg en Unix, y %SYBASE%\
%SYBASE_ASE%\nombre_del_servidor.cfg en Windows.
o Todos los scripts de creación de objetos (scripts DDL) que usted utilice para crear
objetos de usuario. Utilice el programa Sybase Central para generar los scripts.
Desde la versión 12.5, ASE incorpora el utilitario ddlgen, el cual permite la
generación de scriprs DDL desde la línea de comandos del sistema operativo.
Para mayor información sobre éste utilitario vea el documento Generación de
Sentencias DDL con ddlgen (DocId: 10132).
3. Verifique la consistencia de las bases de datos

Ejecute comandos dbcc regularmente para monitorear el estado de sus bases de datos.
Las verificaciones a nivel de base de datos se pueden realizar con dbcc checkdb, dbcc
checkalloc, y dbcc checkstorage (11.5 y posterior). Para mayor explicación sobre los
comandos dbcc, vea el manual System Administration Guide de Sybase.

Dado que los comandos dbcc pueden ser intensivos en uso de recursos, considere adoptar
una estrategia que saque provecho de los comandos dbcc a nivel de objeto. Es posible
utilizar dbcc checktable y dbcc tablealloc para verificar la consistencia de un conjunto
de tablas particulares. Por ejemplo, si su base de datos tiene 200 tablas, adicionales a las
tablas del sistema, ejecute dbccs sobre las tablas del sistema en un día, dbccs sobre un
grupo de 50 tablas otro día, y así sucesivamente; al final de la semana habrá completado
la verificación para la totalidad de las tablas y podrá comenzar el ciclo nuevamente.

Estrategias alternas incluyen:

o Cargar la base de datos en otro servidor (usando dump database y load

database), y ejecutar los comandos dbcc en ese servidor.
o Usar el comando dbcc checkstorage (11.5 y posterior); para mayor información
vea el documento Configuración y Uso del Comando dbcc checkstorage (DocId:
10052).

El incorporar las verificaciones dbcc dentro de sus tareas regulares de generación de

copias de respaldo y mantenimiento puede asegurarle que usted tiene copias de respaldo
consistentes y exactas en todo momento.

4. Implemente Discos Espejo

Los discos espejo, a nivel de Adaptive Server Enterprise o a nivel de sistema operativo,
pueden proporcionar recuperación con disponibilidad continua en el evento de fallas de
medios de almacenamiento (discos físicos).

Los factores que usted necesita considerar y las instrucciones para implementar discos
espejo en Adaptive Server Enterprise, están detallados en el manual System
Administration Guide. Vea también el documento Aspectos Importantes sobre Sybase y
RAID (DocId: 10020).

5. Realice Mantenimiento Continuo

Como parte del programa rutinario de mantenimiento del servidor de datos, usted
debería:

o Monitorear el log de errores de Adaptive Server Enterprise. Note que los usuarios
generalmente no son notificados de errores con severidad 17 o 18, si su trabajo no
se ve interrumpido.
 Defina una rutina que busque mensajes específicos en el log de errores de
Adaptive Server Enterprise. Para información sobre el formato del log de errores
y los niveles de severidad vea el manual System Administration Guide.

Nota:
Los usuarios de Windows NT/2000 también pueden monitorear los mensajes del
servidor de datos a través del Visor de Eventos de Windows (Event Viewer).

Purgue el log de errores de manera regular a medida que éste crece, ya que
Adaptive Server Enterprise agrega mensajes cada vez que arranca. Un log de
errores sin espacio puede causar que el servidor de datos se congele. Recuerde
bajar el servidor de datos primero y realizar una copia del log de errores, antes de
purgarlo.

Un ejemplo de cómo purgar el log de errores en Unix:

% isql -Usa -Psa_passwd -SSYBASE

1> shutdown
2> go
% cp errorlog errorlog.fecha
% rm errorlog

donde fecha es la fecha actual.

o Monitoree el log de errores del sistema operativo para mantener

conciencia del estado del hardware y sistema operativo. Muchos errores de
Adaptive Server Enterprise pueden ser causados por problemas de hardware
(discos, memoria, tarjetas de red, controladoras de disco, etc.) y pueden, en
consecuencia, indicar problemas en el hardware.

o Monitoree la utilización de espacio utilizando los procedimientos

almacenados del sistema sp_helpsegment, sp_spaceused y sp_helpdb. Al
ejecutar el procedimiento sp_spaceused de manera regular, por ejemplo, usted
puede determinar si una base de datos se está quedando sin espacio para nuevos
objetos o para el log de transacciones.

De manera alterna, usted puede definir umbrales para monitorear el espacio libre por segmento.
Para más información vea el manual System Administration Guide, o el documento Uso de
Umbrales para Controlar el Espacio Libre en Adaptive Server Enterprise (DocId: 10005).

o Ejecute periódicamente el comando update statistics, ya que a medida

que una tabla cambia, las estadísticas que el optimizador de ASE utiliza para
resolver las consultas se vuelven obsoletas, y el servidor de datos puede comenzar
a seleccionar la estrategia incorrecta para resolver dichas consultas.

En versiones anteriores a la 11.9.2, las páginas de distribución mantenían las estadísticas de

distribución de los valores de las llaves de los índices; este enfoque era bastante limitado. Desde
la versión 11.9.2, no se utilizan páginas de distribución; en su lugar, se utiliza un mecanismo
basado en tablas del sistema, el cual es mucho más flexible y exacto. Haga referencia a los
siguientes documentos para más detalles:

• Estadísticas del Optimizador desde Adaptive Server Enterprise

11.9.2 (DocId: 10047)
• Estadísticas del Optimizador después de Actualizar a Adaptive
Server Enterprise 11.9.2 (DocId: 10049)

o Ejecute periódicamente el comando reorg. Desde la versión 11.9.2 se

incluyen dos nuevos esquemas adicionales de bloqueo de datos (esquemas DOL,
por la sigla en inglés de Data Only Locking), adicionales al esquema tradicional
allpages; los nuevos esquemas de bloqueo DOL son datapages y datarows. Las
tablas que usan estos esquemas de bloqueo (tablas DOL) son propensas a sufrir de
fragmenteción de datos y a medida que van cambiando es posible que se degrade
el rendimiento de las consultas. Para mayor información consulte los siguientes
documentos:

• Preguntas y Respuestas Frecuentes sobre Esquemas de Bloqueo de

Datos en Adaptive Server Enterprise (Doc Id: 10025)
• Cómo Detectar y Corregir la Fragmentación de Tablas DOL en
Adaptive Server Enterprise 11.9.2 y Posterior (DocId: 10129).

o Monitoree el comportamiento general de su servidor de datos usando el

comando sp_sysmon, el cual genera estadísticas de uso de los diferentes recursos
de ASE (kernel, discos, cachés, índices, transacciones, etc.); el documento Notas
Sobre el Procedimiento Almacenado del Sistema sp_sysmon (DocId: 10072)
contiene más detalles.

6. Evite Prácticas Riesgosas

o De ser posible, extienda tempdb fuera del dispositivo master, sobre todo
cuando se requiera espacio adicional para cierto tipo de consultas, como aquellas
que incluyan cláusulas order by, group by, etc. Desde la versión 12.5.0.3 de
ASE se incluye un mecanismo que permite crear múltiples bases de datos tempdb,
volviendo más flexible la administración del espacio temporal en el servidor de
datos; para más información ves el documento Configuración y Uso de Múltiples
Bases de Datos Temporales en ASE (DocId: 10134).

o Nunca ubique nada distinto a las bases de datos del sistema master, model
y tempdb sobre el dispositivo master. Almacenar otras bases de datos en el
dispositivo master puede hacer muy difícil la recuperación de las bases de datos
del sistema o de las bases de datos de usuario, si alguna de ellas de daña.

7. Consejos de Recuperación, o ¿Qué Hacer Cuando las Cosas Salen Mal?

 o Seleccione el método correcto de recuperación. Su elección de métodos
estará dictado por el tipo de falla que usted encuentre. Por ejemplo, la pérdida de
un dispositivo físico requerirá recuperación a partir de copias de respaldo.

Las fallas de red o hardware usualmente tienen poco impacto en el servidor, pero pueden
comprometer los datos en algunas situaciones, y la recuperación puede fallar.

o Si hay implementados discos espejo en su instalación, deshabilite los

discos espejo antes de cargar una copia de respaldo, preservando así una copia de
lo que usted tenía, por si acaso la copia de respaldo llega a estar corrupta.

o Nunca corra buildmaster en el dispositivo master original. Puede que éste

contenga información que usted necesite posteriormente. Ejecute el buildmaster
sobre un dispositivo distinto, y cuando su ambiente esté completamente
restaurado, usted podría regresar a su dispositivo master original, si es necesario.

Importante:
Desde ASE 12.5 la funcionalidad del utilitario buildmaster fue reemplazada por la del utilitario
dataserver (sqlsrvr.exe en Windows); vea el documento Recuperación de la Base de Datos
master o del Dispositivo master en Adaptive Server Enterprise 12.5 (DocId: 10104).

8. Consejos Adicionales

o Defina y documente claramente sus políticas y procedimientos de

administración.

o Prueba sus procedimientos de administración (por ejemplo, simule una

situación de emergencia en la cual requiera restaurar una base de datos de sus
backups).

o Después de una actualización de sistema operativo, verifique los permisos

sobre sus dispositivos de base de datos.

9. Documentos Adicionales

Los siguientes documentos contienen temas de Administración que pueden complementar ésta
Nota Técnica:

o Uso del Cron de Unix para Programar Copias de Respaldo Automáticas en

Adaptive Server Enterprise

o Uso del Comando AT de Windows NT para Programar Copias de

Respaldo Automáticas en Adaptive Server Enterprise

o ¿Cómo Generar un Script SQL Dinámicamente a Partir de Otro Script

SQL? (UNIX)
o Manuales de Sybase en Línea

o Documentos Técnicos de Syabase