SQL Server e dintorni

Owner, Schema e Permessi su Aruba

lbianchi — Thu, 26 Jun 2008 13:10:00 GMT

Da un paio di giorni è in corso nel newsgroup microsoft.public.it.sql una discussione che ha come argomento la confusione esistente tra i concetti di owner, schema e permessi.

Cercando di riassumere c'è un utente che ha disegnato una base dati all'interno della quale ci sono delle viste e stored procedure che richiamano altri oggetti referenziandoli, come da best practice, anteponendo il nome dello schema al nome dell'oggetto. Questo utente ha stipulato un contratto con un noto fornitore di servizi (Aruba) che ospiterà il suo database sui propri server. Prassi consolidata di questo fornitore è quella di definire un login per l'accesso ai dati e creare, nel database dell'utente, uno schema in cui vengono creati gli oggetti che compongono il database.

In questo modo non solo viene limitata la possibilità di definire altri schema per meglio separare fra loro diverse tipologie di oggetti e/o per utilizzare gli stessi come securables, ma ogni oggetto che ne referenzia un altro smette di funzionare fino a che non vengono resi coerenti gli oggetti referenziati che adesso appartengono ad uno schema differente rispetto al momento della creazione.

Questo utente ha deciso quindi di scrivere ad Aruba, spinto anche dalla discussione scaturita nel newsgroup, chiedendo lumi sulle ragioni di una scelta tanto singolare che non solo limita le possibilità offerte dal prodotto SQL Server (non posso suddividere i miei oggetti in contenitori logici), ma crea anche disagi ai propri clienti che, se vogliono seguire le best practice in tema di "two part name" per tutti gli oggetti di database, si vedono costretti a modificare le stored procedure, le viste, le udf e le proprie applicazioni di accesso ai dati per cambiare il nome dello schema degli oggetti.

Questa è stata la risposta di Aruba:

Gentile cliente,come specificato nel supporto tecnico per l'utilizzo del servizio

http://assistenza.aruba.it/kb/idx/81/0/00002MS_Sql_Server.html

il tipo di accesso come dbo non e' consentito agli oggetti presenti nel suo db in quanto proprietario e' l'utente che le e' stato assegnato.

Inoltre cambiando l'owner dei suoi oggetti in 'dbo' di conseguenza non risulterebbero piu' accessibili in quanto l'utenza assegnata a causa di problemi di sicurezza ha specifici permessi che non sono permessi a livello di ruolo 'owner' e non possono essere cambiati.

Sono evidenti le enormi lacune sul concetto di owner, schema e permessi che ha dimostrato l'autore di questa risposta e non può essere considerata una giustificazione neanche il fatto che fino a SQL Server 2000 il concetto di owner e quello di schema erano sovrapposti.

E' infatti facilmente verificabile che a prescindere dallo schema in cui si trova un oggetto questo può essere acceduto anche se il nome dell'utente non coincide con il nome dello schema

USE master;
GO

CREATE DATABASE ArubaTest;
CREATE LOGIN Luca WITH PASSWORD = 'qwerty12345';
GO

USE ArubaTest;
GO

CREATE SCHEMA MySchema;
GO

CREATE USER Luca FROM LOGIN Luca;
GO

CREATE TABLE MySchema.T1 (ID int NOT NULL);
GO

GRANT SELECT ON MySchema.T1 TO Luca;
GO

EXECUTE AS USER = 'Luca'
SELECT ID FROM MySchema.T1
REVERT
GO

ALTER SCHEMA dbo TRANSFER MySchema.T1;
GO

GRANT SELECT ON dbo.T1 TO Luca;
GO
EXECUTE AS USER = 'Luca'
SELECT ID FROM dbo.T1
REVERT
GO

La stessa query sulla tabella T1 (adesso nello schema dbo) può essere eseguita anche se lo user in questione ha un default schema differente da dbo e non viene referenziato l'oggetto con il "two part name"

ALTER USER Luca WITH DEFAULT_SCHEMA = MySchema;
GO

EXECUTE AS USER = 'Luca'
SELECT ID FROM T1
REVERT
GO

Anche l'eventuale esigenza di creare oggetti nel database non richiede privilegi di livello dbowner. A prescindere da quale sia lo schema in cui un utente debba essere messo in grado di creare degli oggetti, l'esigenza può essere risolta con

