Intrebari generale

Re: database maintenance plan best practices

Diana — Fri, 27 Feb 2009 22:49:10 GMT

Este bine sa pui log-ul pe un "array" de discuri dedicat, vezi

http://sqlskills.com/blogs/Kimberly/post/8-Steps-to-better-Transaction-Log-throughput.aspx

Re: database maintenance plan best practices

rremus — Fri, 27 Feb 2009 16:28:57 GMT

Ba da, pentru ca trebuie citite paginile de log deja scrise, si pentru ca trebuie scrise paginile de backup.
Ba nu, pentru ca backup-ul oricum trebuie facut, deci acelasi volum de I/O se efectueaza, problema e doar daca faci backup de volum X la 10 minute sau backup de volum X * 12 la doua ore.
Daca nu se face backuplog des insa exista doua probleme:
- log-growth event-uri, o problema incomparabil mai grava decit I/O-ul de backup ('freeze' complect pe toate operatiile pina creste LDF-ul)
- cresterea marimii backup-ului
- cresterea perioadei de risk in caz de crash

Un storage bine dimensionat oricum trebuie sa ia in calcul si acest I/O de la backup, este o necesitate de functionare a sistemului, nu poate fi 'maturat sub pres'.

Re: database maintenance plan best practices

Jourjaque — Fri, 27 Feb 2009 11:05:53 GMT

Si nu afecteaza prea mult performantele pe disk ?

Merci!

Re: database maintenance plan best practices

rremus — Thu, 26 Feb 2009 13:37:57 GMT

Absolut. La 10-15 minute max.

Re: database maintenance plan best practices

Jourjaque — Thu, 26 Feb 2009 13:21:36 GMT

Am si eu o intrebare ! Observ ca s-a sugerat ideea unui plan de transaction log f des ! In conditiile unui server f incarcat,cu multi useri, in care fisierul de log ajunge la 11GB dupa doar 2 ore este recomandat acesta ?

Re: database maintenance plan best practices

ggciubuc — Wed, 25 Feb 2009 11:01:39 GMT

SorinT:

Trebuie sa mentionez ca fiecare instanta contine in jur de 2 GB informatie si ca fiecare instanta are in jur de 10 baze.

Vad ca ce ai prezentat aici intra in limitarile unui SQL Server Express Edition; nu stiu care sunt pretentiile la grup , precum si alte contrangeri de nr utilizatori simultan etc. dar o instanta numai pt raportare ar sta bine pe un astfel de server

Re: database maintenance plan best practices

SorinT — Tue, 24 Feb 2009 00:35:00 GMT

OK am inteles ce trebuie facut: voi monitoriza serverul vechi pana la sfarsitul saptamanii si apoi voi lua o decizie privind alocarea memoriei per instante si politica de backup cea mai potrivita.

Va multumesc pentru ajutor

Re: database maintenance plan best practices

rremus — Mon, 23 Feb 2009 14:08:37 GMT

Poate e OK, poate nu e. Pe ce te-ai bazat cind ai ales cifrele de mai sus? Daca configurezi aiurea sar putea sa te trezesti cu cozi enorme de I/O pe discuri din cauza ca bufer-pool-urile nu sint suficient de mari si fac mereu eviction la datele din cache si trebuie sa le citeasca innapoi.

Daca nu ai facut deja, lasa-l neconfigurat (max), fa un capture de perf counters pentru o saptamina-doua ca sa ai o idee cit de folosite sint instantele, apoi potzi sa fac o evaluare. Monitorizeaza Process/CPU (user), Process/Virtual Bytes, Process/Working Set pentru toate procesele sqlservr si memory/buffer pool counterii de la fiecare instanta, si avg disk queue length pe doate discurile.

Re: database maintenance plan best practices

rremus — Mon, 23 Feb 2009 14:02:16 GMT

Criteriul de alegere e timpul de recovery. Daca faci full in fiecare noapte la ora 3:00 si sa zicem log backup la fiecare 30 minute, atunci daca suferi un crash la 2:55 noaptea ca sa faci recovery trebuie sa faci un restore full, urmat de 47 de log restore-uri, urmat de tail-log restore. Ca sa reduci timpul de restore se face in general, intre full back-up-uri, si diferential backup, de ex odata la 3 ora in timpul programului. In acelasi scenariu ca mai sus, daca ai ultimul diferential backup la or 9 pm, atunic timpul de recovery este semnificativ redus pentru ca faci un full restore, apoi diferential, apoi log-restore de 11 ori doar (fata de 47 de ori), si in plus nu prinzi in log back-up activitatea de peste zi care se restoreaza incet.

E foarte important ca odata ce ai un plan niciodata nu mai faci back-up 'de mina' decit daca-i specifici 'with COPY_ONLY'.

Si nu uita sa faci un checklist cum se face un recovery din crash (tail-log backup, restore full, restore diferential, apoi log-uri, apoi tail-log recovery) astfel incit oricine sa stie sa-l faca cind e nevoie, si testeaza-l.

Re: database maintenance plan best practices

rsocol — Mon, 23 Feb 2009 13:42:41 GMT

Dacă recovery model este Full, atunci nu e suficient să faci backup-uri full, ci trebuie să faci periodic şi backup-uri de transaction log (preferabil mai des decât cele full, de exemplu zilnic pt 2004-2008 şi din oră în oră în timpul programului de lucru pentru 2009).

