SQLServerITA

SQL Server e non solo

  • febbraio: 2012
    L M M G V S D
    « Gen   Mar »
     12345
    6789101112
    13141516171819
    20212223242526
    272829  
  • Blog Stats

    • 16,179 hits
  • Inserisci il tuo indirizzo e-mail per iscriverti a questo blog e ricevere notifiche di nuovi messaggi per e-mail.

    Segui assieme ad altri 6 follower

Single VS Multiple Database: i Pro

Posted by belthazor78 su 2 febbraio 2012


Supponiamo di dover tenere circa 3 copie di una stessa struttura dati e ognuna di queste copie ha le sue funzionalità: chi una sorta di snapshot, chi i dati da rendere utilizzabili da report e chi per attività giornaliere per un applicativo web. Tutti con gli stessi identici dati ma con scopi differenti.

Abbiamo due opzioni: ho tre schema all’interno di un Database oppure tre Database distinti sulla stessa istanza SQL Server (separarli fisicamente vorrebbe dire creare o intrudurre problemi di rete che non vorrei avere).

Mi è stato chiesto di fare un piccolo elenco di quelli che potrebbero essere i vantaggi nell’avere tre database distinti anzichè tre schema nello stesso DB.

Vediamo alcuni che sono riuscito ad individuare senza fare troppe ricerche.

1- Maggiore controllo sulla sicurezza degli oggetti del DB e maggiore separazione logica dei dati. In caso di compromissione di sicurezza su un DB gli altri sono più al sicuro. (ipoteticamente ogni DB dovrebbe avere la sua specifica sicurezza in base alla sua funzionalità)

2- Maggiore praticità nella gestione dei backup e loro politche: poter eseguire dei backup separati può, in alcuni casi, risultare molto più pratico. Eseguire il backup di un DB unico da 90GB anzichè tre da 30GB garantisce una flessibilità maggiore.

3- Maggiore praticità nella gestione del RECOVERY MODEL (se praticabile).

Supponiamo che di avere tre schema o tre database e solo uno in realtà richiede in recovery model a FULL (con tutte le criticità del caso…gestione backup full, differenziali, backup dei tlog etc…etc…).

Se abbiamo 3 schema dobbiamo per forza applicare il RECOVERY MODEL a FULL su tutto il DB. In caso di 3 DB separati, il RECOVERY MODEL a FULL potrebbe essere applicato solo al DB più importante mentre agli altri due si potrebbe scegliere un RECOVERY MODEL a SIMPLE.

4- Maggiore praticità nella gestione degli aggiornamenti degli indici e statistiche; tali operazioni sono,  o possono essere, molto onerose in termini di tempi e occupazione del DB. Si potrebbe prevedere, ad esempio, di gestire gli aggiornamenti indici e statistiche in tempi diversi tra i database in modo molto più semplice che nell’utilizzare un unico database.

Anche con con schema separati il discorso è quasi identico: è vero che si può separare a livello schema ma deve essere gestito con maggiore attenzione.

5- Maggiore flessibilità in caso di database corrotti o offline: se tutti i dati stanno su un DB e questo  si corrompe o rimane offline per qualsiasi motivo, tutti i dati rimarranno offline.

Se i dati si trovano  su db diversi il rischio di rimanere senza dati diminuisce.

6- Maggiore flessibilità a sviluppi futuri: si può, in futuro, poter adottare alcune tencologie senza dover intaccare la struttura di un solo database. Supponiamo di dover gestire una Replica o un Mirroring e di doverli applicare solo per alcuni dati.

Avendo 3 database differenti tali operazioni saranno meno invasive.

7- Maggiore flessibilità nel maintenance: in fase di restore di un database (per qualsiasi motivo) si avrà  offline solo quel database mentre gli altri database possono rimanere online senza impatti sulla  usabilità delle applicazioni.

Stesso discorso nella tempistica, ovviamente, di un restore: effettuare il  restore di un singolo DB costa molto meno in termini di tempo CPU e I/O che effettuare il restore di un unico DB (perchè i GB sono “spezzati” su più DB).

8- Magggiore flessibilità, in futuro e se necessario, nella separazione anche fisica a livello di dischi dei database separando i file dati e tlog dei singoli database su dischi differenti.

In fase di test avere dei database differenti contenenti le stesse tabelle può risultare più comoda la  gestione dei test e maggiore sicurezza del passaggio da un database all’altro. Supponiamo di avere una tabella chiamata CAP e di questa dobbiamo avere tre copie: Final, Working e Report.

Supponiamo di avere, per implementare questa tabella, sia un singolo DB che tre database distinti.

Avendo un solo DB e dovendo avere la tabella suddivisa in tre siamo “costretti” ad utilizzare uno schema; le eventuali query di lettura, ad esempio, dovranno essere come segue [NomeSchema.Tabella]:

SELECT * FROM Final.CAP
SELECT * FROM Report.CAP
SELECT * FROM Working.CAP

E’ evidente che in fase di test dovrò crearmi e testare 3 stored diverse tra di loro.

Ora, supponiamo, di dover implementare la stessa cosa ma con tre database differenti:
SELECT * FROM dbo.CAP (non bisognerà cambiare nulla perchè la tabella si troverà fisicamente su 3 database differenti). In questo modo non bisogna dover cambiare la query. Portando tale esempio con query molto più complesse con svariate JOIN il fatto di avere tre DB è evidente.

Direi che ci sono dei bei vantaggi, ma solo in caso in cui i tre database o schema devono presentare sia la stessa struttura che gli stessi identici dati.

 

Lascia un commento

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione / Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione / Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione / Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione / Modifica )

Connessione a %s...

 
%d blogger cliccano Mi Piace per questo: