TodoSQL Blog de SQL Server en español

Hola como están !, hoy les voy a comentar un problema surgido dentro del esquema de mirror como solución de failover.

En las pruebas que nos encontramos realizando en diferentes escenarios de mirror ante una desastre, nos encontramos con un limite con la opción de RESUME (ALTER DATABASE Mibase SET PARTNER RESUME).

Ante el caso en que el server principal se caiga y sea imposible recuperarlo debemos cambiar los roles en forma manual con la siguiente sentencia, si es el caso en donde no existe un equipo como witness o testigo.

Hola ! les paso a detallar un inconveniente detectado al tratar de realizar un chequeo de base (DBCC CHECKDB) sobre bases de sistema (master,msdb), previo a tomar un backup de la misma.
Antes de pasar al problema propiamente dicho, les cuento que si realizábamos un BACKUP DATABASE, el mismo lo corria sin inconvenientes.

A continuación se detalla el error:

"DBCC CHECKDB" contra la base de datos "msdb" :

Msg 1823, Level 16, State 2, Line 1
A database snapshot cannot be created because it failed to start.
Msg 5123, Level 16, State 1, Line 1

Hola como están !, el error que se presenta a continuación, surge cuando quieran verificar un dispositivo de backup de SQL Server en una versión que no es la correcta o mejor dicho un backup realizado por ejemplo con SQL Server 2005 y quieren restorear o verificar en un SQL Server 2000.

Server: Msg 3205, Level 16, State 2, Line 1
Too many backup devices specified for backup or restore; only 64 are allowed.
Server: Msg 3013, Level 16, State 1, Line 1
VERIFY DATABASE is terminating abnormally.

La solución es realizarlo en la versión correrspondiende.

Hola como están !, a continuación les voy a presentar un problema que tuvimos, al tratar de restorear una base de datos de considerable volúmen en MS SQL Server 2000.

Escenario:

OS: Windows 2003 Server Standard Edition SP1
DBMS: MS SQL Server 2000 SP4
Base a Restorear (Tamaño Total): 70 GB
Memoria Ram: 1 GB
PageFile: 2 GB
Espacio Libre en disco: 150 GB

Sentencia:

RESTORE DATABASE mibase FROM device_network WITH RECOVERY

Sintomas:

A continuación les paso a detallar el inconveniente detectado de "registros con datos basura" al utilizar la herramienta "BCP", la solución aplicada y también aclaraciones importantes al momento de utilizar la herramienta citada en párrafos anteriores.

Escenario

Server Origen/Destino:

Windows Server 2003 Standart Edition SP1
MS SQL Server 2005 Standart Edition SP2

Utilidad: BCP (Bulk Copy Program), utilidad de línea de comando (shell) de SQl Server.

Tabla: TxnTable

Hola como están !, a continuación les voy a presentar dos escenarios en donde tuvimos inconvenientes en las consultas donde el motor de base de datos MS SQL Server, utiliza el esquema de paralelismo en un entorno de 2 o mas procesadores, espero les sirva:

Escenario 1

Windows NT Server 4.0 SP 6a
MS SQL 7.0 SP 3
Esquema de dos o mas procesadores

Error:

2006-05-31 12:40:19.24 kernel SQL Server Assertion: File: , line=1931
Failed Assertion = 'm_activeSdesList.Head () == NULL'.

Hola como están !, para los que usen SSRS esto es algo que les puede ser de utilidad: Report Execution Log. De allí pueden sacar la info de cantidad de veces que un reporte se ejecuto, si se corrió de cache o ‘en vuelo’, tipo de formato, de que servidor se ejecuto, tiempo en milisegundos en que tardo cada paso en la creacion del reporte, etc.
Contiene un modelo que deben crear, donde, un paquete de SSIS carga la data a consultar, la BBDD a crear se debe llamar RSExecutionLog.

Links relacionados:

Hola como va!, hoy voy a ser referencia a un problema muy común, cuando se trabaja con script de creación de login´s y permisos o bien cuando en implementaciones, por lo general de laboratorio, se borran los logins de usuarios.
El problema citado en párrafos anteriores es referido a "usuarios huérfanos en SQL Server", tanto para SQL 70, SQL 2000 como SQL 2005.
Es muy común ver el siguiente error:

Msg 916, Level 14, State 1, Line 1
The server principal "pepe" is not able to access the database "BasePrueba" under the current security context.

Hola gente como va!, hoy vamos a tratar sobre una particularidad del comportamiento de MS SQL Server 2005 relacionado al transaction log.
Intentaron llenar el transaction log de una base configurada con ‘recovery model full’ ?, a simple vista no existirían inconvenientes para hacerlo, bueno, es aquí donde a nosotros se nos planteo un problema, pues intentamos llenar el transaction log para que nos dispare una alerta cuando llegaba al umbral del 80% de factor de llenado y no podíamos superar el umbral de +- 65% del factor de llenado, el código ejecutado fue el siguiente: