Cancellazione Log delle Transazioni

[Emanuel Provesi]

È possibile impostare un qualche automatismo che mi cancelli il log delle
transazioni ?

Mi succede infatti che a causa di inserimenti di molti record al giorno
circa 14.000.000 (14 Milioni), il file .ldf cresca mostruosamente, fino a
saturarmi, ogni pochi giorni, lo spazio del disco.

Come devo comportarmi ?

Grazie in anticipo

[Marcello]

Post by Emanuel Provesi
È possibile impostare un qualche automatismo che mi cancelli il log delle
transazioni ?
Mi succede infatti che a causa di inserimenti di molti record al giorno
circa 14.000.000 (14 Milioni), il file .ldf cresca mostruosamente, fino a
saturarmi, ogni pochi giorni, lo spazio del disco.
Come devo comportarmi ?

Ciao,

se non hai necessità di mantenere un recovery model del log impostato su
full, puoi impostarlo simple, in questo modo il log viene mantenuto
contenuto.
In questo ng trovi svariati post sull'argomento.

Post by Emanuel Provesi
Grazie in anticipo

marc.

[Emanuel Provesi]

Post by Marcello
se non hai necessità di mantenere un recovery model del log impostato su
full, puoi impostarlo simple, in questo modo il log viene mantenuto
contenuto.
In questo ng trovi svariati post sull'argomento.

Il recovery model è già impostato su "simple". Ma non basta, attualmente, a
mano, per permettere al sistema di continuare a lavorare, devo intervenire
scollegando il db, cancellando il file .ldf e riagganciando il db me lo
ricrea vuoto. Oltre a non essere possibile che io continui ad intervenire
manualmente, non sono assolutamente convinto che la procedura sia sicura.
Nel log di SQL Server trovo l'indicazione che il file delle transazioni del
mio DB è full, mi consiglia di eseguirne un backup, ma poi come posso
ridurlo, pur perdendo la possibilità di rispristino, senza la procedura
becera che attualmente applico io ?

Grazie di nuovo

[Marcello]

Post by Emanuel Provesi
Il recovery model è già impostato su "simple". Ma non basta, attualmente, a
mano, per permettere al sistema di continuare a lavorare, devo intervenire
scollegando il db, cancellando il file .ldf e riagganciando il db me lo
ricrea vuoto. Oltre a non essere possibile che io continui ad intervenire
manualmente, non sono assolutamente convinto che la procedura sia sicura.
Nel log di SQL Server trovo l'indicazione che il file delle transazioni del
mio DB è full, mi consiglia di eseguirne un backup, ma poi come posso
ridurlo, pur perdendo la possibilità di rispristino, senza la procedura
becera che attualmente applico io ?

Ma l'importazione di queti 14 milio di record avviene in un singolo
batch? Non riesci a spezzare l'operazione gruppi non troppo corposi?

Post by Emanuel Provesi
Grazie di nuovo

marc.

[Andrea Montanari]

salve,

Post by Emanuel Provesi

Post by Marcello
se non hai necessità di mantenere un recovery model del log
impostato su full, puoi impostarlo simple, in questo modo il log
viene mantenuto contenuto.
In questo ng trovi svariati post sull'argomento.

Il recovery model è già impostato su "simple". Ma non basta,
attualmente, a mano, per permettere al sistema di continuare a
lavorare, devo intervenire scollegando il db, cancellando il file
.ldf e riagganciando il db me lo ricrea vuoto. Oltre a non essere
possibile che io continui ad intervenire manualmente, non sono
assolutamente convinto che la procedura sia sicura. Nel log di SQL
Server trovo l'indicazione che il file delle transazioni del mio DB è
full, mi consiglia di eseguirne un backup, ma poi come posso ridurlo,
pur perdendo la possibilità di rispristino, senza la procedura becera
che attualmente applico io ?

se utilizzi il simple recovery model, il file di log comunque tende a
crescere se hai delle transazioni molto corpose come numero righe
interessate dalla singole transazioni stesse... poi, al momento del commit
delle stesse, e successivamente ai checkpoint (che puoi anche fisicamente
effettuare manualmente sul database stesso), lo spazio del file di log sara'
nuovamente disponibile in maniera circolare per il riutilizzo... ma se la
transazione minima che effettui e' monumentale, questa puo' richiedere molto
spazio di log... e questo non cambia a prescindere dalle impostazioni di
recovery... il modello simple solo garantisce la possibilita' di riutilizzo
in questo senso ma solo quando le transazioni saranno committate (o delle
quali effettui il rollback).. se invece utilizzi il modello di recupero
completo, il log non viene mai svuotato e riutilizzato se non quando tu,
periodicamente, provvedi ad effettuare il backup del log stesso.. cosa che
generalemente e' appunto un'attivita' da pianificare secondo le esigenze
OLTP della base dati... potrebbe anche essere richiesto un troncamento del
log giornaliero al fine di non ottenere un file fisico "esagerato".. e
chiaramente il tuo particolare metodo non e' dei piu' ortodossi.. e
sicuramente non e' consigliabile...
dici che lo vuoi ridurre... ma ridurlo sotto la sua soglia minima di
utilizzo a regime non ha neanche molto senso, perche' comunque questo
continuera' almeno a raggiungere tale minima dimensione... vedi ad esempio
http://www.karaszi.com/sqlserver/info_dont_shrink.asp , un ottimo articolo
dell'MVP SQL Server Tibor Karaszi dove molto chiaramente sono evidenziate le
motivazioni per le quali non ha senso ridurre un log sotto la sua soglia
minima di utilizzo...
in definitiva, non devi ntervenire manualmente come ora stai effettuano, ma
devi monitorare la crescita ed intervenire, dapprima manualmente,
effettuando un apposito troncamento del log tramite backup... una volta
evidenziato il flusso (solitamente abbastanza ciclico) a te interessante,
puoi anche procedere con appositi processi di manutenzione automatizzata,
chiaramente puoi anche definirti degli alert specifici informativi che
richiamino la tua attenzione.. un ottimo articoli di Gregory Larsen in
questo senso, proprio per monitarare l'utilizzo disco, e' consultabile
(purtroppo solo per gli abbonati) presso
http://www.windowsitpro.com/Article/ArticleID/26874/26874.html..
una volta definito l'apposito piano "automatizzato" puoi cosi' concentrati
su altre attivita', senza chiaramente dimenticare di passare in rassegna e
verificare che lo stesso sia comunque sufficiente alle necessita'
operative...
saluti

