logs

Hola Diego:
La estructura que MS utiliza para la Bitacora de Transacciones esta
disenada para que el Servidor SQL no deba pedirle al Sistema Operativo
espacio en Disco para la Bitacora de Transacciones(Log).
Y la razon en sencilla, el proceso de inicializacion del Archivo es
Lento, y en el caso del Log TODAS las actividades del servidor de insercion,
borrado y actualizacion se "congelan" hasta el el Sistema Operativo devuelva
y el servidor de SQL inicialice los nuevos bloques. Piensa en esto durante x
segundos el servidor NO procesara ninguna nueva transaccion. Es como si cada
vez que se graba 1 Mb de Transacciones alguien desconectara por 2 par de
segundos el cable de red del servidor.
En un esquema "normal" cuando se respalda periodicamente la Bitacora de
Transacciones, mueves el inicio del registro logico, liberando espacio para
nuevas transacciones, pero SIN DEVOLVER al Sistema Operativo el espacio de
disco. Es esta manera este espacio esta disponible para las nuevas
transacciones. Despues de algun tiempo se "estabiliza" y el servidor de SQL
no solicitara mas al Sistema Operativo espacio para el Log a menos que
exista algun incremento en la operacion o "volatidad" de la Base de Datos.
Por ultimo, como indica muy bien Miguel Egea, bota cualquier esquema
sensato de Respaldo de Datos.
El DBCC SHRINKFILE y el DBCC SHRINKDATABASE, existen para cuando has
realizado alguna actividad anormal en el servidor (Procesos de Importacion
de Datos principalmente) que expanden de forma anormal el LOG.

Saludos,


Javier Loria
Costa Rica
Se aprecia la inclusion de DDL (CREATE, INSERTS, etc.)
que pueda ser copiado y pegado al Query Analizer.
La version de SQL y Service Pack tambien ayuda.

Diego Uribe escribio:

En efecto esta en un servidor de desarrollo...
Sin embargo, no me habia preocupado por la eficiencia del servidor, o
por lo menos no todavia.

Por qué este procedimiento haría más lento el Sql Server?
Mientras se ejecuta?


"Javier Loria" escribió en el mensaje
news:%

Hola Diego:
Es muy probable que tu procedimiento no tenga impacto la primera
vez que se corra y si ocurren suficientes cambios en la BD la
siguiente vez lograra su cometido.
Si quieres profundizar lee la documentacion en Linea: "Reducir el
registro de transacciones", veras que la Bitacora de Transacciones
usa un concepto con un numero de registro virtual que perfectamente
puede estar al final de archivo, de hecho si no hay politica de
respaldos de Log estara siempre ahi. Cuando haces el
SHRINKFILE no tiene ningun impacto, ya que el registro virtual esta
precisamente al final, en la siguiente ocasion cuando se han
producido cambios en la BD, se estara utilizando el inicio del
archivo del log, si lo ejecutas logras el impacto deseado.
Asumo que sabes que tu procedimiento hace de forma importante
mas lento al servidor de SQL, y lo estas haciendo unicamente para
servidores de desarrollo y no para servidores de produccion.
Saludos,


Javier Loria
Costa Rica
Se aprecia la inclusion de DDL (CREATE, INSERTS, etc.)
que pueda ser copiado y pegado al Query Analizer.
La version de SQL y Service Pack tambien ayuda.
"Diego Uribe" wrote in message
news:

El siguiente sql es un procedure para reducir los logs o eso
creo la verdad lo ejecuto y no noto mayor cambio.

El cuento es que saca de la base de datos el nombre exacto del
"LDF" y del "MDF"

Pasale como parámetro el 0 y reduce el log de todas las bases de
datos

/***********************************************************/
USE Master;
/***********************************************************/
CREATE PROCEDURE D_ShrinkDB
@dbid tinyint
AS BEGIN
Declare @db as varchar(50),
@dbfile as varchar(50);
DECLARE dbfls CURSOR FOR
Select Rtrim(sysdatabases.name), Rtrim(sysaltfiles.name)
From sysdatabases,
sysaltfiles
Where sysdatabases.dbid = sysaltfiles.dbid and
sysaltfiles.fileid = 2 and
sysdatabases.dbid >= @dbid;
OPEN dbfls;
FETCH NEXT FROM dbfls INTO @db, @dbfile;
While ( @@FETCH_STATUS = 0 ) BEGIN
Exec ('USE ' + @db + '; CHECKPOINT;');
Exec ('USE ' + @db + '; CHECKPOINT;');
Exec ('USE ' + @db + '; CHECKPOINT;');
DBCC SHRINKDATABASE (@db, 0 , TRUNCATEONLY);
BACKUP LOG @db WITH TRUNCATE_ONLY;
Exec ('USE ' + @db + '; DBCC SHRINKFILE (''' + @dbfile + ''',
EMPTYFILE);');
FETCH NEXT FROM dbfls INTO @db, @dbfile;
End;
CLOSE dbfls;
DEALLOCATE dbfls;
END;

/***********************************************************/
Exec D_ShrinkDB 0
/***********************************************************/

Recibo sugerencias si hay que modificarle algo, seria bueno que
entre todos mejoremos
este procedure

Diego


"N4" escribió en el mensaje
news:%

corri esto:

checkpoint
backup log MIO with truncate_only
DBCC SHRINKFILE(MIO_log,2000)

pero me da esto:
Servidor: mensaje 8985, nivel 16, estado 1, línea 3
No se encuentra el archivo 'MIO_log' en sysfiles.
Ejecución de DBCC completada. Si hay mensajes de error, consulte al
administrador del sistema.

Por que?