SQL Server, archivo de log muy grande

Zuljin · 23 Noviembre 2015

Cabros, de SQL Server cacho pocazo, así que denme una mano.

Tengo una base de datos SQL Server que consume 107 GB, de los cuales 1Gb corresponde a data y 106 GB a Transaction Logs.

Evidentemente alguna cosa no está funcionando bien, porque no es normal esto. Sin embargo, no se como bajar el tamaño de los Transaction Logs.

La Base de datos tiene Recovery Model Full.

¿Algún dato?

Gracias

Harima · 23 Noviembre 2015

fercas dijo:
Para mi, sql server no es de juguete. Por que opinas así? No vale decir que sql 6 o 7 eran malos. Desde 2008 en adelante es un monstruo.
Enviado desde mi XT1058 mediante Tapatalk

Es una forma de decir, comparandolo con Oracle, pero el log nunca nos a servidor de nada (Ojo lo veo desde el punto de administración de sistemas), cuando la BD esta mal diseñada, se le suma una mala implementación te encargo el cacho, aca usabamos cluster para el sql de producción (la BD principal era de como 400 gigas) de nuestro servicio estrella conectado a un super nas por fibra (un EVA en HA), al final el tema de los backups e incrementales y toda la challa, valia wano, porque en caso de falla (nos paso como dos veces) el recuperar la bd y despues meter los incrementales y los logs y toda la challa de las buenas practicas no era util, al final lo mas sano fue crear un backup diario e incrementales por hora, cuando nos paso la ultima vez, estabamos en linea en super poco tiempo, que para el momento del incendio a nadie le importan las buenas practicas, lo unico que importa es tener el sistema en linea en el menor tiempo posible.

ahora ya quedan solo un par de clientes en el sistema antiguo, usamos el SQL de Azure que es mas limitado que el demonio, pero complementamos con elastic search

fercas · 23 Noviembre 2015

Harima dijo:
Es una forma de decir, comparandolo con Oracle, pero el log nunca nos a servidor de nada (Ojo lo veo desde el punto de administración de sistemas), cuando la BD esta mal diseñada, se le suma una mala implementación te encargo el cacho, aca usabamos cluster para el sql de producción (la BD principal era de como 400 gigas) de nuestro servicio estrella conectado a un super nas por fibra (un EVA en HA), al final el tema de los backups e incrementales y toda la challa, valia wano, porque en caso de falla (nos paso como dos veces) el recuperar la bd y despues meter los incrementales y los logs y toda la challa de las buenas practicas no era util, al final lo mas sano fue crear un backup diario e incrementales por hora, cuando nos paso la ultima vez, estabamos en linea en super poco tiempo, que para el momento del incendio a nadie le importan las buenas practicas, lo unico que importa es tener el sistema en linea en el menor tiempo posible.

ahora ya quedan solo un par de clientes en el sistema antiguo, usamos el SQL de Azure que es mas limitado que el demonio, pero complementamos con elastic search

Claro, cualquier sistema mal implementado vale guano.

En mi caso nunca tuve incendios (gracias a dios). Pero hacia prueba de disaster recovery y todo funcionaba como la seda. Usando replicación con failover automático. Una vez me tocó implementar log shipping en 2000 (2000 vale real guano en alta disponibilidad) y aún así se comportó dignamente.

Yo creó que va en como se implementa. Pasaría lo mismo si me pasan un oracle, donde no cacho nada y lo más probable que dejaría la escoba.
Saludos

Enviado desde mi XT1058 mediante Tapatalk

fercas · 23 Noviembre 2015

Zuljin, cuenta el fin de la historia! Bajo el log? Te echaste la base? Fuiste a poner tus gónadas a la mesa de tu jefe igual cuando compraste equipos 939 en vez de p4???

Enviado desde mi XT1058 mediante Tapatalk

Zuljin · 23 Noviembre 2015

Son como 100GB de transaction log. Ahí la huea todavía está haciendo el backup incremental.

Zuljin · 23 Noviembre 2015

Puta, terminó el backup incremental y no bajó en nada el tamaño de los transaction logs. Ahora estoy revisando docs, los links que me enviaron y hueas raras. Mi idea es evitar hacer algo no recomendado, y dejar todo ordenadito para evitarme siempre esta tarea.

fercas · 23 Noviembre 2015

que raro....

hace lo siguiente:

1.- hazle clic derecho a la base, luego option, anda a files y revisa el initial size del log. El log se reduce a lo maximo a ese tamaño.

2.- como te dije, puede cambiar el modelo de recuperación a simple si cumples con lo siguiente
a) tu politica de backups es hacer un backup full 1 vez al dia y nada mas que eso.
b) no importa perder la información del día si sucede un desastre. podrás recuperar solo la data hasta el ultimo backup full
como nota, si actualmente sigues haciendo solo backup full, no tiene sentido tener un modelo de recuperación "full" ya que no lo usas, con el modelo simple estaras bien, no tendrás problemas de log y funcionará todo bien.

si quieres mandame un mp con tu telefono y te llamo.
Saludos,
Fernando

Sago7 · 23 Noviembre 2015

Sharepoint, no se donde he escuchado ese nombre

De que versión estamos hablando?.

Siempre Sharepoint ha sido gloton con los logs y el tema del tamaño es parte de un plan de mantencion que se debe crear. Lo mismo ocurre con las bases de datos. Cuando se eliminan datos quedan con espacio libre y este se debe eliminar cada cierto tpo.

Ponga el modo en simple, tire el shrink al log, devuelva el modo a como estaba antes.

Zuljin · 23 Noviembre 2015

@fercas , estoy tratando de configurar esta huevada para hacer respaldos incrementales durante el día. Así que voy a mantener la opción full.

Estoy probando con una base de datos que no le importa a nadie, luego cuando el procedimiento esté probado largo con lo demás.

Así a cuero pelado estoy seteando el tamaño inicial del archivo de log y funciona. Voy a chequear con otras bases y les cuento.

fercas · 23 Noviembre 2015

Sago7 dijo:
Sharepoint, no se donde he escuchado ese nombre
De que versión estamos hablando?.

Siempre Sharepoint ha sido gloton con los logs y el tema del tamaño es parte de un plan de mantencion que se debe crear. Lo mismo ocurre con las bases de datos. Cuando se eliminan datos quedan con espacio libre y este se debe eliminar cada cierto tpo.

Ponga el modo en simple, tire el shrink al log, devuelva el modo a como estaba antes.

Con eso soluciona el problema de forma momentanea, despues de "x" tiempo lo volverá a suceder lo mismo.
Para solucionar el problema de raiz debe configurar el tamaño inicial del log, revisar los autogrows del log, generar una política de backups transaccionales y con eso soluciona el problema que el log se vaya al infinito y más allá.

Saludos,
Fer

fercas · 23 Noviembre 2015

lee esto zuljin:
http://www.sqlservercentral.com/articles/Administration/64582/
y si tienes tiempo, con este otro articulo, quedas perito!
http://www.sqlservercentral.com/stairway/73776/

Saludos,
Fer

Sago7 · 23 Noviembre 2015

fercas dijo:
Con eso soluciona el problema de forma momentanea, despues de "x" tiempo lo volverá a suceder lo mismo.
Para solucionar el problema de raiz debe configurar el tamaño inicial del log, revisar los autogrows del log, generar una política de backups transaccionales y con eso soluciona el problema que el log se vaya al infinito y más allá.

Saludos,
Fer

Por lo mismo.
Me autocito:

"Siempre Sharepoint ha sido gloton con los logs y el tema del tamaño es parte de un plan de mantencion que se debe crear".

https://technet.microsoft.com/en-us/library/cc262731(v=office.14).aspx

Zuljin · 23 Noviembre 2015

Ok, funcionó.

Puse respaldos transaccionales con la opción de que truncado lógico de logs.
Shrink de los transaction logs.
Redimensionamiento de algunos logs.
Y todo online, nunca bajé las bases de datos.

Bajé en como 300GB el espacio usado de la base de datos. Ahora resta ir controlando el consumo de espacio.

Gracias a todos por sus palabras de buenaventuranza.

fercas · 23 Noviembre 2015

Sago7 dijo:
Por lo mismo.
Me autocito:

"Siempre Sharepoint ha sido gloton con los logs y el tema del tamaño es parte de un plan de mantencion que se debe crear".

https://technet.microsoft.com/en-us/library/cc262731(v=office.14).aspx

aps sorry, no vi esa parte! ja!

Zuljin dijo:
Ok, funcionó.

Puse respaldos transaccionales con la opción de que truncado lógico de logs.
Shrink de los transaction logs.
Redimensionamiento de algunos logs.
Y todo online, nunca bajé las bases de datos.

Bajé en como 300GB el espacio usado de la base de datos. Ahora resta ir controlando el consumo de espacio.

Gracias a todos por sus palabras de buenaventuranza.

wena zuljin! ahora nos debes un asabado a todos!
Saludos!

Zuljin · 23 Noviembre 2015

fercas dijo:
aps sorry, no vi esa parte! ja!

wena zuljin! ahora nos debes un asabado a todos!
Saludos!

Pal próximo asado de Capa9 me rajo con unas longanizas de huemul.

SQL Server, archivo de log muy grande

Zuljin

Fundador

Harima

Pegao al tarro

fercas

Papá de Fercas JR

fercas

Papá de Fercas JR

Zuljin

Fundador

Zuljin

Fundador

fercas

Papá de Fercas JR

Sago7

Tibetan Mod

Zuljin

Fundador

fercas

Papá de Fercas JR

fercas

Papá de Fercas JR

Sago7

Tibetan Mod

Zuljin

Fundador

fercas

Papá de Fercas JR

Zuljin

Fundador