GRANT ALTER ON SCHEMA::dbo TO Luca;
GRANT CREATE TABLE TO Luca;
GO

EXECUTE AS USER = 'Luca'
CREATE TABLE dbo.T2 (ID int NOT NULL)
REVERT
GO

Mi piacerebbe che potesse intervenire qualcuno di Aruba per meglio chiarire quella che, a mio avviso, è una risposta quantomeno lacunosa...

Transparent Data Encryption

lbianchi — Wed, 25 Jun 2008 10:09:00 GMT

L’infrastruttura di cifratura basata su PKI è stata introdotta in SQL Server 2005 (a questo link trovate un mio articolo sull'argomento). L’implementazione, tuttavia, richiede che vengano modificate le applicazioni di accesso ai dati per far uso delle funzioni necessarie per cifrare e decifrare le informazioni oltre che aprire le chiavi simmetriche utilizzate per cifrare i dati sensibili. Tutto questo ha rappresentato un ostacolo all’implementazione della cifratura dei dati che il Transparent Data Encryption (TDE) in SQL Server 2008 si propone di superare.

Con questa feature vengono cifrate le informazioni memorizzate nelle pagine dati su disco (in RAM i dati sono in chiaro) in maniera trasparente per le applicazioni di accesso ai dati. Rispetto all’infrastruttura PKI presente anche in SQL Server 2005 la TDE cifra l’intero database e non è possibile selezionare gli attributi che meritano di essere protetti rispetto a quelli meno critici.

La TDE può essere implementata insieme alla compressione dei dati. Quando la pagina è in RAM, questa viene compressa per poi essere cifrata nel momento di essere scritta su disco; quando deve essere recuperata, la pagina viene decifrata per essere posta in RAM e da qui, eventualmente, decompressa quando viene letta dall’applicazione client. Un database in cui sia abilitata la TDE si rivela poco comprimibile in occasione di un eventuale backup compresso mentre non viene pregiudicata la possibilità di compressione dei dati.

Per poter cifrare un database è necessario definire la MASTER KEY nel master; con questa MK si genera e viene protetto un certificato digitale e questo certificato rappresenterà la protezione del nostro database. Affinchè sia possibile ripristinare il database su un’altra istanza occorre che sia presente il certificato che ha cifrato il database. Diversamente non sarà possibile ripristinare o eseguire l’attach del database.

La TDE, al pari della data compression, è utilizzabile con il database mirroring. Il traffico di mirroring non è automaticamente cifrato (la cifratura riguarda solo le pagine dati su disco). Per cifrare il traffico si utilizza la cifratura a livello di ENDPOINT.

Nella pagina contenente il materiale del workshop UGISS tenutosi a Roma lo scorso mese di maggio trovate, nelle demo, degli esempi di utilizzo della TDE; altri esempi li potete trovare in questo post e in quest'altro.

[SQL Server 2008 Data Compression]: Che cosa comprimere?

lbianchi — Tue, 24 Jun 2008 17:33:00 GMT

Allo scorso workshop UGISS di Roma (qui sono disponibili le slide e le demo) ho parlato, tra le altre cose, di compressione dei dati.

La compressione dei dati, come noto, è una funzionalità in grado di far risparmiare risorse in termini di IO e, conseguentemente, permette un utilizzo più efficiente della RAM. Tutto questo viene pagato con qualche punto percentuale di CPU soprattutto abilitando la compressione a livello di pagina. In circostanze tutt'altro che rare, come ho dimostrato nel workshop tenutosi a Roma, la minor quantità di pagine a cui dover accedere contribuisce anche a ridurre l'utilizzo della CPU e, quindi, l'efficenza generale del sistema sotto tutti i punti di vista.

Chi ha avuto modo di giocare con la data compression in SQL Server 2008 avrà certamente utilizzato la sp_estimate_data_compression_savings che permette di conoscere, per ciascuna tabella o indice, una stima sul fattore di compressione atteso. Paul Nielsen ha creato due stored procedure molto utili in tema di compressione. Con la prima (db_compression_estimate) vengono analizzate tutte le tabelle e tutti gli indici di un database ed un report suggerisce il livello di compressione migliore (row o page). Con la seconda (db_compression) vengono compresse tutte le pagine e tutti gli indici dove le stime precedenti indicano un risparmio di spazio pari o superiore ad una determinata soglia passata come argomento.

Senz'altro molto utili...

Individuare gli indici duplicati o sovrapposti

lbianchi — Fri, 20 Jun 2008 07:06:00 GMT

Come tutti sappiamo una corretta strategia di indicizzazione è uno dei pilastri più importanti nell'implementazione di un database. Non dobbiamo esagerare, almeno in un database OLTP (in un datawarehouse diventa ammissibile "esagerare" un tantino), definendo troppi indici e, soprattutto, dovremmo verificare regolarmente che gli indici che abbiamo creato siano effettivamente utilizzati ed in questo ci viene in aiuto la sys.dm_db_index_usage_stats.

Talvolta però capita di individuare 2 indici che si sovrappongono fra loro dove uno dei 2 rappresenta un subset dell'altro. Lo script riportato in questo post ci evidenzia tutte le coppie di indici sovrapposti fra loro all'interno di un database. Una volta individuate le diverse coppie, quale eliminare per ciascuna coppia... quello che ha più chiavi di indice (meno compatto quindi meno efficiente) o quello meno "specifico"? Dipende. Come noto l'efficienza di un indice è data in primo luogo dalla compattezza della sua chiave (oltre ovviamente alla selettività); non dobbiamo scordarci, però, che un indice con qualche attributo in più nella definizione della sua chiave può rappresentare un indice di copertura per talune query. Non esiste quindi una regola generale da seguire e la valutazione va fatta caso per caso ricordandosi che, in SQL Server 2005, esiste la clausola INCLUDE che permette di rimuovere degli attributi "secondari" di un indice (non clustered) dalla definizione della chiave e memorizzarli solo nel livello foglia salvaguardando sia la compattezza dell'indice (meno livelli b-tree per andare dalla root al livello foglia) che la possibilità di utilizzare questo indice come indice di copertura per determinate query.

Cumulative update package... 8? No... 9!

lbianchi — Wed, 18 Jun 2008 19:12:00 GMT

Solo ieri Davide annunciava il rilascio del Cumulative Update Package 8 che oggi già viene annunciato il 9...

E se succedesse a voi...?

lbianchi — Sun, 15 Jun 2008 17:45:00 GMT

In questi giorni sulla rete si sta discutendo sulla chiusura improvvisa di ITHost.ch.

Per chi non fosse al corrente della cosa, questa società forniva servizi di hosting/housing a molte aziende italiane. Improvvisamente, e senza il minimo preavviso, tutti i siti ospitati sui server di ITHost.ch sono divenuti irraggiungibili (tra questi il sito di Aspitalia.com) in quanto il fornitore di connettività di ITHost ha deciso di chiudere i rubinetti per via delle numerose fatture non pagate da ITHost stessa. I bene informati hanno indagato e sembra che ITHost.ch sia stata dichiarata fallita nel corso del 2006 e ad oggi i responsabili dell'azienda si sono resi irreperibili.

Facile immaginare il "risentimento" di chi ha affidato il proprio dominio ad una società che poteva vantare numerose referenze, sia tecniche che commerciali, ed oggi si trova nell'impossibilità, anche volendo trasferire il proprio dominio altrove, di poter avere i propri dati; in taluni casi anche il dominio risulta essere "bloccato" da ITHost.ch.

A queste persone va ovviamente tutta la mia solidarietà, ma la ragione di questo post non è per esprimere il mio appoggio (peraltro soltanto morale) a chi non può disporre dei propri dati ne tantomeno schierarmi da una parte o dall'altra. Vorrei però che tutti quanti leggeranno questo post si pongano il dubbio se sarebbero stati in grado, qualora l'episodio li avesse riguardati in prima persona, di far sopravvivere la propria azienda o il proprio sito con il minor disagio possibile.

Sicuramente tutti i clienti di ITHost.ch avevano concordato con lo stesso le politiche di backup dei dati ma evidentemente il "buco" è nella conservazione di tali backup che, se fossero stati in possesso dei legittimi proprietari, ciò avrebbe senz'altro mitigato i danni. Quello che è successo avrà sicuramente dei risvolti legali, ma una azienda non può sottostare ai procedimenti legali per entrare (o rientrare) in possesso dei propri dati e del proprio dominio. Effetti simili potevano essere scatenati da cause naturali tipo alluvioni o terremoti e per sopravvivere ad eventi simili, anche se siamo a centinaia o migliaia di chilometri dall'epicentro, è indispensabile implementare per tempo una efficace strategia di disaster recovery.

Bye

Finalmente di nuovo online

lbianchi — Sun, 15 Jun 2008 17:09:00 GMT

Durante questo stop prolungato del sito di UGISS ci sono stati diversi eventi su cui avrei voluto bloggare.

C'è stato il rilascio della RC0 di SQL Server 2008, il down di un fornitore di servizi (ITHOST.ch) che ha coinvolto anche il sito di Aspitalia, si parla sempre di più di "green computing"... argomenti, tutti, sui quali avrei postato qualcosa ma non mancherà certo occasione di recuperare nei prossimi giorni. La cosa più importante è essere tornati "on air"...

Bye

L'evento di oggi

lbianchi — Wed, 14 May 2008 17:03:00 GMT

Oggi si è tenuto l'evento UGISS a Roma. Era il primo evento nella mia città e nonostante le iscrizioni esaurite da tempo erano presenti circa 80 partecipanti. Pochi, sicuramente pochi in considerazione del numero di iscrizioni pervenute e che facevano presagire una partecipazione effettiva oltre le 100 presenze. Non so come leggere questi risultati, probabilmente deludenti, visto che molto spesso mi sento dire che a Roma si organizzano meno eventi di quanti se ne organizzano al nord.

Quello che sicuramente non è stato deludente è l'interesse mostrato dai partecipanti così come il nostro livello di soddisfazione dopo ogni sessione. Hanno iniziato Davide Mauri e Andrea Benedetti con una sessione su "I miti da sfatare in SQL Server"... una sorta di leggende metropolitane di cui ogni tanto circola notizia anche nei newsgroup e che generano false convinzioni che spesso produce errori facilmente evitabili. Quando saranno disponibili le slide, entro pochi giorni, invito tutti a scaricarle e leggerle. Subito dopo Davide ha tenuto una sessione incentrata sulle novità introdotte in SQL Server 2008 per gli sviluppatori mentre subito dopo pranzo io e Gianluca Hotz abbiamo tenuto una sessione analoga dedicata ai database administrator. Il compito di tenere alta l'attenzione dopo i cannelloni mangiati a pranzo non era facile ma ci siamo riusciti facendo sollevare anche un discreto numero di domande da parte dei partecipanti che si sono protratte anche dopo il termine della sessione e per tutto il break che separava la nostra sessione dalla successiva. In chiusura la sessione di Andrea e Francesco De Chirico sulle novità in tema di BI.

Come detto mi aspettavo qualche partecipante in più, ma a parte questo chi c'era credo sia stato estremamente soddisfatto dell'evento in generale...

Bye

Pronti per l'evento UGISS di domani?

lbianchi — Tue, 13 May 2008 06:18:00 GMT

Domani si terrà a Roma un evento UGISS interamente dedicato a SQL Server 2008.

Le iscrizioni per l'evento sono chiuse da tempo... ma sono ancora aperte quelle per la cena di questa sera

Ho scelto Meo Pinelli, facilmente raggiungibile sia per chi pernotta all'Hotel che ospiterà l'evento ma anche per chi si muove con i mezzi pubblici (è a 10 mt dalla fermata della metro Subaugusta). L'appuntamento è per le 21:00; chi ancora non ha dato la sua adesione in questo post del forum può ancora farlo. Oltre a me ci saranno gli altri speaker dell'evento... Gianluca Hotz, Davide Mauri e Andrea Benedetti. Per tutti sarà l'occasione di dare un volto a quelli che finora erano degli anonimi nick...

Bye

Backup compressi in SQL Server 2008

lbianchi — Sun, 04 May 2008 18:17:00 GMT

Come noto a chi ha già esplorato la funzionalità dei backup compressi in SQL Server 2008, è possibile fare un backup di questo tipo utilizzando l'opzione COMPRESSION direttamente nel comando di backup come nell'esempio che segue

BACKUP DATABASE DBM TO DISK = 'C:\DBM.bak' WITH INIT, COMPRESSION

ma è anche possibile impostare l'opzione a livello di istanza con il comando

sp_configure 'backup compression default', 1
RECONFIGURE

dopo aver impartito questo comando tutti i backup verranno eseguiti in maniera compressa salvo esplicitare, nel comando di backup, l'opzione NO_COMPRESSION.
Il primo backup che si esegue in un device determina il fattore di compressione di tutti i backup che potranno essere ospitati dallo stesso device e questo anche se si decide di sovrascrivere il device utilizzando l'opzione INIT; solo l'opzione FORMAT consente di passare da dei backup compressi a dei backup non compressi su un determinato device. Pertanto se viene eseguito il comando

BACKUP DATABASE DBM TO DISK = 'C:\DBM.bak' WITH INIT, COMPRESSION

su un device contenente dei backup non compressi, otterremo l'errore

Msg 3098, Level 16, State 2, Line 1
The backup cannot be performed because 'COMPRESSION' was requested after the media was formatted with an incompatible structure. To append to this media set, either omit 'COMPRESSION' or specify 'NO_COMPRESSION'. Alternatively, you can create a new media set by using WITH FORMAT in your BACKUP statement. If you use WITH FORMAT on an existing media set, all its backup sets will be overwritten.
Msg 3013, Level 16, State 1, Line 1
BACKUP DATABASE is terminating abnormally.

Diversamente se il device contiene dei backup compressi, omettere la clausola COMPRESSION non produce alcun errore ed il backup viene eseguito in maniera compressa a prescindere dal default a livello di istanza. Si tratta di un comportamento che non mi aspettavo e di cui non ho trovato traccia sul BOL ma allo stato attuale, nella CTP 6 (aka CTP Feb ovvero build 10.0.1300) è così...

Domani si parte per Seattle

lbianchi — Fri, 11 Apr 2008 19:33:00 GMT

In queste ore molti degli MVP italiani sono sul volo che da Londra li sta portando a Seattle per l'MVP Summit. Io partirò domani mattina da Roma e arriverò alle 20:12 ora di Seattle (-9 rispetto all'Italia) e mi unirò al resto del gruppo (jet-lag permettendo).

