Undgå transactionlog

skift til simpel recovery mode

(så starter den forfra ved hvert checkpoint)

den står allerede i simple mode... så kan jeg vel evt. opsætte et job som regelmæssigt kører CHECKPOINT?

den checkpointer selv en gang imellem

med recovery simple burde din transaktions log aldrig fylde disken op

der kører mange jobs som arbejder med meget store datamængder - og disken bliver ofte fyldt. 'En gang imellem' betyder vel at den kører når den så småt bliver presset?

fra docs:

Automatic Checkpoints
SQL Server 2000 always generates automatic checkpoints. The interval between automatic checkpoints is based on the number of records in the log, not time. The time interval between automatic checkpoints can be highly variable. The time interval between automatic checkpoints is long if few modifications are made in the database. Automatic checkpoints occur frequently if a lot of data is modified.

The interval between automatic checkpoints is calculated from the recovery interval server configuration option. This option specifies the maximum time SQL Server should use to recover a database during a system restart. SQL Server estimates how many log records it can process in the recovery interval during a recovery operation. The interval between automatic checkpoints also depends on whether or not the database is using the simple recovery model.

If the database is using either the full or bulk-logged recovery model, an automatic checkpoint is generated whenever the number of log records reaches the number SQL Server estimates it can process during the time specified in the recovery interval option.


If the database is using the simple recovery model, an automatic checkpoint is generated whenever the number of log records reaches the lesser of these two values:
The log becomes 70 percent full.


The number of log records reaches the number SQL Server estimates it can process during the time specified in the recovery interval option.
Automatic checkpoints truncate the unused portion of the transaction log if the database is using the simple recovery model. The log is not truncated by automatic checkpoints if the database is using the full or bulk-logged recovery models. For more information, see Truncating the Transaction Log.

det er normalt ikke mange transaktioner som er slemme men snarere store
transaktioner

DELETE FROM tabel WHERE ....

som matcher 10 millioner rækker er en rigtig log spiser

...hvis bare 10mio. kunne gøre det :-s
(har læst doc'en)

problemet er at 1 SQL sætning = 1 transaktion = alle de data klumper som
ændres skal gemmes i loggen

Hvis du kan leve uden kravet om atomicitet kan du ændre 1 DELETE til f.eks.
10 DELETE med noget ekstra på din WHERE og på den måde klare dig
med 1/10 log plads.

men kan '08/08-2005 09:40:52' ikke bruges som en ok løsning?

du kan aldrig trunkere noget log for en transaktion der ikke er afsluttet

nej, det er klart... men så vidt jeg er orienteret så kører alle jobs ikke én transaction

så kunne du prøve at checkpoint sidst i hvert job

ja, ok det kan man jo også... (det er bare hurtigere at sætte et nyt job op istedet for at modificere alle eksisterende ;-)) - men det er jo nok den 'pæneste' løsning. Det undrer mig bare at man ikke helt kan disable den log

du kan jo ikke bruge transaktioner uden en log ...

nej, det er selvfølgelig rigtigt ;-) - men de tager bare uendelig meget krudt

OK ?