[Andrea Montanari]

....
se invece utilizzi il modello di recovery semplice, non ti e' necessario
effettuare il troncamento del log tramite backup log... questo e' chiaro..
cio' non toglie che per ridurre l'impatto di richiesta fisica di spazio,
come gia' riportato da Marcello, puoi solo provvedere, in ogni caso e tipo
di modello di recupero, a frazionare la tua transazione/i in transazioni
meno corpose... cio' fara' si che, nel caso di modello di recupero semplice,
piu' facilmente lo spazio reso disponibile al termine di ogni batch possa
essere ciclicamente riutilizzato da altre transazioni... ripeto.. cio' non
toglie che le dimensioni fisiche del file non incrementino.. ma al fine di
valutare la dimensione mimima puoi provare a ridurre quanto serve il numero
di righe processate per ogni singolo batch.. potresti avere necessita' di
portarlo a poche righe come anche mantenerlo abbastanza corposo.. il
compromesso devi valutarlo personalmente..
saluti

[Paolo Fiore]

Post by Emanuel Provesi
Il recovery model è già impostato su "simple".
...
Nel log di SQL Server trovo l'indicazione che il file delle transazioni del
mio DB è full,

questo comunque non dipende dal "recovery model", ma dalla dimensione
massima impostata. ;)

Io "spezzerei" la transazione unica in tante più piccole

tu dici "Mi succede infatti che a causa di inserimenti di molti record al
giorno";
ok, ma è necessario farlo con un'unica INSERT (xché è li il tuo problema)?
ciao
Nota: Quel "al giorno" mi turba l'analisi però...

[Emanuel Provesi]

Post by Paolo Fiore
questo comunque non dipende dal "recovery model", ma dalla dimensione
massima impostata. ;)

Ma se io imposto una dimensione massima, lui poi (il Log delle Transazioni)
si riscrive come una memoria circolare o si pianta Sql server ?
Io "spezzerei" la transazione unica in tante più piccole
La transazione non è unica, si trattano di circa una dozzina di programmi in
esecuzione contemporanea, che nell'arco di circa 8 ore importano le letture
di circa 400 strumenti di misura distribuiti in tutta Italia.

Post by Paolo Fiore
tu dici "Mi succede infatti che a causa di inserimenti di molti record al
giorno";
ok, ma è necessario farlo con un'unica INSERT (xché è li il tuo problema)?
ciao
Nota: Quel "al giorno" mi turba l'analisi però...

Qui non ho capito cosa volevi intendere, specie nel "mi turba l'analisi"

Grazie per l'interessamento

[Luca Bianchi]

Post by Emanuel Provesi
Ma se io imposto una dimensione massima, lui poi (il Log delle
Transazioni) si riscrive come una memoria circolare o si pianta Sql
server ?

Al raggiungimento delle dimensioni massime impostate per il t-log (o
all'esaurimento dello spazio disco) si pianta il database (non SQL Server)

Post by Emanuel Provesi
La transazione non è unica, si trattano di circa una dozzina di
programmi in esecuzione contemporanea, che nell'arco di circa 8 ore
importano le letture di circa 400 strumenti di misura distribuiti in
tutta Italia.

...al completamento di una transazione, con il recovery model SIMPLE,
vengono liberati i virtual log inattivi (ovvero quelli contenenti TUTTE
transazioni già completate e riportate su disco) in occasione del
CHECKPOINT. Se un virtual log contiene anche una sola informazione relativa
ad una transazione non ancora conclusa oppure non ancora sottoposta a
checkpoint, l'intero virtual log non può essere dichiarato inattivo e,
quindi, non riciclabile. Con un recovery model differente dal SIMPLE l'unico
evento in grado di dichiarare "riutilizzabile" un virtual log (fermi
restando i prerequisiti di cui sopra) è il backup del T-LOG.

Post by Emanuel Provesi
Grazie per l'interessamento

Bye

[Paolo Fiore]

Post by Emanuel Provesi
Ma se io imposto una dimensione massima,

come ha detto Luca (e ci mancherebbe ;)) si pianta.
Infatti io intendevo che ho la sensazione che tu GIA' OGGI abbia una
dimensione massima; infatti ti dice che è "full", concetto applicabile
sono 1) in presenza di limiti 2) disco pieno

