none
Registro enorme, no lo puedo reducir RRS feed

  • Pregunta

  • buenos días,

    tenemos un SQL 2005 con una base de datos bastante grande, de unos 600 GB. Los archivos de datos están más o menos contenidos, sin embargo el log es enorme, unos 180 Gb de archivo.

    Hacemos copias de seguridad todos los días, y están saliendo correctas. Sin embargo, nada más terminar la copia me voy a ver si puedo reducir el fichero de log y me dice que está ocupado al 97 %, nada más terminar la copia de seguridad.

    ¿Cómo puede ser? ¿Qué hago mal?

    Muchas gracias.

    un saludo.

    martes, 16 de junio de 2015 8:51

Respuestas

  • Ok primero hagamos unas pruebas,

    Ya sacaste un full backup y un transactional log backup (con truncate)

    Y el log me dices que no reduce con un full recovery model correcto?

    El initial size mencionas que esta en 181560 mb pero que no lo puedes cambiar?

    ejecuta 

    dbcc sqlperf(logspace) y pon los resultados.

    también compartenos el resultado de

    SELECT name, log_reuse_wait_desc FROM sys.DATABASES


    miércoles, 17 de junio de 2015 14:42
  • Antes de tomar medidas mas drásticas vamos a ver que tienes ejecutando

    SELECT 
        DB_NAME(dbid) as DBName, 
        a.loginame as LoginName,
    	s.session_id
    FROM
        sys.sysprocesses a inner join
    	sys.dm_exec_sessions s
    	on a.dbid = s.database_id
    WHERE 
        dbid = 0

    En el dbid pon el id de tu base sino lo sabes lo puedes buscar por medio del sys.databases

    miércoles, 17 de junio de 2015 15:16