Quella italiana sarà come al solito una spedizione molto nutrita dove avrò l'opportunità di rivedere persone che vedo solo in rare circostanze e partecipare a sessioni tecniche insieme a gente del calibro di Itzik Ben-Gan, Kalen Delaney, Fernando Guerrero, Paul Randal e tanti altri ancora e una sensazione a cui difficilmente mi abituerò... anche se questo è il mio quarto MVP Summit. Quest'anno non ci saranno Lorenzo Benaglia e Andrea Montanari, amici SQLlari di vecchia data, che speravo ci ripensassero in extremis. Non so che summit sarà senza di loro, ma cercherò di far tesoro di tutte le sessioni tecniche ma soprattutto, come consuetudine, saranno giornate dense di party e ricche bevute...

Eseguire un backup senza indici

lbianchi — Thu, 10 Apr 2008 18:48:00 GMT

Sul newsgroup privato degli MVP sto seguendo da qualche giorno il thread che Greg Linwood ha lanciato in merito ad un suo post, segnalato anche da Andrea, sulla possibilità di eseguire backup solo dei dati di un database. Lasciando fuori gli indici si potrebbe risparmiare mediamente un 50% di spazio (e tempo) di informazioni, tutto sommato, per certi versi ridondanti e comunque riproducibili

Da un punto di vista implementativo non è affatto semplice dare seguito alla richiesta e non mi addentro nei dettagli delle motivazioni che alcuni membri del team di sviluppo di SQL Server hanno dato, sempre nel newsgroup privato MVP, per motivare le ragioni per le quali, allo stato attuale, la richiesta è stata chiusa con un "won't fix".

