2013/4/15 petrescs <[email protected]> > 2013/4/14 Bogdan BOTEZ <[email protected]> > > > Daca scriptul foloseste multe scrieri, este important sa fii > > sigur ca ai nevoie de toate. Cateodata chiar nu este nevoie. > > Si daca scrii, conteaza si cum grupezi scrierile (controlul > > tranzactional) - 10k tranzactii != 1 tranzactie cu 10k inregistrari. > > > De acord, insa nu e scriptul meu, e de la producator si nu stiu in ce > masura ar putea fi optimizat. Din fericire nu se executa decat in cazuri > extreme si cu baza de date deconectata (baleiaza si revalideaza practic > toate documentele din baza de date), iar zilnic pe productie se fac > operatiuni mult mai putin intensive. > > > Sa stii ca si "producatorul" este si el un om, nu are expertiza perfecta in toate cele si daca aude o idee buna poate o si implementeaza. (standard disclaimers apply)
> > > Daca iti pasa de date, sync-ul trebuie sa fie coordonat de > > responsabilul datelor (care este baza). Parerea mea (2 cents). > > > Si eu imi pun centii pe aceeasi varianta, de asta am lasat forced writes on > (by default). Am gasit deja ca dezactivarea acestor FW duce la > imbunatatirea pwrite() cu aprox. 2 ordine de marime, insa prefer sa > sacrific viteza, bottleneck-ul asta apare doar in anumite conditii, din > fericire nu pe productie. Ca si workaround, scripturile de genul asta le > voi executa pe o copie a DB, cu forced-writes off, urmata de un backup > restore pentru validare si re-activarea forced-writes inainte de a reveni > pe productie (din fericire am ferestre in care sa fac aceste operatiuni, nu > ruleaza 24/7). > > In lipsa unor alte detalii e greu de comentat. Daca ai ferestre de mentenanta si esti sigur ca scrii doar tu ... iar restore-ul este clar o optiune, atunci nu vad de ce ai face toata manevra pe inca un mediu in locul celui de productie. Daca iti crapa in mijlocul activitatii, ai optiunea de restore. Daca nu, ura si asta e. Dar e greu de spus in lipsa unor informatii concrete. peace, _bogdan_ _______________________________________________ RLUG mailing list [email protected] http://lists.lug.ro/mailman/listinfo/rlug