Todas las respuestas

  • Hola,

    ¿Haces backup del log de transacciones o backup de la base de datos?

    Para que una BBDD en modo FULL o BulkLogged te permita reducir el log tienes que hacer un backup del log de transacciones.

    También podría ocurrirte símplemente que las transacciones que tienes "en curso" ocupen ese espacio realmente y por eso no lo puedas reducir, pero probablemente sea el primer caso.

    Espero que te sirva.

    Un saludo.

    Diego Fernández

    martes, 16 de junio de 2015 10:34
  • ave_int_hotmail,

    como estas? que recovery model tenes configurado? en el caso de que este en simple... primero vas a tener que ver cuanto esta siendo usado de ese archivos.... en la base boton derecho luego task despues shrink y files.... ahi vas a ver cuanto de lo asignado tenes usado..... en el caso que este vacio podes chequear el valor configurado en los files (boton derecho en la base deseada properties.... luego files... y ahi vas a ver que es lo que tiene asignado....) y modificar el archivo para que ese espacio no se tome maas... sino podes ejecutar lo siguiente:

    use base deseada

    go

    dbcc shrinkfile(archivo de log de la base,truncateonly) -> aca vas a borrar todas las vlf actuales


    dbcc shrinkfile(archivo de log de la base,0) -> vas a limpiar el archivo de log dejando el valor default asignado en el archivo de log... (en este caso puse 0 pero en realidad vas a comprimir hasta lo que indicaste que tome el archivo de log).

    Espero te sirva!!

    saludos!

    martes, 16 de junio de 2015 13:13
  • Saludos

    De lo que menciona Diego hablo aqui, http://sqlservertoolbox.blogspot.com/2015/01/liberar-espacio-del-transactional-log.html

    Recuerda que esto no afecta el tamaño del log si este ya crecio y tiene un tamaño inicial mayor que el del shirtk, asi que ve a las opciones de la base de datos y revisa cual es el tamaño inicial de la ldf.  

    martes, 16 de junio de 2015 19:32
  • Hola a todos,

    la base de datos está en modo full, esta mañana hice una copia del log y de hecho voy a tasks, shrink, files, elijo el log y me da lo siguiente:

    Currently allocated space:   181559,81 MB

    Available free Space:  173446,67 MB (95%)

    pero le doy y no me reduce nada.

    he intentado con los dbcc shrinkfile pero tampoco, me muestra esta información:

    DBLd FIELD CurrentSize MinimumSize USedPAges EstimatedPages

    10 2 23239656 719985 23239656 719984

    Voy a las propiedades de la base de datos y me dice que el fichero de log tiene initial size 181560 MB. Intento cambiar ese valor, pero cuando vuelvo a abrir no ha cambiado en absoluto.

    ¿Es esto correcto? En lñas propiedades de la base de datos me dice que la última copia del registro es de hoy  y la copia me aparece como correcta.

    Mil gracias,

    saludos.




    miércoles, 17 de junio de 2015 14:35
  • Ok primero hagamos unas pruebas,

    Ya sacaste un full backup y un transactional log backup (con truncate)

    Y el log me dices que no reduce con un full recovery model correcto?

    El initial size mencionas que esta en 181560 mb pero que no lo puedes cambiar?

    ejecuta 

    dbcc sqlperf(logspace) y pon los resultados.

    también compartenos el resultado de

    SELECT name, log_reuse_wait_desc FROM sys.DATABASES


    miércoles, 17 de junio de 2015 14:42
  • Hola Enrique,

    gracias por tu respuesta.

    Como dices tengo un full backup de ayer y un log backup de hoy, el initial size está en 181560 MB pero no se puede cambiar.

    La primera consulta da:

    databasename Log size (MB) LOg space used (%)  Status

    master 1,492188 53,66492 0
    tempdb 13,30469 66,23238 0
    model 6,117188 28,9272 0
    msdb 1,992188 52,94118 0
    ReportServer 148,8047 7,627841 0
    ReportServerTempDB 2001,742 1,187808 0
    PR2012.05.08 40963,18 0,6096474 0
    ICEPCiosa 0,484375 45,66532 0
    INVENTARIO_TYS 0,9921875 50,98425 0
    NAVISION 181559,8 5,197091 0
    PTL_CIONE 61,92969 23,94191 0
    NAVISION_HISTORICO 5518,93 0,417526 0

    La segunda consulta me da este resultado:

    master NOTHING
    tempdb ACTIVE_TRANSACTION
    model NOTHING
    msdb NOTHING
    ReportServer NOTHING
    ReportServerTempDB NOTHING
    PR2012.05.08 NOTHING
    ICEPCiosa NOTHING
    INVENTARIO_TYS NOTHING
    NAVISION LOG_BACKUP
    PTL_CIONE NOTHING
    NAVISION_HISTORICO NOTHING

    Lo de log_backup es como si se hubiera quedado en la copia, pero el backup exec me dice que ya ha acabado.¿?¿?¿

    Muchas gracias.

    saludos.




    miércoles, 17 de junio de 2015 14:53
  • Antes de tomar medidas mas drásticas vamos a ver que tienes ejecutando

    SELECT 
        DB_NAME(dbid) as DBName, 
        a.loginame as LoginName,
    	s.session_id
    FROM
        sys.sysprocesses a inner join
    	sys.dm_exec_sessions s
    	on a.dbid = s.database_id
    WHERE 
        dbid = 0

    En el dbid pon el id de tu base sino lo sabes lo puedes buscar por medio del sys.databases

    miércoles, 17 de junio de 2015 15:16
  • Hola Enrique

    No parece que exista la columna database_id en la vista sys.dm_exec_sessions, obtengo lo siguiente:

    Msg 207, Level 16, State 1, Line 9

    Invalid column name 'database_id'.

    No estoy muy ducho en SQL, y no sé como buscar en que vista o tabla está ese campo, necesito que me lo digas, por favor.

    Muchas gracias.

    saludos.


    jueves, 18 de junio de 2015 6:38
  • Hola de nuevo,

    acabo de lanzar de nuevo el shrink file y ahora sí que lo ha hecho.

    No entiendo por qué ahora sí y antes no.

    Muchas gracias por todo.

    Un saludo.

    jueves, 18 de junio de 2015 9:45
  • Parece que teniasn una transaccion ejecutando y no habia temiado que tenia ocupado el log y no te dejaba realizar la transacción.  
    • Editado Enrique AA sábado, 20 de junio de 2015 0:18
    jueves, 18 de junio de 2015 14:59
  • Hola

    Creo hay información en este enlace que te puede ser muy útil acerca de los logs

    Issues with SQL Server backup log with no_log or truncate_only
    http://www.mssqltips.com/sqlservertip/1464/issues-with-sql-server-backup-log-with-nolog-or-truncateonly/

    Ahora en términos prácticos te se decir que en algunas ocasiones los log no dejan reducir hasta que ejecutas varias veces la reducción, esto depende de muchos factores pero en términos prácticos probablemente busques una solución, el siguiente artículo te habla de un procedimiento para llevar a cabo la reducción del log te lo recomiendo es muy interesante.

    How to shrink the transaction log file in SQL Server
    http://www.mssqltips.com/sqlservertip/2097/how-to-shrink-the-transaction-log-file-in-sql-server/

    De hecho es la continuación del primer artículo

    No pierdes nada con revisarlos.

    Espero que la información te sirva :)


    Jaime B. Garcia de Alba

    viernes, 19 de junio de 2015 23:51