dimon a scris:
>
> Dar în cursul experimentelor de noapte de ieri și de astăzi privind tranziția
> în clasic, am o altă problemă. Pentru ziua curentă de 3 ori primită
> Blocați tranzacția WAIT.
Să învățăm cum să introduceți complet mesajul de eroare.
Blocați conflictul pe tranzacția WAIT?
A existat alt text?
> Având în vedere că versiunea anterioară nu a dat un astfel de efect, ea sa strecurat
> îndoiți că am citit ceva greșit în documentație sau ceva
> nu înțeleg. Tranzacțiile cu atributul WAIT sunt doar pentru noi pentru a ne actualiza
> și ștergeți. Mai exact, acesta este "CITIȚI WRITE WAIT READ RECORD_VERSION ANGAJAT
Dacă nu există o eroare a formularului "actualizare conflict", atunci UPDATE / DELETE este cel mai probabil aici
nimic deloc. Metadatele în mișcare nu se schimbă cu o oră?
> O altă întrebare incidentală. Pentru o ieșire "manuală" dintr-o situație similară,
> am incercat sa facem -shut full-force 0 pentru baza, dar cand incercam
> baza de date online returnată a primit o blocare a erorilor în așteptarea tranzacției.
Undeva despre asta am auzit deja.
> Cum să procedăm corect în această situație.
Deconectați toți clienții.
> gfix -rollback.
Este chiar dintr-o altă operă.
> Și pot obține numărul tranzacției care blochează lucrarea.
Dacă acesta este un conflict de actualizare a înregistrărilor, atunci puteți. În 2.1 :-)
Dacă există vreun alt conflict de blocare, atunci este imposibil în principiu.
Îmi pare rău pentru întârziere. Când rulezi SuperServer, este foarte clar
Valorile DeadLockTimeout sunt procesate. Dacă este clasic
actualizarea simultană a acelorași date prin conexiuni diferite,
actualizarea "se blochează" pentru o perioadă nedeterminată. Nu am putut să înțeleg
câte. De ce se întâmplă acest lucru. Dacă totul este rescris
ca NU WAIT, acest lucru ne va ajuta.
Pe 28 iunie, ora 12:02, Dmitri Yemanov <[hidden email]> a scris:
> ddimon a scris:
>> Dmitry ai dreptate, mesajul pe care l-am adus nu este deloc.
>
> Și atunci ce este mesajul "același"? Aspecte pe care le vom trage?
>
> Dmitry
>
> Zashibis. Nu răspundem în mod fundamental întrebărilor adresate?
>
Dmitry, nu există niciun mesaj. Este doar "atârnă" pe actualizare.
>> Când rulezi SuperServer, este foarte clar
>> sunt procesate valorile DeadLockTimeout.
>
> Unde ați decis că există un impas, nu un conflict de actualizare?
>
Da, probabil ai dreptate. Deoarece testul este valabil
actualizăm aceleași date.
>> Dacă clasic, atunci la actualizarea simultană a unui
>> și aceleași date prin conexiuni diferite,
>> Actualizarea "se blochează" pentru o perioadă nedeterminată.
>
> Înainte de comiterea concurentului, presupun.
>
Cum să reduceți timpul de așteptare. Aceeași aplicație în moduri diferite
lucrează la Super și Classic. Sincer, nu înțeleg unde am lohanulsya. În
Supere primește o eroare exact așa cum este specificată de DeadLockTimeout, adică Sunt așa
Înțeleg după această întârziere, una dintre actualizări este marcată ca
NOWAIT și un mesaj de eroare este generat. Acest lucru este normal pentru noi
cerere. Suntem gata să vă asigurați că actualizările pot fi finalizate în așa fel.
mod. Dar când actualizarea se blochează pentru o perioadă nedeterminată, este foarte
pentru noi este critică. Rescrieți toate tranzacțiile ca WAIT LOCK TIMEOUT 10
sau în general NU WAIT. Nu înțeleg de ce un astfel de comportament diferit
de pe server.
Trimiteți-le prietenilor: