Registro transacciones en SQL 2005
Agustí Pons
Tengo una bbdd con 35 Gb y cada noche como tarea de mantenimiento ejecuto
una copia de la bbdd
una copia del registro transacciones
y despues regenero los indices
debido a este ultimo punto me genera una registro de trasnaccines de 20 Gb.
la pregunta es: es normal teniendo en cuenta que mucho mucho hay 15/20
usuarios?, despues de este ultimo punto aconsejarias realizar de nuevo una
backup del registro de transacciones? lo digo para "vaciarlo"
Muchas Gracias por adelantado!
Carlos Sacristan
transacciones, pero 20Gb en tu caso me parece excesivo.
�Has comprobado el porcentaje de uso de ese archivo? Probablemente sea muy
bajo, pero por alguna acci�n anterior tuvo que alcanzar ese tama�o y luego
no lo has llegado a reducir...
--
--
--
Un saludo
-------------------------------
www.navento.com
Servicios de Localizaci�n GPS
http://blogs.solidq.com/ES/ElRinconDelDBA/default.aspx
"Agust� Pons" <Agus...@discussions.microsoft.com> escribi� en el mensaje
news:0735E95E-BB47-4AED...@microsoft.com...
Agustí Pons
pero despues a la noche vuelve a explotar, si cada noche reindexo los
indices, me cuesta imaginar que la bbdd se fragmente tanto en un solo dia de
trabajo.....
Muchas gracias Carlos
"Carlos Sacristan" wrote:
> La tarea de reconstrucción de índices puede cargar bastante el log de
> transacciones, pero 20Gb en tu caso me parece excesivo.
>
> ¿Has comprobado el porcentaje de uso de ese archivo? Probablemente sea muy
> bajo, pero por alguna acción anterior tuvo que alcanzar ese tamaño y luego
> no lo has llegado a reducir...
>
> --
> --
> --
> Un saludo
> -------------------------------
> www.navento.com
> Servicios de Localización GPS
>
> http://blogs.solidq.com/ES/ElRinconDelDBA/default.aspx
>
> "Agustí Pons" <Agus...@discussions.microsoft.com> escribió en el mensaje
CEMorales
"Agust� Pons" <Agus...@discussions.microsoft.com> escribi� en el mensaje
news:0735E95E-BB47-4AED...@microsoft.com...
Agustí Pons
Hola CEMorales
esa es una buena pregunta, pero si no los regenero diariamente, temo que se
genero un log enorme que me llene el disco, por eso lo hago diaramente
"CEMorales" wrote:
> ¿y por qué te es necesario regenerar los índices con una frecuencia diaria?
>
> "Agustí Pons" <Agus...@discussions.microsoft.com> escribió en el mensaje
Emilio Boucau
He leido tus mensajes anteriores a este junto con sus respuestas y por lo
que decis, saco en limpio lo siguiente (decime si me equivoco) con mis
comentarios:
Todos los dias haces una copia de la base de datos: entiendo que haces un
Full Backup, a mi criterio es una politica riesgosa de respaldo
Todos los dias haces una copia del log: no es necesario si haces un Full
Backup (de hecho, no te sera util ya que no lo podras utilizar sobre esa
bbdd) y tener esa base de datos en modo full de recuperacion no te aporta
nada y en cambio te da trabajo con el log. Pasala a simple y descontiua el
backup del log.
Todos los dias regeneras los indices: coicido con los posts anteriores, no
creo que tu base tenga tanta transaccionalidad dispar para que de un dia a
otro la fragmentacion te juegue en contra, te recomiendo hagas eso solo los
domingos (por decir un dia).
Si queres, contanos como es la actividad de esa base y vemos una mejor
estrategia de restore.
Saludos !
---
Emilio Boucau
Buenos Aires - Argentina
"Agustí Pons" <Agus...@discussions.microsoft.com> wrote in message
news:0735E95E-BB47-4AED...@microsoft.com...
Agustí Pons
muchas gracias por la respuesta.
cada dia ejecuto un backup completo tanto de la BBDD como del registro de
transacciones.
El problema es que no puedo realizar una reindexacion porque me genera un
log de transacciones tan grande que me llena el disco.
Mi bbddd son 60 Gb y tengo un espacio de 105 Gb libre, pues se llena....
Entiendo que puedo realizar el backup solo de la BBDD, pero el log de
transacciones es minusculo (500 Mb), por tanto hablando de esas cantidad tb
lo copio, el problema es que no puedo optimizar en ningun momento los indices
de la bbdd.
SI mal no recuerdo, el uso del logo de transacciones se debe al tipo de
bbdd, si e ssimple creo que los cambios se realizan no en el log de
transacciones sino directamente en la bbdd, he pensado esa solucion por lo
menos para conseguir reindexar...
Mcuhas gracias de nuevo...
Carlos Sacristan
SQL Server puede garantizar la perdurabilidad de las operaciones que se
realizan en la base de datos. Eso no cambia, sea cual sea el modo de
recuperación que tengas establecido. No voy a ser yo el que lo explique
mejor que viene en los BOL, así que te remito al tema "Introducción al
modelo de recuperación".
No comentas cómo estás reindexando, si estás usando reconstruyendo (rebuild)
o reorganizando (reorganize). En el modelo de recuperación SIMPLE y
BULK-LOGGED, reconstruir se registra mínimamente, con lo que el tamaño del
log no debería ser tan grande.
En cualquier caso, hay opciones que permiten ahorrar espacio. Por ejemplo,
deshabilitar los índices no agrupados (echa un vistazo al tema "Reorganizar
y volver a generar índices " en los BOL), o usar la opción SORT_IN_TEMPDB =
ON para usar esta base de datos en el proceso.
De todos modos, yo iría poco a poco. Es decir, no sé si ese proceso lo estás
haciendo por medio de un plan de mantenimiento (en el que no puedes
especificar qué indices quieres desfragmentar), pero si es así, te
recomiendo que construyas las instrucciones pertinentes para aquellos
índices que efectivamente estén en peores condiciones y ve observando cómo
va creciendo el log y/o el(los) archivo(s) de datos.
Por último, échate una ojeada al tema "Espacio en disco del registro de
transacciones para operaciones de índice" en los BOL.
Sin embargo, personalmente me suena extraño que ese proceso suponga 40Gb...
--
-----------------------------
"Caminar sobre el agua y desarrollar software a partir de unas
especificaciones es fácil, si ambas están congeladas."
Edward V. Berard, ingeniero informático
http://blogs.solidq.com/es/elrincondeldba
"Agustí Pons" <Agus...@discussions.microsoft.com> wrote in message
news:CA48D44D-1F5B-434C...@microsoft.com...
Emilio Boucau
ayudara en el mantenimiento de los indices y las estadisticas, son muy
sencillos y no deberian darte problemas para nada, probalos asi como estan.
En tu lugar, yo haria esto:
Dejaria de hacer backup de log (haces un full backup diario con lo cual el
log no te sirve de nada)
Pondria la bbdd en modo simple
Utilizaria el SQL Agent para que corran estos SPs una vez por semana
dejandole inicialmente el umbral de fragmentacion por defecto
Saludos !!
================== INICIO DEL SCRIPT ==================
-------------------------------------------------------------------------------------------------------
-- MANTENIMIENTO DE INDICES
-------------------------------------------------------------------------------------------------------
IF OBJECT_ID ( 'dbo.spu_reindexar', 'P' ) IS NOT NULL DROP PROCEDURE
dbo.spu_reindexar
GO
CREATE PROCEDURE dbo.spu_reindexar( @Nivel float = 30.0 )
AS
BEGIN
SET NOCOUNT ON
DECLARE @ObjectID int
DECLARE @IndexID int
DECLARE @PartitionCount bigint
DECLARE @SchemaName nvarchar(130)
DECLARE @ObjectName nvarchar(130)
DECLARE @IndexName nvarchar(130)
DECLARE @PartitionNum bigint
DECLARE @Partitions bigint
DECLARE @Frag float
DECLARE @Command nvarchar(4000)
-- Seleccionar los indices y convertir sus IDs en nombres ...
SELECT OBJECT_ID AS 'ObjectID',
INDEX_ID AS 'IndexID',
PARTITION_NUMBER AS 'PartitionNum',
AVG_FRAGMENTATION_IN_PERCENT AS 'Frag'
INTO #indices
FROM sys.dm_db_index_physical_stats( DB_ID(), NULL, NULL , NULL, 'LIMITED' )
WHERE AVG_FRAGMENTATION_IN_PERCENT > 10.0
AND INDEX_ID > 0
-- Declarar el cursor ...
DECLARE PARTITIONS CURSOR FOR SELECT * FROM #indices
-- Abrir el cursor ...
OPEN PARTITIONS
-- Ciclar las particiones ...
WHILE ( 1 = 1 )
BEGIN
FETCH NEXT
FROM PARTITIONS
INTO @ObjectID, @IndexID, @PartitionNum, @Frag
IF @@FETCH_STATUS < 0 BREAK
SELECT @ObjectName = QUOTENAME( O.NAME ), @SchemaName =
QUOTENAME( S.NAME )
FROM sys.objects AS O
INNER JOIN sys.schemas AS S ON S.SCHEMA_ID = O.SCHEMA_ID
WHERE O.OBJECT_ID = @objectid
SELECT @IndexName = QUOTENAME( name )
FROM sys.indexes
WHERE OBJECT_ID = @ObjectID AND INDEX_ID = @IndexID
SELECT @PartitionCount = Count(*)
FROM sys.partitions
WHERE OBJECT_ID = @ObjectID AND INDEX_ID = @IndexID
-- @Nivel es el valor recibido como parametro o un valor
arbitrario para decidir entre reorganizar
-- y regenerar el indice. Se puede cambiar por el que se desee
...
IF @Frag < @Nivel
SET @Command = N'ALTER INDEX ' + @IndexName + N' ON ' +
@SchemaName + N'.' + @ObjectName + N' REORGANIZE'
IF @Frag >= @Nivel
SET @Command = N'ALTER INDEX ' + @IndexName + N' ON ' +
@SchemaName + N'.' + @ObjectName + N' REBUILD WITH( SORT_IN_TEMPDB = ON,
STATISTICS_NORECOMPUTE = ON, ONLINE = ON )'
EXEC ( @Command )
PRINT N'Se ejecuto: ' + @command
END
-- Cerrar el cursor y liberar recursos ...
CLOSE PARTITIONS
DEALLOCATE PARTITIONS
-- Eliminar la tabla temporal ...
DROP TABLE #indices
END
GO
-------------------------------------------------------------------------------------------------------
-- MANTENIMIENTO DE ESTADISTICAS
-------------------------------------------------------------------------------------------------------
IF OBJECT_ID ( 'dbo.spu_estadisticas', 'P' ) IS NOT NULL DROP PROCEDURE
dbo.spu_estadisticas
GO
CREATE PROCEDURE dbo.spu_estadisticas
AS EXEC sp_updatestats
GO
-------------------------------------------------------------------------------------------------------
-- PRUEBAS DE LOS STORED PROCEDURES ...
-------------------------------------------------------------------------------------------------------
/*
-- Reindexar los indices dando un umbral del 55.0 para el REORGANIZE /
REBUILD
EXEC dbo.spu_reindexar 55.0
-- Actualizar las estadisticas de las tablas que sean necesarias.
EXEC dbo.spu_estadisticas
*/
================== FIN DEL SCRIPT ==================
"Carlos Sacristan" <nom...@nomail.com> wrote in message
news:%238Yi5vD...@TK2MSFTNGP02.phx.gbl...