Răzvan

Re: database maintenance plan best practices

SorinT — Mon, 23 Feb 2009 13:15:48 GMT

Politica de back-up:
Pentru instantele 2004-2008: un fullbackup o data pe saptamana adica Sambata noaptea.
Pentru instanta 2009 : un fullbackup in fiecare zi de Luni pana Vineri in cursul noptii cand nu se lucreaza
exclusiv Sambata si Duminica cand nu se lucreaza deasemenea.
Aceaste backup-uri vor fi salvate pe o partitie a serverului si o copie a lor
va fi arhivata si salvata pe un alt server de storage.
Modelul de recovery al bazelor va fi full pentru toate.

Din celelalte componente ale Maintenance Plan din SQL Server 2005 referitor la instanta 2009 nu stiu deocamdata ce ar fi bine sa activez.

Re: database maintenance plan best practices

SorinT — Mon, 23 Feb 2009 10:37:27 GMT

Serverul are 8 GB RAM memorie totala.Alocarea spatiului de memorie pe instante m-am gandit sa-l fac asa:

Propunere spatiu de memorie alocat pe instante:

   inst 2004 256 MB
   inst 2005 256 MB
   inst 2006 256 MB
   inst 2007 256 MB
   inst 2008 512 MB inca este utilizata

    inst def 512 MB pe ea exista o baza a unei aplicatii de monitorizare a hardware-ului unor servere
--------------------
Total          2 GB

    inst 2009 nelimitat pt ca este cea pe care se lucreaza acum(sau ar fi mai bine sa o limtez si pe aceasta la 5 GB) astfel 1 GB sa ramana in cazul cel mai rau pentru SO).

Re: database maintenance plan best practices

rremus — Sun, 22 Feb 2009 13:11:40 GMT

Daca esti sigur ca instantele 2004-2008 sint read-only atunci nu au nevoie de maintenance plan in principiu, doar de un disaster recovery plan ca sa fie reinstalate daca suferi de vre-un crash (pierzi discurile). Si atunci faci doar un maintenance plan pentru 2009, potzi porni ca idee de la un plan creat cu Maintenance Plan Wizard. In primul si in primul rind trebuie sa te asiguri ca planul tau poate fi folosit in caz de incident sa repui baza de date online intr-un timp acceptabil (si asta i-tzi va dicta frecventa la care faci full backup, diffrential backup si log backup). In functie de cum este folosita instnta curenta, potzi sa adaugi pasi de re-index, de defragmentare, de dbcc checkdb samd, dar toate astea sint secundare comparat cu importanta planului de backup (si al procedurii corespunzatoare de recovery, care trebuie documentatata intr-un step-by-step checklist care sa stie toata lumea unde e, si testata).

In alta ordine de idei, autorul aplicatiei stie ca exista un numar limitat de instance care se pot instala pe o masina? http://msdn.microsoft.com/en-us/library/ms143432(SQL.90).aspx

Problema cea mai mare cind ai mai mult instante este consumul de memorie. Pentru ca instantele nu vor stii una de cealalta si cind cresc buffer-pool-ul. Fiecare va tinde sa-l creasca la maxim (adica cca 95% din RAM), ori maxim x 6 este mai mult decit disponibilul de RAM fizic. Sistemul de operare le va notifica ca exista 'memory pressure', si atunci toate instantele vor incepe sa elimine date din cache. Este descris aici in detaliu: http://blogs.msdn.com/slavao/archive/2005/02/19/376714.aspx Cind exista o singura instanta aceasca nu va creste memoria peste cca 95% din disponibilul de RAM fizic si nu i-si va cauza singura 'memory pressure'.
In plus si scheduling-ul de CPU este mult mai optim cind exista o singura instanta decit cind exista 6.

Re: database maintenance plan best practices

SorinT — Sun, 22 Feb 2009 12:16:30 GMT

Salut

Noul server este pe 64 bit si am instalat win ser 2008 64x si sql ser 2005 64x

Este vorba de o aplicatie (un fel de erp) utilizata intern in cadrul grupului,fiecare an este intr-o instanta separata de la 2004 la 2009 asa a fost creata aplicatia pe care noi nu o putem modifica din pacate.Userul ruleaza aplicatia si alege un an (adica in spate se conecteaza pe o instanta) apoi alege baza din anul respectiv pe care vrea sa lucreze.Pe instantele(anii) 2004-2008 nu se mai fac modificari doar sunt accesate date, pe 2009 se fac modificari avem insert,delete si view pe tabele cam asta e situatia acum.Eu vreau sa folosesc maintenance plan din sql server 2005 dar nu stiu cum ar fie cel mai bine sa fac in conditiile date.Trebuie sa mentionez ca fiecare instanta contine in jur de 2 GB informatie si ca fiecare instanta are in jur de 10 baze.

Multumesc pentru ajutor.

Re: database maintenance plan best practices

rremus — Sun, 22 Feb 2009 07:16:46 GMT

Ai trecut si de la 32 de biti la 64 (SQL si OS) ?

Care este motivul pentru care ai 6 instante diferite? Exista o separare de securitate intre ele (adica au setarile de access complet diferite la nivel de *instanta*)?
Daca nu ai un motiv serios pentru a separa instantele, daunezi foarte mult prin a creea 6 instante in loc de una, pentru ca 6 instante nu-si pot coordona resursele (CPU, memorie, I/O), pe cind una poate.