Crecimiento de Base de Datos | SQL Server Performance Forums

SQL Server Performance Forum – Threads Archive

Crecimiento de Base de Datos

Buenas, yo nuevamente, tengo un problema, he puesto un scrip que reindexa los indices, actualiza estadisticas, hace backup de la base de datos y del log, luego hace el SHRINKDATABASE, todo bien pero el log no disminuye su tamaño a pesar que hago el log, y esto lo hago todos los dias automaticamente a la 8, los comandos usados son : DBCC DBREINDEX(@TableName,’ ‘,90)
exec(‘update statistics ‘ + @TableName + ‘ with fullscan’)
exec (‘BACKUP DATABASE [‘ + @BaseDatos + ‘] TO DISK = N”D:Base de DatosBackupBkProgramado’ + @BaseDatos + ”’ WITH INIT , NOUNLOAD , NAME = N”Copia de seguridad ‘ + @BaseDatos + ”’, NOSKIP , STATS = 10, NOFORMAT’) exec (‘BACKUP LOG [‘ + @BaseDatos + ‘] TO DISK = N”D:Base de DatosBackupBkProgramadoLog’ + @BaseDatos + ”’ WITH INIT , NOUNLOAD , NAME = N”Copia de seguridad Log ‘ + @BaseDatos + ”’, NOSKIP , STATS = 10, NOFORMAT’) DBCC SHRINKDATABASE (@BaseDatos,10,NOTRUNCATE) si consulto el nivel de archivo me dice que pesa 4 Gb pero casi 2 Gb estan libres y sigue en crecimiento el log basicamente y no tengo salida, me podrian ayudar, o quien tiene un codigo, ah y necesariamente nadie debe estar en los sistemas?, como puedo quitar a todos de conexion para mandar el proceso mas tarde. Gracias nuevamente

Me olvidaba, en caso anterior tuve que poner la base de datos como de una sola conexion y ejecutar el procedimiento, pero no hay manera de hacerlo sin necesidad de cambiar los permisos?, pq es muy dificil que el servidor este libre, el nivel que tenemos demanda 2 turnos los 7 dias de la semana, gracias.
Suponiendo que tienes un modelo de recuperación simple, el shrink debería realizarce como primero o segundo paso, quizás después del backup, pero nunca después del reindex ya que deshace todo el trabajo del reindex. Te sugiero, backup y, ahora como único usuario, checkpoint, shrink y reindex. Luis Martin
Moderator
SQL-Server-Performance.com One of the symptoms of an approaching nervous breakdown is the belief that one’s work is terribly important
Bertrand Russell
All postings are provided “AS IS” with no warranties for accuracy.
Un favor, la vez pasada me dijiste que cumpliera esta secuencia: 1) Reordenar indexs (DBCC DBREINDEX) o fijate en un store procedure publicada en Articles por Tom Pullen que defragmenta de acuerdo al porcentaje de fragmentación. O sea defragmenta solamente lo índices necesarios.
2) Update statistics (opcional, pero necesario una vez por semana)
3) Backup completo de la base de datos.
4) Shrinkdatabase. Ahora me dices primero el backup 1) Backup completo de la base de datos y log.
2) Checkpoint
3) Shrinkdatabase.
4) Reordenar indexs (DBCC DBREINDEX) o fijate en un store procedure publicada en Articles por Tom Pullen que defragmenta de acuerdo al porcentaje de fragmentación. O sea defragmenta solamente lo índices necesarios. Y porque el aclare si tengo la recuperacion simple, porque actualmete tengo la recuperacion completa activa, que diferencia hay?, y obligatoriamente es como unico usuario pero como haria porque la unica hora posible es a media noche y eso si no vienen como te comente, no tengo una manera de hacerlo asi hayan usuarios, y si uso el kill, como lo usaria para que mate todas las conexiones, por ultimo si no uso el chechpoint prodria reducir todo de toda manera, o no?.

Vamos por partes.
La secuencia primera no tenìa la intención de que se ejecutara todos los días. La segunda es debido a tu comentario sobre las tareas que realizas en forma secuencial. El tema del modo de recuperación es el siguiente: El modo completo se usa para aquellas bases en las cuales se realiza un backup total por día y backups del transaction log, digamos cada 2 horas, con lo cual ante una caída se puede volver al punto del último transation log. Si la política es hacer un backup total una vez por día y nada más, entonces no tiene sentido dejar el modo de recuperación completo sino sencillo. La diferencia, desde el punto de vista del tamaño del transaction log, es abismál. Con recupero completo crece muchísimo, con recupero simple crece mucho menos. Dependerá de la política de backup el tipo de recupero que se emplee. Podrás comprobar, en el caso de usar simple, que el log no crece tanto y es fácil de realizar el shrink. Es más podrías hacer el shrink del log, sin necesidad de hacer el de la base. Luis Martin
Moderator
SQL-Server-Performance.com One of the symptoms of an approaching nervous breakdown is the belief that one’s work is terribly important
Bertrand Russell
All postings are provided “AS IS” with no warranties for accuracy.
Ok, pero en cualquier caso el shrink solo podra reducir el log si es la unica conexion en la base de datos, para lo cual tendria que matar las conexiones existentes, usar el checkpoint y luego los backups, en ningun caso se reduce un log si estuviera en uso, eso seria la determinacion que obtendria.
Si está en uso, no se puede reducir. A veces varios usuarios están conectados y se puede reducir igual, pero lo seguro es como usuario único. Luis Martin
Moderator
SQL-Server-Performance.com One of the symptoms of an approaching nervous breakdown is the belief that one’s work is terribly important
Bertrand Russell
All postings are provided “AS IS” with no warranties for accuracy.
La salida que hice por el momento fue activar reducir automaticamente en la noche antes de irme y al dia siguiente ya estaba reducido, y lo desactive, no es lo recomendable pero funciona. Gracias terminare de revisar todo referente a copias de seguridad y reduccion de archivos.
]]>