Sicuramente in un'ottica di disaster recovery avrebbe poco senso ripristinare un database privo di indici perchè questi andrebbero sicuramente ricreati o ricostruiti prima di restituire l'operatività del database ed i tempi di ricostruzione vanificherebbero qualunque risparmio di tempo precedente. Certamente l'attività di ricostruzione degli indici può essere posticipata e le "funzionalità vitali" del database, ovvero mettere a disposizione i dati a chi ne faccia richiesta, sarebbero certamente salvaguardate già con il ripristino, minimale, dei soli dati. Tutte le query sarebbero risolte con un table scan, ma l'operatività sarebbe comunque garantita.
Inoltre in quegli scenari dove i tempi di downtime devono tendere a zero, la continuità non può essere affidata ad una seppur eccellente strategia di disaster recovery ma ci saranno soluzioni basate su cluster, log shipping, database mirroring, san in mirror, ecc (e sicuramente 2 o più di queste funzionalità integrate fra loro) in grado di assicurare la continuità del servizio nelle diverse circostanze relegando il restore alle attività più catastrofiche.
La soluzione che prevede il backup dei soli dati potrebbe essere percorribile in quegli ambienti dove non è vitale una rapida ripresa del servizio a seguito di un danno, ma ci si può permettere un fermo più ampio, necessario alle attività di creazione/ricostruzione degli indici. In questo caso avrei comunque il vantaggio di avere un backup di dimensioni contenute che mi farebbe risparmiare sullo spazio disco/nastro necessario per le diverse esigenze di archiviazione insite/offsite. Ragionando nell'ottica "il backup lo faccio quotidianamente, il restore spero di non farlo mai (se non in ambiente di test)" si tratta certamente di una soluzione non solo percorribile ma anche raccomandabile che consente di risparmiare tempo e risorse in occasione dei backup a fronte di un accettabile ritardo nei tempi di ripristino.

