Diario de SQL Server

El lector pregunta: cómo pasar datos si existe integridad referencial

Escrito por qwalgrande 28-12-2010 en General. Comentarios (0)

Tengo 2 DB en SQL Server 2005 ambas con \"Intregridad Referencial\" y necesito pasar los datos que estan en la DB1 a la DB2 pro si hago un Import and export cancela por el control de Integridad referencial. Desde ya agradezco cualquier ayuda que me puedas brindar.

 

Tienes dos opciones:
- Averiguar y ejecutar el traspaso de datos en el orden correcto en que has de pasar los datos para que la integridad referencial quede respetada (primero las tablas auxiliares, luego las maestras y luego las de detalle).
- Deshabilitar la integridad referencial (para cada tabla, alter table MiTabla nocheck constraint all), pasar los datos y volver a habilitarla (alter table MiTabla check constraint all).

El lector pregunta: Reducir, reorganizar

Escrito por qwalgrande 28-12-2010 en General. Comentarios (0)

Hola Alberto:

 

El dia de ayer ejecute en una base de datos sql 2000 la opcion de reducir archivos que se encuentra en " click derecho sobre la base de datos Todas las tareas\Reducir base de datos". Reduje el archivo Log en el boton "Archivos" ubicado en la seccion "Reducir Archivos", despues di aceptar a ambas ventanas. Tengo entendido que al darle a aceptar a la primera ventana (Todas las tareas\Reducir base de datos), reduce el archivo data.

 

Lo que me ocurrio es lo siguiente:

 

Antes, la cantidad de data era de 3893.69 MB y despues de ejecutar la reduccion la cantidad de data es de 911.21 MB.

 

No hay reporte de incidente de perdida de data, pero si hay una gran alarma por el cambio drastico de tamaño que ha habido ya que ocurrio en produccion.

 

Es posible que se haya reducido tanto? A la espera de tus comentarios.
 
Si lo que ejecutaste es un shrink, es lógico que se hayan reducido los ficheros de log y datos. Ten en cuenta que además se reordenan las páginas, con lo que la reducción no es sólo el sobrante. Si ahora haces otra reducción podrás dejar los ficheros mucho más pequeños.

 

Es importante que tengas en cuenta que este tipo de acciones no son muy recomendables en entornos de producción. Durante el tiempo que estás reduciendo, generas muchos bloqueos y además se produce fragmentación de disco. Lo ideal es configurar un tamaño (el que estimes que pueda ser ) y vigilar que no se llena. Otra cosa sería que estuvieras quedándote sin espacio, en ese caso, hay que tomar medidas drásticas como ésta. Recuerda realizar un backup completo de tu base de datos, ya que con el shrink pierdes la secuencia del log de transacciones.

 

El objetivo fue reducir solo el archivo Log por error ejecute el asistente el cual tambien redujo el de data. La reduccion de data de 3893.69 a 911.31 genero una enorme alarma, pensaron que se perdio Data. Ahora solo me queda elaborar el informe al respecto.

 

Esta tarea la hice en un tiempo en el que se aviso a los usuarios que no iba haber servicio.

 

¿Esta reordenacion de paginas es buena?,  ¿puede afectar en el rendimiento de la bd?

¿Existe otra manera de reordenar las paginas sin hacer shrink?

 