Post by Emanuel Provesi
Io "spezzerei" la transazione unica in tante più piccola
La transazione non è unica,

Ti rispondo in informatichese: impossibile :)

Post by Emanuel Provesi

Post by Paolo Fiore
Nota: Quel "al giorno" mi turba l'analisi però...

Qui non ho capito cosa volevi intendere, specie nel "mi turba l'analisi"

lo riprendo sotto, ma c'è qualcosa che non torna tra ciò che scrivi, giò
che capisco io e la realtà del log che si pianta ;)

Post by Emanuel Provesi
si trattano di circa una dozzina di programmi in
esecuzione contemporanea, che nell'arco di circa 8 ore importano le letture
di circa 400 strumenti di misura distribuiti in tutta Italia.

un programma 9 su 10 usa un istruzione SQL attraverso una qualche
interfaccia di programmazione. Mi aspetto di guardare il codice e trovare
la costruzione di una stringa tipo "INSERT PIPPO VALUES('a',1). A
prescindere dall'interfaccia è questo lo statement che viene eseguito dal
SQLServer (1)
Se non ci fosse null'altro, come sembra, ciò che dici sarebbe impossibile.
Perché il record del TLOG verrebbe riusato non appena la insert termina (e
quindi crescita tlog vicina a zero).
Perché ci sia il comportamento da te citato ci deve essere in piedi una
transazione (2). Ovvero il programma parte con BEGIN TRANS e non completa
mai con COMMIT probabilmente sinché non viene termina il programma
stesso...

Insomma, per non tirare ancora a caso: il mio pendolino dice che il
comprotamento da te descritto è anomalo. period. Sullo scoprire l'anImalia
ci dobbiamo ancora lavorare un pochino ;)
ciao
pf
(1) Attiva il Profiler così vedi il tipo di statement che vengono
eseguiti; non escludo (anzi!) che invece dei comandi ci siano chiamate a
specifiche stored procedure con EXECUTE
(2) oppure ritorniamo a bomba, su quel DB non c'è SIMPLE!

[Luca Bianchi]

Post by Paolo Fiore
Perché il record del TLOG verrebbe riusato non appena la
insert termina (e quindi crescita tlog vicina a zero).

No, non è così.
La entry nel t-log viene rimossa solo dopo che l'informazione è stata
travasata nel file dati dal processo di CHECKPOINT che può avvenire anche
dopo un'ora. Inoltre, anche a checkpoint avvenuto, affinchè la porzione del
t-log venga considerata riutilizzabile è necessario che TUTTE le
informazioni contenute nello stesso virtual log siano già state committate
(o annullate fa lo stesso, ma comunque concluse) e sottoposte a checkpoint.
Basta infatti la presenza di una entry relativa ad transazione non conclusa
ad impedire che il virtual log venga svuotato...

Bye

[Emanuel Provesi]

Post by Luca Bianchi

Post by Paolo Fiore
Perché il record del TLOG verrebbe riusato non appena la
insert termina (e quindi crescita tlog vicina a zero).

No, non è così.
La entry nel t-log viene rimossa solo dopo che l'informazione è stata
travasata nel file dati dal processo di CHECKPOINT che può avvenire anche
dopo un'ora. Inoltre, anche a checkpoint avvenuto, affinchè la porzione del
t-log venga considerata riutilizzabile è necessario che TUTTE le
informazioni contenute nello stesso virtual log siano già state committate
(o annullate fa lo stesso, ma comunque concluse) e sottoposte a checkpoint.
Basta infatti la presenza di una entry relativa ad transazione non conclusa
ad impedire che il virtual log venga svuotato...

Ma in sostanza, scusami se banalizzo, oltre ovviamente ad analizzare il
flusso del mio programma per determinare eventuali funzionamenti non
corretti, non esiste una impostazione o una sequenza di operazioni che
mantengano le dimensioni del T-Log contenute entro certi limiti ?
Nel mio caso raggiungendo le diverse decine di Gb saturano lo spazio libero
del disco.

Grazie

[Luca Bianchi]

Post by Emanuel Provesi
Ma in sostanza, scusami se banalizzo, oltre ovviamente ad analizzare
il flusso del mio programma per determinare eventuali funzionamenti
non corretti, non esiste una impostazione o una sequenza di
operazioni che mantengano le dimensioni del T-Log contenute entro
certi limiti ?
Nel mio caso raggiungendo le diverse decine di Gb saturano lo spazio
libero del disco.

Il t-log è una "scienza esatta".
Conoscendone l'architettura è possibile prevederne il comportamento che,
anche se talvolta può apparire "anomalo", è del tutto coerente con i
requisiti che deve soddisfare. Se mi dai un'indirizzo e-mail valido ti invio
un mio articolo sull'architettura del t-log (uscito su un Visual Basic
Journal di un paio di anni fa) che può aiutarti a chiarire qualche concetto
(i principali, tuttavia, sono già stati affrontati in questo stesso thread).

Post by Emanuel Provesi
Grazie

Bye

[Emanuel Provesi]