In ogni caso in SQL Server 2005 è possibile velocizzare il processo di ripristino dei dati ricorrendo al "piecemeal restore", ovvero un restore parziale in grado di restituire l'operatività del database anche se il processo di ripristino non si è completato. Questo obiettivo possiamo realizzarlo suddividendo il database su diversi filegroup e posizionando i dati su un filegroup e gli indici non clustered su un altro filegroup. Così facendo, in occasione di un ripristino, potremmo accedere al db già immediatamente dopo il ripristino del filegroup contenente i dati e prima che sia terminato il ripristino del filegroup contenente gli indici (il filegroup primary deve essere ripristinato prima di tutti).
Tuttavia questa soluzione richiede la reingegnerizzazione del database affinchè venga strutturato secondo determinate regole e benchè lo spostamento degli indici su un altro filegroup sia una attività che può essere fatta agevolmente (e online) mediante la ricostruzione degli indici stessi, la soluzione appare poco percorribile perchè possa essere utilizzata su vasta scala così come in tutti quegli ambienti, anche di medie dimensioni, dove non esiste una figura di DBA a tempo pieno in grado di pianificare e documentare la strategia di ripristino (last but not least il "partial restore" è presente solo nella versione Enterprise).

Tornando alle ragioni per le quali potrei voler eseguire un backup dei soli dati, tenderei ad escludere anche quelle attività che richiedono il ripristino di un database di produzione nell'ambiente di test perchè un ambiente di collaudo che non sia il più possibile simile a quello di produzione vanificherebbe buona parte della destinazione d'uso specifica di questi ambienti (sempre che non voglia farmi carico della duplice attività restore + reindex). Restano i casi legati ad un eventuale ripristino in ambiente di sviluppo oppure quando il database deve essere inviato ad un fornitore esterno o ad una sede periferica della società, ovvero quei casi in cui ridurre le dimensioni fisiche dei dati da inviare si traduce in un immediato e tangibile vantaggio.

