Salut

Tot legat de mutarea de pe SQL Server 2000 pe SQL Server 2005 (si un hardware mai puternic evident pe noul server) trebuie sa implementez un maintenance plan.Situatia este asa: sunt sase instante diferite pentru sase ani de la 2004 pana la 2009,fiecare instanta contine bazele ei.Instantele sau bazele nu sunt legate intre ele pe ani diferiti.Se lucreaza in mod curent doar pe anul in curs 2009 dar mai sunt accesate si baze din ceilalti ani mai mult pentru view decat pt modificari.Din experienta voastra cum ar fi bine sa fie conceput planul de mentenanta a bazelor inclusiv backup in aceasta situatie?

Multumesc

---

Sorin Titu
MCITP Database Administrator
MCITP Enterprise Administrator

SorinT:

dar mai sunt accesate si baze din ceilalti ani mai mult pentru view decat pt modificari.

Intrebare : sunt doar pentru view ? Incearca sa le pui ReadOnly - sa vezi daca sunt DOAR pentru view(Probabil 2008 nu e doar view... dar 2007 da)
Daca e asa, un simplu backup si readonly ar ajunge

---

Ignat Andrei
http://serviciipeweb.ro/iafblog

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.

---

http://rusanu.com

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. 

---

Sorin Titu
MCITP Database Administrator
MCITP Enterprise Administrator

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.

---

http://rusanu.com

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).

---

Sorin Titu
MCITP Database Administrator
MCITP Enterprise Administrator

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.

---

Sorin Titu
MCITP Database Administrator
MCITP Enterprise Administrator

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

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.

---

http://rusanu.com

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.

---

http://rusanu.com

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 

---

Sorin Titu
MCITP Database Administrator
MCITP Enterprise Administrator

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

---

Gheorghe Ciubuc,SQL Server Influencer, MCP(SQL 2000), MCTS (SQL Server 2005) , OCA(Oracle 9i), Sybase(Brainbench)

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 ?

---

MCSE;MCITP

Absolut. La 10-15 minute max.

---

http://rusanu.com

Si nu afecteaza prea mult performantele pe disk ?

Merci!

---

MCSE;MCITP