La reordenación y/o reindexación sí es buena y necesaria para un rendimiento adecuado. Hacerlo con un shrink no lo es. Afecta al rendimiento muy positivamente una vez que se completa, aunque puede ocasionar bloqueos en función de cómo lo realices. Lo suyo es que utilices una reindexación a medida, como la que aquí se sugiere (http://ola.hallengren.com/), aunque puedes usar en su lugar cualquier otra fórmula que encuentres y se adapte a tus necesidades. A las malas, usa un plan de mantenimiento.

 

 

Monitorizar esperas

Escrito por qwalgrande 13-12-2010 en General. Comentarios (1)

Una de las bases de la monitorización de servidores de bases de datos es el seguimiento de las esperas para identificar cuellos de botella, problemas generales y problemas puntuales.

 

Estos scripts son para llevar un seguimiento de las esperas. Se crea una tabla (en una base de datos) y se van grabando fotos cada 15 minutos, porque las esperas tienen sentido como gradiente, no por el valor absoluto. Así que lo primero es crear dicha tabla:

 

--Base de datos de estadsticas

USE [master]

GO

CREATE DATABASE [Estadisticas] ON PRIMARY

( NAME = N'Estadisticas_Data', FILENAME = N'C:\DATA\Estadisticas_Data.MDF' , SIZE = 1048576KB , MAXSIZE = UNLIMITED, FILEGROWTH = 10240KB )

LOG ON

( NAME = N'Estadisticas_Log', FILENAME = N'C:\LOGS\Estadisticas_Log.LDF' , SIZE = 1024KB , MAXSIZE = 2048GB , FILEGROWTH = 10240KB )

GO

 

--Tabla de estadsticas:

USE [Estadisticas]

GO

CREATE TABLE [dbo].[WaitStats](

[wait_type] [sysname] NOT NULL,

[requests] [bigint] NULL,

[wait_time] [bigint] NULL,

[signal_wait_time] [bigint] NULL,

[FEC_Hora] [datetime] NOT NULL

) ON [PRIMARY]

GO

 

El siguiente paso es crear un job, que se lance cada 15 minutos, que ejecute lo siguiente:

 

--Para el job de carga

insert WaitStats (wait_type, requests, wait_time, signal_wait_time, FEC_Hora)

select wait_type, waiting_tasks_count, wait_time_ms, signal_wait_time_ms, getdate()

from sys.dm_os_wait_stats

 

Y por último, creamos un procedimiento almacenado que nos ayude a monitorizarlo. Si lo creamos como sp_WaitStats, podemos crear un atajo en Management Studio para que, por ejemplo, pulsando Ctrl + 9 podamos lanzarlo, sin preocuparnos de en qué base de datos estemos situados en ese momento. Su código sería este:

 

--Procedimientos almacenados para consultarlas

create proc sp_WaitStats as

declare @fecha datetime, @Total_Req bigint, @Total_Time bigint, @fecha_ant datetime, @Total_Req_ant bigint, @Total_Time_ant bigint

 

select @fecha = max(FEC_Hora) from Estadisticas.dbo.WaitStats with(nolock)

select @fecha_ant= max(FEC_Hora)

from Estadisticas.dbo.WaitStats with(nolock) where FEC_Hora < @fecha

select @Total_Req = sum(requests), @Total_Time = sum(wait_time)

from Estadisticas.dbo.WaitStats with(nolock) where FEC_Hora = @fecha

select @Total_Req_ant = sum(requests), @Total_Time_ant = sum(wait_time)

from Estadisticas.dbo.WaitStats with(nolock) where FEC_Hora = @fecha_ant

select @Total_Req_ant = isnull(@Total_Req_ant, 0), @Total_Time_ant = isnull(@Total_Time_ant, 0)

--Media General

select

wait_type,

cast(100.0*requests/ @Total_Req as numeric(19,2)) as [% Req],

cast(100.0*wait_time/ @Total_Time as numeric(19,2)) as [% Time],

cast(case when requests = 0 then 0 else 1.0*wait_time/requests end as numeric(19,2))as Avg_ms

from Estadisticas.dbo.WaitStats with(nolock)

where FEC_Hora = @fecha

order by [% Time] desc

--Entre dos momentos (los dos ltimos)

select

M2.wait_type,

cast(100.0*(M2.requests - isnull(M1.requests, 0))/ (@Total_Req - @Total_Req_ant) as numeric(19,2)) as [% Req],

cast(100.0*(M2.wait_time - isnull(M1.wait_time, 0))/ (@Total_Time - @Total_Time_ant) as numeric(19,2)) as [% Time],

cast(case when (M2.requests - isnull(M1.requests, 0)) <= 0 then 0 else 1.0*(M2.wait_time - isnull(M1.wait_time, 0))/(M2.requests - isnull(M1.requests, 0)) end as numeric(19,2))as Avg_ms

from

 (select wait_type, requests, wait_time from Estadisticas.dbo.WaitStats with(nolock) where FEC_Hora = @fecha) M2 left join

(select wait_type, requests, wait_time from Estadisticas.dbo.WaitStats with(nolock) where FEC_Hora = @fecha_ant) M1 on M2.wait_type = M1.wait_type

order by [% Time] desc

 

return 0

 

Y ya lo tenemos, cuando ejecutemos sp_WaitStats, obtendremos dos recordset, el primero con las esperas más significativas en general y el segundo con las esperas de los últimos 15 minutos. Hasta que no tengas 2 lecturas, no funcionará adecuadamente.

 

Lo que queda es saber interpretar estos resultados.

 

Para SQL Server 2005 (aunque aplicable al versiones siguientes): http://download.microsoft.com/download/4/7/a/47a548b9-249e-484c-abd7-29f31282b04d/Performance_Tuning_Waits_Queues.doc

Para SQL Server 2008 R2 (Books Online): http://msdn.microsoft.com/es-es/library/ms179984(v=SQL.105).aspx

Un conjunto de links para mayor profundidad, del blog del MVP Brent Ozar: http://www.brentozar.com/sql/sql-server-performance-tuning/wait-stats/

 

Como dice Brent, demasiada información. El whitepaper de 2005 es más que suficiente para la gran mayoría de las situaciones. Y si encuentras dudas de interpretación, bueno, aquí seguiremos.

El lector pregunta: Un restore que tarda mucho y no termina

Escrito por qwalgrande 02-12-2010 en General. Comentarios (0)

Pregunta: Mi situación actual es la siguiente, tengo una bd en sql2000personal y tengo un backup y necesito restaurarla en mi equipo que tiene SQL2008R2, pero resulta que cuando le doy restaurar se queda colgado no avanza el contador de progreso y se queda infinito...
Veo que lo que hace es generar el log gigantisimo y no se que esta haciendo.

 

Respuesta: En cuanto a lo que me planteas, es normal que tarde bastante, y más si la base de datos es medianamente grande. Pero si haces el restore desde una consulta, verás que va indicándote que debe realizar migraciones de versión tras versión y son muchísimas versiones. Haz eso, lanza el restore desde Management Studio, irás viendo cómo progresan esas migraciones.

 

Entiendo que has pasado el Upgrade Advisor a la base de datos para asegurarte de que es posible la migración.

 

Pregunta: Las bases de datos que tienen estado Restaurando son aquellas que no concluyeron el proceso de restauración y deje que lo realizara por casi 1 hora.
La BD de instancia SQLEXPRESS llego a 90% y se quedo sin hacer nada.

El tamaño que genera de log es gigantismo y aun hay espacio en disco. Pero nada…

 

(se adjunta un backup de la base de datos)

 

Respuesta:El problema está en que la base de datos de la que se hizo backup tenía un log enorme. Ejecuta lo siguiente (reemplaza la ruta del backup):

 

restore filelistonly from disk = N'[RutaDelBackup]\CopiaDeSeguridad.BAK'

 

Verás que el log ocupa 32 Gb. Con ese tamaño es más que normal que se tarde muchísimo tiempo en hacer el redo y levantar la base de datos.

 

Te recomiendo que revises la base de datos original y verifiques que ese tamaño del log es el esperado (para lo que ocupan los datos, no lo es). Así que lo que yo haría sería truncar el log y hacer otro backup que ya sí podrás restaurar en un tiempo razonable.