Non sarebbe male, quindi, avere una clausola che ci permetta di eseguire un

BACKUP DATABASE MyDB TO DISK = myDevice WITH DATA_ONLY

Qui nasce, però, uno degli interrogativi da porsi: è l'integrità dei dati? Per poterla garantire devo aver bisogno, almeno, di tutte le primary key e di tutti gli unique constraint che, se non sono di tipo clustered, avrebbero a loro volta bisogno dei rispettivi indici clustered per non perdere il puntamento alle pagine dati. Oppure voglio rinunciare anche a questa garanzia che un DBMS dovrebbe darmi?

Forse tutto sommato utilizzerei veramente poco un backup privo di indici, anche in considerazione del fatto che, in SQL Server 2008, verrà introdotta la possibilità di comprimere dati e backup ottenendo i benefici voluti e da test che ho eseguito la compressione dei dati ed i backup compressi sono "cumulabili" fra loro ed un backup compresso di un database compresso può essere ulteriormente zippato (anche se di pochi punti percentuali) o posizionato su una cartella compressa a livello NTFS riducendolo da 14,6 GB iniziali ad 1,02 GB. Stiamo parlando di una riduzione del 93% che benchè sia maturata in circostanze favorevoli ad un elevato fattore di compressione dei dati, rappresenta un risultato di sicuro interesse...

