Error en JOB

Buenas, disculpad pero no leí esto hasta hoy, los viajes y esas cosas

a muy grandes ragos. SQL necesita escribir de forma síncrona (es decir
garantizando la transaccionalidad) cada operación de escritura, ya sean
borrados, actualizaciones o inserciones. Lo que SQL hace es escribir esa
información de forma síncrona en el fichero de log de transacciones. Cuando
se hace cualquier operación se le asigna una marca llamada LSN, y se van
escribiendo en ese fichero todas las operaciones necesarias en los datos
hasta otro LSN. Luego un proceso asincrono se encarga de consolidar esta
información en el fichero de datos.

La cuestión en esto es ¿cuando puede SQL Server volver a usar ese trozo de
fichero?. Bien, si el modo de recuperacón es simple (alter database XX set
secovery simple), tan pronto como esté consolidado en el fichero de datos
(que pasa bastante rápido) SQL puede reusar ese espacio sobreescribiendolo
sin embargo si la bbdd se estropease solamente podríamos recuperar el último
backup, ya que ese trozo del log puede haber sido sobre escrito. Sin embargo
si el modo de recuperación es Bulk logged o Full ese trozo del log no se
sobreescribirá hasta que se haya hecho un backup, ese backup puede hacerse
frecuentemente y el proceso de recuperación sería recuperar el ultimo backup
completo y los backups del log uno tras otro hasta el último, pero incluso
aunque ya haya petado el sistema podrías hacer un backup de la cola del log
(si no es eso lo que se ha dañado) y recuperar todo hasta el mismo punto de
ruptura.

Dicho todo esto está claro que es "mejor" el modo de recuperación full, sin
embargo como podéis imaginar lleva más trabajo y necesita algo más de
conocimientos.

Si haces un backup log XX with truncate_only, (es decir truncar el log que
es como se llamaba el job original), y quizá luego un srink haces un backup
sin guardarlo, por lo que el resultado será el mismo que con el modo de
recuperación sencillo, pero eso si, con más esfuerzo y problemas. Este es el
motivo de mi recomendación


Miguel Egea
SQL Server MVP, Mentor
Solid Quality Learning
http://www.SolidQualityLearning.com
"Solid Quality Learning is the trusted global provider of advanced education
and solutions for the entire Microsoft database platform"



"Mauro" wrote in message
news:%237Dfwj%

a grandes rasgos con el simple mode no puedes recuperar backups del
transaction log y el log no crece tanto y con el full puedes recuperar
desde
backups de transaction logs. te repito a grandes rasgos, habria que ver
que
mantenimiento tiene tu base y para que queres poner en simple el modo de
recuperacion.

"Guillermo" wrote in message
news:

Gracias igual Maxi.

"Maxi" escribió en el mensaje
news:
> Guillermo, te pediria que leas los libros on line (BOL) todo lo que
> respecta a recuperacion y backup
>
>
> Salu2
> Maxi [MVP SQL SERVER]
>
>
> "Guillermo" escribió en el mensaje
> news:
>> Disculpen mi completa ignorancia,
>> pero que es la "Recuperación Simple", para que sirve, y como hago que

la

>> base esté en modo de recuperación simple
>>
>> "Miguel Egea" escribió en el

mensaje

>> news:
>>> La respuesta es perfecta técnicamente hablando, ese es uun motivo de
>>> fallo, sin embargo, si hace esta operación, no tiene ningún sentido
>>> tener el modo de recuperaicón en algo que no sea simple.
>>>
>>> En mi opinión si no se va a hacer copias reales del log, lo suyo es
>>> poner la base de datos en modo de recuperación simple y olvidarse de
>>> ejecutar el job..
>>>
>>> Saludos
>>> Miguel Egea
>>> "Penta" wrote in message
>>> news:
>>>> Hola.
>>>> Verifica que el modo de recuperacion de la BD no debe estar en
>>>> sencilla.
>>>>
>>>> Penta.
>>>>
>>>
>>>
>>
>>
>
>