copia seguridad diaria

"Raquel Santamaria" wrote in message
news:

Puede ser la propiedad RECUPERACION que dice COMPLETO(full)?

Sí, creo que en la versión española se llama así, aunque yo siempre
monto la inglesa.

Pone completo y es la base de datos que estoy usando... La base de datos
de
mi compañero
sin embargo pone SENCILLO (simple)...

Esto es muy raro... a mí no me funcionaba y yo no toqué esa propiedad
(por
lo que suponemos que
siempre estuvo COMPLETO) y a mi compañero con su base de datos le
funcionaba
y en la suya
pone SIMPLE ¿? ¿?

Pues habrá que descifrar el programa en cuestión, que es bastante
enrevesado, pero por lo que veo a simple vista tiene un "IF" que dice que si
@pFullBackup=0 entonces dé un error si está configurada como "simple" y en
caso contrario, no, así que todo depende de cómo lo estés ejecutando y con
qué parámetros.

Por cierto, ojo con un tema: Ese programa hace llamadas al procedimiento
extendido xp_cmdshell, que normalmente suele estar deshabilitado en todo
servidor en que el administrador se preocupe por la seguridad. De hecho, en
SQL Server 2005 viene deshabilitado de forma predeterminada.

"Carlos Gómez" wrote in message
news:

Ahí es donde busqué, pero no aparece dicha entrada.
[...]
Ah, antes de nada. Uso SqlServer 2005 Express

Debería dar igual la versión. Es una herramienta del sistema operativo,
no del SQL Server.

He encontrado que con
DBCC SQLPERF(LOGSPACE)
me devuelve el tamaño de los log.

Estupendo. Yo sabía que había alguna instrucción de ese tipo, pero de
memoria no sabía cuál.

Ahora bien, si yo hago copias de seguridad 'completas' (soy
tremendamente nuevo en SQLServer y no conozco bien la terminología),
has comentado que el log de transacciones aumenta, y -según he
entendido-, hay que reducir su tamaño a mano.

Sólo aumenta si la base de datos tiene establecido el modelo de
recuperación como "completo", cosa que no es aconsejable si no necesitas
hacer copias del Log. En tu caso es mejor que configures el modelo de
recuperación como "simple", y te olvides del Log.

Lo hago de la siguiente forma:
Para la base de datos Guion:
DBCC SHRINKFILE (Guion_log,1)

No, eso no vale. Eso solo reduce la parte del Log que no está en uso,
pero la parte ocupada seguiría ocupada. Dado que en tu caso se te reduce a
un tamaño muy pequeño, se deduce que ya tienes el modelo de recuperación
configurado como "simple", y por lo tanto el Log no te está creciendo.

Si realmente tuvieras que vaciar el log, el comando sería "Backup Log
Guion With TRUNCATE_ONLY", pero insisto que no tiene ninguna lógica
configurar la base de datos de modo que conserve los Logs para luego
vaciarlo sin guardar nada. Para eso es mejor configurarla en modo de
recuperación SIMPLE.

Para crear las copias de seguridad hago:
BACKUP DATABASE Guion TO GuionBackUp WITH FORMAT
y para restaurarlas hago:
RESTORE DATABASE Guion FROM GuionBackUp WITH REPLACE

Correcto, suponiendo que previamente hayas creado y configurado el
dispositivo GuionBackUp.

El pero (siempre hay un pero) es que a veces al restaurar (desde
VB.NET) da error porque necesita acceso exclusivo.

Eso es porque la propia aplicación tiene una conexión abierta. Puedes
hacerle un conexion.Dispose() desde el programa, abrir otra conexión a la
base de datos Master, y desde esa conexión (que ya no usa tu base de datos)
hacer el restore.

¿Es correcto el planteamiento? (con independencia de mejoras), o por
el contrario, estoy haciendo un disparate...

Es razonablemente correcto, salvo el tema de no haber comprobado en qué
modo de funcionamiento está configurada tu base de datos y haber amoldado en
consecuencia el modo de hacer backups. Desde luego lo que no tiene sentido
es truncar el log: O la configuras para que no guarde los logs, o si la
configuras para que sí los guarde es porque vas a hacer backup de los
mismos, no para truncarlos.

Muchas gracias por responder.

Ya encontré la dichosa entrada del monitor de rendimiento.

Siguiendo tu consejo, estudiare el tema de modo de recuperación simple
para implementarlo.

Por otro lado, cuando te pregunté si era correcto el planteamiento, me
respondiste:

Es razonablemente correcto, salvo el tema de no haber comprobado en qué
modo de funcionamiento está configurada tu base de datos y haber amoldado en
consecuencia el modo de hacer backups. Desde luego lo que no tiene sentido
es truncar el log: O la configuras para que no guarde los logs, o si la
configuras para que sí los guarde es porque vas a hacer backup de los
mismos, no para truncarlos.

2 últimas preguntas (espero)
¿Como se comprueba e modo de funcionamento de la BBDD?
Haciendo copias de seguridad en modo simple en vez de completo, ¿me
puedo olvidar del tema ese de los logs, o tengo que configurar la BBDD
para que no guarde logs?

"Carlos Gómez" wrote in message
news:

¿Como se comprueba e modo de funcionamento de la BBDD?

Desde el la herramienta administrativa, (Enterprise Manager si es un
2000, o Sql Server Management Studio si es un 2005), se pincha con el botón
derecho sobre la base de datos en el Examinador de Objetos y se selecciona
Propiedades. Se busca por las distintas propiedades hasta encontrar una que
dice "Recovery model" (creo que en la traducción al español pone
"recuperación") y tiene un "combo" con tres valores: Simple, Full y
Bulk-Logged. El que esté seleccionado es el modo actual de funcionamiento de
esa base de datos.

Haciendo copias de seguridad en modo simple en vez de completo, ¿me
puedo olvidar del tema ese de los logs,

Si. En modo Simple, olvídate de ellos.

Ok, Muchas gracias por todo.

Carlos.