Post by Luca Bianchi
Il t-log è una "scienza esatta".
Conoscendone l'architettura è possibile prevederne il comportamento che,
anche se talvolta può apparire "anomalo", è del tutto coerente con i
requisiti che deve soddisfare. Se mi dai un'indirizzo e-mail valido ti invio
un mio articolo sull'architettura del t-log (uscito su un Visual Basic
Journal di un paio di anni fa) che può aiutarti a chiarire qualche concetto
(i principali, tuttavia, sono già stati affrontati in questo stesso thread).

Ben volentieri, eccoti il mio indirizzo.

Grazie ancora per la pazienza e la costanza.

Emanuel Provesi
***@teamware.it

[Luca Bianchi]

Post by Emanuel Provesi
Ben volentieri, eccoti il mio indirizzo.

Spedito.
Ti consiglio comunque di non scrivere mai l'indirizzo in chiaro nel ng (e
neanche quando registri il ng in OE). Ci sono dei motori che scansionano
costantemente tutti i "luoghi pubblici" in internet alla ricerca di
indirizzi e-mail da spammare. In genere si usa qualcosa del tipo

lucapuntobianchi dominio.it

Chi legge interpreta facilmente il vero indirizzo; un sw no...

Bye

[Paolo Fiore]

Post by Luca Bianchi

Post by Paolo Fiore
Perché il record del TLOG verrebbe riusato non appena la
insert termina (e quindi crescita tlog vicina a zero).

No, non è così.
La entry nel t-log viene rimossa solo dopo che l'informazione è stata
travasata nel file dati dal processo di CHECKPOINT

sono stato impreciso

Post by Luca Bianchi
che può avvenire anche dopo un'ora.

beh, potrebbe lanciare l'istruzione da codice... ;)

diavolo però un'ora è tanto non avevo mai pensato potessero così
dilatarsi.

Nel caso specifico dovrebbero essere frequenti(ssime) però!

"L'intervallo tra i checkpoint automatici si basa sul numero di record di
log, non sul tempo. ()"
"Se il database utilizza il modello di recupero semplice, viene generato
un checkpoint automatico ogni volta che il numero di record di log
raggiunge il minore tra i valori seguenti:
Il log viene riempito al 70%.
il numero di record di log raggiunge il valore che SQL Server stima sia
possibile elaborare nel periodo di tempo specificato dall'opzione recovery
interval. "

[Luca Bianchi]

Post by Paolo Fiore
diavolo però un'ora è tanto non avevo mai pensato potessero così
dilatarsi.
Nel caso specifico dovrebbero essere frequenti(ssime) però!

...resta allora viva l'ipotesi che i virtual log non possono essere
dichiarati inattivi a causa della presenza di una transazione non completata
e non riportata sui file dati...

Bye

[Emanuel Provesi]

Post by Paolo Fiore
come ha detto Luca (e ci mancherebbe ;)) si pianta.
Infatti io intendevo che ho la sensazione che tu GIA' OGGI abbia una
dimensione massima; infatti ti dice che è "full", concetto applicabile
sono 1) in presenza di limiti 2) disco pieno

Dice che è full perchè il disco è pieno.

Post by Paolo Fiore
Ti rispondo in informatichese: impossibile :)

In informatichese replico che ogni giorno, circa 400 esecuzioni dello stesso
programma (con un parallelismo di 12 istanze) inseriscono i dati nel db. Lo
avevo espresso così :
"> > si trattano di circa una dozzina di programmi in

Post by Paolo Fiore

Post by Emanuel Provesi
esecuzione contemporanea, che nell'arco di circa 8 ore importano le letture
di circa 400 strumenti di misura distribuiti in tutta Italia."

Questa è un'unica transazione ?

Post by Paolo Fiore
un programma 9 su 10 usa un istruzione SQL attraverso una qualche
interfaccia di programmazione. Mi aspetto di guardare il codice e trovare
la costruzione di una stringa tipo "INSERT PIPPO VALUES('a',1). A
prescindere dall'interfaccia è questo lo statement che viene eseguito dal
SQLServer (1)
Se non ci fosse null'altro, come sembra, ciò che dici sarebbe impossibile.
Perché il record del TLOG verrebbe riusato non appena la insert termina (e
quindi crescita tlog vicina a zero).
Perché ci sia il comportamento da te citato ci deve essere in piedi una
transazione (2). Ovvero il programma parte con BEGIN TRANS e non completa
mai con COMMIT probabilmente sinché non viene termina il programma
stesso...

Sperando risulti comprensibile inserisco una porzione del codice che
effettua l'inserimento:

DM->IBQ_Global->SQL->Add("INSERT INTO T_GLOBAL (COD_CAMPAIGN, COD_MEASURE,
COD_TIME, VALORE, PHASE) VALUES (:COD_CAMPAIGN, :COD_MEASURE, :COD_TIME,
:VALORE, :PHASE);");