Bye

Quanti dati sono cambiati rispetto all'ultimo backup full?

lbianchi — Wed, 09 Apr 2008 12:25:00 GMT

Come noto il backup differenziale esegue la copia di tutti gli extent in cui sia avvenuta una modifica dopo l'ultimo backup. L'extent viene copiato per intero anche se la modifica ha riguardato un solo bit in una sola pagina ed a prescindere dal numero di volte in cui qualcosa sia cambiato in una delle pagine di un extent. Rispetto ad un backup del transaction log, che riapplica sequenzialmente tutta la cronologia di modifiche che hanno interessato il database, il backup differenziale esegue quindi una "snapshot" di tutti gli extent modificati e, in fase di restore, tali pagine/extent vanno a rimpiazzare quelle del precedente backup full.

Proprio per questo motivo ci potremmo trovare nella condizione in cui un backup differenziale rappresenti il 70/80% (o anche più) rispetto al backup completo. Il processo di ripristino sarebbe quindi più veloce se anzichè il differenziale avessimo eseguito un ulteriore backup completo e la risposta alla domanda iniziale dovrebbe essere alla base di un controllo di flusso nei nostri job per determinare il tipo di backup da eseguire.

La risposta al quesito può arrivare da questa idea che Paul Randal ha pubblicato nel suo post. Attenzione al fatto che, come Paul ci tiene ad evidenziare, porebbero esserci dei risultati inattesi quando il singolo file di database è superiore a 4 TB...

Non per sminuire quanto fatto da Paul, ci mancherebbe altro... però preferisco di gran lunga una strategia di backup "fissa" dove ogni tipo di backup viene fatto secondo le schedulazioni previste.

Bye

Cluster failover time

lbianchi — Tue, 01 Apr 2008 20:54:00 GMT

Mi è capitato di avere un cluster in cui il tempo necessario al failover era molto elevato e superava il minuto di attesa. Analizzando la situazione ho scoperto che erano le risorse di tipo Virtual Server Name a tardare ad andare online. L'event viewer era praticamente pulito e non erano presenti altri warning o errori che potessero indirizzarmi verso la soluzione finchè, nel cluster log (in C:\Windows\cluster), non mi sono imbattuto in eventi tipo questo

0000065c.00000720::2008/04/01-15:58:02.893 WARN Network Name <Cluster Name>: Failed to register DNS PTR record 113.240.168.192.in-addr.arpa. for host virtualname.dominio.it over adapter 'LAN', status 1460

Alla base di tutto c'erano quindi i problemi di registrazione del record PTR dei virtual server name perchè, per quella subnet, non era stata definita una reverse lookup zone. Creata la reverse lookup zone i tempi di failover sono diventati normali.

MVP... e 6

lbianchi — Tue, 01 Apr 2008 20:39:00 GMT

Poche ore fa ho ricevuto la mail che mi conferma, per il sesto anno consecutivo, l'MVP Award.

Oggi come 6 anni fa l'entusiasmo è rimasto immutato benchè il programma MVP, in questi anni, sia cambiato molto. Per Microsoft l'award è il ringraziamento per l'attività che si svolge nelle community, ma ognuna delle persone che ha posto un quesito in un newsgroup o in un forum, in tutti questi anni, ha lasciato anche lui qualcosa in me. La forza delle community è quella di condividere le esperienze, i problemi e, soprattutto, le soluzioni che altrimenti farebbero sbattere la testa ad ognuno sugli stessi problemi.

Colgo quindi l'occasione per ringraziare tutti quelli che postano nei newsgroup e che condividono quotidianamente, con tutti gli altri, le proprie esperienze.

Bye