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