for(riga = 0; riga < ContaMeasure; riga++) {
DM->IBQ_Global->Params->Items[0]->Value = DM->Letture[riga].Campaign;
DM->IBQ_Global->Params->Items[1]->Value = DM->Letture[riga].Measure;
DM->IBQ_Global->Params->Items[2]->Value = DM->Letture[riga].Time;
DM->IBQ_Global->Params->Items[3]->Value = DM->Letture[riga].Valore;
DM->IBQ_Global->Params->Items[4]->Value = DM->Letture[riga].Phase;
try {
DM->IBQ_Global->Prepare();
if (!DM->IBDatabase->InTransaction)
DM->IBDatabase->StartTransaction(); // Call
StartTransaction to begin a new user transaction against the database server

// Use Execute to execute the SQL statement on the server. If
SQL statement is a query Execute calls Open method.
DM->IBQ_Global->Execute();

DM->DB_Commit(); // Call Commit to commit current transaction
InsedRec++;
}
catch(EMSError &Err) {
. . . . . .

}

Tutto questo con il Borland C++ Builder 5 e driver di connessione a SQL
Server della CoreLab www.crlab.com

Post by Paolo Fiore
(1) Attiva il Profiler così vedi il tipo di statement che vengono
eseguiti; non escludo (anzi!) che invece dei comandi ci siano chiamate a
specifiche stored procedure con EXECUTE

Lo farò appena possibile.

Grazie

[Paolo Fiore]

Post by Emanuel Provesi
In informatichese replico che ogni giorno, circa 400 esecuzioni dello stesso
programma (con un parallelismo di 12 istanze) inseriscono i dati nel db. Lo
"> > si trattano di circa una dozzina di programmi in

Post by Emanuel Provesi
esecuzione contemporanea, che nell'arco di circa 8 ore importano le letture
di circa 400 strumenti di misura distribuiti in tutta Italia."

Questa è un'unica transazione ?

Assolutamente no, ma ogni chiamata lo potrebbe essere se la transazione
non viene chiusa sinché il programma non termina

Post by Emanuel Provesi
Sperando risulti comprensibile inserisco una porzione del codice che

Non sono io la persona giusta a questo punto; già non conosco l'uso che fa
di quelle variabili e.g. :COD_CAMPAIGN per passarne il valore:(
[Sembrano parametri di una SP, ma si vede chiaramente che viene usata una
INSERT]

Post by Emanuel Provesi
DM->IBQ_Global->SQL->Add("INSERT INTO T_GLOBAL (COD_CAMPAIGN,
COD_MEASURE,
COD_TIME, VALORE, PHASE) VALUES (:COD_CAMPAIGN, :COD_MEASURE, :COD_TIME,
:VALORE, :PHASE);");
for(riga = 0; riga < ContaMeasure; riga++) {
DM->IBQ_Global->Params->Items[0]->Value =
DM->Letture[riga].Campaign;
DM->IBQ_Global->Params->Items[1]->Value =
DM->Letture[riga].Measure;
DM->IBQ_Global->Params->Items[2]->Value = DM->Letture[riga].Time;
DM->IBQ_Global->Params->Items[3]->Value = DM->Letture[riga].Valore;
DM->IBQ_Global->Params->Items[4]->Value = DM->Letture[riga].Phase;
try {
DM->IBQ_Global->Prepare();
if (!DM->IBDatabase->InTransaction)
DM->IBDatabase->StartTransaction(); // Call
StartTransaction to begin a new user transaction against the database server

Quindi le transazioni ci sono eccome!

Post by Emanuel Provesi
DM->IBQ_Global->Execute();

non capisco dove si chiude la FOR iniziale. Il programma fa
// Call Commit to commit current transaction

Post by Emanuel Provesi
InsedRec++;

[Paolo Fiore]

"Emanuel Provesi" <***@teamware.it> wrote in message news:***@tk2msftngp13.phx.gbl...
DANNAZ, HO DATO INVIO TROPPO PRESTO:)))

Post by Emanuel Provesi
In informatichese replico che ogni giorno, circa 400 esecuzioni dello stesso
programma (con un parallelismo di 12 istanze) inseriscono i dati nel db. Lo
"> > si trattano di circa una dozzina di programmi in

Post by Emanuel Provesi
esecuzione contemporanea, che nell'arco di circa 8 ore importano le letture
di circa 400 strumenti di misura distribuiti in tutta Italia."

Questa è un'unica transazione ?

Assolutamente no, ma ogni chiamata lo potrebbe essere se la transazione
non viene chiusa sinché il programma non termina

Post by Emanuel Provesi
Sperando risulti comprensibile inserisco una porzione del codice che

Non sono io la persona giusta a questo punto; già non conosco l'uso che fa
di quelle variabili e.g. :COD_CAMPAIGN per passarne il valore:(
[Sembrano parametri di una SP, ma si vede chiaramente che viene usata una
INSERT]

Post by Emanuel Provesi
DM->IBQ_Global->SQL->Add("INSERT INTO T_GLOBAL (COD_CAMPAIGN,
COD_MEASURE,
COD_TIME, VALORE, PHASE) VALUES (:COD_CAMPAIGN, :COD_MEASURE, :COD_TIME,
:VALORE, :PHASE);");
for(riga = 0; riga < ContaMeasure; riga++) {
DM->IBQ_Global->Params->Items[0]->Value =
DM->Letture[riga].Campaign;
DM->IBQ_Global->Params->Items[1]->Value =
DM->Letture[riga].Measure;
DM->IBQ_Global->Params->Items[2]->Value = DM->Letture[riga].Time;
DM->IBQ_Global->Params->Items[3]->Value = DM->Letture[riga].Valore;
DM->IBQ_Global->Params->Items[4]->Value = DM->Letture[riga].Phase;
try {
DM->IBQ_Global->Prepare();
if (!DM->IBDatabase->InTransaction)
DM->IBDatabase->StartTransaction(); // Call
StartTransaction to begin a new user transaction against the database server

Quindi le transazioni ci sono eccome!

Post by Emanuel Provesi
DM->IBQ_Global->Execute();
DM->DB_Commit();

E qui c'è anche la commit

non capisco però dove si chiude la FOR iniziale. Il programma fa una
execute/commit per ogni ContaMeasure oppure ha preparato tutte le INSERT e
le spara contro il DB in un sol colpo?
E comunque quante istruzioni può generare la FOR?

[Emanuel Provesi]

Post by Paolo Fiore
Non sono io la persona giusta a questo punto; già non conosco l'uso che fa
di quelle variabili e.g. :COD_CAMPAIGN per passarne il valore:(
[Sembrano parametri di una SP, ma si vede chiaramente che viene usata una
INSERT]

Non no è una SP ma una istruzione SQL è quello che ho postato è il modo di
valorizzarne i parametri, in sostanza per costruire l'elenco dei valori da
passare alla INSERT

Post by Paolo Fiore
non capisco però dove si chiude la FOR iniziale. Il programma fa una
execute/commit per ogni ContaMeasure oppure ha preparato tutte le INSERT e
le spara contro il DB in un sol colpo?
E comunque quante istruzioni può generare la FOR?

Il FOR si chiude più sotto semplicemente dopo aver aggiornato dei contatori.
Ogni "giro" del FOR esegue una execute / commit e per fare un conto globale,
giornalmente ne vengono eseguiti circa 14 Milioni.

Ciao e grazie per l'interessamento.

[Paolo Fiore]

Post by Emanuel Provesi
Non no è una SP ma una istruzione SQL è quello che ho postato è il modo di
valorizzarne i parametri, in sostanza per costruire l'elenco dei valori da
passare alla INSERT

si, è il fatto che rimanga tutta tra apici che mi perplimeva. ok comunque
non c'entra

Post by Emanuel Provesi

Post by Paolo Fiore
non capisco però dove si chiude la FOR iniziale.

Il FOR si chiude più sotto semplicemente dopo aver aggiornato dei contatori.
Ogni "giro" del FOR esegue una execute / commit e per fare un conto globale,
giornalmente ne vengono eseguiti circa 14 Milioni.

non so se ho capito.
ogni "giro" di FOR imposti UNA insert, apro la transazione, la mando al db
e faccio commit
e torni su a testare riga< ContaMeasure
Giusto?
Mi sembra pesante e non lo comprendo (1), ma non vedo errori per il
problema di cui stiamo discutendo :(
Quesl record del TLOG *deve* essere riusato!!!

spero che qualcuno sia più bravo di me
mi ritiro a pensare
ciao
(1) perché allora ci sono le transazioni se inserisci UN solo record?????

[Luca Bianchi]

Post by Paolo Fiore
Quesl record del TLOG *deve* essere riusato!!!

...non vorrei apparire insistente ribadendo sempre le stesse cose, ma quello
che sto cercando di dire (senza riuscire a spiegarmi) da diversi post è che
affinchè venga reso riutilizzabile un virtual log (è questa la porzione
minima da considerare e non il "record del t-log") occorre che si
verifichino entrambe le condizioni

1) il virtual log deve contenere TUTTE informazioni relative a transazioni
concluse
2) deve essere avvenuto un checkpoint o un backup del t-log (a seconda del
recovery model)

Quello che forse è stato sottointeso nei post precedenti è che per la
condizione 1) devono essere concluse ANCHE tutte le transazioni relative ai
virtual log precedenti e che, quindi, la "parte attiva" è dopo il virtual
log che deve essere svuotato. Il fatto di non poter fare un disegno
penalizza la mia esposizione, ma ci provo. Considera, nello schema seguente,
la riga vuota come la separazione tra 2 virtual log adiacenti e, nel
proseguo del tempo, il t-log registra le seguenti attività:

======================
BEGIN TRAN T1
ISTRUZIONE_A T1

CHECKPOINT
BEGIN TRAN T2
ISTRUZIONE_A T2

ISTRUZIONE_B T1
CHECKPOINT

ISTRUZIONE_B T2
COMMIT TRAN T1

CHECKPOINT
BEGIN TRAN T3
ISTRUZIONE_A T3
COMMIT TRAN T3

CHECKPOINT
ROLLBACK TRAN T2
CHECKPOINT
======================

Il primo checkpoint riporta su disco le informazioni come modificate da
ISTRUZIONE_A della transazione T1; subito dopo viene avviata un'altra
transazione ed una istruzione modifica dei dati in un diverso contesto; una
seconda istruzione (ISTRUZIONE_B T1) viene eseguita (registrata in un nuovo
virtual log) e successivamente un nuovo checkpoint riversa su disco le
pagine dati modificate dopo il precedente checkpoint. Un nuovo virtual log
contiene quindi le entry relative ad una nuova istruzione (appartenente a
T2) ed il commit della transazione T1. Nuovo virtual log e nuovo checkpoint
che scrive delle pagine dati su disco e solo a questo punto può essere
liberato il primo virtual log (se il recovery model è simple oppure al
successivo backup del t-log con gli altri rm). Solo il primo virtual log,
infatti, riguarda transazioni già concluse e viene marcato come INATTIVO (le
info contenute non sono più indispensabili per un eventuale processo di
recovery). Dopo questo checkpoint viene avviata una transazione, eseguita
un'istruzione e confermata la stessa. In un nuovo virtual log viene quindi
marcato un evento di checkpoint. Questo evento non marcherà come inattiva
alcuna porzione di t-log (sebbene nel precedente virtual log ci siano SOLO
info relative a transazioni concluse) a causa della presenza di una
transazione aperta. In questo momento il Min LSN è posizionato sul punto
BEGIN TRAN T2; fintanto che rimane aperta questa transazione, per quante
transazioni vengano iniziate e concluse e per quanti eventi di checkpoint
incorrano, per quanti backup del t-log vengano eseguiti, NESSUN virtual log
verrà svuotato. Solo la chiusura della transazione T2 (ed il successivo
checkpoint), farà avanzare il MinLSN rendendo liberabili, dopo l'ultimo
checkpoint, tutti i virtual log (fino a quello dove è il COMMIT TRAN 3)
mantenendo attivo solo l'ultimo virtual log (un virtual log attivo ci sarà
sempre).
Ho semplificato la situazione comprendendo un numero limitato di entry per
ciascun virtual log, ma il principio di funzionamento è questo. In sostanza
ad ogni entry viene assegnato un valore LSN (Log Sequence Number) ed in
considerazione del valore LSN relativo alla transazione aperta più vecchia
(Min LSN) vengono marcati come inattivi (quindi svuotabili in occasione del
checkpoint o di un backup del t-log a seconda del rm) SOLO i virtual log
precedenti a tale Min LSN.
E' possibile conoscere lo stato dei virtual log utilizzando l'istruzione

DBCC LOGINFO ('nomedb')

(si tratta di una istruzione non documentata di cui non vi è traccia nel
BOL). I virtual log attivi (pertanto non svuotabili e non riciclabili) sono
quelli con il campo Status = 2.
In presenza di una situazione come quella ipotizzata (una unica vecchia
transazione che impedisce il riutilizzo di tutto o parte del t-log)
l'esecuzione dell'istruzione di cui sopra mostra un numero molto elevato di
virtual log con Status = 2.

Spero di aver contribuito a fare un po più di chiarezza. Se non ci sono
riuscito ora non ci riesco più... ;-)

Bye

[Marcello]

[CUT]

Ciao,
Provo anch'io a riinfilarmi nella discussione.
Anzitutto trattandosi di un'unica operazione l'apertura e la chiusura
della transazione non è strettamente necessaria, quindi, potresti
provare a valutare se i metodi StartTransaction e DB_Commit [Stranamente
di due classi diverse!] contengano errori semplicemente remmandoli.
In pratica quindi ti suggerisco di provare ad eliminare le righe

if (!DM->IBDatabase->InTransaction)
DM->IBDatabase->StartTransaction();

e

DM->DB_Commit();

E eventuali Rolback all'interno della gestione degli errori.

Detto ciò il problema potrebbe essere comunque riaffrontato in un'ottica
nuova e molto meno stressante per SQL Server. In particolare pernso alla
possibilità di creare dei file, a partire dagli imput degli strumenti, e
importarli in blocco con apposite strategie, tipicamente via DTS.
Potresti ottenere a mio avviso miglioramenti molto molto significativi,
indipendentemente dal problema T-Log del momento.

marc.

[Emanuel Provesi]

Post by Marcello
Provo anch'io a riinfilarmi nella discussione.
Anzitutto trattandosi di un'unica operazione l'apertura e la chiusura
della transazione non è strettamente necessaria, quindi, potresti
provare a valutare se i metodi StartTransaction e DB_Commit [Stranamente
di due classi diverse!] contengano errori semplicemente remmandoli.
In pratica quindi ti suggerisco di provare ad eliminare le righe

No, non sono di due classi diverse, è solo che nel caso della Commit l'ho
inglobata, assieme al controllo che la transazione sia attiva in una mia
funzione che si chiama proprio DB_Commit.

Post by Marcello
if (!DM->IBDatabase->InTransaction)
DM->IBDatabase->StartTransaction();
e
DM->DB_Commit();
E eventuali Rolback all'interno della gestione degli errori.

Proprio qui sta il problema. Dato che specialmente all'inizio dello sviluppo
di questo progetto, dagli strumenti, per motivi vari, può arrivarmi di
tutto, l'INSERT è stato "atomizzato" per permettermi di non perdere gli
inserimenti andati a buon fine in caso di errore. Inoltre ho potuto
verificare che senza l'inizio e fine di una transazione ad ogni insert, il
tentativo di accedere, in visualizzazione ai dati, da parte di un altro mio
software di analisi, risultava bloccato nel caso fossero in esecuzioni
istanze del sw di inserimento. Tieni presente che per inserire i dati di
tutti gli strumenti, l'esecuzione da 2 PC impiega circa 9/10 ore tutti i
giorni; non mi è possibile impedirne l'analisi anche di dati precedenti nel
frattempo.

Post by Marcello
Detto ciò il problema potrebbe essere comunque riaffrontato in un'ottica
nuova e molto meno stressante per SQL Server. In particolare pernso alla
possibilità di creare dei file, a partire dagli imput degli strumenti, e
importarli in blocco con apposite strategie, tipicamente via DTS.
Potresti ottenere a mio avviso miglioramenti molto molto significativi,
indipendentemente dal problema T-Log del momento.

La soluzione dei DTS non l'avevo considerata, anche perchè non riesco ad
immaginare come "generalizzarne" il funzionamento, nel mio caso dei 400
strumenti. Ho invece scoperto la BULK INSERT, che sto approfondendo e forse,
seppur con alcune limitazioni, potrei sfruttare.

Qualcuno sa dirmi di più della BULK INSERT e, oso chiedere troppo,
considerare se rispetto al mio problema di T_LOG "mostruosi" può essere
d'aiuto ?

Thak's

[Marcello]

Post by Emanuel Provesi
Proprio qui sta il problema. Dato che specialmente all'inizio dello sviluppo
di questo progetto, dagli strumenti, per motivi vari, può arrivarmi di
tutto, l'INSERT è stato "atomizzato" per permettermi di non perdere gli
inserimenti andati a buon fine in caso di errore.

Questo non ha nulla a che fare con la transazione. Se avviene un errore
sulla singola insert, l'inserimento fallisce e viene sollevata
un'eccezione a cui accedi nel catch. Begin Commit e rollbak non hanno un
ruolo e vengono eseguiti implicitamente.

Post by Emanuel Provesi
Inoltre ho potuto
verificare che senza l'inizio e fine di una transazione ad ogni insert, il
tentativo di accedere, in visualizzazione ai dati, da parte di un altro mio
software di analisi, risultava bloccato nel caso fossero in esecuzioni
istanze del sw di inserimento.

Quindi stai dicendo che in transazione viene usato un livello di lock
diverso? ...mmm... non quadra e anzi avvalora la tesi che la transazione
sia perennemente aperta [e quindi il log non venga mai svuotato].
Siamo sicuri sicuri sicuri che l'oggetto DM non apra delle connessioni
di suo e apra transazioni permanenti?

Post by Emanuel Provesi
Tieni presente che per inserire i dati di
tutti gli strumenti, l'esecuzione da 2 PC impiega circa 9/10 ore tutti i
giorni; non mi è possibile impedirne l'analisi anche di dati precedenti nel
frattempo.

Certo, capisco, ribadisco che i dati a mio avviso andrebbero importati
in blocco non con un sovraccarico di chiamate.

Post by Emanuel Provesi
La soluzione dei DTS non l'avevo considerata, anche perchè non riesco ad
immaginare come "generalizzarne" il funzionamento, nel mio caso dei 400
strumenti.

Ma questi dati come arrivano dai 400 strumenti ai due PC?

Post by Emanuel Provesi
Ho invece scoperto la BULK INSERT, che sto approfondendo e forse,
seppur con alcune limitazioni, potrei sfruttare.

Beh, "usare i dts" era proprio una forma molto evoluta dell'idea "usare
la bulk insert" Se i 400 strumenti generano files tutti disomogenei
impostare script di bulk insert potrebbe essere ancora più complesso che
sfruttare i dts.

Post by Emanuel Provesi
Qualcuno sa dirmi di più della BULK INSERT e, oso chiedere troppo,
considerare se rispetto al mio problema di T_LOG "mostruosi" può essere
d'aiuto ?

Si, ma il problema che riscontri non è un difetto di SQL ma un problema
della tua applicazione. Se l'applicazione continuerà a contenere bug
sull'uso delle transazioni non otterrai benefici.

Post by Emanuel Provesi
Thak's

marc.

[Emanuele Bonin]

Post by Emanuel Provesi
Proprio qui sta il problema. Dato che specialmente all'inizio dello sviluppo
di questo progetto, dagli strumenti, per motivi vari, può arrivarmi di
tutto, l'INSERT è stato "atomizzato" per permettermi di non perdere gli

Il singolo statment insert è Atomico .... per questo non ha bisogno di
transazoni esplicite. Non è che pèer casio hai il SET IMPLICIT_TRANSACTIONS
ON. In questo caso ti verrebbe *IMPLICITAMENTE * aperta una transazione
anche che rimarrebbe apertra sino ad un tuo comando di commit/rollback

Post by Emanuel Provesi
inserimenti andati a buon fine in caso di errore. Inoltre ho potuto
verificare che senza l'inizio e fine di una transazione ad ogni insert, il
tentativo di accedere, in visualizzazione ai dati, da parte di un altro mio
software di analisi, risultava bloccato nel caso fossero in esecuzioni
istanze del sw di inserimento. Tieni presente che per inserire i dati di

Oltre che l'attivazione delle transazioni implicite potresti aumentare la
concorrenza settando SET TRANSACTION ISOLATION LEVEL in modo tale da
sbattertene di eventuali letture che potrebbero falklire o compagnia bella
... sempre ammesso che la cosa in fase di interrogazione dei dati ti sia
ininfluente!


Spero non essermi intromesso nel treadh utilmente.

[Marcello]

Post by Emanuele Bonin
Spero non essermi intromesso nel treadh utilmente.

?? Errore di battitura spero :-D

marc.

[Emanuele Bonin]

E` un errore di battitura ... anche se potrebbe essere letto come una
battuta da sbruffone!

Post by Marcello

Post by Emanuele Bonin
Spero non essermi intromesso nel treadh utilmente.

?? Errore di battitura spero :-D
marc.