 TechNet Magazine March 2007
TechNet Magazine March 2007
MARCH 2007
SQL Server

SINTONIZZATI SU SQL SERVER

In TechNet Magazine questo è il mese di SQL Server. In questo numero verranno illustrate delle metodologie per la messa a punto di SQL Server. Si apprenderà come ottenere degli indici perfettamente puliti in modo che sia possibile eseguire query veloci con SQL Server e avere sempre a portata di mano le informazioni desiderate.

Si vedrà come il clustering di SQL Server garantisca la ridondanza e supporti migliori tempi di attività. Si parlerà anche di alta disponibilità e di come ottenerla. Infine, si forniranno degli strumenti per risolvere in modo definitivo i problemi di partizione delle tabelle.

Amministrazione di Windows

Mark Russinovich torna ancora questo mese con altri consigli sul kernel di Windows Vista.
FUNZIONALITÀ
SQL Server Nuovi strumenti per la diagnosi dell'integrità degli indici

Per ottenere le migliori prestazioni con SQL Server, è necessario tenere sotto controllo l'integrità degli indici con una manutenzione costante. Le nuove viste e funzioni di gestione dinamiche offrono una finestra in SQL Server che aiuta a comprendere meglio il funzionamento degli indici e consente di scoprire i potenziali problemi di prestazione.

Randy Dyess Alta disponibilità per SQL Server

SQL Server 2005 offre un numero di opzioni per migliorare la disponibilità dei database, dalla replica al clustering alla distribuzione dei log. Diamo un'occhiata alle varie opzioni di configurazione di SQL Server e cerchiamo di scoprire quella più adatta ai vari ambienti.

Zach Nichter Semplificare la manutenzione del database con le partizioni delle tabelle

In passato, lavorare con le partizioni e tabelle di grandi dimensioni era un'attività complessa e noiosa, ma con SQL Server 2005 la partizione delle tabelle si è semplificata. Adesso è possibile creare facilmente più partizioni, spostarle, eliminare quelle meno recenti e persino cambiare la modalità di partizione. Ecco come.

Noah Gomez Suggerimenti per il clustering di SQL Server

Un cluster di server fornisce funzionalità di failover, assicurando maggior tempo di attività per le operazioni critiche. Ma per essere efficace, un cluster deve essere implementato correttamente. Ecco alcuni importanti consigli per l'implementazione di un cluster veloce e affidabile.

Tom Moreau, PhD Amministrazione di Windows Il Kernel di Windows Vista: Parte 2

Questo mese continua la nostra discussione approfondita sulle novità del kernel di Windows Vista. In questo numero, vengono esaminati alcuni potenziamenti di Windows Vista relativi alla gestione della memoria oltre a una panoramica su avvio di sistema, arresto del sistema e gestione dell'energia.

Mark Russinovich
COLONNE
Dal redattore

L'angolo trofei

Joshua Trupin Casella degli strumenti

Nuovi prodotti per professionisti IT

Greg Steen Utilità sotto i riflettori

SyncToy

Jay Munro SQL: Domande&Risposte

Ora legale, memoria del server e altro ancora

A cura di Nancy Michell The Cable Guy

Protocollo DHCPv6

Joseph Davies Windows Powershell

Il potere delle variabili

Don Jones 		Hey, Scripting Guy!

Risposte alle domande sull'unità organizzativa...per soli 5 centesimi

Gli Scripting Guys di Microsoft Exchange Queue & A

Log di transazioni, cmdlet, gestione remota e altro ancora

KC Lemson e Nino Bilic Controllo della protezione

Distribuzione di EFS: Parte 2

John Morello Desktop File

Panoramica su PsTools

Wes Miller All'interno di Microsoft.com

Guida introduttiva al mirroring del database

Saleem Hakani Appunti

Dottore in

Matt Hester Windows Confidential

Sembrare intelligenti senza esserlo

Raymond Chen


 SQL Server: Nuovi strumenti per diagnosticare l'integrit&#224; dell'indice
SQL Server Randy Dyess

Nuovi strumenti per diagnosticare l'integrità dell'indice
Panoramica:
  • Frammentazione dell'indice
  • Utilizzo dell'indice
  • Attività operativa dell'indice
Scarica il codice per questo articolo: DyessSQLIndex2007_03.exe (151KB)

Una delle voci di maggior interesse in qualsiasi elenco di controllo per la regolazione delle prestazioni di SQL Server è la modifica degli indici nel database. La capacità di Query Optimizer di SQL Server di fare buon uso degli indici durante l'esecuzione di una query dipende non solo dalla creazione di indici efficaci ma
anche dal buono stato di questi ultimi. Le serie di viste di gestione dinamiche (DMV) e funzioni di gestione dinamiche (DMF) introdotte in SQL Server™ 2005, consentono agli amministratori di database di determinare l'efficacia degli indici e scoprirne i problemi di prestazioni.
DMV e DMF consentono di esaminare un server e di ricavarne informazioni sullo stato, per monitorarne l'integrità e le prestazioni e diagnosticare i problemi dell'istanza server. Gli amministratori di database che hanno familiarità con le versioni precedenti di SQL Server troveranno che queste DMV e DMF sostituiscono i comandi DBCC per l'esecuzione di alcune stored procedure di sistema, operazioni di query di molte tabelle di sistema e la cattura di eventi con SQL Profiler.
Tre funzioni e viste principali, per l'esattezza sys.dm_db_index_physical_stats, sys.dm_db_index_usage_stats, e sys.dm_db_index_operational_stats, sono disponibili per scoprire se gli indici stanno funzionando come previsto. Permettono di riesaminare l'I/O e gli schemi di blocco degli indici e capire se questi siano utilizzati da Query Optimizer in maniera da non produrre conflitti inutili nel database.

Frammentazione dell'indice
La funzione DMF sys.dm_db_index_physical_stats è stata creata per sostituire DBCC SHOWCONTIG e indica la frammentazione dell'indice. A differenza di DBCC SHOWCONTIG, che posiziona un blocco condiviso sulla tabella contenente l'indice, sys.dm_db_index_physical_stats inserisce soltanto un tipo di blocco condiviso (IS) che riduce notevolmente il blocco della tabella durante l'esecuzione della funzione.
Per determinare la frammentazione di un indice quando si utilizza sys.dm_db_index_physical_stats, bisogna esaminare una combinazione di tre colonne nell'output della funzione. La frammentazione logica degli indici (frammentazione extent di heap) può essere determinata osservando il valore riportato nella colonna avg_fragmentation_in_percent. La frammentazione logica è la percentuale di pagine fuori posto nel livello foglia dell'indice, mentre la frammentazione extent è la percentuale di extent fuori posto nel livello foglia dell'indice. Le frammentazioni logica e extent possono influire sulle prestazioni di un indice in quanto richiedono I/O e movimento della testina del disco aggiuntivi, poiché la testina del disco deve cambiare di posizione per leggere le pagine in sequenza. L'ideale è mantenere le frammentazioni logica ed extent più vicine possibile al valore zero.
La frammentazione interna di un indice è la percentuale in cui la pagina è stata riempita. Nonostante l'obiettivo sia un livello di riempimento pagina più elevato possibile, è essenziale equilibrare il livello di riempimento pagina con il numero di inserimenti nelle pagine di indice, per mantenere il numero di divisioni di pagina al minimo.
L'argomento avg_page_space_used_in_percent di sys.dm_db_index_physical_stats deve essere esaminato per determinare il livello di riempimento pagina dell'indice. Per determinare correttamente quanto questo valore sia vicino al 100 percento, bisogna regolare il fillfactor dell'indice e osservare il numero di divisioni di pagina che si sta verificando. A un certo punto, il numero di divisioni di pagina inizierà ad aumentare in maniera notevole e questo indicherà che il fillfactor dell'indice è stato impostato su un valore superiore a quanto opportuno. La regolazione di un fillfactor di indice richiede tempo e verifiche e non deve essere eseguita senza un'opportuna pianificazione. Per gli indici privi di inserimenti casuali nell'indice è possibile impostare il fillfactor su 100, senza doversi preoccupare dell'aumento delle divisioni di pagina.
Per determinare i livelli di frammentazione di tutti gli indici nella tabella AdventureWorks.HumanResources.Employee, è possibile utilizzare un'istruzione come la seguente:
SELECT *
FROM sys.dm_db_index_physical_stats (DB_ID('AdventureWorks')
,OBJECT_ID('HumanResources.Employee')
,NULL
-- NULL to view all indexes;
-- otherwise, input index number
,NULL -- NULL to view all partitions of an index
,'DETAILED') -- We want all information
Utilizzare questa DMF per determinare automaticamente gli indici che devono essere ricostruiti, quelli che devono essere riorganizzati e quelli che non hanno bisogno di manutenzione. Esaminare i valori delle colonne avg_page_space_used_in_percent e avg_fragmentation_in_percent di questa DMF per la frammentazione degli indici che supera la soglia di logica e densità accettate, può aiutare a determinare quale operazione eseguire sull'indice.
In funzione dello stato degli indici, l'esempio della Figura 1 potrebbe non restituire dati nella copia del database di esempio AdventureWorks, tuttavia può essere facilmente adattato ad altri database.
Figure 1 Analisi del livello di riempimento e della frammentazione della pagina (Close Figure 1)
--Reorganize the following indexes in the AdventureWorks database
USE AdventureWorks
GO

SELECT OBJECT_NAME([object_id]) AS 'Table Name',
index_id AS 'Index ID'
FROM sys.dm_db_index_physical_stats (DB_ID('AdventureWorks')
,NULL -- NULL to view all tables
,NULL -- NULL to view all indexes; otherwise, input index number
,NULL -- NULL to view all partitions of an index
,'DETAILED') --We want all information
WHERE ((avg_fragmentation_in_percent > 10
AND avg_fragmentation_in_percent < 15) -- Logical fragmentation
OR (avg_page_space_used_in_percent < 75
AND avg_page_space_used_in_percent > 60)) --Page density
AND page_count > 8 -- We do not want indexes less than 1 extent in size
AND index_id NOT IN (0) --Only clustered and nonclustered indexes

--Rebuild the following indexes in the AdventureWorks database
USE AdventureWorks
GO

SELECT OBJECT_NAME([object_id]) AS 'Table Name',
index_id AS 'Index ID'
FROM sys.dm_db_index_physical_stats (DB_ID('AdventureWorks')
,NULL -- NULL to view all tables
,NULL -- NULL to view all indexes; otherwise, input index number
,NULL -- NULL to view all partitions of an index
,'DETAILED') --We want all information
WHERE ((avg_fragmentation_in_percent > 15) -- Logical fragmentation
OR (avg_page_space_used_in_percent < 60)) --Page density
AND page_count > 8 -- We do not want indexes less than 1 extent in size
AND index_id NOT IN (0) --Only clustered and nonclustered indexes
Sarebbe facile memorizzare i risultati delle query in una variabile di tabella e poi eseguire un ciclo nella variabile di tabella per costruire una stringa dinamica per la corretta istruzione ALTER INDEX (vedere la Figura 2).
Figure 2 Creazione di una stringa dinamica ALTER INDEX (Close Figure 2)
--Rebuild the following indexes in the AdventureWorks database
USE AdventureWorks
GO

--Table to hold results
DECLARE @tablevar TABLE(lngid INT IDENTITY(1,1), objectid INT,
index_id INT)

INSERT INTO @tablevar (objectid, index_id)
SELECT [object_id],index_id
FROM sys.dm_db_index_physical_stats (DB_ID('AdventureWorks')
,NULL -- NULL to view all tables
,NULL -- NULL to view all indexes; otherwise, input index number
,NULL -- NULL to view all partitions of an index
,'DETAILED') --We want all information
WHERE ((avg_fragmentation_in_percent > 15) -- Logical fragmentation
OR (avg_page_space_used_in_percent < 60)) --Page density
AND page_count > 8 -- We do not want indexes less than 1 extent in size
AND index_id NOT IN (0) --Only clustered and nonclustered indexes

SELECT 'ALTER INDEX ' + ind.[name] + ' ON ' + sc.[name] + '.'
+ OBJECT_NAME(objectid) + ' REBUILD'
FROM @tablevar tv
INNER JOIN sys.indexes ind
ON tv.objectid = ind.[object_id]
AND tv.index_id = ind.index_id
INNER JOIN sys.objects ob
ON tv.objectid = ob.[object_id]
INNER JOIN sys.schemas sc
ON sc.schema_id = ob.schema_id

Utilizzo dell'indice
Mentre sys.dm_db_index_physical_stats è una sostituzione potente di DBCC SHOWCONTIG e può aiutare a determinare l'integrità di un indice, spesso è necessario affrontare il problema più complicato di scoprire quali indici siano utili per le query eseguite su una tabella. Spesso gli sviluppatori o gli amministratori di database creano indici su una tabella che pensano sarà utilizzata da Query Optimizer durante l'esecuzione di una query. Nelle versioni precedenti di SQL Server, era molto più complicato sapere se questi indici erano effettivamente utilizzati. Era necessario eliminare l'indice e vedere se la prestazione delle query ne veniva influenzata oppure catturare i progetti di esecuzione delle query e ricercare poi l'utilizzo dell'indice.
Esiste una nuova vista di gestione dinamica, view-sys.dm_db_index_usage_stats, che rende più facile capire in che modo gli indici siano utilizzati da Query Optimizer e quali siano le query eseguite su una tabella. Questa vista può essere esaminata per determinare l'utilità di un indice, consentendo di eliminare quelli non utilizzati da Query Optimizer. Non sarà più necessario preoccuparsi se gli indici stanno sprecando spazio di archiviazione o se la manutenzione di indici inutilizzati stia diminuendo le prestazioni del database.
Esaminando l'output di questa DMV per gli indici con ricerche e scansioni pari a zero, è possibile determinare se un indice è stato utilizzato dall'ultimo avvio di SQL Server. Bisogna tenere presente, tuttavia, che molte DMV e DMF non sono mantenute e si riazzerano una volta che SQL Server viene riavviato. Questo vale specialmente quando si utilizzano DMV o DMF per determinare l'utilizzo di un indice. È possibile semplicemente che l'indice non sia stato utilizzato dall'ultimo riavvio del servizio e che sia necessario solo per query a fine settimana, fine mese o ogni tre mesi.
Per visualizzare tutti gli indici di un'istanza che non sono stati utilizzati dall'ultimo riavvio del servizio SQL Server, è possibile utilizzare l'istruzione seguente:
SELECT DB_NAME(database_id),OBJECT_NAME([object_id])
FROM sys.dm_db_index_usage_stats
WHERE user_seeks = 0
AND user_scans = 0
AND user_lookups = 0
AND system_seeks = 0
AND system_scans = 0
AND system_lookups = 0

Attività operativa dell'indice
La funzione DMF sys.dm_db_index_operational_stats sarà molto utile per comprendere l'attività operativa degli indici. È possibile utilizzarla per osservare le attività di I/O, blocco, latch e del metodo di accesso su ogni indice di un database, per capire come siano utilizzati gli indici e diagnosticare i problemi di blocco degli indici dovuti ad attività estese di I/O o all'esistenza di un'area sensibile nell'indice.
Utilizzare le colonne di attesa latch di questa DMF per stabilire la durata delle operazioni di READ e WRITE per ottenere l'accesso alle risorse dell'indice. Ciò consente di determinare se il sottosistema del disco utilizzato per memorizzare l'indice sia adeguato per le attività di I/O dell'indice. Indica inoltre se il progetto e l'utilizzo dell'indice abbiano introdotto un'area sensibile dove attività estese in una o più pagine di un indice causino un conflitto nei dati contenuti in quelle pagine. Un conflitto di questo tipo conduce spesso a un blocco eccessivo delle operazioni di READ e WRITE in quest'area.
Nella Figura 3 viene illustrato come determinare i modelli di blocco e I/O di tutti gli indici nella tabella AdventureWorks.HumanResources.Employee.
Figure 3 Determinazione dei modelli di blocco e I/O (Close Figure 3)
SELECT page_latch_wait_count --page latch counts
,page_latch_wait_in_ms --page latch wait times
,row_lock_wait_in_ms --row lock wait times
,page_lock_wait_in_ms --page lock wait times
,row_lock_count --row lock counts
,page_lock_count --page lock counts
,page_io_latch_wait_count --I/O wait counts
,page_io_latch_wait_in_ms --I/O wait times
FROM sys.dm_db_index_operational_stats (DB_ID('AdventureWorks')
,OBJECT_ID('HumanResources.Employee')
,NULL -- NULL to view all indexes; otherwise, input index number
,NULL -- NULL to view all partitions of an index
)

Ulteriori informazioni
Le DMV e DMF introdotte in questo articolo hanno molti altri usi oltre a quelli descritti. Consultare gli articoli della Documentazione in linea di SQL Server relativi alle funzioni e viste indicate nell'argomento complementare "Ulteriori riferimenti" per venire a conoscenza della vasta gamma di informazioni che si possono ottenere e analizzare dal loro utilizzo.
Per conoscere altre DMF e DMV di indici che non sono stati trattati in quest'articolo, vedere il post del blog del team di ottimizzazione delle query di SQL Server presso blogs.msdn.com/queryoptteam/570176.aspx.
Ulteriori riferimenti
  • sys.dm_db_index_physical_stats
  • sys.dm_db_index_usage_stats
  • sys.dm_db_index_operational_stats

Randy Dyess è mentore presso Solid Quality Learning ed è specializzato nei sistemi OLTP di SQL Server. Dyess è autore di numerosi libri e articoli dedicati a SQL Server. È fondatore e autore principale di www.TransactSQL.Com e www.Database-Security.Info.
© 2007 Microsoft Corporation e CMP Media, LLC. Tutti i diritti riservati. È vietata la riproduzione completa o parziale senza autorizzazione.


 SQL Server: Disponibilit&#224; elevata per SQL Server
SQL Server Zach Nichter

Disponibilità elevata per SQL Server
Panoramica:
  • Mirroring
  • Snapshot di database
  • Distribuzione dei log
  • Clustering
  • Replica
Scarica il codice per questo articolo: NichterHA2007_03.exe (151KB)

Tutti gli amministratori del database dovrebbero essere a conoscenza del concetto di disponibilità elevata. Tale concetto si rifersce alla capacità di risposta e all'accessibilità del sistema. Talvolta disponibilità elevata significa un tempo di risposta di qualche secondo, mentre altre situazioni richiedono tempi di risposta pari a

frazioni di secondo. In passato ho lavorato come consulente presso un'azienda dove i server Web richiedevano che le query SQL avessero tempi di risposta con sequenza di andata e ritorno di millisecondi. Se la risposta eccedeva tale limite, il sistema di database veniva considerato guasto e il server Web si riconnetteva al primo server di database disponibile.
Oggi gli utenti hanno bisogno di applicazioni sempre più veloci, pertanto sapere come ottenere una disponibilità elevata e tempi di risposta rapidi sarà molto utile per ottenere una pianificazione efficace delle applicazioni dipendenti da dati.
Fortunatamente SQL Server™ 2005 offre numerose opzioni per migliorare la disponibilità, fra cui la replica, il clustering, il mirroring del database, gli snapshot di database e la distribuzione dei log. Esamineremo queste funzionalità e cercheremo di scoprire come decidere quali siano le più appropriate all'ambiente in cui si lavora. Iniziamo con la Figura 1, in cui sono descritte le opzioni di disponibilità in SQL Server 2005.
Figure 1 Opzioni di disponibilità elevata (Close Figure 1)

Attributi della tecnologia | Replica | Mirroring del database | Clustering | Snapshot di database | Distribuzione dei log
Opzione di disponibilità elevata |  |  |  |  |
Tollera requisiti di transazione elevati |  |  |  |  |
Disponibilità dei dati in tempo reale |  |  |  |  |
L'immagine dei dati è di sola lettura |  |  |  |  |
Configurazione hardware unica |  |  |  |  |
Basso costo |  |  |  |  |
Fornisce il ripristino dei dati |  |  |  |  |
Failover automatico |  |  |  |  |
Implementazione e gestione potenzialmente complicate |  |  |  |  |
Possibili considerazioni sulle prestazioni |  |  |  |  |

Definizione di disponibilità elevata
Uno dei primi obbiettivi quando si progetta un'applicazione di disponibilità elevata è definire che cosa ciò significhi in ogni ambiente specifico. Per alcune organizzazioni, disponibilità elevata significa che l'hardware ridondante deve essere pari all'hardware di produzione e sia i dati sia l'hardware devono offrire un tempo di attività e una disponibilità pari al 99,995 percento o superiore. Altre organizzazioni possono richiedere tale disponibilità elevata solo per i dati ed essere meno interessate alla prestazione del livello di produzione qualora fosse necessario un failover. Essere in grado di definire la disponibilità elevata è importante per determinare la corretta soluzione in ogni situazione.
Inoltre, è necessario identificare i tipi di interruzione di corrente che si possono verificare e indicare in che modo influiscano sui propri contratti di servizio. Le interruzioni di corrente che possono influire sulla disponibilità includono le prestazioni pianificate, non pianificate e a livello ridotto.
Un'interruzione di corrente pianificata è, di solito, una finestra di manutenzione pianificata, di cui gli utenti del sistema sono informati anticipatamente. Un'interruzione di corrente non pianificata è, di solito, il risultato di un'operazione hardware o software non riuscita che rende i dati inaccessibili. Anche un livello di prestazione ridotto può causare interruzioni di corrente e viene spesso misurato in tempo di risposta dell'utente finale. Quest'ultimo viene, di solito, concordato in anticipato dall'azienda o dall'organizzazione IT in alcuni tipi di contratti di servizio.
Oltre a identificare le cause potenziali delle interruzioni di corrente, è necessario determinare il livello di attività dei propri dati e stabilire se debbano sempre essere in linea o se talvolta possano essere su supporto rimovibile o non in linea. Bisogna decidere inoltre se l'opzione di disponibilità debba trovarsi nella stessa posizione geografica o in una posizione remota. Probabilmente anche le limitazioni di budget devono essere tenute presenti nel prendere questa decisione. E ora esaminiamo ogni singola opzione di disponibilità.

Mirroring del database
Prima di analizzare il mirroring del database, è opportuno definirne la terminologia.
Il server principale è il server di produzione primario contenente il database che invia continuamente i log delle transazioni al server e al database di mirroring.
Il server mirror è il server secondario che ospita la copia di backup del database. La copia mirror viene sempre sincronizzata con il database principale.
Il ruolo indica lo scopo di quel particolare server, se sia primario o di copia.
Il server di controllo del mirroring è l'istanza che monitora il server principale e il server mirror durante l'esecuzione delle loro attività e può iniziare un failover automatico.
Il server partner può essere sia il server principale sia il server mirror.
In un ambiente tipico, il database principale sarà sottoposto a backup sull'istanza principale e il backup sarà ripristinato sull'istanza di mirroring (vedere la Figura 2). Una volta ripristinato il database, bisogna impostare il mirroring sul server principale utilizzando la finestra delle proprietà del database principale in SQL Server Management Studio (SMS) oppure gli script T-SQL.
Figura 2 Architettura del mirroring del database
Figura 2 Architettura del mirroring del database (Fare clic sull'immagine per ridurla)
Figura 2 Architettura del mirroring del database
Figura 2 Architettura del mirroring del database (Fare clic sull'immagine per ingrandirla)
Dopo che è stato configurato il mirroring e si è stabilita la sessione di mirroring, il database principale e il database mirror si sincronizzano. Il database principale invierà quindi il log delle transazioni degli eventi verificatisi dall'ultima applicazione del backup al database mirror. Il server mirror riceverà il log e tenterà di applicarlo il più rapidamente possibile. Se si utilizza SQL Server 2005 Enterprise Edition, questo processo è a thread multipli; altrimenti si tratterà di un'operazione a thread singolo. Non appena questi log vengono applicati al server mirror, i database sono considerati sincronizzati e rimarranno sincronizzati finché la sessione mirror non sarà interrotta.
Man mano che i client eseguono nuove transazioni, il server principale esegue le transazioni a fronte del database principale e invia i record dei log delle transazioni dal database principale al log di ripristino del database mirror, o code del log, dove vengono prelevati e applicati al database mirror. Una volta che la transazione è stata applicata e ne è stato eseguito il commit al database mirror, viene inviata una risposta al server principale, che annuncia che è stato eseguito il commit della transazione al server mirror. Il server principale non confermerà alcuna nuova transazione che potrebbe arrivare al sistema finché non sia stata ricevuta la conferma dal server mirror.
In caso di errore, il mirror può iniziare una procedura di errore automatica e il server di controllo del mirroring supporta il processo determinando se il database principale sia disponibile o meno. In caso di errore, il problema sul server che adesso è diventato il partner di mirroring deve essere risolto prima che possa diventare nuovamente il partner primario. Dopo che sono stati risolti i problemi sul server mirror partner, viene iniziato lo spostamento sul server mirror partner e i database vengono nuovamente sincronizzati. Una volta sincronizzati, la sessione di mirroring può ricominciare.
Questa particolare modalità di mirroring è una modalità di alta protezione che fornisce operazioni per transazioni sincrone attivando la protezione delle transazioni, ma non richiede un server di controllo del mirroring perché non utilizza il failover automatico, in quanto tutti i failover sono inziati manualmente. Esiste un altro tipo di modalità di mirroring che fornisce disponibilità elevata alle operazioni di transazioni sincrone. Non solo richiede l'attivazione della protezione delle transazioni, ma anche l'utilizzo di un server di controllo del mirroring per il failover automatico in caso di errore.
La terza e ultima modalità di mirroring disponibile è la prestazione elevata. Richiede che la protezione delle transazioni sia disattivata per consentire il supporto asincrono delle operazioni che, a sua volta, permette di eseguire il commit delle transazioni sul partner principale senza dover aspettare la scrittura del record della transazione sul server mirror. La modalità a prestazione elevata non richiede un server di controllo del mirroring nella configurazione.
Notare che il mirroring richiede la stessa edizione di SQL Server sul server primario e sul mirror ma non sul server di controllo del mirroring, che può essere l'edizione SQL Server Express. Inoltre è importante che il database principale sia in modalità di ripristino completa.
ADO.NET 2.0 è integrato con SQL Server 2005: supporta il mirroring del database e fornisce un failover trasparente per l'applicazione sull'ambiente di mirroring. Questo offre all'applicazione ADO.NET la funzionalità di failover automatico senza alcuna codificazione o configurazione aggiuntiva qualora non sia possibile stabilire una connessione con il database principale. La configurazione è facile, basta specificare un utente comune tra i due ambienti e il partner di failover nella stringa di connessione. Segue un esempio di una stringa di connessione ADO.NET con l'identificazione del partner di failover per l'ambiente di database mirror:
"Provider=SQLNCLI.1;Data Source=MirrorDB;Failover Partner=SQL03;
 Initial Catalog=AdventureWorks;
Persist Security Info=True;User ID=TestUser; Password=TestPswd; Pooling=True;
Connect Timeout=5;Application Name=ADOMirrorTest"
Il mirroring del database può essere la scelta adatta per un'azienda, in base ai requisti delle sue applicazioni e dei suoi dati, tuttavia, è necessario considerare altri punti per poter ottenere un'ottima prestazione. Ad esempio, qual è la frequenza delle transazioni del sistema o il volume della modifica dati? Quando si considera il mirroring del database, è essenziale determinare se la velocità della larghezza di banda e della rete siano sufficienti per gestire il volume dei dati e la velocità di elaborazione delle transazioni. Bisogna inoltre considerare la saturazione del collegamento. Ciò è importante soprattutto se il server mirror si trova in una posizione geografica diversa. Il controllo anticipato del sistema è cruciale nel determinare se esistano limitazioni ambientali che possano impedire un funzionamento efficiente del mirroring.
Il mirroring del database può essere un'opzione particolarmente adatta se si desidera mantenere bassi i costi. Infatti, l'architettura del mirroring del database non richiede la condivisione dei dischi e nessuna abilità avanzata o specializzata per eseguire l'ambiente. E, a differenza del clustering, il mirroring del database non richiede che i due partner dispongano dello stesso hardware. Inoltre, è semplice implementare il mirroring utilizzando la procedura di installazione guidata presente sulla scheda di mirroring nella finestra delle proprietà del database (vedere la Figura 3). Consiglio oltretutto di leggere il white paper "Database Mirroring Best Practices and Performance Considerations" (in inglese) all'indirizzo go.microsoft.com/fwlink/?LinkId=80897 per ulteriori utili informazioni.
Figura 3 Installazione guidata del mirroring
Figura 3 Installazione guidata del mirroring (Fare clic sull'immagine per ridurla)
Figura 3 Installazione guidata del mirroring
Figura 3 Installazione guidata del mirroring (Fare clic sull'immagine per ingrandirla)

Snapshot di database
Gli snapshot di database sono una nuova tecnologia offerta in SQL Server 2005 Enterprise Edition, ma non sono considerati un'opzione a disponibilità elevata. Gli snapshot di database svolgono la funzione di opzione di ripristino o di possibile reporting quando sono utilizzati con altre tecnologie. Uno snapshot è semplicemente la visualizzazione in sola lettura di un database in un particolare momento.
Lo snapshot viene creato utilizzando il comando CREATE DATABASE nel modo seguente:
CREATE DATABASE SnapDB_20061028_2030 ON
(NAME = SnapDB_Data, FILENAME =
    'C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data\SnapDB_20061028_2030.snp')
AS SNAPSHOT OF SnapDB;
GO
quando viene creato, lo snapshot del database utilizza uno o più file chiamati file sparse, come farebbe un database tipico. Questi file sparse sono essenzialmente luoghi virtuali di transito che inizialmente non utilizzano dati. Sono utilizzati per contenere dati solo se questi vengono modificati o cancellati nel database di origine. I dati sono scritti nei file sparse una pagina alla volta e lo snapshot del database visualizza soltanto i dati che sono stati modificati al momento della cattura dello snapshot stesso. Il resto dei dati proviene dalle pagine di dati del database di origine.
I file snapshot di database sono allocati alla dimensione del database quando lo snapshot è stato catturato. La dimensione allocata non indica l'entità dei dati effettivamente contenuta. Per ottenere tale informazione, bisogna eseguire un'istruzione T-SQL come la seguente:
SELECT *
FROM fn_virtualfilestats(DB_ID(N'SnapDB_20061028_
    2030'), 1);
GO

I dati sono memorizzati nei file sparse e nel database di origine in modo tale che quando si accede a uno snapshot di database, le pagine di dati nei file dati del database originali e le pagine dei dati nei file sparse dello snapshot vengono recuperati. Gli snapshot possono esistere soltanto sul server con il database di origine dello snapshot, a causa della necessità di condividere le pagine di dati. Poiché questa architettura non risolve le operazioni di I/O sul database di origine, gli snapshot non sono un'opzione di reporting valida in quanto non rappresentano lo stato reale del database.
Consideriamo uno scenario in cui il mirroring del database sia utilizzato insieme agli snapshot. Ciò consente ai dati di reporting, al mirroring e agli snapshot di database di essere fisicamente separati dal database principale. Lo snapshot di database viene pianificato utilizzando SQL Server Agent e uno script personalizzato per fornire nuovi snapshot ad intervalli regolari. Lo script di esempio nella Figura 4 mostra la stored procedure utilizzata per realizzare questa attività. È progettato per essere utilizzato all'interno di un processo per gestire la creazione e l'eliminazione di snapshot per un database particolare nell'ambiente dell'utente. Ciò consente una soluzione di reporting accettabile in quanto i dati di reporting sarebbero isolati dai dati di produzione.
Figure 4 Stored procedure per la pianificazione degli snapshot (Close Figure 4)
use msdb;
GO
set nocount on
GO

CREATE PROCEDURE usp_snaprefresh
     @database    sysname = NULL    --name of the database to snapshot
    ,@keepsnap    int        = 24   --# of hours to keep a snapshot
                                    --after it was created
                                    --use a value of '0' to keep all
                                    --existing snapshots
    ,@fileloc    sysname            --location for snapshot
        = 'C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data\'
AS

DECLARE
     @dt            datetime        ,@cnt          int
    ,@databaseid    int             ,@snap         sysname
    ,@sql           nvarchar(1000)  ,@yy           varchar(4)
    ,@mm            varchar(2)      ,@dd           varchar(2)
    ,@h             varchar(2)      ,@m            varchar(2)
    ,@lname         sysname         ,@pname        sysname
    ,@file          sysname         ,@pos1         int
    ,@pos2          int

-- initialize variables
SELECT
     @dt = getdate()
    ,@cnt = 0, @pos1 = 0, @pos2 = 0
    ,@databaseid = db_id(@database)

-- check if valid database was provided
IF @databaseid IS NULL
BEGIN
    RAISERROR ('Missing database name. Rerun the procedure specifying a
       valid database name.',16,1)
    RETURN (0)
END

--determine if snapshots should be kept
IF @keepsnap <> 0
BEGIN
    -- determine if other snapshots exist for this server older than @
    -- keepsnap value hrs
    SELECT ROW_NUMBER() OVER(ORDER BY name DESC) AS [RowNum],
        name INTO #t1
    FROM master.sys.databases
    WHERE source_database_id = @databaseid
        AND create_date < dateadd(hh,-(@keepsnap),getdate())

    IF (SELECT max(RowNum) FROM #t1 where name is not null) > 0
    BEGIN
        WHILE @cnt <= (SELECT max(RowNum) FROM #t1)
        BEGIN
            SELECT @snap = name FROM #t1 WHERE RowNum = @cnt

            PRINT 'Dropping snapshot ''' + @snap + ''''

            SET @sql = 'DROP DATABASE ' + @snap

            EXEC(@sql)
            SELECT @cnt = @cnt + 1
        END
    END
END

-- break apart point in time date time information for file name
SELECT @yy = convert(varchar(4),year(@dt)),@mm = convert(varchar(2),
   month(@dt))
    ,@dd = convert(varchar(2), day(@dt)),@h = convert(varchar(2),
         datepart(hh,@dt))
    ,@m = convert(varchar(2), datepart(mi,@dt))

-- piece together the database snapshot name and the file name
SELECT @file = @database + '_' + @yy + @mm + @dd + '_' + @h + @m

-- identify logical file name of primary data file
SET @sql = 'SELECT name INTO tempdb..t1
FROM ' + @database + '.sys.database_files
WHERE file_id = 1'

EXEC(@sql)

--setting logical filename for the snap
SELECT @lname = name FROM tempdb..t1

-- making sure the file location ends with '\'
IF substring(@fileloc, len(@fileloc), 1) <> '\'
BEGIN
    SET @fileloc = @fileloc + '\'
END

-- build sql statement to be run
SET @sql = N'CREATE DATABASE ' + @file + ' ON
(NAME = ' + @lname + ', FILENAME = ''' + @fileloc + @file + '.snp'')
AS SNAPSHOT OF ' + @database

EXEC(@sql)

-- cleanup
DROP TABLE tempdb..t1;
GO
Bisogna ricordare tuttavia che gli snapshot di database sono considerati temporanei in quanto non possono essere sottoposti a backup e non possono esistere senza il database di origine. Se un file sparse rimane senza spazio, lo snapshot sarà considerato corrotto e dovrà essere eliminato.
Inoltre con gli snapshot di database il ivello di prestazione del sistema può essere ridotto durante le operazioni di modifica dei dati sul database di origine, in quanto le pagine di dati vengono scritte per ogni snapshot nei file sparse dai file di dati del database di origine. Ciò a sua volta moltiplica il numero di scritture per il numero di snapshot contenuto nel database.
Le autorizzazioni di lettura sono definite dal database di origine al punto dello snapshot e non possono essere modificate. Lo snapshot deve risiedere nella stessa istanza del database di origine poiché questi condividono le pagine di dati e la cache buffer.
È possibile considerare di utilizzare snapshot come soluzione di reporting solo se al contempo si utilizza il mirroring; altrimenti non ci sarà alcun miglioramento della prestazione per l'ambiente. Gli snapshot di database sono forse il modo più rapido per proteggere i dati prima che un'operazione ambigua sia eseguita sul sistema. Il database può essere riportato allo stato dello snapshot oppure i dati possono essere estratti dallo snapshot e sostituire i dati nel database di origine.
Sarà necessario determinare una denominazione standard per i database snapshot. Lo standard che utilizzo è originaldatabasename_date_time.snp. Specifica prima il database di origine, poi il giorno e l'ora (nel formato a 24 ore) in cui lo snapshot è stato catturato.

Distribuzione dei log
La distribuzione dei log è un'opzione di disponibilità elevata limitata che utilizza il backup e il ripristino per eseguire una soluzione a basso costo. La distribuzione dei log approfitta dei backup dei log delle transazioni a intervalli pianificati per mantenere aggiornato un database secondario.
La distribuzione dei log in SQL Server 2005 utilizza procedure guidate per seguire i processi di installazione, pianificazione, inizializzazione e monitoraggio (vedere la Figura 5). Il processo è semplice e può essere completato in pochi minuti.
Figura 5 Installazione guidata della distribuzione dei log
Figura 5 Installazione guidata della distribuzione dei log (Fare clic sull'immagine per ridurla)
Figura 5 Installazione guidata della distribuzione dei log
Figura 5 Installazione guidata della distribuzione dei log (Fare clic sull'immagine per ingrandirla)

Dopo che è stato identificato il database primario, viene creata una pianificazione e viene determinata l'età del file per i file di backup. Quindi è necessario stabilire le condivisioni file per i file di backup. Dopo avere impostato le condivisioni file, deve essere stabilito il percorso di file del database secondario e il database deve essere inizializzato completando un ripristino del database primario. Infine, bisogna impostare le pianificazioni per le copie dei file di backup e i ripristini dei backup dei log delle transazioni insieme a tutti gli avvisi o i ritardi necessari per ogni passaggio.
Una volta completata l'impostazione, la distribuzione dei log esegue periodicamente il back up del log delle transazioni di un database in un percorso di rete condiviso. Una volta che i file sono stati inviati al percorso condivisio, il backup viene applicato al database secondario in maniera pianificata.
La distribuzione dei log funziona bene in situazioni diverse in quanto è molto semplice. È una buona soluzione per una disponibilità elevata poco costosa e può gestire un sistema di transazione elevato. Il database secondario impiegato nella distribuzione dei log può essere utilizzato in modalità di sola lettura, cosa utile per un database di reporting. La distribuzione dei log richiede un overhead minimo ma necessita di criteri di avviso per la gestione degli errori.
Altri due punti da considerare se si intende adottare la distribuzione dei log nel proprio ambiente sono l'installazione e la gestione semplici e il fatto che non richiede alcuna abilità particolare. Tuttavia la distribuzione dei log non è una soluzione di elevata disponibilità in tempo reale, benché a questo fine possa essere combinata con il mirroring del database. È limitata da pianificazioni e da operazioni quali backup, copie di file e ripristini. Richiede inoltre un failover manuale. Per queste ragioni, la distribuzione dei log fornisce una soluzione semplice per ambienti che non abbiano esigenze legate al tempo.

Clustering di SQL Server
Le attività di clustering del server a livello di sistema operativo comportano hardware duplicato e risorse disco condivise per consentire l'accesso del cluster. Il clustering potrebbe forse essere l'opzione meno intrusiva per gli utenti finali, ma è la più costosa. Richiede almeno il doppio dell'hardware necessario per eseguire un'istanza cluster.
Il clustering è un argomento piuttosto complesso, pertanto, invece di esplorarne tutti i dettagli adesso, ne fornirò una panoramica generale. Il clustering richiede due o più server, in cui devono installate le stesse versioni di Windows® 2000 Advanced Edition o Datacenter Edition o di Windows Server® 2003 Enterprise Edition o Datacenter Edition. Richiede inoltre l'installazione di Microsoft® Cluster Services (MSCS) per gestire la proprietà delle risorse condivise tra i server e gestire gli indirizzi IP, i dischi condivisi e i nomi delle reti. Il clustering richiede inoltre una risorsa del disco condivisa, di solito sotto forma di rete di archiviazione (SAN) o di periferica di archiviazione SCSI collegata.
Anche un'istanza SQL Server è considerata una risorsa e le due edizioni Standard ed Enterprise di SQL Server 2005 possono essere installate in una configurazione cluster. Per un elenco delle funzionalità supportate da entrambe le edizioni di SQL Server 2005, vedere "Feature Comparison Chart for SQL Server 2005" (in inglese) (microsoft.com/sql/prodinfo/features/compare-features.mspx).
Una volta stabilite le risorse sul cluster, il nodo secondario del cluster mantiene una comunicazione regolare con il nodo primario del cluster attraverso una pulsazione stabilita su una rete privata tra i due nodi del cluster. L'hearbeat è un punto di controllo dell'intervallo, misurato per stabilire se il server primario ha generato un errore.
Nel caso di errore del server primario, le risorse vengono spostate sul nodo secondario mantenendo invariato lo stato del server logico. Questo consente ai client di continuare a lavorare con solo una pausa di interazione. L'intero processo di failover può richiedere da 5 a 30 secondi o più in alcuni casi, in funzione dell'hardware, del software e dei componenti di rete coinvolti nel cluster.
Il clustering può rivelarsi una tecnologia costosa e complicata e richiedere abilità specializzate per la risoluzione degli errori del sistema; offre, tuttavia, il failover più facile fra tutte le opzioni di failover automatico disponibili agli utenti finali. Ogni applicazione è diversa e alcune potrebbero non essere abilitate al clustering, o compatibili. Nella peggiore delle ipotesi, può essere necessaria la riconnessione dell'applicazione.

Replica
La replica di SQL Server 2005 può essere utilizzata anche in architetture a disponibilità elevata. Sono disponibili quattro tipi di replica: snapshot, transazionale, peer-to-peer e unione (merge). Peer-to-peer è in realtà una forma di replica transazionale che pertanto non verrà trattata in questa sede.
La replica permette di disporre di un sito e di un database secondari per disponibilità elevata, con funzionalità esattamente uguali a quelle del database primario. Ciò può essere conseguito utilizzando la replica di tipo merge, che gestisce le transazioni dei database primario e secondario e quindi incorpora le modifiche di entrambi i database nei due database. Si potrà ben immaginare come in questa configurazione sia necessaria una procedura di risoluzione dei conflitti.
La replica transazionale è molto simile nella progettazione logica al mirroring del database. Le transazioni applicate al database primario vengono distribuite nel database secondario per assicurare la coerenza dell'ambiente. Una volta arrivate, le transazioni vengono applicate al database secondario, che quindi attende l'applicazione della successiva transazione nel sistema.
La replica snapshot è molto simile alla distribuzione dei log in quanto entrambe sono eseguite a intervalli pianificati e aggiornano il database secondario in modifiche di massa piuttosto che applicare ogni transazione a entrambi i sistemi man mano che ne viene eseguito il commit. Le due tecnologie sono utilizzate pressocché nello stesso modo.
La replica richiede conoscenze specializzate e questo potrebbe essere uno svantaggio in ambienti che non dispongono di un amministratore del database (DBA) dedicato. La replica può rivelarsi relativamente complicata nella risoluzione dei problemi e richiede una progettazione più complessa se deve essere utilizzata come opzione di disponibilità elevata.
La replica può soddisfare in maniera appropriata i requisiti per una soluzione di disponibilità elevata. Questa tecnologia offre quanto può offrire il mirroring del database a livello di record utilizzando la replica transazionale, senza però fornire l'opzione di failover automatico. Supponendo che l'utente disponga di risorse sufficienti e di un pizzico di creatività, creare lo script per una soluzione di failover automatico non dovrebbe rivelarsi troppo complicato.
A differenza del mirroring del database, i database di origine e di destinazione sono entrambi completamente accessibili dalle applicazioni client. La replica fornisce la stessa funzionalità della distribuzione dei log con l'aggiunta della replica degli snapshot.
Bisogna ricordare comunque che la tecnologia della replica è comprovata e ben documentata. Utilizzare la replica per una soluzione di disponibilità elevata comporta alcune limitazioni e le prestazioni possono non essere perfetta, ma solo nella stessa misura del mirroring del database. Qualsiasi soluzione di disponibilità elevata progettata con la replica avrà probabilmente un'architettura più complicata da gestire; non necessariamente più avanzata ma indubbiamente più complessa. Inoltre, uno dei maggiori ostacoli da considerare è che se la struttura del database viene modificata o se si desidera aggiungere una tabella da replicare, è necessario scomporre e ridefinire la pubblicazione affinché le modifiche siano integrate su entrambi i database.

Conclusioni
Si può vedere adesso come creare una soluzione di disponibilità elevata per il proprio ambiente richieda una dose di creatività. Ogni tecnologia SQL Server 2005 di disponibilità elevata possiede punti di forza e punti deboli e ognuna si presta a situazioni diverse.
La distribuzione dei log, la replica degli snapshot e anche il mirroring del database in modalità di prestazione elevata sono utili quando si separa geograficamente un database Web primario dagli ambienti database secondari (in particolare se non richiedono che i dati secondari siano disponibili in tempo reale).
Se, d'altra parte, esiste un requisito secondario di database per dati in tempo reale, allora la replica transazionale o il mirroring del database possono sopportare il carico se la frequenza delle transazioni sul server primario è bassa e il collegamento tra i due siti di ambiente è veloce e non saturato.
Bisogna inoltre considerare in che misura ci si sente a proprio agio con queste tecnologie. Se già si possiede esperienza in alcune delle tecnologie suddette, non ci dovrebbero essere problemi. Se si è manager ma non si dispone di un amministratore del database dedicato, è meglio evitare le tecnologie più complicate come la replica, che presentano molte parti in movimento e una risoluzione dei problemi complicata. Non è escluso considerare di assumere un consulente esperto SQL Server per ottenere assistenza nel progettare, implementare e forse anche formare lo staff nella gestione di una nuova disponibilità elevata che si adatti al proprio ambiente.
Se nella propria organizzazione la disponibilità elevata richiede che i dati siano disponibili in una percentuale di tempo elevata e il tempo di inattività dei dati è un fatto molto serio, il clustering potrebbe essere l'opzione ideale.
In conclusione, per implementare la disponibilità elevata SQL Server 2005 fornisce numerose nuove opzioni, che vengono adattate per servire tipi diversi di ambienti. Una singola opzione di disponibilità potrebbe adattarsi alle proprie esigenze o si potrebbe scegliere di approfittare di una combinazione di tecnologie, ma è oramai chiaro, sono disponibili molte opzioni.

Zach Nichter è un professionista SQL Server con oltre 10 anni di esperienza. Ha ricoperto ruoli di supporto SQL Server diversi, fra cui amministratore del database (DBA), responsabile del team, manager e consulente. Attualmente Zach è architetto DBA presso Levi Strauss & Co. e si dedica in particolare a prestazioni, monitoraggio, architettura e altre atività strategiche di SQL Server.


 SQL Server: Manutenzione del database semplificata con la partizione delle tabelle
SQL Server Noah Gomez

Manutenzione del database semplificata con la partizione delle tabelle
Panoramica:
  • Creazione di tabelle partizionate
  • Aggiunta e unione di partizioni
  • Creazione e gestione di indici partizionati
Scarica il codice per questo articolo: GomezPartitioning2007_03.exe (156KB)

In passato, gli amministratori di database che dovevano gestire tabelle contenenti milioni di righe di dati erano costretti a creare più tabelle. Una volta partizionate queste tabelle, l'amministratore doveva unirle
durante l'esecuzione di molte query. Unire le partizioni significava creare una vista partizionata oppure un wrapper per stored procedure in grado di intuire la posizione dei dati e di eseguire un'altra stored procedure solo per le partizioni necessarie in modo da restituire il dataset.
Sebbene questi metodi funzionassero, erano comunque molto complessi. L'amministrazione di tabelle multiple e dei relativi indici, così come i metodi utilizzati per cercare di tenerle insieme, creavano spesso problemi in termini di gestione. Inoltre, la creazione di tabelle multiple per partizionare i dati determinava un notevole livello di rigidità, dal momento che le stored procedure, le operazioni di manutenzione, le operazioni DTS (Data Transformation Services), il codice applicativo e gli altri processi dovevano riconoscere la natura del partizionamento. Quindi, per consentire all'amministratore di aggiungere o eliminare queste partizioni senza modificare il proprio codice, questi elementi venivano di regola creati in maniera non dinamica, pertanto erano inefficienti.
Le edizioni Enterprise e Developer di SQL Server™ 2005 consentono di dividere grandi quantità di dati contenuti in un'unica tabella in diverse partizioni più piccole che possono essere gestite in maniera più efficace. La capacità di creare segmenti di dati accessibili da un unico punto di entrata riduce molti dei problemi di amministrazione riscontrati con la procedura precedente. L'utilizzo di un unico punto di entrata (il nome della tabella o dell'indice) nasconde i segmenti dei dati multipli del codice applicativo e consente all'amministratore o allo sviluppatore di modificare le partizioni in caso di necessità senza dover modificare il codice di base.
In breve, è possibile creare più partizioni, spostarle, eliminare le meno recenti e perfino modificare il modo in cui i dati vengono partizionati senza dover modificare il codice applicativo. Il codice applicativo continua semplicemente a richiamare lo stesso nome di base di tabella o di indice. Nel frattempo, è possibile ridurre la quantità di dati contenuti nei singoli indici, diminuendo a sua volta i tempi di gestione di questi indici ed è possibile aumentare la velocità di caricamento dei dati in partizioni vuote.
Dal punto di vista tecnico, ogni tabella di SQL Server 2005 è partizionata, vale a dire dispone di almeno una partizione. In pratica, SQL Server 2005 consente agli amministratori di database di creare partizioni aggiuntive su ogni tabella. Le partizioni delle tabelle e degli indici sono partizioni fisse e a livello di riga (non è consentito il partizionamento per colonne) che consentono un solo punto di entrata (il nome della tabella o dell'indice) senza che il codice applicativo debba riconoscere il numero di partizioni oltre il punto di entrata. Le partizioni possono esistere sia sulla tabella di base che sugli indici associati alla tabella stessa.

Creazione di tabelle partizionate
Per creare una tabella in grado di crescere oltre la singola partizione predefinita, si utilizzano le funzioni e gli schemi di partizionamento. Questi oggetti consentono di dividere i dati in segmenti specifici e di controllare la posizione di questi dati in base al relativo progetto di archiviazione. Ad esempio, è possibile organizzare i dati su matrici di unità multiple in base alla relativa data di creazione o ad altri differenziatori comuni. Una tabella può essere partizionata in base a una colonna della tabella e ogni partizione deve contenere dati che non possono essere collocati in altre partizioni.
Funzioni di partizione Quando si effettua la partizione di una tabella, è necessario prima decidere in quale modo i dati verranno divisi in segmenti diversi. Una funzione di partizionamento viene utilizzata per associare le singole righe di dati in diverse partizioni. Queste singole righe di dati possono essere associate a qualunque tipo di colonna tranne text, ntext, image, xml, timestamp, varchar(max), nvarchar(max), varbinary(max), tipi di dati alias o tipi CLR definiti dall'utente. Comunque, la funzione di partizionamento deve consentire di collocare una riga di dati in un'unica partizione di tabelle: una riga di dati non può appartenere a più partizioni allo stesso tempo.
Per effettuare la partizione di una tabella, è necessario creare la colonna di partizionamento all'interno della tabella interessata. Questa colonna di partizionamento può esistere nello schema della tabella quando questa è già stata creata oppure è possibile modificare la tabella e aggiungere la colonna in seguito. La colonna può accettare i valori NULL ma tutte le righe contenenti questi valori saranno collocate per impostazione predefinita nella partizione più a sinistra della tabella. Per evitare che ciò accada, è necessario specificare che i valori NULL vengano collocati nella partizione più a destra della tabella durante la creazione della funzione di partizionamento. L'uso della partizione sinistra o destra è un'importante decisione perché si andrà a modificare lo schema di partizionamento e ad aggiungere più partizioni oppure a eliminare quelle esistenti.
Quando si crea una funzione di partizionamento, è possibile scegliere tra LEFT (sinistra) o RIGHT (destra). Una partizione LETF o RIGHT stabilirà il luogo in cui verrà posizionato l'intervallo di valori nello schema di partizionamento. Le partizioni LEFT (impostazione predefinita) includono l'intervallo di valori all'interno della partizione mentre le partizioni RIGHT collocano questo intervallo nella partizione successiva.
Per capire meglio questo concetto, verranno mostrate di seguito una partizione LEFT e una RIGHT:
CREATE PARTITION FUNCTION Left_Partition (int) AS RANGE LEFT
FOR VALUES (1,10,100)

CREATE PARTITION FUNCTION Right_Partition (int) AS RANGE RIGHT
FOR VALUES (1,10,100)
Nella prima funzione (Left_Partition), i valori 1, 10 e 100 sono collocati rispettivamente nella prima, seconda e terza partizione. Nella seconda funzione (Right_Partition), i valori sono collocati nella seconda, terza e quarta partizione.
Quando si crea una tabella partizionata, è importante garantire alle partizioni il livello più elevato di uniformità. In tal modo si potrà comprendere quanto spazio sarà necessario per una partizione. L'utilizzo di una partizione LEFT o RIGHT determina il luogo in cui i dati verranno collocati e, di conseguenza, determina anche la dimensione della partizione e la dimensione di ogni indice creato su quella partizione.
È possibile determinare il numero di partizioni in cui verrà collocato un valore dati tramite la funzione $PARTITION, come mostrato di seguito:
SELECT $PARTITION.Left_Partition (10)
SELECT $PARTITION.Right_Partition (10)
Nella prima istruzione SELECT il risultato sarà 2. La seconda istruzione SELECT darà come risultato 3.
Schemi di partizione Dopo aver creato la funzione e deciso il modo in cui verranno divisi i dati, è necessario stabilire il luogo in cui le singole partizioni verranno create nel sottosistema del disco. Per creare questo layout del disco, si utilizzano gli schemi di partizione. Gli schemi di partizione gestiscono l'archiviazione su disco di partizioni individuali utilizzando filegroup per collocare ogni partizione in un punto del sottosistema del disco. È possibile configurare gli schemi di partizione in modo da collocare tutte le partizioni in un unico filegroup, in differenti filegroup oppure in filegroup che condividono più partizioni. Quest'ultimo metodo consente all'amministratore di database molta flessibilità nella propagazione dell'I/O del disco.
La Figura 1 illustra alcuni dei metodi con cui è possibile assegnare uno o più filegroup a uno schema di partizione. I filegroup utilizzati dallo schema di partizione devono essere già presenti all'interno del database prima di creare lo schema di partizione.
Figure 1 Assegnazione di filegroup a uno schema di partizione (Close Figure 1)
--Place all partitions into the PRIMARY filegroup
CREATE PARTITION SCHEME Primary_Left_Scheme
AS PARTITION Left_Partition
--Partition must currently exist in database
      ALL TO ([PRIMARY])

--Place all partitions into the different filegroups
CREATE PARTITION SCHEME Different_Left_Scheme
AS PARTITION Left_Partition
--Partition must currently exist in database
      TO (Filegroup1, Filegroup2, Filegroup3, Filegroup4)
--Filegroups must currently exist in database

--Place multiple partitions into the different filegroups
CREATE PARTITION SCHEME Multiple_Left_Scheme
AS PARTITION Left_Partition
--Partition must currently exist in database
      TO (Filegroup1, Filegroup2, Filegroup1, Filegroup2)
--Filegroups must currently exist in database
Se si creano le funzioni di partizione come mostrato nella Figura 1 e si utilizza lo schema di partizione per creare una tabella, è possibile determinare dove collocare le singole righe di dati nelle tabelle appena partizionate. Successivamente è possibile visualizzare la distribuzione di tali righe di dati dopo averle inserite nella tabella partizionata. Il codice da utilizzare per effettuare questa operazione sarà molto simile a quello illustrato nella Figura 2.
Figure 2 Posizionamento di righe di dati e visualizzazione della distribuzione (Close Figure 2)
--Prepare database
IF OBJECT_ID('Partitioned_Table') IS NOT NULL
DROP TABLE Partitioned_Table
GO

IF EXISTS(SELECT [name] FROM sys.partition_schemes
WHERE [name] = 'Primary_Left_Scheme')
DROP PARTITION SCHEME Primary_Left_Scheme
GO

IF EXISTS(SELECT [name] FROM sys.partition_functions
WHERE [name] = 'Left_Partition')
DROP PARTITION FUNCTION Left_Partition
GO

--Create partitioned table
CREATE PARTITION FUNCTION Left_Partition (int) AS RANGE LEFT
FOR VALUES (1,10,100)

--Place all partitions into the PRIMARY filegroup
CREATE PARTITION SCHEME Primary_Left_Scheme
AS PARTITION Left_Partition
      ALL TO ([PRIMARY])

CREATE TABLE Partitioned_Table
(
col1 INT
,col2 VARCHAR(15)
) ON Primary_Left_Scheme (col1)

--Determine where values will be placed (this is not required)
--You should try to do this before executing the code
SELECT $PARTITION.Left_Partition (1)
SELECT $PARTITION.Left_Partition (2)
SELECT $PARTITION.Left_Partition (3)
SELECT $PARTITION.Left_Partition (4)
SELECT $PARTITION.Left_Partition (10)
SELECT $PARTITION.Left_Partition (11)
SELECT $PARTITION.Left_Partition (12)
SELECT $PARTITION.Left_Partition (13)
SELECT $PARTITION.Left_Partition (14)
SELECT $PARTITION.Left_Partition (100)
SELECT $PARTITION.Left_Partition (101)
SELECT $PARTITION.Left_Partition (102)
SELECT $PARTITION.Left_Partition (103)
SELECT $PARTITION.Left_Partition (104)

--Insert data into partitioned table
INSERT INTO Partitioned_Table VALUES (1,'Description')
INSERT INTO Partitioned_Table VALUES (2,'Description')
INSERT INTO Partitioned_Table VALUES (3,'Description')
INSERT INTO Partitioned_Table VALUES (4,'Description')
INSERT INTO Partitioned_Table VALUES (10,'Description')
INSERT INTO Partitioned_Table VALUES (11,'Description')
INSERT INTO Partitioned_Table VALUES (12,'Description')
INSERT INTO Partitioned_Table VALUES (13,'Description')
INSERT INTO Partitioned_Table VALUES (14,'Description')
INSERT INTO Partitioned_Table VALUES (100,'Description')
INSERT INTO Partitioned_Table VALUES (101,'Description')
INSERT INTO Partitioned_Table VALUES (102,'Description')
INSERT INTO Partitioned_Table VALUES (103,'Description')
INSERT INTO Partitioned_Table VALUES (104,'Description')

--View the distribution of data in the partitions
SELECT ps.partition_number
,ps.row_count
FROM sys.dm_db_partition_stats ps
INNER JOIN sys.partitions p
ON ps.partition_id = p.partition_id
AND p.[object_id] = OBJECT_ID('Partitioned_Table')

Modifica delle tabelle partizionate
Malgrado un'attenta pianificazione, a volte è necessario regolare le tabelle partizionate dopo averle create e popolate. Lo schema di partizione può funzionare a dovere ma potrebbe essere necessario, ad esempio, aggiungere nuove partizioni man mano che si accumulano nuovi dati o, magari, eliminare grandi quantità di dati partizionati contemporaneamente. Fortunatamente, le tabelle partizionate e le strutture di partizionamento sottostanti consentono di effettuare modifiche dopo aver creato e riempito di dati le tabelle.
Aggiunta di partizioni Molti progetti di partizionamento consentono di aggiungere una nuova partizione in un secondo momento. Si potrebbe trattare di una particolare data oppure di una data dipendente da un valore presente in una colonna di identità incrementale. Pertanto, se non è stato stabilito in partenza quando aggiungere nuove partizioni ad una tabella partizionata è possibile farlo in seguito. Considerare la tabella creata nella Figura 2. È possibile aggiungere una nuova partizione a questa tabella per contenere valori maggiori di 500, come il seguente:
--Determine where values live before new partition
SELECT $PARTITION.Left_Partition (501)  --should return a value of 4

--Create new partition
ALTER PARTITION FUNCTION Left_Partition ()
SPLIT RANGE(500)

--Determine where values live after new partition
SELECT $PARTITION.Left_Partition (501)  --should return a value of 5
La possibilità di aggiungere nuove partizioni offre grande flessibilità. La Figura 3 illustra come aggiungere una partizione sul lato sinistro della funzione. In questo caso, è necessario indicare allo schema di partizionamento dove inserire la nuova partizione poiché, quando è stato creato lo schema di partizionamento, sono stati utilizzati tutti i filegroup. Anche se si utilizza il filegroup PRIMARY per tutte le partizioni, è necessario indicare allo schema di partizionamento di riutilizzare il filegroup PRIMARY per la nuova partizione.
Figure 3 Aggiunta di una partizione al lato sinistro della funzione (Close Figure 3)
--Determine where values live after new partition
SELECT $PARTITION.Left_Partition (5)   --should return a value of 2
SELECT $PARTITION.Left_Partition (1)   --should return a value of 1
SELECT $PARTITION.Left_Partition (10)  --should return a value of 2

--Add new filegroups to the partitioning scheme
ALTER PARTITION SCHEME Primary_Left_Scheme
NEXT USED [PRIMARY]

--Create new partition
ALTER PARTITION FUNCTION Left_Partition ()
SPLIT RANGE(5)

--Determine where values live after new partition
SELECT $PARTITION.Left_Partition (5)   --should return a value of 2
SELECT $PARTITION.Left_Partition (1)   --should return a value of 1
SELECT $PARTITION.Left_Partition (10)  --should return a value of 3
Unione di due partizioni SQL Server consente di eliminare singole partizioni da una tabella pur conservando i dati. Questa funzione può essere utilizzata per unire i dati attivi meno recenti con i dati archiviati oppure per ridurre il numero di partizioni a disposizione, semplificando la gestione della tabella partizionata. È possibile utilizzare questa funzione anche per unire più partizioni, per spostare dati da un filegroup all'altro per liberare spazio su disco in specifici array di unità. Il codice nella Figura 4 illustra come spostare i dati da una partizione all'altra nello stesso filegroup.
Figure 4 Spostamento di dati da una partizione all'altra (Close Figure 4)
--Prepare database
IF OBJECT_ID('multiple_partition') IS NOT NULL
DROP TABLE multiple_partition
GO

IF EXISTS(SELECT [name] FROM sys.partition_schemes
WHERE [name] = 'Primary_Left_Scheme')
DROP PARTITION SCHEME Primary_Left_Scheme
GO

IF EXISTS(SELECT [name] FROM sys.partition_functions
WHERE [name] = 'Left_Partition')
DROP PARTITION FUNCTION Left_Partition
GO

--Create partitioned table
CREATE PARTITION FUNCTION Left_Partition (int) AS RANGE LEFT
FOR VALUES (1,10,100)

--Place all partitions into the PRIMARY filegroup
CREATE PARTITION SCHEME Primary_Left_Scheme
AS PARTITION Left_Partition
--Partition must currently exist in database
      ALL TO ([PRIMARY])

CREATE TABLE multiple_partition
(
col1 INT PRIMARY KEY CLUSTERED
,col2 VARCHAR(15)
) ON Primary_Left_Scheme (col1)

INSERT INTO multiple_partition VALUES (1,'Description')
INSERT INTO multiple_partition VALUES (2,'Description')
INSERT INTO multiple_partition VALUES (3,'Description')
INSERT INTO multiple_partition VALUES (4,'Description')
INSERT INTO multiple_partition VALUES (10,'Description')
INSERT INTO multiple_partition VALUES (11,'Description')
INSERT INTO multiple_partition VALUES (12,'Description')
INSERT INTO multiple_partition VALUES (13,'Description')
INSERT INTO multiple_partition VALUES (14,'Description')
INSERT INTO multiple_partition VALUES (100,'Description')
INSERT INTO multiple_partition VALUES (101,'Description')
INSERT INTO multiple_partition VALUES (102,'Description')
INSERT INTO multiple_partition VALUES (103,'Description')
INSERT INTO multiple_partition VALUES (104,'Description')

--Verify partitions
SELECT OBJECT_NAME(ps.[object_id])
,ps.partition_number
,ps.row_count
FROM sys.dm_db_partition_stats ps
INNER JOIN sys.partitions p
ON ps.partition_id = p.partition_id
AND p.[object_id] = OBJECT_ID('multiple_partition')

--Check where data would be placed
SELECT $PARTITION.Left_Partition (1)
SELECT $PARTITION.Left_Partition (10)
SELECT $PARTITION.Left_Partition (100)
SELECT $PARTITION.Left_Partition (101)

--Merge two partitions
ALTER PARTITION FUNCTION Left_Partition()
MERGE RANGE (10)

--Verify partitions
SELECT OBJECT_NAME(ps.[object_id])
,ps.partition_number
,ps.row_count
FROM sys.dm_db_partition_stats ps
INNER JOIN sys.partitions p
ON ps.partition_id = p.partition_id
AND p.[object_id] = OBJECT_ID('multiple_partition')

--Check where data would be placed
SELECT $PARTITION.Left_Partition (1)
SELECT $PARTITION.Left_Partition (10)
SELECT $PARTITION.Left_Partition (100)
SELECT $PARTITION.Left_Partition (101)
Spostamento di una tabella di partizione in una tabella partizionata Durante le normali attività di caricamento, è spesso necessario caricare grandi quantità di dati nel database e modificarli o aggregarli prima che vengano spostati nella tabella di dati effettiva. Il partizionamento di SQL Server 2005 consente di spostare una singola tabella di partizione in una tabella con più partizioni. Ciò significa che è possibile caricare i dati in una singola tabella di caricamento, modificarli e spostare l'intera tabella in una tabella esistente senza dover spostare ogni singola riga di dati. Questo livello di partizionamento non implica la modifica della struttura di partizionamento sottostante, ma solo la modifica della tabella partizionata. Il codice nella Figura 5 illustra come effettuare l'operazione.
Figure 5 Spostamento di un'intera tabella in una tabella esistente (Close Figure 5)
--Prepare database
IF OBJECT_ID(‘multiple_partition’) IS NOT NULL
DROP TABLE multiple_partition
GO

IF OBJECT_ID(‘single_partition’) IS NOT NULL
DROP TABLE single_partition
GO

IF EXISTS(SELECT [name] FROM sys.partition_schemes
WHERE [name] = ‘Primary_Left_Scheme’)
DROP PARTITION SCHEME Primary_Left_Scheme
GO

IF EXISTS(SELECT [name] FROM sys.partition_functions
WHERE [name] = ‘Left_Partition’)
DROP PARTITION FUNCTION Left_Partition
GO

--Create single partition table
CREATE TABLE single_partition
(
col1 INT PRIMARY KEY CLUSTERED
,col2 VARCHAR(15)
)

--Table must have a CHECK Constraint
ALTER TABLE single_partition
WITH CHECK
ADD CONSTRAINT CK_single_partition
    CHECK (col1 > 100)

INSERT INTO single_partition VALUES (101,’Description’)
INSERT INTO single_partition VALUES (102,’Description’)
INSERT INTO single_partition VALUES (103,’Description’)
INSERT INTO single_partition VALUES (104,’Description’)

--Create partitioned table
CREATE PARTITION FUNCTION Left_Partition (int) AS RANGE LEFT
FOR VALUES (1,10,100)

--Place all partitions into the PRIMARY filegroup
CREATE PARTITION SCHEME Primary_Left_Scheme
AS PARTITION Left_Partition
--Partition must currently exist in database
      ALL TO ([PRIMARY])

CREATE TABLE multiple_partition
(
col1 INT PRIMARY KEY CLUSTERED
,col2 VARCHAR(15)
) ON Primary_Left_Scheme (col1)

INSERT INTO multiple_partition VALUES (1,’Description’)
INSERT INTO multiple_partition VALUES (2,’Description’)
INSERT INTO multiple_partition VALUES (3,’Description’)
INSERT INTO multiple_partition VALUES (4,’Description’)
INSERT INTO multiple_partition VALUES (10,’Description’)
INSERT INTO multiple_partition VALUES (11,’Description’)
INSERT INTO multiple_partition VALUES (12,’Description’)
INSERT INTO multiple_partition VALUES (13,’Description’)
INSERT INTO multiple_partition VALUES (14,’Description’)
INSERT INTO multiple_partition VALUES (100,’Description’)

--Verify partitions
SELECT OBJECT_NAME(ps.[object_id])
,ps.partition_number
,ps.row_count
FROM sys.dm_db_partition_stats ps
INNER JOIN sys.partitions p
ON ps.partition_id = p.partition_id
AND p.[object_id] IN (OBJECT_ID(‘multiple_partition’), OBJECT_
      ID(‘single_partition’))

--Move the single table into the partitioned table
ALTER TABLE single_partition SWITCH TO multiple_partition PARTITION 4

--Verify partitions
SELECT OBJECT_NAME(ps.[object_id])
,ps.partition_number
,ps.row_count
FROM sys.dm_db_partition_stats ps
INNER JOIN sys.partitions p
ON ps.partition_id = p.partition_id
AND p.[object_id] IN (OBJECT_ID(‘multiple_partition’), OBJECT_ID(‘single_partition’))
Spostamento di una partizione da una tabella all'altra Una comune attività amministrativa consiste nello spostare i dati meno recenti in tabelle di archivi separate. Il processo di archiviazione implica generalmente una serie di istruzioni che possono creare un utilizzo di risorse aggiuntivo nei log delle transazioni. Il passaggio della proprietà di una partizione da una tabella all'altra, comunque, è un metodo semplice per l'archiviazione di grandi quantità di dati senza l'overhead del log delle transazioni. Questa funzionalità consente all'amministratore di database di spostare i segmenti di dati meno recenti dalle tabelle attive alle tabelle archiviate. Ma poiché i dati non vengono effettivamente spostati, la quantità di tempo impiegato è decisamente inferiore rispetto a quello necessario per spostare singole righe di dati. La Figura 6 mostra come effettuare questa operazione.
Figure 6 Spostamento di dati meno recenti in tabelle archiviate (Close Figure 6)
--Prepare database
IF OBJECT_ID('active_data') IS NOT NULL
DROP TABLE active_data
GO

IF OBJECT_ID('archive_data') IS NOT NULL
DROP TABLE archive_data
GO

IF EXISTS(SELECT [name] FROM sys.partition_schemes
WHERE [name] = 'Active_Scheme')
DROP PARTITION SCHEME Active_Scheme
GO

IF EXISTS(SELECT [name] FROM sys.partition_functions
WHERE [name] = 'Active_Partition')
DROP PARTITION FUNCTION Active_Partition
GO

IF EXISTS(SELECT [name] FROM sys.partition_schemes
WHERE [name] = 'Archive_Scheme')
DROP PARTITION SCHEME Archive_Scheme
GO

IF EXISTS(SELECT [name] FROM sys.partition_functions
WHERE [name] = 'Archive_Partition')
DROP PARTITION FUNCTION Archive_Partition
GO

--Create active function
CREATE PARTITION FUNCTION Active_Partition (int) AS RANGE LEFT
FOR VALUES (1,10,100)

--Create archive function
CREATE PARTITION FUNCTION Archive_Partition (int) AS RANGE LEFT
FOR VALUES (100,200,300)

--Place all partitions into the PRIMARY filegroup
CREATE PARTITION SCHEME Active_Scheme
AS PARTITION Active_Partition
--Partition must currently exist in database
      ALL TO ([PRIMARY])

--Place all partitions into the PRIMARY filegroup
CREATE PARTITION SCHEME Archive_Scheme
AS PARTITION Archive_Partition
--Partition must currently exist in database
      ALL TO ([PRIMARY])

CREATE TABLE active_data
(
col1 INT PRIMARY KEY CLUSTERED
,col2 VARCHAR(15)
) ON Active_Scheme (col1)

CREATE TABLE archive_data
(
col1 INT PRIMARY KEY CLUSTERED
,col2 VARCHAR(15)
) ON Archive_Scheme (col1)

INSERT INTO active_data VALUES (1,'Description')
INSERT INTO active_data VALUES (2,'Description')
INSERT INTO active_data VALUES (3,'Description')
INSERT INTO active_data VALUES (4,'Description')
INSERT INTO active_data VALUES (10,'Description')
INSERT INTO active_data VALUES (11,'Description')
INSERT INTO active_data VALUES (12,'Description')
INSERT INTO active_data VALUES (13,'Description')
INSERT INTO active_data VALUES (14,'Description')
INSERT INTO active_data VALUES (100,'Description')

INSERT INTO archive_data VALUES (200,'Description')
INSERT INTO archive_data VALUES (300,'Description')
INSERT INTO archive_data VALUES (400,'Description')

--Verify partitions
SELECT OBJECT_NAME(ps.[object_id])
,ps.partition_number
,ps.row_count
FROM sys.dm_db_partition_stats ps
INNER JOIN sys.partitions p
ON ps.partition_id = p.partition_id
AND p.[object_id] IN (OBJECT_ID('active_data'),OBJECT_ID('archive_
      data'))

--Switch ownership of partition to another table
ALTER TABLE active_data SWITCH PARTITION 3 TO archive_data PARTITION 1

--Verify partitions
SELECT OBJECT_NAME(ps.[object_id])
,ps.partition_number
,ps.row_count
FROM sys.dm_db_partition_stats ps
INNER JOIN sys.partitions p
ON ps.partition_id = p.partition_id
AND p.[object_id] IN (OBJECT_ID('active_data'),OBJECT_ID('archive_
      data'))
Utilizzo di una singola partizione per creare una nuova tabella È possibile spostare una singola partizione da una tabella partizionata esistente in una tabella vuota non partizionata. In tal modo, un amministratore di database è in grado di eseguire la manutenzione degli indici sulla singola partizione o eliminare con facilità grandi quantità di dati senza registrare il processo di eliminazione. L'esempio nella Figura 7 mostra come spostare una partizione in una tabella vuota e quindi utilizzare questa nuova tabella per eliminare i dati.
Figure 7 Spostamento ed eliminazione di dati (Close Figure 7)
--Prepare database
IF OBJECT_ID('active_data') IS NOT NULL
DROP TABLE active_data
GO

IF OBJECT_ID('archive_data') IS NOT NULL
DROP TABLE archive_data
GO

IF EXISTS(SELECT [name] FROM sys.partition_schemes
WHERE [name] = 'Active_Scheme')
DROP PARTITION SCHEME Active_Scheme
GO

IF EXISTS(SELECT [name] FROM sys.partition_functions
WHERE [name] = 'Active_Partition')
DROP PARTITION FUNCTION Active_Partition
GO

--Create active function
CREATE PARTITION FUNCTION Active_Partition (int) AS RANGE LEFT
FOR VALUES (1,10,100)

--Place all partitions into the PRIMARY filegroup
CREATE PARTITION SCHEME Active_Scheme
AS PARTITION Active_Partition
--Partition must currently exist in database
      ALL TO ([PRIMARY])

CREATE TABLE active_data
(
col1 INT PRIMARY KEY CLUSTERED
,col2 VARCHAR(15)
) ON Active_Scheme (col1)

CREATE TABLE archive_data
(
col1 INT PRIMARY KEY CLUSTERED
,col2 VARCHAR(15)
)

INSERT INTO active_data VALUES (1,'Description')
INSERT INTO active_data VALUES (2,'Description')
INSERT INTO active_data VALUES (3,'Description')
INSERT INTO active_data VALUES (4,'Description')
INSERT INTO active_data VALUES (10,'Description')
INSERT INTO active_data VALUES (11,'Description')
INSERT INTO active_data VALUES (12,'Description')
INSERT INTO active_data VALUES (13,'Description')
INSERT INTO active_data VALUES (14,'Description')
INSERT INTO active_data VALUES (100,'Description')

--Verify partitions
SELECT OBJECT_NAME(ps.[object_id])
,ps.partition_number
,ps.row_count
FROM sys.dm_db_partition_stats ps
INNER JOIN sys.partitions p
ON ps.partition_id = p.partition_id
AND p.[object_id] IN (OBJECT_ID('active_data'),OBJECT_ID('archive_
      data'))

--Switch ownership of partition to another table
ALTER TABLE active_data SWITCH PARTITION 3 TO archive_data

--Verify partitions
SELECT OBJECT_NAME(ps.[object_id])
,ps.partition_number
,ps.row_count
FROM sys.dm_db_partition_stats ps
INNER JOIN sys.partitions p
ON ps.partition_id = p.partition_id
AND p.[object_id] IN (OBJECT_ID('active_data'),OBJECT_ID('archive_
      data'))

--Drop all archive data without logging
DROP TABLE archive_data
GO

--Verify partitions
SELECT OBJECT_NAME(ps.[object_id])
,ps.partition_number
,ps.row_count
FROM sys.dm_db_partition_stats ps
INNER JOIN sys.partitions p
ON ps.partition_id = p.partition_id
AND p.[object_id] IN (OBJECT_ID('active_data'),OBJECT_ID('archive_
      data'))

Indici partizionati
Oltre alla possibilità di partizionare i dati di una tabella è possibile anche creare indici partizionati. Questa procedura consente all'amministratore di database di progettare la struttura degli indici in base ai dati divisi e non ai dati dell'intera tabella. La creazione di indici partizionati conduce alla formazione di singole strutture B-trees sugli indici partizionati. La divisione degli indici provoca la creazione di indici più piccoli e più facilmente gestibili dal motore di archiviazione durante la modifica, l'aggiunta e l'eliminazione di dati. Questi indici più piccoli possono essere gestiti anche individualmente dall'amministratore di database, consentendo quindi una migliore gestione degli indici su dataset di grandi dimensioni.
Creazione di indici partizionati Quando si creano indici partizionati è possibile creare indici allineati o non allineati. Nel primo caso l'indice viene creato con un collegamento diretto ai dati partizionati. (Per gli indici non allineati, scegliere uno schema di partizionamento differente).
Se si crea la tabella di partizione e poi gli indici, senza specificare uno schema di partizionamento diverso, il metodo preferito, eseguito automaticamente, è quello che prevede la creazione di indici allineati. L'utilizzo di indici allineati garantisce la flessibilità di creare partizioni aggiuntive sulla tabella e la capacità di trasferire la proprietà di una partizione a un'altra tabella. Queste funzionalità sono spesso la ragione principale per cui gli amministratori di database creano tabelle partizionate, pertanto l'utilizzo dello schema di partizionamento della tabella per i relativi indici è il metodo ideale per raggiungere gli obiettivi prefissati.
È possibile creare degli indici in tabelle in cui i dati dell'indice non sono allineati con i dati della tabella. Se i dati sono posizionati in una tabella partizionata, questo procedimento consente di unire i dati in diversi modi (i dati partizionati possono essere uniti in modo efficace ad altri dati partizionati tramite il Query Optimizer). Altrimenti, è possibile utilizzare una tabella non partizionata che consente di creare un indice partizionato (su una singola tabella di partizione) in modo da poter effettuare con facilità la manutenzione degli indici.
Il codice nella Figura 8 crea un indice partizionato ma non raggruppato in una tabella partizionata. L'indice non raggruppato verrà allineato con la tabella e utilizzerà la colonna di partizionamento della tabella come chiave di indice non raggruppata.
Figure 8 Indice partizionato e non raggruppato su una tabella partizionata (Close Figure 8)
--Prepare database
IF OBJECT_ID('multiple_partition') IS NOT NULL
DROP TABLE multiple_partition
GO

IF EXISTS(SELECT [name] FROM sys.partition_schemes
WHERE [name] = 'Primary_Left_Scheme')
DROP PARTITION SCHEME Primary_Left_Scheme
GO

IF EXISTS(SELECT [name] FROM sys.partition_functions
WHERE [name] = 'Left_Partition')
DROP PARTITION FUNCTION Left_Partition
GO

--Create partitioned table
CREATE PARTITION FUNCTION Left_Partition (int) AS RANGE LEFT
FOR VALUES (1,10,100)

--Place all partitions into the PRIMARY filegroup
CREATE PARTITION SCHEME Primary_Left_Scheme
AS PARTITION Left_Partition
--Partition must currently exist in database
    ALL TO ([PRIMARY])

CREATE TABLE multiple_partition
(
col1 INT
,col2 VARCHAR(15)
) ON Primary_Left_Scheme (col1)

--Create partitioned non-clustered index
CREATE NONCLUSTERED INDEX cl_multiple_partition ON multiple_
      partition(col1)

INSERT INTO multiple_partition VALUES (1,'Description')
INSERT INTO multiple_partition VALUES (2,'Description')
INSERT INTO multiple_partition VALUES (3,'Description')
INSERT INTO multiple_partition VALUES (4,'Description')
INSERT INTO multiple_partition VALUES (10,'Description')
INSERT INTO multiple_partition VALUES (11,'Description')
INSERT INTO multiple_partition VALUES (12,'Description')
INSERT INTO multiple_partition VALUES (13,'Description')
INSERT INTO multiple_partition VALUES (14,'Description')
INSERT INTO multiple_partition VALUES (100,'Description')
INSERT INTO multiple_partition VALUES (101,'Description')
INSERT INTO multiple_partition VALUES (102,'Description')
INSERT INTO multiple_partition VALUES (103,'Description')
INSERT INTO multiple_partition VALUES (104,'Description')

--Verify partitions
SELECT OBJECT_NAME(ps.[object_id])
,ps.partition_number
,ps.row_count
FROM sys.dm_db_partition_stats ps
INNER JOIN sys.partitions p
ON ps.partition_id = p.partition_id
AND p.[object_id] = OBJECT_ID('multiple_partition')

--Verify index partitions
SELECT partition_id, index_id FROM sys.partitions pt
WHERE pt.[object_id] = OBJECT_ID('multiple_partition')
Il codice nella Figura 9 crea un indice non allineato e non raggruppato in una tabella partizionata. Questo indice non raggruppato utilizzerà colonne diverse per la relativa chiave che può essere utilizzata per confrontare le unioni su altre tabelle partizionate.
Figure 9 Indice non allineato e non raggruppato su una tabella partizionata (Close Figure 9)
--Prepare database
IF OBJECT_ID('multiple_partition') IS NOT NULL
DROP TABLE multiple_partition
GO

IF EXISTS(SELECT [name] FROM sys.partition_schemes
WHERE [name] = 'Primary_Left_Scheme')
DROP PARTITION SCHEME Primary_Left_Scheme
GO

IF EXISTS(SELECT [name] FROM sys.partition_schemes
WHERE [name] = 'Index_primary_Left_Scheme')
DROP PARTITION SCHEME Index_primary_Left_Scheme
GO

IF EXISTS(SELECT [name] FROM sys.partition_functions
WHERE [name] = 'Left_Partition')
DROP PARTITION FUNCTION Left_Partition
GO

IF EXISTS(SELECT [name] FROM sys.partition_functions
WHERE [name] = 'Index_Left_Partition')
DROP PARTITION FUNCTION Index_Left_Partition
GO

--Create partitioned index function
CREATE PARTITION FUNCTION Index_Left_Partition (int) AS RANGE LEFT
FOR VALUES (10,50,100)

--Create partitioned table
CREATE PARTITION FUNCTION Left_Partition (int) AS RANGE LEFT
FOR VALUES (1,10,100)

--Place all index partitions into the PRIMARY filegroup
CREATE PARTITION SCHEME Index_primary_Left_Scheme
AS PARTITION Index_Left_Partition
--Partition must currently exist in database
      ALL TO ([PRIMARY])

--Place all partitions into the PRIMARY filegroup
CREATE PARTITION SCHEME Primary_Left_Scheme
AS PARTITION Left_Partition
--Partition must currently exist in database
      ALL TO ([PRIMARY])

CREATE TABLE multiple_partition
(
col1 INT
,col2 INT
) ON Primary_Left_Scheme (col1)

--Create non-aligned partitioned nonclustered index
CREATE NONCLUSTERED INDEX cl_multiple_partition ON multiple_
     partition(col2)
ON Index_primary_Left_Scheme (col2)

INSERT INTO multiple_partition VALUES (1,10)
INSERT INTO multiple_partition VALUES (2,10)
INSERT INTO multiple_partition VALUES (3,10)
INSERT INTO multiple_partition VALUES (4,10)
INSERT INTO multiple_partition VALUES (10,50)
INSERT INTO multiple_partition VALUES (11,50)
INSERT INTO multiple_partition VALUES (12,50)
INSERT INTO multiple_partition VALUES (13,50)
INSERT INTO multiple_partition VALUES (14,50)
INSERT INTO multiple_partition VALUES (100,100)
INSERT INTO multiple_partition VALUES (101,100)
INSERT INTO multiple_partition VALUES (102,100)
INSERT INTO multiple_partition VALUES (103,100)
INSERT INTO multiple_partition VALUES (104,100)

--Verify row count on partitioned data
SELECT OBJECT_NAME(ps.[object_id])
,ps.partition_number
,ps.row_count
FROM sys.dm_db_partition_stats ps
INNER JOIN sys.partitions p
ON ps.partition_id = p.partition_id
AND p.[object_id] = OBJECT_ID('multiple_partition')
AND p.index_id = 0

--Verify row count on partitioned index
--Row counts will not match those found in the data partitions
SELECT OBJECT_NAME(ps.[object_id])
,ps.partition_number
,ps.row_count
FROM sys.dm_db_partition_stats ps
INNER JOIN sys.partitions p
ON ps.partition_id = p.partition_id
AND p.[object_id] = OBJECT_ID('multiple_partition')
AND p.index_id <> 0
Gestione di indici partizionati In passato, la manutenzione di indici su tabelle di grandi dimensioni contenenti milioni o anche miliardi di righe di dati spesso richiedeva più tempo di quello che gli amministratori di database avevano a disposizione. La manutenzione spesso non veniva eseguita perché i dati erano bloccati mentre l'indice veniva ricreato. Con SQL Server 2005, l'amministratore di database può eseguire la manutenzione degli indici in linea senza bloccare la tabella sottostante per un lungo periodo di tempo. Ma anche quest'approccio (che consiste nell'eseguire la manutenzione degli indici durante l'accesso degli utenti ai dati) può rallentare il sistema a causa del grande utilizzo di risorse. Un approccio migliore consiste nel partizionare gli indici in segmenti più piccoli ed esegue poi la manutenzione degli indici su quelle partizioni più piccole. Ad esempio, per eseguire la manutenzione degli indici su una partizione è possibile aggiungere semplicemente il frammento di codice alla fine del codice illustrato nella Figura 8.
ALTER INDEX cl_multiple_partition
ON multiple_partition
REBUILD Partition = 2
Si noti che questa manutenzione degli indici su singole partizioni deve essere eseguita non in linea e può provocare il blocco della tabella. Per evitare che ciò avvenga è possibile spostare la singola partizione in una partizione separata, eseguire la manutenzione degli indici e riportare la partizione nella tabella principale. Questo processo causerà dei problemi di prestazioni dal momento che la partizione viene riportata nella tabella e l'indice raggruppato viene aggiornato, ma risulta meno problematico rispetto al blocco di un'intera tabella e richiede minori risorse di sistema.

Riepilogo
Come si può notare, il partizionamento delle tabelle con SQL Server 2005 offre una maggiore flessibilità per l'archiviazione e la gestione di dati in tabelle di grandi dimensioni senza dover rielaborare il codice applicativo o i processi di SQL Server. Con queste capacità, SQL Server si presenta come una piattaforma efficace per la gestione di database aziendali importanti.

Noah Gomez è un amministratore di database senior di Verizon esperto in VLDB e applicazioni su larga scala. È membro dell'Associazione Professionale di SQL Server (PASS) e ha fatto parte del team di amministratori di database di Verazon che ha lavorato sui VLDB di svariati terabyte vincendo nel 2003 il Winter Corp. Top Ten Grand Prize.


 SQL Server: Suggerimenti per il clustering di SQL Server
SQL Server Tom Moreau, PhD

Suggerimenti per il clustering di SQL Server
Panoramica:
  • Esecuzione di SQL Server su cluster
  • Requisiti hardware e software
  • Clustering di un nodo
  • Opzioni efficaci dal punto di vista dei costi

Un cluster di server consente di connettere un numero di server fisici, o nodi, che fungono da partner di failover. La ridondanza di un cluster fornisce tempi di operatività più lunghi per
le operazioni critiche. Ho implementato molti cluster in 13 anni di lavoro utilizzando SQL Server™, ciascuno con una serie specifica di problemi. Quest'esperienza mi ha consentito di raccogliere una serie di consigli per agevolare e semplificare il clustering.
I cluster di server si avvalgono delle funzionalità di clustering integrate nella versione Enterprise Edition della famiglia Windows Server®. Per quanto riguarda il clustering, Windows Server 2003 è considerevolmente migliore di Windows 2000 Advanced Server. Per ottimizzare i vantaggi del clustering, occorre l'hardware giusto, il che implica un investimento. Non è sufficiente collegare due server mediante un disco condiviso, né affidarsi al fatto che i singoli componenti hardware appartengano al catalogo Windows® (in passato conosciuto come Elenco di compatibilità hardware). Il sistema nel suo insieme deve appartenere al Catalogo di Windows. Sono disponibili soluzioni cluster approvate e a basso costo. Nella Figura 1 è mostrata una tipica configurazione cluster.
Figura 1 Un cluster tipico
Figura 1 Un cluster tipico (Fare clic sull'immagine per ridurla)
Figura 1 Un cluster tipico
Figura 1 Un cluster tipico (Fare clic sull'immagine per ingrandirla)
Il clustering non è fatto di solo hardware; occorre anche scegliere l'edizione giusta di SQL Server 2005. Enterprise Edition abilita il clustering e altre funzionalità utili, come la capacità di sfruttare più CPU, viste distribuite e partizionate aggiornabili, distribuzione dei log incorporata, uso automatico di viste indicizzate. Se già si dispone di una licenza Enterprise Edition, si consiglia di prendere in considerazione il clustering, anche se non si dispone del numero di server necessario a formare un cluster tradizionale, da due a otto nodi (parleremo dei cluster a un nodo più avanti). Se si dispone di SQL Server 2005 Standard Edition, è possibile installare un cluster a due nodi.
Windows Server 2003 Enterprise Edition e Datacenter Edition hanno il clustering integrato, ed è sufficiente eseguire Amministrazione cluster per configurare il cluster. È possibile aggiungere tutti i nodi con un'operazione unica o inserirli uno per volta. Allo stesso modo, quando si installa SQL Server, è possibile eseguire l'installazione su un server singolo non in cluster o installare un'istanza virtuale su un cluster. Se si decide di installare un'istanza virtuale, è possibile farlo su tutti i nodi del cluster, su alcuni nodi o su un nodo soltanto.
Infine, per ottenere l'elevata disponibilità clustering, occorrono persone qualificate e procedure collaudate da seguire in caso di problemi. Sebbene il clustering fornisca un'ottima protezione dagli errori hardware, non può impedire gli errori degli utenti, ad esempio nel caso in cui un amministratore di database assonnato perda una tabella di importanza critica nel mezzo della notte.

Cluster a un nodo
Anche se è necessario un solo server, è consigliabile creare un cluster a un nodo. Sarà sempre possibile potenziarlo in un secondo momento, evitando di ricrearlo dal nulla. Accertarsi che l'hardware scelto si trovi nella sezione cluster del Catalogo di Windows.
L'aggiunta di un nodo in un secondo momento non è mirata unicamente a ottenere l'alta disponibilità. Potrebbe ad esempio succedere che il server in uso non disponga della capacità necessaria. Per ovviare al problema, occorrerebbe intervenire con una migrazione, ossia un dispendio di tempo ed energie. In un cluster a un nodo invece, la migrazione è facilitata e i tempi di inattività inferiori. Basta aggiungere il nuovo nodo al cluster, i valori binari e service pack SQL Server al nuovo nodo ed eseguire il failover sul nuovo nodo. Quindi, aggiungere gli aggiornamenti successivi ai service pack e rimuovere il vecchio nodo. Il tempo di inattività richiesto è quello necessario a eseguire il failover e aggiungere gli aggiornamenti, se presenti.

Aggiunta di nodi
Poiché tutti i nodi di un cluster devono essere uguali, è meglio agire per tempo per aggiungere un nodo. Se si attende troppo a lungo si rischia che il nodo vada fuori produzione. In uno dei progetti a cui ho lavorato, dovevo occuparmi della ricostruzione di un nodo in un cluster SQL Server 2000. L'amministratore di rete/SO si era occupato della costruzione del computer di base, poi ero intervenuto io per aggiungerlo al cluster e prepararlo a funzionare come nodo SQL Server. Non ci sono stati problemi fino al momento del failover sul nuovo nodo. L'operazione generava errore. Nonostante avessi preparato un documento dettagliato sulla costruzione del nuovo cluster, compresa l'aggiunta degli account dei servizi cluster e SQL Server per entrambi i nodi, il documento non era stato seguito. L'amministratore non aveva aggiunto gli account dei servizi al nodo ricostruito, pertanto i privilegi che vigevano prima della ricostruzione erano andati persi.
Non riuscivo a risolvere il problema, finché non pensai di controllare l'appartenenza al gruppo locale. Una volta aggiunti i due account, il failover è riuscito. L'episodio mi aveva fatto pensare. Ricostruire un nodo è un'operazione che non viene eseguita di frequente, spesso eseguita in situazioni di emergenza. Avevo preparato un documento, ma non era stato utilizzato. Avremmo potuto automatizzare la parte di protezione scrivendo un breve script da aggiungere ai due account ed eseguire le personalizzazioni necessarie. In SQL Server 2005 le cose sono state migliorate. Il programma di installazione richiede di impostare gruppi a livello di dominio per gli account del servizio SQL Server.
Ciò mi ha fatto pensare ulteriormente. È possibile creare degli script che invocano CLUSTER.EXE per aggiungere il nodo al cluster Microsoft® Cluster Server (MSCS). Basta inserire nello script il nome del nodo. In una situazione di emergenza, l'automazione è fondamentale.

Cluster N+1
Non sempre per aggiungere un nodo a un cluster occorre sostituirne un altro. È possibile aggiungere più istanze SQL Server al cluster e ogni istanza richiede risorse disco separate. Tuttavia, più istanze eseguite su un solo nodo condividono CPU e RAM, con il rischio di causare un calo delle prestazioni. In una situazione ideale, si dovrebbe eseguire un'istanza per nodo. Come è possibile garantire che ciò accada durante il failover? Semplice: un nodo rimane libero mentre sui nodi restanti sono eseguite singole istanze SQL Server. È questa la definizione di cluster N+1: N istanze eseguite su N+1 nodi. Il nodo extra è il backup.

Aggiornamento di SQL Server
L'aggiornamento di un'istanza cluster di SQL Server non è un'operazione semplice. Il cluster ha uno scopo preciso: migliorare i tempi di attività. SQL Server 2005, da parte sua, offre numerosi miglioramenti per evitare i tempi di inattività.
Quali sono le opzioni disponibili? La soluzione più costosa: creare un cluster completamente nuovo, con nuovi server ed eventualmente una nuova rete di archiviazione SAN. Gli unici componenti immutati rimangono gli switch di rete. Ovviamente, l'approccio non è economico ma ha diversi vantaggi. Il nuovo hardware dà prestazioni migliori del vecchio, oltre a presentare l'aumento della capacità del disco e della velocità. Il cambiamento di hardware potenzia quindi le prestazioni. Una soluzione potrebbe essere quella di adottare una formula leasing.
Una volta configurato il nuovo hardware, è possibile creare il nuovo SQL Server virtuale, copiarvi i database di produzione, quindi mettere in funzione il nuovo sistema, dopo avere testato eventuali bug prima dell'attivazione. Ricordarsi di trasferire gli accessi del server esistente Vedere anche support.microsoft.com/kb/246133. Un'altra ottima idea consiste nell'aggiornare lo script di creazione dell'accesso in caso di errore irreversibile.
Per minimizzare il tempo di inattività, utilizzare la distribuzione dei log, a meno che i database non siano di dimensioni limitate e ci siano periodi di tempo lunghi in cui gli utenti non si connettano. È possibile eseguire la distribuzione dei log fino a un attimo prima dell'attivazione. Dopodiché, una volta disconnessi gli utenti, tagliare e distribuire il log finale, quindi utilizzare l'applicazione su una nuova istanza Per un'alternativa interessante alla distribuzione del log, vedere la sezione di mirroring del database che segue. Se si fa uso di alias DNS, non sarà necessario farlo. Sarà sufficiente aggiornare gli alias DNS. Quest'approccio ha il vantaggio di conservare l'originale, nel caso in cui a metà dell'operazione di migrazione sia necessario tornare indietro.
Esiste un'alternativa meno costosa, che richiede però un'attenta pianificazione. Un cluster è in grado di supportare più istanze SQL Server, ma ogni istanza deve disporre di risorse disco proprie. Durante la divisione della SAN, assegnare una LUN a un aggiornamento futuro. Per eseguire l'aggiornamento, installare i valori binari SQL Server nella risorsa disco. Preparare il sistema e chiudere l'istanza corrente di SQL Server, spostare le risorse disco dal vecchio gruppo SQL Server, aggiornare le dipendenze e mettere in linea la nuova istanza SQL Server. Collegare il database della vecchia istanza per completare l'operazione. Prima di iniziare, eseguire il backup.
Si tratta dell'opzione più economica che comporta però alcuni rischi. Se qualcosa non funziona, non sarà possibile scollegare i database dalla nuova istanza e rimetterli nella posizione originale. Sarà necessario ricorrere al ripristino dal backup e ciò potrebbe implicare lunghi tempi di inattività.
Un'alternativa consiste nell'inserire due istanze di SQL Server nella SAN, purché lo spazio sia sufficiente. Eseguire il ripristino dei backup (e distribuzione dei log) nella nuova istanza, come indicato sopra, ma in questo caso sarà disponibile un fallback. Una volta completata la migrazione, è possibile liberare le risorse SAN dalla vecchia istanza. L'unico costo è quello dei dischi aggiuntivi.

Bilanciamento del carico
Innanzitutto sfatiamo una credenza errata. Lo scopo del clustering MSCS è fornire disponibilità elevata e non bilanciamento del carico. SQL Server non dispone di alcuna funzione di bilanciamento del carico automatica integrata. Di questo è responsabile la progettazione fisica delle applicazioni. Cosa significa?
La crescita della tabella implica la riduzione delle prestazioni, soprattutto quando si eseguono ricerche nelle tabelle. Quando entrano in gioco miliardi di righe di dati, la soluzione tradizionale è utilizzare viste partizionate, fatte di tabelle con schemi identici collegati da UNION ALL. Per differenziare le tabelle dei membri, inoltre, sono impiegati i vincoli CHECK; ciò evita la duplicazione di dati nella vista partizionata. Se la colonna utilizzata nel vincolo CHECK è anche parte della chiave primaria, la vista è aggiornabile.
Se le tabelle dei membri sono a loro volta filegroup, è possibile ottenere prestazioni migliori del disco se i filegroup si trovano su unità fisiche separate. Le tabelle possono trovarsi anche in database separati. In SQL Server 2005, tuttavia, purché tutti i dati si trovino nello stesso database, è possibile utilizzare la partizione della tabella, molto più semplice da implementare.
Se tuttavia, nonostante la partizione della tabella o le viste partizionate (locali) le prestazioni rimangono lente, in SQL Server 2000 o SQL Server 2005 è possibile utilizzare le viste partizionate distribuite. La differenza principale è che le tabelle dei membri possono risiedere su istanze diverse di SQL Server e queste istanze possono essere installate su un cluster N+1. Vantaggi dell'opzione Se una tabella di membri non è più in linea in una vista partizionata, l'intera vista risulta non in linea. Raccogliere questi membri in un cluster offre l'affidabilità necessaria per supportare le prestazioni e fornire il bilanciamento del carico.

Effettiva necessità del cluster
Per chi dispone di alcuni server di riserva che non sono nel catalogo Windows per i cluster e non desidera investire in nuovi server per supportare un cluster,
un'alternativa attraente al clustering potrebbe essere il mirroring del database. Il mirroring coinvolge tre elementi: un'istanza che ospita il database con mirroring, detto database principale; un server di backup detto server mirror e, se si desidera il failover automatico, un terzo server noto come server di controllo. In pratica, una transazione che avviene nel database principale viene eseguita anche in quello mirror. Se il database principale genera un errore, esegue automaticamente il failover sul database mirror, purché esista un server di controllo. Occorre configurare il mirroring per tutti i database applicativi e non è possibile eseguire il mirroring dei database di sistema.
A differenza del cluster, il mirror è un istanza separata di SQL Server ed è disponibile in modalità remota. Le cache sono popolate dall'attività di aggiornamento che avviene come risultato delle transazioni duplicate dal database principale. Si presuppone che l'unica attività che avviene nel database mirror sia la ricezione delle transazioni con mirroring effettuate in quello principale. Il failover è generalmente più veloce rispetto a un cluster poiché SQL Server è già in esecuzione sul server mirror. Poiché le cache sono parzialmente riempite, le prestazioni iniziali non sono lente come avviene nel cluster. Quando il database con mirroring esegue il failover, i ruoli di database principale e mirror si invertono.
Il lato negativo del mirroring del database sta nel fatto che necessita del doppio della capacità totale del disco rispetto al cluster. La struttura richiede inoltre più alimentazione della CPU se si utilizza la modalità sincrona senza perdita di dati. Come già detto, ottenere disponibilità elevata non è un operazione economica.

Approccio combinato
Il fatto che il server mirror possa risiedere lontano dal server principale ne fa un'ottima scelta per pianificazioni di ripristino di emergenza. Il cluster è una prima linea di difesa; ma cosa succede se si impiegano sia cluster sia mirroring? Durante il failover del cluster, se la configurazione mirror include un server di controllo, il database mirror diventa database principale quando SQL Server sta per mettersi in linea. Tuttavia, il failover dal database principale a quello mirror (in cluster) non è automatico. È meglio perciò non attivare il failover automatico per i database con mirroring se utilizzati in congiunzione con un cluster.
Il vantaggio del mirroring non si limita a DR, ma risulta utile anche per applicare un service pack o un aggiornamento rapido al database principale; in questa situazione è possibile eseguire il failover manuale sul mirror. Durante l'applicazione del service pack o dell'aggiornamento rapido, il server che era quello principale è temporaneamente non in linea e le transazioni sottoposte a commit nel nuovo server principale vengono messe in coda, in attesa di essere rispedite al nuovo server mirror (ex principale). Una volta completata l'installazione di service pack o l'aggiornamento rapido, ha luogo la sincronizzazione e alla fine i due server si troveranno completamente in sincronia. A questo punto, è possibile invertire i ruoli di server principale e mirror. Il tempo di inattività si limita ai pochi secondi necessari a eseguire failover e failback. È possibile utilizzare questo approccio per eseguire la migrazione di SQL Server a un altro computer: basta non impostare il failback.

Server virtuale per una flessibilità maggiore
La virtualizzazione consente di eseguire uno o più sistemi operativi simultaneamente su un unico server fisico. Il software di virtualizzazione aggiunge un altro strato di funzionalità al concetto di cluster perché abilita il cluster del software. Conseguentemente, se il server host genera errore, è possibile eseguire il failover di server e dei sistemi operativi guest su un nodo di backup. Si tratta di un metodo molto facile per eseguire la migrazione su un server guest. Inoltre, il SO guest non deve essere dotato di funzionalità cluster. In questo modo, è possibile eseguire SQL Server Workgroup Edition in Windows Server 2003 guest, con Microsoft Virtual Server 2005 in esecuzione su cluster. Indirettamente, si tratta di eseguire un cluster in Workgroup Edition (vedere la figura 2).
Figura 2 Uso di un server virtuale
Figura 2 Uso di un server virtuale (Fare clic sull'immagine per ridurla)
Figura 2 Uso di un server virtuale
Figura 2 Uso di un server virtuale (Fare clic sull'immagine per ingrandirla)

Controllo
Il responsabile di un'implementazione SQL Server deve poter contare su un server sempre disponibile. Il clustering di server serve ad assicurare che ciò avvenga. In quest'articolo sono forniti alcuni importanti suggerimenti di base; informazioni più dettagliate sono disponibili nell'intestazione laterale "Risorse di clustering".
Risorse di clustering
Per ulteriori informazioni sui metodi qui citati e i vari prodotti necessari alla configurazione del cluster Server di SQL, vedere:
  • Clustering di failover di SQL Server 2005
  • Clustering di failover di SQL Server 2000
  • Windows Server 2003 R2 Enterprise Edition – Cluster Server (in inglese)
  • Guida dell'amministratore di server cluster Microsoft
  • Microsoft Virtual Server 2005 R2 (in inglese)

Tom Moreau, PhD, BSc, PhD, MCSE, MCDBA, è un consulente indipendente specializzato in amministrazione, progettazione e implementazione di database SQL Server, con sede a Toronto. Tom utilizza SQL Server dal 1993 ed è MVP dal 2001. Ha scritto oltre 100 articoli ed è coautore di un libro su SQL Server. Un ringraziamento a Geoff Hiten, MVP per SQL Server per il suo prezioso contributo.


 Amministrazione di Windows: Il kernel di Windows Vista: parte 2
Amministrazione di Windows Mark Russinovich

Il kernel di Windows Vista: parte 2
Panoramica:
  • Gestione della memoria
  • Avvio e arresto del sistema
  • Risparmio di energia

Il mese scorso, nella prima parte di questa serie di tre articoli, sono stati illustrati i miglioramenti del kernel di Windows Vista nelle aree dei processi e dell'I/O.
In questo numero vengono presentati i miglioramenti nel modo in cui Windows Vista gestisce la memoria, oltre alle importanti novità relative all'avvio e arresto del sistema e al risparmio di energia (parte 1).
In ogni nuova versione di Windows ® vengono migliorate scalabilità e prestazioni e Windows Vista™ non fa eccezione. Sono stati apportati molti miglioramenti al Memory Manager di Windows Vista, come un utilizzo più estensivo delle tecniche di sincronizzazione senza blocchi, delle procedure di blocco più versatili e controllabili, delle strutture di dati più compatte, I/O con paging di maggiori dimensioni, supporto per le architetture di memoria delle GPU più recenti e un impiego più efficiente del buffer TLB (Translation Lookaside Buffer) hardware. Inoltre, la gestione della memoria di Windows Vista ora consente l'allocazione dinamica dello spazio degli indirizzo per i requisiti di carichi di lavoro diversi.
Quattro funzionalità tutte nuove per il miglioramento delle prestazioni che utilizzano tecnologie inedite debuttano in un sistema operativo proprio con Windows Vista: SuperFetch, ReadyBoost, ReadyBoot e ReadyDrive. Verranno descritte dettagliatamente più avanti in questo articolo.

Spazio degli indirizzi dinamico del kernel
Windows e le applicazioni che vengono eseguite in ambiente Windows hanno sempre dovuto fare i conti con i limiti dello spazio degli indirizzi dei processori a 32 bit. Il kernel di Windows viene limitato per impostazione predefinita a 2 GB oppure alla metà dello spazio degli indirizzi virtuale a 32 bit totale, con l'altra metà riservata al processo con il thread in esecuzione sulla CPU. Nella propria metà il kernel deve eseguire il mapping di se stesso, dei driver di dispositivo, della cache del file system, degli stack del kernel, delle strutture dei dati dei codici in base alla sessione e di entrambi i buffer non di paging (memoria fisica bloccata) e di paging allocati dai driver di dispositivo. Prima di Windows Vista, Memory Manager determinava al momento dell'avvio la quantità di spazio degli indirizzi da assegnare a questi scopi, ma la mancanza di flessibilità a volte generava situazioni in cui una delle aree si riempiva mentre l'altra restava quasi vuota. Quando un'area si riempie, possono verificarsi problemi con le applicazioni e con i driver di dispositivo che non riescono a completare le operazioni di I/O.
In Windows Vista a 32 bit Memory Manager gestisce lo spazio degli indirizzi del kernel in modo dinamico, allocando e rilasciando spazio per i vari usi in base al carico di lavoro. La quantità di memoria virtuale utilizzata per la memorizzazione dei buffer di paging può aumentare quando i driver di dispositivo ne richiedono di più e diminuire quando i driver ne rilasciano. Windows Vista sarà quindi in grado di gestire una varietà più ampia di carichi di lavoro e, allo stesso modo della versione a 32 bit del prossimo Windows Server® con nome in codice "Longhorn," di scalare per più utenti contemporanei di Terminal Server.
Naturalmente nei sistemi Windows Vista a 64 bit le limitazioni dello spazio degli indirizzi non rappresentano al momento un problema pratico e non richiedono quindi alcun trattamento particolare poiché sono già configurati sui rispettivi massimi.

Priorità della memoria
Come definisce le priorità di I/O (vedere il numero precedente), Windows Vista implementa allo stesso modo le priorità della memoria. Per comprendere il modo in cui Windows utilizza le priorità della memoria è necessario avere chiara l'implementazione della cache di Memory Manager, definita elenco di standby. In tutte le versioni di Windows che hanno preceduto Windows Vista, quando una pagina fisica (che in genere è di 4 KB) di proprietà di un processo veniva richiesta dal sistema, Memory Manager collocava la pagina alla fine dell'elenco di standby. Quando il processo doveva accedere di nuovo alla pagina, Memory Manager recuperava la pagina dall'elenco di standby e la riassegnava al processo. Quando invece un processo doveva utilizzare una nuova pagina di memoria fisica e non era disponibile memoria libera, Memory Manager passava la pagina all'inizio dell'elenco di standby. In questo schema tutte le pagine dell'elenco di standby venivano trattate in modo paritetico, utilizzando solo il tempo per cui erano collocate nell'elenco per eseguirne l'ordinamento.
In Windows Vista a ciascuna pagina di memoria viene assegnata una priorità compresa tra 0 e 7, dunque Memory Manager suddivide l'elenco di standby in otto elenchi che contengono ciascuno le pagine con una determinata priorità. Quando Memory Manager deve prelevare una pagina dall'elenco di standby, sceglie prima le pagine dagli elenchi con priorità più bassa. La priorità di una pagina in genere riflette la priorità del thread che ne ha richiesto per primo l'allocazione. Se la pagina è condivisa, riflette la priorità della memoria più alta dei thread di condivisione. Un thread eredita il valore di priorità della pagina dal processo a cui appartiene. Memory Manager utilizza le priorità più basse per le pagine che legge dal disco in modo speculativo quando anticipa gli accessi alla memoria del processo.
Per impostazione predefinita, ai processi viene assegnata una priorità di pagina pari a 5, ma alcune funzioni consentono ad applicazioni e sistema di modificare la priorità di pagina e il processo. I vantaggi della priorità della memoria si realizzano al massimo quando le priorità relative delle pagine vengono comprese a livello di macro, che è la funzione di SuperFetch.

SuperFetch
Una novità significativa di Memory Manager consiste nella modalità di gestione della memoria fisica. La gestione dell'elenco di standby utilizzata dalle versioni precedenti di Windows era afflitta da due limitazioni. Primo limite: la definizione della priorità delle pagine era basata solo sul comportamento recente dei processi e non prevedeva le esigenze future in termini di memoria. Secondo limite: i dati utilizzati per la definizione della priorità si limitavano all'elenco delle pagine di proprietà di un processo in un determinato momento. Queste limitazioni possono generare scenari come "la sindrome del dopo pranzo", in cui si lascia il computer per un breve periodo e si avvia un'applicazione che utilizza la memoria in modo intensivo (ad esempio, una deframmentazione del disco o una scansione dell'antivirus). Tale applicazione forza la sovrascrittura da parte delle attività a consumo intensivo di memoria del codice e dei dati che le applicazioni attive avevano inserito nella cache in memoria. Quando si torna dalla pausa, le prestazioni sono molto peggiori perché le applicazioni devono richiedere la lettura di dati e codice dal disco.
Con Windows XP è stato introdotto il supporto della prelettura, che ha migliorato le prestazioni di avvio del sistema e delle applicazioni eseguendo operazioni di I/O da disco per precaricare in memoria i dati del file system e il codice necessari, in base agli avvii precedenti di sistema e applicazioni. Con Windows Vista si fa un importante passo avanti con SuperFetch, uno schema di gestione della memoria che migliora l'approccio dell'accesso meno recente utilizzando le informazioni della cronologia e la gestione proattiva della memoria.
SuperFetch è implementato in %SystemRoot%\System32\Sysmain.dll come servizio Windows eseguito in un processo Host servizio (%SystemRoot%\System32\Svchost.exe). Lo schema si fonda sul supporto da parte di Memory Manager, in modo da recuperare la cronologia di utilizzo delle pagine oltre a dirigere Memory Manager nel precaricamento di dati e codice dai file sul disco oppure da un file di paging nell'elenco di standby per assegnare le priorità alle pagine. Il servizio SuperFetch estende il tracciamento anche alle pagine di dati e codice che erano presenti in precedenza in memoria, ma che Memory Manager ha riutilizzato per fare spazio per nuovi dati e nuovo codice. Queste informazioni vengono memorizzate in file di scenario con estensione .db nella directory %SystemRoot%\Prefetch, insieme ai file di prelettura standard utilizzati per ottimizzare l'avvio delle applicazioni. Sfruttando questa profonda conoscenza dell'utilizzo della memoria, SuperFetch è in grado di precaricare dati e codice quando diventa disponibile la memoria fisica.
Quando la memoria si libera, ad esempio quando un'applicazione viene chiusa o rilascia memoria, SuperFetch chiede a Memory Manager di recuperare i dati e il codice rimossi di recente. Questa operazione viene eseguita alla velocità di poche pagine al secondo con una priorità di I/O Molto bassa, in modo che il precaricamento non abbia un impatto sulle applicazioni attive dell'utente o di altra natura. Ne consegue che se si lascia il computer per andare a pranzo e un'attività in background che utilizza una grande quantità di memoria provoca la rimozione del codice e dei dati delle applicazioni attive dalla memoria, SuperFetch sarà spesso in grado di recuperare tutti o la maggior parte degli elementi rimossi in memoria prima del ritorno dell'utente. SuperFetch comprende inoltre il supporto dello scenario specifico per ibernazione, standby, Cambio rapido utente e avvio delle applicazioni. Quando il sistema entra in ibernazione, ad esempio, SuperFetch memorizza i dati e il codice nel file di ibernazione che (in base alle ibernazioni precedenti) prevede verrà utilizzato al ripristino successivo. Quando invece viene ripristinato Windows XP, i dati che vengono richiesti e che erano memorizzati in precedenza nella cache devono essere letti di nuovo dal disco.
Per una descrizione dell'impatto di SuperFetch sulla memoria disponibile, vedere il riquadro "Funzionamento di SuperFetch".
Funzionamento di SuperFetch
Dopo aver utilizzato per un po' di tempo un sistema Windows Vista, si noterà un valore basso nel contatore della memoria fisica disponibile nella pagina Prestazioni di Gestione attività. Questo accade perché SuperFetch e la cache standard di Windows utilizzano tutta la memoria fisica disponibile per memorizzare i dati del disco. Se si esegue Gestione attività subito dopo aver avviato il sistema, ad esempio, si noterà che il valore della memoria disponibile diminuisce con l'aumentare del valore della cache. In alternativa, se si esegue e poi si chiude un programma che utilizza una grande quantità di memoria (ad esempio, una qualunque applicazione freeware di "ottimizzazione della RAM" che alloca grandi quantità di memoria per poi rilasciarla) oppure si copia un file di grandi dimensioni, il valore della memoria disponibile aumenterà e il grafico Cronologia utilizzo memoria fisica segnerà un brusco calo perché il sistema reclama la memoria rilasciata. Con il passare del tempo, tuttavia, SuperFetch riempirà di nuovo la cache con i dati rimossi in modo forzato dalla memoria e il valore della cache tornerà a salire, con la conseguente riduzione del valore della memoria disponibile.
Memoria sotto osservazione
Memoria sotto osservazione (Fare clic sull'immagine per ridurla)
Memoria sotto osservazione
Memoria sotto osservazione (Fare clic sull'immagine per ingrandirla)

ReadyBoost
Le velocità di CPU e memoria stanno superando di gran lunga le velocità dei dischi rigidi, che rappresentano ormai un tipico collo di bottiglia per le prestazioni del sistema. L'I/O casuale dei dischi è molto dispendioso perché i tempi di ricerca delle testine dei dischi sono nell'ordine di 10 millisecondi, un'eternità per i processori a 3 GHz odierni. La RAM è una cache ideale per i dati del disco, ma è piuttosto costosa. La memoria flash, tuttavia, è in genere più economica e consente di eseguire letture casuali con una velocità fino a 10 volte maggiore rispetto a un disco rigido standard. In Windows Vista è disponibile la funzionalità ReadyBoost, che sfrutta i vantaggi dei dispositivi di archiviazione con memoria flash creando uno livello di cache intermedio che risiede logicamente tra memoria e dischi.
ReadyBoost consiste in un servizio implementato in %SystemRoot%\System32\Emdmgmt.dll che viene eseguito in un processo Host servizio e in un driver del filtro del volume, %SystemRoot%\System32\Drivers\Ecache.sys. Emd è l'acronimo di External Memory Device (dispositivo di memoria esterno), il nome attribuito a ReadyBoost nella fase di sviluppo. Quando si inserisce un dispositivo flash come una chiave USB in un sistema, il servizio ReadyBoost esamina il dispositivo per determinarne le prestazioni e memorizza i risultati del test in HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\Currentversion\Emdmgmt, come in Figura 1.
Figura 1 Risultati del test del dispositivo di ReadyBoost nel Registro di sistema
Figura 1 Risultati del test del dispositivo di ReadyBoost nel Registro di sistema (Fare clic sull'immagine per ridurla)
Figura 1 Risultati del test del dispositivo di ReadyBoost nel Registro di sistema
Figura 1 Risultati del test del dispositivo di ReadyBoost nel Registro di sistema (Fare clic sull'immagine per ingrandirla)
Se non si utilizza già un dispositivo per la cache e il nuovo dispositivo contiene tra 256 MB e 32 GB di dati, ha una velocità di trasferimento di 2,5 MB/s o maggiore per letture casuali di 4 KB e ha una velocità di trasferimento dei dati di 1,75 MB/s o maggiore per scritture casuali di 512 KB, ReadyBoost richiederà se si desidera dedicare fino a 4 GB alla cache del disco. ReadyBoost può utilizzare NTFS, ma limita le dimensioni massime della cache a 4 GB per compatibilità con le limitazioni del file system FAT32. Se si accetta, il servizio creerà un file di cache denominato Readyboost.sfcache nella directory radice del dispositivo e chiederà a SuperFetch di popolare preliminarmente la cache in background.
Dopo che il servizio ReadyBoost ha inizializzato la cache, il driver del dispositivo Ecache.sys intercetta tutte le letture e scritture dei dischi rigidi locali (C:\, ad esempio) e copia i dati in scrittura nel file di cache creato dal servizio. Ecache.sys comprime i dati raggiungendo in genere un rapporto di compressione di 2:1, in modo che il file di cache di 4 GB contenga fino a 8 GB di dati. Il driver crittografa ciascun blocco che scrive utilizzando lo standard AES (Advanced Encryption Standard) con una chiave di sessione generata casualmente a ogni avvio, per garantire la privacy dei dati memorizzati nella cache quando il dispositivo viene rimosso dal sistema.
Quando ReadyBoost rileva letture casuali che possono essere soddisfatte dalla cache, utilizza quest'ultima per l'operazione ma, poiché i dischi rigidi garantiscono prestazioni migliori rispetto alle memorie flash nelle letture sequenziali, consente alle letture che fanno parte di modelli sequenziali di accedere direttamente ai dischi, anche se i dati sono presenti nella cache.

ReadyBoot
Nel caso di un sistema con meno di 512 MB di memoria Windows Vista utilizza la stessa prelettura di avvio di Windows XP, ma se il sistema dispone di 700 MB o più di RAM, utilizza una cache sulla RAM per ottimizzare il processo di avvio. Le dimensioni della cache dipendono dalla RAM totale disponibile, ma sono sufficienti a creare una cache ragionevole e consentire al sistema di accedere alla memoria necessaria per un avvio rapido e senza problemi.
Dopo ogni avvio, il servizio ReadyBoost (lo stesso servizio che implementa la funzionalità ReadyBoost appena descritta) sfrutta il tempo di CPU inutilizzato per calcolare uno schema di memorizzazione nella cache per il prossimo avvio. Il servizio inoltre analizza le informazioni di tracciamento file dei cinque avvii precedenti e individua i file a cui è stato eseguito l'accesso e le rispettive posizioni su disco. Le tracce elaborate vengono memorizzate in %SystemRoot%\Prefetch\Readyboot come file .fx e lo schema di memorizzazione nella cache viene salvato sotto HKLM\System\CurrentControlSet\Services\Ecache\Parameters in valori REG_BINARY denominati in base ai volumi interni di riferimento.
La cache viene implementata dallo stesso driver di dispositivo che implementa la cache di ReadyBoost (Ecache.sys), ma il popolamento della cache è condotta dal servizio ReadyBoost all'avvio del sistema. Se la cache di avvio è compressa come la cache ReadyBoost, un'altra differenza tra ReadyBoost e la gestione della cache di ReadyBoot consiste nel fatto che in modalità ReadyBoot, diversa dagli aggiornamenti del servizio ReadyBoost, la cache non cambia in modo da riflettere i dati letti o scritti durante l'avvio. Il servizio ReadyBoost elimina la cache 90 secondi dopo l'inizio dell'avvio, oppure se altre richieste di memoria lo garantiscono, e registra le statistiche della cache in HKLM\System\CurrentControlSet\Services\Ecache\Parameters\ReadyBootStats, come illustrato nella Figura 2. I test delle prestazioni di Microsoft hanno dimostrato che ReadyBoot consente di migliorare le prestazioni di circa il 20% rispetto alla funzione di prelettura di Windows XP.
Figura 2 Statistiche delle prestazioni di ReadyBoot
Figura 2 Statistiche delle prestazioni di ReadyBoot (Fare clic sull'immagine per ridurla)
Figura 2 Statistiche delle prestazioni di ReadyBoot
Figura 2 Statistiche delle prestazioni di ReadyBoot (Fare clic sull'immagine per ingrandirla)

ReadyDrive
ReadyDrive è una funzionalità di Windows Vista che sfrutta i nuovi dischi rigidi ibridi denominati H-HDD. Un H-HDD è un disco con memoria flash incorporata non volatile (anche definita NVRAM). In genere in un H-HDD è integrata una cache da 50 MB a 512 MB, ma il limite della cache in Windows Vista è di 2 TB.
In Windows Vista vengono utilizzati i comandi ATA-8 per definire i dati del disco da archiviare nella memoria flash. I dati di avvio, ad esempio, vengono salvati nella cache all'arresto del sistema, consentendo un riavvio più rapido. Vengono inoltre memorizzati nella cache parti dei dati del file di ibernazione quando il sistema entra in ibernazione, in modo che il ripristino successivo sia più veloce. Poiché la cache resta attiva anche quando i piattelli del disco non ruotano, Windows può utilizzare la memoria flash come cache in scrittura sul disco, evitando di avviare la rotazione dei piattelli del disco quando il sistema è alimentato a batteria. Quando si lascia la rotazione del disco disattivata, si risparmia molta dell'energia consumata dall'unità disco in condizioni di uso normale.

Database della configurazione di avvio
Con Windows Vista sono stati migliorati alcuni aspetti dell'avvio e dell'arresto del sistema. Per l'avvio sono stati introdotti il database di configurazione di avvio (BCD) per la memorizzazione della configurazione di avvio di sistema e sistema operativo, nuovi flusso e organizzazione dei processi di avvio del sistema, una nuova architettura di accesso e il supporto per i servizi di avvio automatico ritardato. Le modifiche apportate alla procedura di arresto del sistema di Windows Vista includono la notifica di pre-arresto del sistema per i servizi Windows, l'ordinamento dell'arresto dei servizi Windows e una modifica significativa della modalità di gestione da parte del sistema operativo delle transizioni dello stato di alimentazione.
Una delle modifiche più evidenti del processo di avvio è l'assenza del file Boot.ini dalla radice del volume di sistema. Il file non è più necessario perché la configurazione dell'avvio, che nelle versioni precedenti di Windows era memorizzata nel file di testo Boot.ini, ora è memorizzata nel BCD. In Windows Vista si utilizza il BCD anche perché questo unifica le due architetture di avvio attualmente supportate da Windows: MBR (Master Boot Record) ed EFI (Extensible Firmware Interface). MBR viene in genere utilizzato da sistemi desktop x86 e x64, mentre EFI viene utilizzato da sistemi basati su Itanium (in un prossimo futuro anche i computer desktop potranno essere forniti con il supporto EFI). Il BCD estrae il firmware e ha altri vantaggi rispetto a Boot.ini, come il supporto per stringhe Unicode ed eseguibili di pre-avvio alternativi.
Il BCD viene memorizzato su disco in un hive del Registro di sistema che viene caricato nel Registro di sistema di Windows per l'accesso tramite API del Registro di sistema. Nei computer, Windows lo memorizza in \Boot\Bcd sul volume di sistema. Nei sistemi EFI, si trova sulla partizione di sistema EFI. Quando viene caricato, l'hive è riportato sotto HKLM\Bcd00000000, ma il formato interno non è documentato, quindi per la modifica è necessario uno strumento come %SystemRoot%\System32\Bcdedit.exe. Le interfacce per la manipolazione del BCD sono disponibili anche per script ed editor personalizzati tramite Strumentazione gestione Windows (WMI) ed è possibile utilizzare l'utilità di configurazione di sistema di Windows (%SystemRoot%\System32\Msconfig.exe) per modificare o aggiungere i parametri fondamentali, come le opzioni di debug del kernel.
Il BCD separa le impostazioni di avvio della piattaforma, come la selezione del sistema operativo predefinito e il timeout del menu di avvio, dalle impostazioni specifiche per il sistema operativo, come le opzioni di avvio e il percorso del caricatore di avvio del sistema operativo. Nella Figura 3, ad esempio, è illustrata l'esecuzione di Bcdedit senza opzioni della riga di comando, con le impostazioni di piattaforma nella sezione Windows Boot Manager all'inizio dell'output e le impostazioni specifiche del sistema operativo nella sezione successiva del caricatore di avvio di Windows.
Figura 3 Impostazioni visualizzate in BCDEdit
Figura 3 Impostazioni visualizzate in BCDEdit (Fare clic sull'immagine per ridurla)
Figura 3 Impostazioni visualizzate in BCDEdit
Figura 3 Impostazioni visualizzate in BCDEdit (Fare clic sull'immagine per ingrandirla)
Quando si avvia un'installazione di Windows Vista, questo nuovo schema separa le attività che nelle versioni precedenti di Windows erano gestite dal caricatore del sistema operativo (Ntldr) in due eseguibili diversi: \BootMgr e %SystemRoot%\System32\Winload.exe. Bootmgr legge il BCD e mostra il menu di avvio del sistema operativo, mentre Winload.exe gestisce il caricamento del sistema operativo. Durante un avvio pulito, Winload.exe carica i driver di dispositivo di avvio del sistema e i file principali del sistema operativo, compreso Ntoskrnl.exe, e trasferisce il controllo al sistema operativo; durante il ripristino dall'ibernazione, viene quindi avviato %SystemRoot%\System32\Winresume.exe per il caricamento dei dati di ibernazione in memoria e il ripristino del sistema operativo.
Bootmgr prevede inoltre il supporto per eseguibili di pre-avvio aggiuntivi. Windows Vista viene fornito con Strumento di diagnostica memoria Windows (\Boot\Memtest.exe) già configurato come opzione per il controllo dell'integrità della RAM, ma terze parti possono aggiungere eseguibili di pre-avvio proprietari come opzioni da visualizzare nel menu di avvio di Bootmgr.

Processi di avvio
Nelle versioni precedenti di Windows il rapporto tra i vari processi del sistema non era intuitivo. All'avvio del sistema, ad esempio, il gestore di accesso interattivo (%SystemRoot%\System32\Winlogon.exe) avvia Local Security Authority Subsystem Service (Lsass.exe) e Gestione controllo servizi (Services.exe). Inoltre, Windows utilizza un contenitore di spazio dei nomi denominato Sessione per isolare i processi in esecuzione delle diverse sessioni di accesso. Prima di Windows Vista, l'utente accedeva alla sessione 0 condivisa della console, la sessione utilizzata dai processi di sistema, generando potenziali problemi di protezione. Un problema di questo tipo si verificava, ad esempio, quando un servizio Windows scritto con scarsa perizia eseguito nella sessione 0 mostrava un'interfaccia utente sulla console interattiva, consentendo al malware di attaccare la finestra tramite alcune tecniche volte ad acquisire i privilegi di amministrazione.
Per risolvere questi problemi, alcuni processi di sistema sono stati riprogettati per Windows Vista. La gestione delle sessioni (Smss.exe) è il primo processo in modalità utente creato durante l'avvio come nelle versioni precedenti di Windows, ma in Windows Vista ne viene avviata una seconda istanza per la configurazione della sessione 0, dedicata esclusivamente ai processi di sistema. Il processo di gestione delle sessioni per la sessione 0 avvia l'applicazione di avvio di Windows (Wininit.exe), un processo del sottosistema Windows (Csrss.exe) per la sessione 0, e viene quindi chiuso. L'applicazione di avvio di Windows continua avviando Gestione controllo servizi, Local Security Authority Subsystem e un nuovo processo, Gestione sessioni locali (Lsm.exe), che gestisce le connessioni Terminal Server per il computer.
Quando un utente accede al sistema, Gestione sessioni locali crea una nuova di se stesso per configurare la nuova sessione. Il nuovo processo Smss.exe avvia un processo del sottosistema Windows e il processo Winlogon per la nuova sessione. Il vantaggio costituito da un gestore delle sessioni principale che utilizza altre copie di se stesso per inizializzare nuove sessioni non viene percepito su un sistema client, ma sui sistemi Windows Server "Longhorn" utilizzati come Terminal Server, le copie multiple possono essere eseguite simultaneamente per consentire accessi più rapidi a più utenti.
Con questa nuova architettura i processi del sistema, compresi i servizi Windows, restano isolati nella sessione 0. Se un servizio Windows eseguito nella sessione 0 mostra un'interfaccia utente, il servizio Rilevamento servizi interattivi (%SystemRoot%\System32\UI0Detect.exe) notifica l'evento all'amministratore connesso avviando un'istanza di se stesso nel contesto di protezione dell'utente e mostrando il messaggio visualizzato nella Figura 4. Se l'utente sceglie il pulsante "Mostra messaggio", il servizio passa dal desktop al desktop del servizio Windows, in cui l'utente può interagire con l'interfaccia utente del servizio e tornare quindi al proprio desktop. Per ulteriori informazioni su quanto avviene all'avvio, vedere il riquadro "Visualizzazione delle relazioni tra i processi di avvio".
Figura 4 Finestra mostrata dal servizio
Figura 4 Finestra mostrata dal servizio (Fare clic sull'immagine per ridurla)
Figura 4 Finestra mostrata dal servizio
Figura 4 Finestra mostrata dal servizio (Fare clic sull'immagine per ingrandirla)
Visualizzazione delle relazioni tra i processi di avvio
È possibile utilizzare Process Explorer di Sysinternals (microsoft.com/technet/sysinternals) (in inglese) per visualizzare la struttura di avvio dei processi di Windows Vista.
Nella schermata riportata di seguito è riportata la colonna Session, che può essere aggiunta tramite la finestra di dialogo delle colonne di Process Explorer. Il processo evidenziato è l'Smss.exe iniziale. Di seguito sono elencati i processi Csrss.exe e Wininit.exe della sessione 0, allineati a sinistra perché il processo padre, ovvero l'istanza di Smss.exe che ha configurato la sessione 0, è stato chiuso. I tre processi figlio di Wininit sono Services.exe, Lsass.exe e Lsm.exe.
Process Explorer identifica una serie di processi come in esecuzione nella sessione 1, ovvero nella sessione a cui si è connesso l'utente tramite desktop remoto. In Process Explorer i processi in esecuzione nello stesso account vengono inoltre evidenziati in blu. Infine, la sessione 2 è stata inizializzata in modo da preparare l'accesso di un utente alla console e la creazione di una nuova sessione di accesso. È questa la sessione in cui è in esecuzione Winlogon che utilizza LogonUI per richiedere al nuovo utente della console "Per eseguire l'accesso, premere CTRL + ALT + CANC" e in cui Logonui.exe richiederà le credenziali all'utente.
Informazioni su processi e sessioni di avvio
Informazioni su processi e sessioni di avvio (Fare clic sull'immagine per ridurla)
Informazioni su processi e sessioni di avvio
Informazioni su processi e sessioni di avvio (Fare clic sull'immagine per ingrandirla)

Provider di credenziali
In Windows Vista è stata modificata anche l'architettura di accesso. Nelle versioni precedenti di Windows il processo Winlogon caricava la DLL per l'identificazione e l'autenticazione grafiche (GINA) specificata nel Registro di sistema, che consentiva di visualizzare un'interfaccia utente di accesso in cui venivano richieste le credenziali agli utenti. Il modello della DLL GINA era purtroppo caratterizzato da alcune limitazioni, tra cui la possibilità di configurare una sola GINA, l'eccessiva complessità di scrittura di una GINA per le terze parti e le GINA personalizzate con interfacce utente non standard che inficiavano l'usabilità di Windows.
In Windows Vista viene utilizzato, in luogo di una GINA, la nuova architettura del provider di credenziali. Winlogon avvia un nuovo processo (Logonui.exe), che carica i provider di credenziali configurati in HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\Currentversion\Authentication\Credential Providers. Logonui può supportare simultaneamente più provider di credenziali; infatti, Windows Vista viene fornito con i provider interattivo (Authui.dll) e smartcard (Smart-cardcredentialprovider.dll). Per garantire prestazioni uniformi dal punto di vista dell'utente, LogonUI gestisce l'interfaccia utente visualizzata dagli utenti finali, ma consente ai provider di credenziali di specificare elementi personalizzati come testo, icone e controlli di modifica.

Servizi di avvio automatico ritardato
Se si è eseguito qualche volta l'accesso a un sistema Windows subito dopo l'avvio, si sono di certo notati dei ritardi prima che venga configurato il desktop e che sia possibile interagire con la shell e con qualsiasi applicazione avviata. Durante l'accesso, Gestione controllo servizi avvia i numerosi servizi Windows configurati come servizi ad avvio automatico e che si attivano quindi al momento dell'avvio. Molti servizi eseguono inizializzazioni che sfruttano a fondo le risorse di CPU e disco, in competizione con le attività di accesso. Per risolvere i conflitti, in Windows Vista è stato aggiunto un nuovo tipo di avvio dei servizi, definito avvio automatico ritardato, che i servizi possono utilizzare quando non devono attivarsi subito dopo l'avvio di Windows.
Gestione controllo servizi avvia i servizi configurati per l'avvio automatico ritardato al termine dell'avvio dei servizi ad avvio automatico e imposta la priorità dei rispettivi thread iniziali su THREAD_PRIORITY_LOWEST. Ne consegue che a tutte le operazioni di I/O da disco eseguite dal thread viene assegnata la priorità di I/O Molto Bassa. Al termine dell'inizializzazione, Gestione controllo servizi imposta la priorità normale del servizio. La combinazione di avvio ritardato, bassa priorità di CPU e memoria e priorità in background del disco riduce di molto l'interferenza con l'accesso dell'utente. Molti servizi Windows, compresi Servizio trasferimento intelligente in background, Client di Windows Update e Windows Media® Center, utilizzano il nuovo tipo di avvio per migliorare le prestazioni degli accessi dopo un avvio.

Arresto del sistema
Un problema che ha sempre afflitto gli scrittori di servizi Windows è il limite predefinito di venti secondi per eseguire la pulizia durante l'arresto del sistema. Le versioni di Windows prima di Vista non supportavano un arresto pulito del sistema che restasse in attesa della chiusura di tutti i servizi, perché un servizio con errori di programmazione poteva ritardare indefinitamente l'arresto del sistema. Alcuni servizi, come quelli che prevedono operazioni di arresto del sistema correlate alla rete o il salvataggio di grandi quantità di dati su disco, potrebbero richiedere più tempo. Windows Vista consente a questo genere di servizi di richiedere una notifica di pre-arresto del sistema.
Quando Windows Vista viene arrestato, Gestione controllo servizi notifica in anticipo la chiusura ai servizi che richiedono una notifica di pre-arresto del sistema, quindi resterà indefinitamente in attesa che questi servizi vengano chiusi. Se tuttavia i servizi non rispondono alle query a causa di qualche errore di programmazione, Gestione controllo servizi procede all'arresto del sistema dopo altri tre minuti. Una volta chiusi tutti i servizi oppure al termine del timeout, Gestione controllo servizi procede con la chiusura degli altri servizi secondo le procedure standard. Criteri di gruppo e i servizi Windows Update registrano la notifica di pre-arresto del sistema in una nuova installazione di Windows Vista e
utilizzano, inoltre, un'altra funzionalità per i servizi di Windows Vista: l'ordinamento dell'arresto dei servizi Windows. I servizi sono sempre stati in grado di specificare le dipendenze di avvio che Gestione controllo servizi rispetta per avviare i servizi in un ordine soddisfacente, ma prima di Windows Vista non erano in grado di specificare le dipendenze di arresto del sistema. Ora i servizi registrati per la notifica di pre-arresto del sistema possono anche inserirsi nell'elenco memorizzato in HKLM\System\CurrentControlSet\Control\PreshutdownOrder e Gestione controllo servizi li chiuderà secondo l'ordine specificato. Per ulteriori informazioni su questi servizi, vedere il riquadro "Identificazione di un servizio di avvio automatico ritardato e di pre-arresto del sistema".

Risparmio di energia
Sospensione e ibernazione sono altre forme di arresto del sistema e le funzioni di risparmio di energia di scarsa qualità di driver e applicazioni sono sempre stati un problema per gli utenti mobili, fin da quando con Windows 2000 fu introdotto il risparmio di energia nella gamma di sistemi operativi basati su Windows NT®. Gli utenti si aspettavano che il sistema portatile entrasse in sospensione o ibernazione dopo la chiusura del coperchio del computer prima della partenza, ma una volta giunti a scoprivano di avere una borsa rovente, una batteria scarica e dei dati persi. Questi problemi si verificavano perché Windows ha sempre chiesto ai driver dei dispositivi e alle applicazioni l'autorizzazione per la modifica dello stato di alimentazione e un singolo driver o applicazione non standard impediva la transizione.
In Windows Vista il gestore dell'alimentazione del kernel informa ancora driver e applicazioni delle modifiche dello stato di alimentazione, in modo da preparare la transizione, ma non chiede più l'autorizzazione. Inoltre, il gestore dell'alimentazione resta in attesa di una risposta alle notifiche di modifica per un massimo di 20 secondi, invece dei due minuti delle versioni precedenti di Windows. Di conseguenza gli utenti di Windows Vista possono contare su funzioni di sospensione e ibernazione più affidabili.

Nella prossima puntata
Come anticipato, questa è la seconda parte di una serie in tre parti. Nella prima parte sono stati illustrati i miglioramenti apportati al kernel di Windows Vista nelle aree di I/O e processi. In questo articolo sono stati esaminati i miglioramenti di Windows Vista nei settori della gestione della memoria, dell'avvio e dell'arresto del sistema. Nell'ultima parte della serie si descriveranno le modifiche apportate al kernel nelle aree di affidabilità e protezione.
Identificazione di un servizio di avvio automatico ritardato e di pre-arresto del sistema
Il comando SC integrato è stato aggiornato in Windows Vista in modo da mostrare i servizi configurati come servizi di avvio automatico ritardato:
Utilizzo di SC per la visualizzazione del tipo di avvio
Utilizzo di SC per la visualizzazione del tipo di avvio (Fare clic sull'immagine per ridurla)
Utilizzo di SC per la visualizzazione del tipo di avvio
Utilizzo di SC per la visualizzazione del tipo di avvio (Fare clic sull'immagine per ingrandirla)
Il comando SC, purtroppo, non fornisce informazioni sui servizi che hanno richiesto la notifica di pre-arresto del sistema, ma per verificare se un servizio ha accettato la notifica di pre-arresto del sistema è possibile impiegare l'utilità PsService di Sysinternals:
Visualizzazione dello stato di pre-arresto del sistema
Visualizzazione dello stato di pre-arresto del sistema (Fare clic sull'immagine per ridurla)
Visualizzazione dello stato di pre-arresto del sistema
Visualizzazione dello stato di pre-arresto del sistema (Fare clic sull'immagine per ingrandirla)

Mark Russinovich è un Technical Fellow di Microsoft nella Platform and Services Division. È coautore di Microsoft Windows Internals (Microsoft Press, 2004) (in inglese) e spesso partecipa come oratore a conferenze su IT e sviluppo. Si è unito a Microsoft con la recente acquisizione dell'azienda che ha cofondato, Winternals Software. Ha inoltre creato Sysinternals, dove ha pubblicato le utilità Process Explorer, Filemon e Regmon.


 Dal redattore: L'angolo trofei
Dal redattore
L'angolo trofei
Joshua Trupin

SONO ARRIVATO A TRENT'ANNI senza vincere mai niente. Da sempre, sotto la striscia del gratta e vinci trovo solo faccine tristi. Scartando le caramelle scopro immancabilmente la scritta "Riprova, sarai più fortunato". Per non parlare del totocalcio.
Con un curriculum del genere, non c'è da stupirsi se sono quasi impazzito quando ho finalmente vinto qualcosa. TechNet Magazine è stata premiata dalla Society for Technical Communication (STC) con quattro riconoscimenti. Ogni numero è frutto di un lavoro intenso ed è meraviglioso vedere riconosciuti tanti sforzi. Vorrei pertanto dedicare un ringraziamento particolare al personale, agli autori e al loro prezioso contributo.
In allegato al numero di marzo/aprile 2006 era incluso il puzzle-poster della guida ad Active Directory. La popolarità del numero è stata tale che ancora oggi ce ne vengono richieste continuamente delle copie. L'STC ha premiato il nostro poster con il più alto riconoscimento per le guide software.
Anche due dei nostri articoli sono stati premiati. Sia "Playing with Exchange in a Sandbox" (in inglese) di Greg Taylor e Simon Shepherd, comparso nel numero di agosto 2006 sia "Deconstructing Common Security Myths" (in inglese), di Jesper Johansson e Steve Riley, comparso nel numero di maggio/giugno 2006, hanno ricevuto premi di merito dall'STC.
TechNet Magazine ha inoltre vinto l'Award of Excellence for Scholarly &Professional Journals. Non potrei essere più orgoglioso del riconoscimento e lo stesso vale per tutti i membri della nostra squadra.
Ma non ci riposeremo sugli allori. In questo numero, Mark Russinovich esplora le modifiche del kernel in Windows Vista, offrendo informazioni preziose ai professionisti IT coinvolti nella distribuzione desktop o nei servizi di supporto. Nel numero è inoltre trattato nei dettagli SQL Server: dall'uso di metadati di indice, alla partizione di tabelle, alle opzioni di alta disponibilità, ai suggerimenti per il clustering.
Non facciamo mai festa qui a One TechNet Magazine Plaza (colpa delle scadenze), ma ogni tanto ci piace respirare aria nuova. Per questo parteciperemo al Microsoft TechoEd a Orlando dal 4 all'8 giugno 2007 (vedere microsoft.com/teched). Vieni a conoscere alcuni tra i premiati autori ed editori di TechNet Magazine. E visto che ci sono doni e regali in programma, il vincitore potresti essere tu! -JOSHUA TRUPIN
Un grazie ai seguenti esperti e tecnici di Microsoft: Vijay Bharadwaj, Paul Bowden, Elden Christensen, Manish Karla, Michael Murgolo, Rajeev Nagar, John Peng, Mark Russinovich, Abraham Samuel, Mark Scurrell, Jim Truher, George Walters e Buck Woody.

Joshua Trupin


 Toolbox: Nuovi prodotti per professionisti IT
Toolbox
Nuovi prodotti per professionisti IT
Grog Steen

Gestione della sincronizzazione della rete
ViceVersa Pro
www.tgrmn.com

A meno che l'infrastruttura non consista di una sola casella, probabilmente è necessario spostare continuamente i file da un ambiente all'altro. Dai file di log alle versioni delle applicazioni, ai backup del database, i dati sono sempre in movimento attraverso la rete. Ed è importante sapere cosa copiare per poter mantenere sincronizzati ambienti diversi. Per la maggior parte dei professionisti IT, spostare manualmente i file fra gli ambienti non è accettabile, oltre a non essere raccomandabile in quanto può causare cattive sincronizzazioni.
Il software ViceVersa Pro di TGRMN permette di automatizzare e pianificare facilmente queste attività. L'applicazione fornisce quattro diverse modalità di copia. La modalità Basic Synchronization fornisce la sincronizzazione dall'origine alla destinazione e Advanced Synchronization offre la sincronizzazione bidirezionale di file e directory con rilevamento file. Le altre due modalità sono Backup (per il mirroring dell'origine) e Consolidation.
Mentre la modalità Backup effettua il mirroring dall'origine alla destinazione aggiungendo ed eliminando file da quella destinazione, è possibile scegliere la replica dei file, che copia solo i file alla destinazione. Questo è molto utile nel caso di utenti che eliminano materiale in modo imprevisto. La sincronizzazione bidirezionale si comporta come suggerisce il nome, con l'aggiunta del rilevamento di conflitti ed eliminazioni. Se un file viene modificato sia all'origine che alla destinazione prima della successiva sincronizzazione, viene rilevato un conflitto e il problema può essere corretto manualmente. Il metodo per il consolidamento è simile a quello della sincronizzazione bidirezionale, ma non tiene traccia di conflitti o eliminazioni.
Protezione contro gli errori di copia e la perdita di dati
Protezione contro gli errori di copia e la perdita di dati (Fare clic sull'immagine per ridurla)
Protezione contro gli errori di copia e la perdita di dati
Protezione contro gli errori di copia e la perdita di dati (Fare clic sull'immagine per ingrandirla)
ViceVersa Pro può essere utile nelle attività di distribuzione log grazie alle funzionalità integrate di compressione e crittografia dei file in modalità Backup. L'applicazione comprime i file di origine nel formato standard gzip, che può essere poi protetto da password.
L'applicazione fornisce inoltre una buona funzionalità integrata di confronto file, tuttavia è possibile impostare ViceVersa Pro affinché utilizzi un programma esterno di confronto file. Per supportare un ambiente globale, ViceVersa può gestire caratteri e percorsi Unicode lunghi più di 256 caratteri. L'applicazione offre inoltre supporto incorporato per la sincronizzazione con l'ora Internet, pertanto la si può impostare con la propria casella locale NTP o qualsiasi server NTP esterno se si autorizzano richieste in uscita dall'ambiente che utilizzeranno l'applicazione.
Può succedere che l'utilizzo della larghezza di banda sia problematico, soprattutto se il traffico scorre attraverso una rete VPN o WAN. In tali casi ViceVersa consente di ridurre l'entità della larghezza di banda utilizzata dall'applicazione per ogni attività di sincronizzazione. Ciò può essere d'aiuto inoltre per assicurare la risposta a livello di produzione dai server su cui o da cui si sta copiando. In alternativa è possibile impostare una soglia massima di utilizzo della CPU, che contribuisce ad assicurare la disponibilità del server quando l'applicazione è in esecuzione.
ViceVersa Pro protegge contro gli errori di copia e la perdita dei dati utilizzando un algoritmo di copia sicuro. L'applicazione esegue inoltre controlli di ridondanza ciclici di verifica per assicurare l'integrità dei dati. Le attività di sincronizzazione possono essere pianificate per esecuzione in quasi qualsiasi intervallo, compresa la modalità in tempo reale (in questa modalità i file vengono sincronizzati man mano che sono aggiunti o eliminati dalle cartelle di sincronizzazione).
Un'altra interessante funzionalità di ViceVersa Pro è che l'interfaccia utente lascia vedere tutte le operazioni in anteprima prima di eseguirle. Questo permette di assicurarsi di copiare ciò che si desidera copiare; non c'è niente di peggio che ritrovarsi file di log da due gigabyte nella directory di sistema.
Nel complesso, se si è alla ricerca di uno strumento di sincronizzazione, completo di ogni funzionalità e a basso prezzo, ViceVersa Pro può soddisfare tutte le esigenze.
Prezzo:59.95 Dollari USA per singolo utente.

Amministra i tuoi dischi di sistema
Partition Manager 8.0 Professional Edition
www.partition-manager.com/corporate/professional
Se stai cercando un'applicazione che ti aiuti ad amministrare i dischi del sistema, Partition Manager 8.0 Professional Edition di Paragon Software Group è certamente da prendere in considerazione.
La funzionalità principale di questa applicazione basata su Windows® offre un'interfaccia intuitiva gestita da procedura guidata, che permette di creare, eliminare e formattare facilmente le partizioni del disco rigido e modificarne la visibilità, nei formati FAT16/32, NTFS, Ext2/3 o HPFS. Inoltre è possibile ridimensionare le partizioni esistenti o spostarle da un disco a un altro.
Gli utenti più avanzati possono effettuare conversioni tra tipi di file system come NTFS da FAT16/32 o da Ext2 a Ext3 e viceversa. La copia di una partizione da un disco all'altro ridimensiona automaticamente la partizione alla dimensione del disco; ciò può rivelarsi utile per estendere l'unità dati sul sistema senza dover copiare tutti i file manualmente. Una pratica funzionalità della versione 8.0 è la capacità "Hot Resize" che permette di aumentare le dimensioni di una partizione attiva di NTFS senza riavviare Windows.
Aumenta la dimensione di una partizione attiva di NTFS senza riavviare
Aumenta la dimensione di una partizione attiva di NTFS senza riavviare (Fare clic sull'immagine per ridurla)
Aumenta la dimensione di una partizione attiva di NTFS senza riavviare
Aumenta la dimensione di una partizione attiva di NTFS senza riavviare (Fare clic sull'immagine per ingrandirla)
Un'altra utile funzionalità dell'edizione professionale è la capacità di convertire dischi dinamici in dischi fondamentali in client Windows 2000, Windows XP e Windows Server® 2003. Partition Manager supporta dischi con capacità pari ad almeno 500 GB (limite di testing Paragon e non limite fisico reale) oltre alle unità collegate FireWire e USB. Partition Manager supporta i dischi rigidi PATA (IDE), SATA e SCSI.
Partition Manager consente di creare un CD di ripristino (o un DVD o addirittura un disco floppy) da utilizzare nel ripristino del sistema dopo un guasto irreversibile del disco. Inoltre, se una partizione viene eliminata per sbaglio ma il sistema è ancora attivo, è possibile annullare la eliminazione della partizione attraverso l'interfaccia. È possibile addirittura modificare la dimensione del cluster del disco per ottimizzarne la prestazione. L'applicazione offre inoltre una visualizzazione virtuale prima dell'esecuzione, che consente di valutare le modifiche al disco prima di effettuarle concretamente.
Con Partition Manager 8.0 è inoltre possibile aggiornare un disco rigido nel sistema. L'applicazione consente di copiare una partizione o l'intera immagine del disco rigido su un nuovo disco, adattandone dimensione alla partizione di destinazione.
Infine Partition Manager contiene un'unità di deframmentazione disco incorporata, in grado di deframmentare unità piene fino al 99 percento. Si spera, tuttavia, che l'utente sia in grado di prendere le opportune misure prima di raggiungere tale stato.
Prezzo: 99,95 Dollari USA per Professional Edition.

Aggiungi il completamento automatico a SQL Editor
SQL Prompt: IntelliSense per SQL
www.red-gate.com/products/SQL_Prompt/index.htm

Sarebbe bello credere che tutti i database sono creati e strutturati con convenzioni di denominazione logiche in forma normalizzata, ma purtroppo tutti sappiamo che non è così. Quando svolgo le mansioni di amministratore del sistema o del database, spesso devo fare riferimento alla struttura della tabella per creare o eseguire query e ancora di più in veste di sviluppatore.
Benché SQL Server™ Management Studio per SQL Server 2005 abbia reso la vita molto più facile integrando un browser di oggetti nella sezione di visualizzazione struttura dell'interfaccia, ho ancora bisogno di una funzionalità utilissima di Visual Studio® IDE: IntelliSense®. Fortunatamente, Red-Gate Software offre SQL Prompt, che fornisce l'autocompletion agli editor di Microsoft SQL Server.
L'applicazione viene eseguita nella barra delle applicazioni e rileva quando si inizia a lavorare in un editor. Innanzitutto, SQL Prompt richiede le informazioni di connessione per quel database in modo da raggiungere e memorizzare nella cache tutti i dati degli oggetti. In tal modo vengono accelerate le prestazioni e si riduce il sovraccarico. Se si modificano costantemente oggetti sull'istanza del database, tuttavia, bisognerà ricordare di cancellare la cache (con un semplice doppio clic) per vedere le modifiche sull'elenco dei prompt.
Oltre a IDE di Visual Studio, Enterprise Manager, Query Analyzer e SQL Server Management Studio, SQL Prompt si integra direttamente con UltraEdit e EditPlus 2. Sulla scheda Opzioni dell'interfaccia utente Settings è possibile indicare le parole chiave SQL per attivare l'elenco candidati (ad esempio FROM, JOIN, EXEC e così via). Attivando SQL Prompt su SQL JOINS si fornisce inoltre l'istruzione ON (presumendo che si sia impostato il riferimento o che i campi abbiano lo stesso nome). Qui è possibile impostare anche i collegamenti di testo per l'inserimento di uno snippet di codice. Ad esempio, l'applicazione imposta "ssf" seguito dal tasto TAB per compitare "SELECT * FROM". È possibile inoltre far sì che SQL Prompt converta automaticamente le parole chiave SQL in lettere maiuscole man mano che si digita. Questa funzionalità e gli snippet di codice faranno sicuramente risparmiare tempo.
Sulla scheda Candidates dell'interfaccia utente Settings, è possibile impostare SQL Prompt in modo che utilizzi nomi di colonne pienamente qualificati, prefisso con informazioni su proprietario/schema, inserisca i nomi tra parentesi quadre e inoltre imposti i tipi di funzionalità di SQL da visualizzare nell'elenco candidati. Se si utilizza SQL, questo è un utile strumento da aggiungere.
SQL Prompt rimarrà gratuito fino al rilascio della versione 3.0, che al momento di questo articolo era in fase Beta finale. Il prezzo per la versione 3.0 non è stato ancora divulgato
Prezzo: Gratuito.

Calcola la dimensione della pagina
Atomic Web Page Size Calculator
www.info-pack.com/pagesize
La larghezza di banda degli utenti finali diventa sempre più ampia e le nuove tecnologie aiutano gli stessi utenti a realizzare contenuti Web in modo sempre più rapido. Le dimensioni della pagina rimangono, tuttavia, importanti. Tutti quei byte possono far lievitare il costo della larghezza di banda per i siti a traffico elevato.
L'utilità Atomic Page Size Calculator (Calcolatore atomico di dimensione della pagina) di Info-pack.com fornisce un metodo semplice e a basso costo per verificare il peso delle pagine dei siti Web. Basta digitare l'URL della pagina di cui si desidera conoscere le dimensioni e il programma cattura la pagina calcolando il peso di tutti i suoi elementi, comprese tutte le immagini indicate esternamente, articoli che potrebbero non apparire nei log di Web del dominio primario.
Tieni sotto controllo il costo della larghezza di banda
Tieni sotto controllo il costo della larghezza di banda (Fare clic sull'immagine per ridurla)
Tieni sotto controllo il costo della larghezza di banda
Tieni sotto controllo il costo della larghezza di banda (Fare clic sull'immagine per ingrandirla)
Il calcolatore supporta pagine, immagini e file JavaScript, pertanto dovrebbe essere possibile ottenere dati sulla maggior parte delle risorse della pagina. L'applicazione manda inoltre un avviso quando incontra una risorsa 404 "interrotta". Una volta ottenuta l'informazione sul peso per il proprio URL, basta fare clic sul pulsante Report per conoscere i dettagli della dimensione e le stime sul tempo necessario per eseguire il download di quell'URL nelle diverse velocità di connessione.
Sarebbe perfetto se l'applicazione potesse gestire URL multipli simultaneamente e forse ciò sarà possibile in una versione futura. Se si cerca una maniera rapida per controllare la dimensione delle pagine del team di sviluppo, quest'applicazione è una buona soluzione.
Prezzo:19,95 Dollari USA con acquisto diretto.

Scrivi a Toolbox
Se hai uno strumento o una utilità preferiti che vorresti vedere recensiti qui, scrivi all'autore all'indirizzo tntools@microsoft.com.
Grog Steen è un professionista IT oltre ad essere un appassionato imprenditore. È sempre alla ricerca di nuovi metodi e strumenti che aiutino a rendere più semplici operazioni e sviluppo per i professionisti IT.


 Utilit&#224; sotto i riflettori: SyncToy
Utilità sotto i riflettori
SyncToy
Jay Munro
Scarica il codice per questo articolo: SynctToy (971KB)

UNO DEI GRATTACAPO PRINCIPALI di professionisti IT, amministratori di rete e staff Help Desk è la chiamata di un utente che ha il computer impazzito e non dispone di un backup. Abituarsi a salvare il lavoro in rete piuttosto che localmente è una pratica difficile, anche per i più previdenti. SyncToy può fornire la soluzione adatta.
Originalmente progettato per sincronizzare le fotografie digitali tra fotocamera, computer e unità esterne, SyncToy fornisce un modo flessibile e affidabile di eseguire il backup per qualunque tipo di file. Compatibile con Windows Vista™, Windows® XP e Windows Server® 2003, SyncToy funziona con unità locali, esterne o USB, oltre che con condivisioni di rete o di gruppi di lavoro.
SyncToy utilizza un'architettura basata su coppie di cartelle, dove è possibile specificare una directory a sinistra e una a destra. È possibile creare tutte le coppie di cartelle desiderate e sincronizzare una o tutte le coppie con un solo clic. Per creare una coppia di cartelle, è disponibile una procedura guidata in quattro passaggi, che richiede di digitare o incollare un percorso o di accedere al percorso delle cartelle destra e sinistra. SyncToy riconosce la denominazione file UNC (ad esempio \MyServer\Joe_smith\backup) oltre al mapping e ai percorsi delle unità locali (E:\doc_backup). Una volta immessi i percorsi, scegliere una delle cinque azioni eseguite da SyncToy durante il confronto tra cartelle.
Sync (Sincronizza) Copia i file nuovi e aggiornati in entrambe le direzioni. Se un file viene rinominato o eliminato in una cartella, l'azione viene replicata nell'altra.
Echo (Eco) Copia i file nuovi e aggiornati e rinomina ed elimina i file solo dalla cartella a sinistra a quella a destra.
Subscribe (Sottoscrivi) Copia i file nuovi e aggiornati da destra a sinistra e soltanto se il file esiste già a sinistra. Le modifiche eseguite a sinistra non saranno replicate a destra.
Contribute (Partecipa) Copia i file nuovi e aggiornati da sinistra a destra, ignorando le eliminazioni.
Combine (Combina) Tiene più macchine in lockstep copiando i file che esistono in una cartella ma non nell'altra. I file che sono cancellati o rinominati non sono utilizzati né replicati.
Una volta scelta l'azione desiderata, completare selezionando un nome descrittivo per la coppia di cartelle. Al momento, SyncToy non consente di modificare i percorsi né di cambiare il nome una volta creata una coppia di cartelle. In caso di errori, selezionare la coppia di cartelle, fare clic sull'opzione di eliminazione e crearla di nuovo. È possibile impostare i file e le sottodirectory da includere e decidere se salvare o meno i file sovrascritti nel Recycle Bin (Cestino), attivo per impostazione predefinita.
Sincronizzazione di file con SyncToy
Sincronizzazione di file con SyncToy (Fare clic sull'immagine per ridurla)
Sincronizzazione di file con SyncToy
Sincronizzazione di file con SyncToy (Fare clic sull'immagine per ingrandirla)

La finestra di dialogo SyncToy principale visualizza le coppie di cartelle nella parte sinistra, oltre ai percorsi, le opzioni e le azioni per la coppia scelta. L'opzione All Folder Pairs (Tutte le coppie di cartelle) elenca tutte le coppie di cartelle e consente di eseguire il comando Preview (Anteprima) o Run All (Esegui tutto) per le coppie selezionate. L'anteprima simula l'esecuzione della sincronizzazione senza effettuare realmente le modifiche. Si tratta di un'operazione molto utile se si desidera pianificare sincronizzazioni impreviste. L'anteprima visualizza un report delle operazioni necessarie. Se non si verificano problemi, fare clic su Run (Esegui).
La funzione di pianificazione non è integrata, ma i file della Guida consentono di consultare le utilità di pianificazione di Windows Vista e Windows XP. Gli utenti non tecnici potrebbero avere bisogno di aiuto per la configurazione dell'opzione, da eseguire una volta sola dato che le modifiche alle coppie di cartelle, azioni e opzioni vengono eseguite in SyncToy.
Come tutti i Power Toys, SyncToy, benché scritto in base agli stessi standard dei software regolari, non prevede l'assistenza Microsoft, ma un supporto disponibile attraverso forum e documentazione. Devi fare affidamento solo su te stesso. La Guida è scritta per tutti i livelli di utilizzo e tratta nei dettagli le varie funzionalità. L'interfaccia utente è intuitiva e permette una navigazione di base fin dall'inizio.
Per eseguire il download di SyncToy e mostrare agli utenti come creare il back up dei file. Sonni più tranquilli per tutti.

Jay Munro è autore del team Windows User Assistance di Microsoft, specializzato in Internet Explorer. Precedentemente, è stato leader di progetto nei laboratori di PC Magazine.


 SQL: Domante&amp;Risposte: Ora legale, memoria del server e altro ancora
SQL: Domante&Risposte
Ora legale, memoria del server e altro ancora
A cura di Nancy Michell

Ora legale
D Date le modifiche imminenti all'ora legale negli Stati Uniti per conformarsi all'Energy Policy Act 2005 (Atto sulla politica energetica), devo aggiornare SQL Server™?
R La risposta è no. Al momento non sono richiesti aggiornamenti specifici a SQL Server per supportare le modifiche all'ora legale. Per le informazioni relative a data e ora, SQL Server si basa sul sistema operativo sottostante, vale a dire che se il sistema operativo riporta data e ora corrette, SQL Server riporterà e utilizzerà gli stessi valori. Per conformarsi alle modifiche imminenti all'ora legale, sarà richiesto di aggiornare le copie di Windows® come descritto in support.microsoft.com/kb/928388. Ciò è richiesto per tutti i sistemi operativi Windows precedenti a Windows Vista™ (che già contiene le modifiche) per conformità alle modifiche all'ora legale, compresi i sistemi operativi in cui è in esecuzione SQL Server. Anche in Australia sono previste modifiche. Vedere support.microsoft.com/kb/ il 912475.

Collegamento a Windows Vista
D Ho installato Windows Vista e adesso non riesco più a collegarmi a SQL Server 2005 sul mio sistema. Sono un amministratore locale e sono sempre riuscito a effettuare questa connessione senza problemi. Che cosa è successo?
R Questo tipo di comportamento è prevedibile in Windows Vista e SQL Server 2005 senza Service Pack 2 (SP2). Windows Vista contiene un nuovo modello di protezione (il controllo dell'account utente) che in effetti racchiude l'appartenenza dell'utente nel gruppo di amministratori locali e richiede di verificare le operazioni che richiedono privilegi amministrativi. Se si fa clic sul pulsante Consenti, le credenziali, che contengono il token amministratore, sono inviate all'applicazione. Nel caso di SQL Server Management Studio (SSMS) non viene visualizzata una finestra di dialogo perché non sono richieste autorizzazioni amministrative per eseguire solo lo strumento. Il problema è che, per impostazione predefinita, il ruolo amministratore di sistema SQL Server 2005 comprende il gruppo di amministratori locali dal sistema operativo, ed è questo che l'account utilizzava in precedenza per accedere a SQL Server. Poiché Windows Vista non invia tale autorizzazione, l'utente non riesce ad ottenere l'accesso.
Bisogna notare l'esecuzione di SQL Server 2005 senza SP2 non è supportata in Windows Vista e che SP2 contiene uno strumento che aggiungerà automaticamente l'account utente. Se si aspetta ancora SP2, la correzione è semplice. L'account utente Windows individuale deve essere aggiunto a SQL Server, in questo caso al ruolo amministratore di sistema. A tale scopo, fare clic con il pulsante destro del mouse su SQL Server Management Studio e scegliere Esegui come amministratore. Collegarsi a SQL Server e aggiungere il proprio account Windows al ruolo amministratore di sistema. Per ulteriori informazioni, vedere la Documentazione in linea di SQL Server.

Replica per componenti transazionali con viste
D Se ho una vista pubblicata e l'aggiorno, so che quella transazione sarà replicata. Se, invece, aggiorno la tabella di base di questa vista, tale transazione sarà replicata? E ancora, se ho una tabella pubblicata, ne creo una vista e aggiorno la vista invece della tabella di base, tale transazione sarà replicata?
R Supponendo che la tabella di base sia configurata come articolo in una pubblicazione (vale a dire, la tabella di base è stata configurata anche per la replica), ogni aggiornamento alla tabella di base sarà replicato.
Quando si replica una vista, per impostazione predefinita tutto ciò che è replicato come parte di una vista è la porzione di schema della vista o il codice dietro la vista, non i dati sottostanti (a meno che non si tratti di una vista indicizzata). Quindi, anche senza replica, ogni volta che si aggiorna una vista (in questo caso ciò vuol dire eseguire un'istruzione DML (Data Manipulation Language) con la vista come destinazione) si aggiornano effettivamente i dati nella tabella sottostante e non nella vista. Una vista è semplicemente un'archiviazione logica di un'istruzione di query senza alcuna archiviazione fisica associata (di nuovo, a meno che non si utilizzino viste indicizzate).

Memoria massima del server
D Ho un computer in cui sono in esecuzione Windows Server® 2003 e SQL Server 2000, con 5 GB di RAM. Utilizzo lo switch /3GB per aumentare lo spazio virtuale di indirizzi in modalità utente, lo switch /PAE per caricare la versione di estensione indirizzo fisico (PAE) del kernel Windows e impostare Address Windowing Extensions (AWE) Enabled su 1 (attivando le pagine di blocco in memoria). Con le estensioni AWE attivate, l'opzione di memoria massima del server configurerà solo la dimensione della cache dati o la dimensione di tutte le cache buffer (dati, processi, sessioni e così via)? Poiché soltanto la cache dati può utilizzare la memoria mappata AWE, se configuro la memoria massima del server su 4 GB, la cache dati utilizzerà soltanto 1 GB (la porzione mappata da AWE) o potrà utilizzare anche questo 1 GB aggiuntivo? Continuerà, inoltre, a utilizzare tutti gli altri consumatori di memoria nello spazio di indirizzi standard o competerà con essi?
R La memoria massima del server limiterà sempre l'intera dimensione pool di buffer; tuttavia, l'unico consumer di memoria che potrebbe fare uso della memoria mappata AWE è la cache dati.
Per quanto riguarda la prima domanda, anche con AWE attivato, la memoria massima del server limita l'intero pool di buffer, ma chi non utilizza cache dati non utilizzerà mai alcuna porzione della memoria mappata AWE.
Per quanto riguarda la seconda domanda, la cache dati utilizzerà la memoria mappata AWE e, inoltre, ogni altra memoria nel pool di buffer che sarà ritenuta appropriata da SQL Server; l'utilizzo non sarà limitato soltanto alla memoria AWE, semplicemente è il solo consumer che può utilizzare la memoria AWE. Se si hanno dubbi sulle funzioni dello switch /3GB, vedere il blog di Raymond Chen.

Profiling e prestazioni
D Ho SQL Server 2005 con mirroring in produzione. Quando avvio SQL Server Profiler sul computer del database e scrivo i dati di traccia su file, noto una notevole riduzione delle prestazioni. Perché?
R La ragione della riduzione delle prestazioni dipende da dove è in esecuzione Profiler. Se Profiler è in esecuzione in modalità interattiva sul server, l'interfaccia utente di Profiler utilizza sia la memoria sia la CPU del server e ciò ha un impatto sulle prestazioni.
Se Profiler è in esecuzione in modalità interattiva su una workstation, le informazioni degli eventi si spostano attraverso la rete. Questo ha un impatto sulla produttività. Se è la stessa rete utilizzata per effettuare il mirroring, si noterà un impatto anche qui. Inoltre, se si archivia l'output di Profiler su una condivisione di rete, i dati vengono spostati attraverso la rete, con effetti negativi sulle prestazioni.
Probabilmente, il modo migliore per attenuare questi problemi è eseguire Profiler in modo non interattivo sul server in cui è in esecuzione l'istanza da analizzare e quindi trasportare l'output in un file locale. In tal modo si utilizzano risorse del server, tuttavia questo approccio ha generalmente il minimo impatto. Questo funziona molto meglio del file traccia Profiler (in memoria). Il file traccia utilizza la memoria di sistema in maniera più efficiente; dispone di buffer più ampi e li inserisce nel disco più efficacemente. Inoltre non dipende da processi esterni (come SQL Server Profiler).
Infine, i dati di traccia sono scritti su un file su disco mentre Profiler continua a realizzare il profiling. Il file di traccia è condiviso in modo che altri utenti possano vedere i dati di profilo in tempo reale in modalità remota. Se si chiama il file di traccia in modo interattivo, significa che Profiler è stato richiamato manualmente e si sta osservando l'output sulla schermata. I file di traccia possono essere creati a livello di programmazione senza alcun output visivo, motivo per cui si dovrebbero eseguire attività in modo non interattivo.
È possibile creare una condivisione su una directory locale e altri utenti possono accedere ai file presenti, e questo di solito funziona bene. Come indicato in precedenza, è preferibile non inviare output di traccia a un file su una condivisione remota, soprattutto a una condivisione cui si accede attraverso la stessa pipe di rete utilizzata per effettuare il mirroring.
Inoltre bisognerebbe scegliere soltanto la minima serie di eventi necessaria per la ricerca. Per la posizione del file di traccia è necessario scegliere l'unità più veloce del sistema (che sia preferibilmente diversa dal database e dalle unità di log delle transazioni SQL Server). Se si verifica ancora una riduzione significativa delle prestazioni, bisogna dividere gli eventi in due o più tracce, ognuna con un disco rigido di destinazione diverso. Anche se le tracce vengono destinate allo stesso disco rigido, la divisione apporterà dei benefici in quanto ogni traccia possiede una serie di buffer individuale. Per ulteriori informazioni vedere sp_trace_create e gli argomenti relativi nella Documentazione in linea di SQL Server.

Problemi relativi al clustering
D Sto cercando di installare SQL Server su un cluster in cui è in esecuzione Windows Server 2003. Ogni volta che provo, ricevo il messaggio di errore "Impossibile eseguire le operazioni necessarie in almeno un nodo del cluster." In sqlstp.log è contenuta la dichiarazione:
Script file copied to '\\SERVER01\ADMIN$\SERVER01_MSSQLSERVER.iss' successfully.
Installing remote service (SERVER01)...
An error occured in the service create (SERVER01): 1069...
Qual è la causa del problema?
R Questo errore può essere causato da motivi diversi. La procedura di installazione installa Windows NT® Service su tutti i nodi selezionati per gestire in modalità remota il processo di installazione sui computer individuali. Pertanto è necessario essere consapevoli di alcuni problemi che possono accadere.
In primo luogo, gli utenti dell'account di dominio potrebbero utilizzare dei criteri di gruppo che negano l'autorizzazione "log on as service (accedi come servizio)". Ricordare che i criteri di dominio hanno la precedenza sui criteri del computer locale. Assicurarsi di utilizzare un account libero da queste restrizioni.
In secondo luogo, l'account connesso del computer in cui si sta eseguendo l'installazione dovrebbe avere accesso amministrativo su tutti i nodi per i motivi seguenti: il processo di installazione master richiede l'accesso al registro di sistema remoto per tutti i computer; l'installazione copia cnvsvc.exe sulla directory Windows del computer remoto; oppure l'installazione utilizza Windows API standard che utilizzano soltanto l'autorizzazione dell'account per accedere ai computer remoti. Per queste ragioni è necessario collegarsi con accesso amministrativo in tutte le modalità, per impostazione predefinita.

Piano di ripristino di emergenza
D Sto considerando se utilizzare il mirroring del database (modalità asincrona) o la distribuzione dei log per implementare la strategia Ripristino di emergenza nei miei database SAP. La mia produzione di siti DR avrà una connessione a banda larga da 100 MB non dedicata alla sessione di mirroring. La connessione sarà condivisa fra diverse sessioni di mirroring o anche con altri server DR.
Se sussiste un problema di rete che impedisce al record del log di essere inviato al database di mirroring, il computer tenterà un retry?
Quando la sessione di mirroring è sospesa, esiste un periodo di conservazione? E infine, oltre alle viste del sistema, esistono informazioni log di cui mi posso servire per monitorare il traffico di mirroring e la trasmissione dei record di log?
R Iniziamo rispondendo alla domanda: qual è la logica delle operazioni di retry del mirroring del database? È possibile analizzare questo argomento in due modi: Per prima cosa, se esiste un problema di rete temporaneo, lo stato della sessione di mirroring è disconnesso. Esiste un valore di timeout di rete predefinito pari a 10 secondi; ciò significa che un record di log non può essere inviato dal database principale al database di mirroring. In tali casi, il database principale continuerà a essere in esecuzione in modalità "esposta" e la transazione eseguirà il commit dal lato client. Una volta risolto il problema di rete, la sessione di mirroring verrà ritentata automaticamente, senza intervento da parte dell'utente. La sessione tenterà il recupero utilizzando i record di log; i partner si sincronizzeranno per primi e una volta recuperata la posizione, lo stato sarà sincronizzato.
In secondo luogo, se si verifica un problema di ripristino, lo stato della sessione di mirroring viene sospeso. Un problema di ripristino significa che il database di mirroring non è in grado di eseguire il commit dei record del log sul proprio database. I problemi di ripristino sono principalmente causati dal mancato ritrovamento di un file fisico o da spazio su disco insufficiente. In tali casi, il database principale continuerà ad essere eseguito in modalità esposta e la transazione eseguirà il commit dal lato client. Dopo che sono stati risolti manualmente i problemi di ripristino sul server di mirroring, occorre intervenire sulla sessione di mirroring:
ALTER DATABASE <db> SET PARTNER RESUME;
Per quanto riguarda i periodi di conservazione, la risposta è che, a prescindere se la sessione di mirroring è disconnessa o sospesa, i record di log saranno mantenuti finché la sessione non sarà ripristinata e tutti record, dal momento in cui la sessione è stata sospesa fino al momento del suo ripristino, verranno protetti sul mirror. In sostanza, mentre la sessione di mirroring è disconnessa o sospesa, il log nel computer principale non può essere troncato, in quanto ciò bloccherebbe la catena di ripristino del log. Questo significa che il log del computer principale aumenterà senza limiti finché la sessione non verrà ripristinata. Pertanto, non esiste effettivamente alcun limite di conservazione nella sessione di mirroring; l'unico vincolo reale è lo spazio sul disco del server principale per la memorizzazione del log, in quanto questo non può essere troncato.
Infine, non esiste un file di log specifico da utilizzare per monitorare il mirroring. SQL Server 2005 fornisce a questo scopo uno strumento GUI chiamato Database Mirroring Monitor, che permette agli amministratori di sistema di osservare e aggiornare lo stato e configurare soglie di avviso su diversi criteri di misurazione di prestazioni chiave. Ciò consente di ricevere un avviso quando il mirroring non viene eseguito correttamente. La questione essenziale per le prestazioni nel mirroring del database è se i record del log siano elaborati in maniera tempestiva. Per ulteriori informazioni sul monitoraggio del mirroring del database, consultare l'articolo Monitoring Mirroring Status (in inglese) all'indirizzo msdn2.microsoft.com/fr-fr/library/ms365781.aspx.

Si ringraziano i seguenti professionisti IT di Microsoft per la propria esperienza tecnica: Chad Boyd, Sandu Chirica, Alan Doby, Kaloian Manassiev, Luciano Moreira, Ivan Penkov, Sivagaminathan Rajarethinam, Deborah To, Patrick Woodward, Buck Woody, Stanley Yau e Warren Young.


 The Cable Guy: Il protocollo DHCPv6
The Cable Guy
Il protocollo DHCPv6
Joseph Davies

Il protocollo DHCP (Dynamic Host Configuration Protocol) è stato progettato per l'assegnazione di indirizzi IP ed altre informazioni di rete ai computer, in modo che essi siano in grado di comunicare automaticamente sulla rete. Attraverso una rete IPv6, non occorre in realtà DHCP per configurare gli indirizzi, ma possono sussistere buone ragioni per utilizzarlo. DHCP per IPv6 (DHCPv6) è in grado di
fornire la configurazione dell'indirizzo con controllo di stato o le impostazioni di configurazione senza controllo di stato agli host IPv6i. Gli host IPv6 utilizzano vari metodi per configurare gli indirizzi:
Configurazione automatica dell'indirizzo senza controllo di stato Viene utilizzata per configurare sia indirizzi locali collegati che ulteriori indirizzi locali non collegati scambiando messaggi di richiesta router e messaggi di annuncio router con i router vicini.
Configurazione automatica dell'indirizzo con controllo di stato Viene utilizzata per configurare indirizzi locali non collegati attraverso l'uso di un protocollo di configurazione come DHCP.
Un host IPv6 esegue la configurazione automatica di un indirizzo senza controllo di stato e utilizza un protocollo di configurazione come DHCPv6 basato sui seguenti flag nel messaggio di annuncio router inviato da un router vicino:
Flag di configurazione per indirizzo gestito, noto anche come flag M. Se impostato su 1, questo flag indica all'host di utilizzare un protocollo di configurazione per ottenere indirizzi con controllo di stato.
Altro flag di configurazione con controllo di stato, noto anche come flag O. Quando viene impostato su 1, questo flag indica all'host di utilizzare un protocollo di configurazione per ottenere indirizzi con controllo di stato.
Combinando i valori dei flag M e O, il risultato è il seguente:
Entrambi i flag M ed O sono impostati su 0. Questa combinazione corrisponde a una rete senza un'infrastruttura DHCPv6. Gli host utilizzano gli annunci router per indirizzi locali non collegati e altri metodi (come la configurazione manuale) per configurare le altre impostazioni.
I flag M ed O sono entrambi impostati su 1. DHCPv6 viene utilizzato per entrambi gli indirizzi e altre impostazioni di configurazione. Questa combinazione è come DHCPv6 con controllo di stato, in cui DHCPv6 assegna gli indirizzi con controllo di stato agli host IPv6i.
Il flag M è impostato su 0 e il flag O è impostato su 1. DHCPv6 non è utilizzato per assegnare indirizzi, ma soltanto per assegnare altre impostazioni di configurazione. I router vicini sono configurati per annunciare prefissi di indirizzi locali non collegati da cui gli host IPv6 traggono gli indirizzi senza controllo di stato. Questa combinazione è nota come DHCPv6 senza controllo di stato: DHCPv6 non assegna gli indirizzi con controllo di stato agli host IPv6, bensì le impostazioni di configurazione senza controllo di stato.
Il flag M è impostato su 1 e il flag O è impostato su 0. In questa combinazione, DHCPv6 viene utilizzato per la configurazione dell'indirizzo ma non per altre impostazioni. Poiché gli host IPv6 hanno generalmente bisogno di essere configurati con altre impostazioni, come gli indirizzi IPv6 dei server Domain Name System (DNS), questa combinazione è improbabile.
Come DHCP per IPv4, i componenti di un'infrastruttura DHCPv6 comprendono client DHCPv6 che devono essere configurati, server DHCPv6 che forniscono la configurazione e agenti di inoltro DHCPv6 che convogliano messaggi tra client e server quando i client sono su subnet che non hanno un server DHCPv6.

Messaggi di DHCPv6
Come con DHCP per IPv4, DHCPv6 utilizza messaggi del tipo User Datagram Protocol (UDP). I client DHCPv6 sono in attesa di messaggi di DHCP sulla porta UDP 546. I server e gli agenti di inoltro DHCPv6 sono in attesa di messaggi di DHCPv6 sulla porta UDP 547. La struttura per i messaggi di DHCPv6 è molto più semplice di quella di DHCP per IPv4, che ha avuto origine nel protocollo BOOTP per supportare le workstation senza dischi. Nella Figura 1 viene mostrata la struttura dei messaggi DHCPv6 inviati tra client e server.
Figura 1 Messaggi DHCPv6 tra client e server
Figura 1 Messaggi DHCPv6 tra client e server (Fare clic sull'immagine per ridurla)
Figura 1 Messaggi DHCPv6 tra client e server
Figura 1 Messaggi DHCPv6 tra client e server (Fare clic sull'immagine per ingrandirla)
Il campo Msg-Type (Tipo Msg) da 1 byte indica il tipo di messaggio DHCPv6. Il campo Transaction-Id (ID transazione) da 3 byte è determinato da un client ed è utilizzato per raggruppare i messaggi di uno scambio di messaggi DHCPv6. Dopo il campo Transaction-Id (ID transazione), le opzioni di DHCPv6 sono utilizzate per indicare l'identificazione di client e server, gli indirizzi, e le altre impostazioni di configurazione. Per l'elenco delle opzioni DHCPv6 definite, vedere la RFC 3315, in base al riferimento nella barra laterale "Risorse RFC di DHCPv6".
Le opzioni di DHCPv6 sono formattate con il formato Type-Length-Value (TLV). Nella Figura 2 viene mostrata la struttura delle opzioni di DHCPv6.
Il campo Option-Code (Codice opzione) da 2 byte indica un'opzione specifica. Il campo Option-Len (Lunghezza opzione) da 2 byte indica la lunghezza del campo Option-Data (Dati opzione) sotto forma di byte. Il campo Option-Data (Dati opzione) contiene i dati per l'opzione.
C'è una struttura di messaggio separata per i messaggi scambiati tra gli agenti di inoltro e i server per registrare ulteriori informazioni. Nella Figura 3 viene mostrata la struttura di questi tipi di messaggi.
Figura 2 Struttura delle opzioni di DHCPv6
Figura 2 Struttura delle opzioni di DHCPv6 (Fare clic sull'immagine per ridurla)
Figura 2 Struttura delle opzioni di DHCPv6
Figura 2 Struttura delle opzioni di DHCPv6 (Fare clic sull'immagine per ingrandirla)
Il campo Hop-Count (Conteggio hop) da 1 byte indica il numero di agenti di inoltro che hanno ricevuto il messaggio. Un agente di inoltro in ricezione può scartare il messaggio se questo eccede il numero di hop massimo configurato. Il campo Link-Address (Indirizzo collegamento) da 16 byte contiene un indirizzo locale non collegato che è assegnato ad un'interfaccia connessa alla subnet su cui si trova il client. Dal campo Link-Address (Collegamento indirizzo), il server è in grado di determinare l'ambito corretto dell'indirizzo da cui assegnare un indirizzo. Il campo Peer-Address (Indirizzo peer) da 16 byte contiene l'indirizzo IPv6 del client che ha inviato il messaggio in origine o l'agente di inoltro precedente che ha trasmesso il messaggio. Oltre al campo Peer-Address (Indirizzo peer) vi sono le opzioni DHCPv6 che contengono l'opzione del messaggio di inoltro, che a sua volta contiene il messaggio in fase di trasmissione e altre opzioni. L'opzione del messaggio di inoltro fornisce un incapsulamento dei messaggi scambiati tra client e server.
Non ci sono indirizzi di broadcast definiti per l'IPv6. Pertanto, l'uso dell'indirizzo di tramissione limitato per alcuni messaggi DHCPv4 è stato sostituito con l'uso dell'indirizzo All_DHCP_Relay_Agents_and_Servers di FF02::1:2 per DHCPv6. Per esempio, un client DHCPv6 che tenta di scoprire la posizione del server DHCPv6 sulla rete invia un messaggio di Sollecito dal suo indirizzo locale collegato al FF02::1:2. Se sulla subnet dell'host c'è un server DHCPv6, questo riceve il messaggio di sollecito e invia una risposta appropriata. Di solito, un agente di inoltro DHCPv6 sulla subnet dell'host riceve il messaggio di sollecito e lo invia a un server DHCPv6.
Figura 3 Struttura dei messaggi tra relay e server
Figura 3 Struttura dei messaggi tra relay e server (Fare clic sull'immagine per ridurla)
Figura 3 Struttura dei messaggi tra relay e server
Figura 3 Struttura dei messaggi tra relay e server (Fare clic sull'immagine per ingrandirla)

Scambio di messaggi con controllo di stato
Uno scambio di messaggi DHCPv6 con controllo di stato per ottenere indirizzi e impostazioni per la configurazione dell'IPv6 (quando i flag M e O in un annuncio router ricevuto sono impostati su 1) consiste generalmente nei messaggi seguenti:
  • Un messaggio di sollecito inviato dal client per individuare i server.
  • Un annuncio inviato da un server per indicare che può fornire indirizzi e impostazioni di configurazione.
  • Un messaggio di richiesta inviato dal client per richiedere indirizzi e impostazioni di configurazione da un server specifico.
  • Un messaggio di risposta inviato dal server richiesto che contiene indirizzi e impostazioni di configurazione.
Se è tra client e server, l'agente di inoltro invia messaggi Relay-Forward al server contenenti i messaggi incapsulati di sollecito e richiesta provenienti dal client. Il server invia i messaggi Relay-Reply dell'agente di inoltro che contenogno i messaggi incapsulati di annuncio e risposta per il client. Per un elenco completo dei messaggi di DHCPv6, vedere la Figura 4.
Figure 4 Messaggi di DHCPv6 (Close Figure 4)

Messaggio di DHCPv6 | Descrizione | Equivalenza del messaggio DHCP a IPv4
Sollecito | Inviato da un client per individuare i server. | DHCPDiscover
Annuncio | Inviato da un server in risposta a un messaggio di sollecito per indicare la disponibilità. | DHCPOffer
Richiesta | Inviato da un client per richiedere le impostazioni degli indirizzi o della configurazione da un server specifico. | DHCPRequest
Conferma | Inviato da un client a tutti i server per determinare se la configurazione di un client è valida per il collegamento attivo. | DHCPRequest
Rinnovo | Inviato da un client a un server specifico per estendere la durata degli indirizzi assegnati e ottenere le impostazioni di configurazione aggiornate. | DHCPRequest
Riesecuzione del binding | Inviato da un client a qualunque server quando non viene ricevuta una risposta al messaggio di rinnovo. | DHCPRequest
Risposta | Inviato da un server a un client specifico in risposta a un messaggio di sollecito, richiesta, rinnovo, riesecuzione del binding, richiesta di iInformazioni, conferma, rilascio o rifiuto. | DHCPAck
Rilascio | Inviato da un client per indicare che il client non utilizza più un indirizzo assegnato. | DHCPRelease
Rifiuto | Inviato da un client a un server specifico per indicare che l'indirizzo assegnato è già in uso. | DHCPDecline
Riconfigurare | Inviato da un server a un client per indicare che il server ha impostazioni di configurazione nuove o aggiornate. Il client invia poi un messaggio di richiesta di rinnovo o di informazioni. | N/D
Richiesta di informazioni | Inviato da un client per richiedere le impostazioni di configurazione (ma non gli indirizzi). | DHCPInform
Relay-Forward | Inviato da un agente di inoltro per inviare un messaggio a un server. Relay-Forward contiene un messaggio incapsulato del client come l'opzione Relay-Message di DHCPv6. | N/D
Relay-Reply | Inviato da un server per inviare un messaggio a un client tramite un agente di inoltro. Relay-Reply contiene un messaggio del server incapsulato come l'opzione Relay-Message di DHCPv6. | N/D

Scambio di messaggi senza controllo di stato
Uno scambio di messaggi senza controllo di stato di DHCPv6 per ottenere soltanto impostazioni di configurazione (quando il flag M è impostato su 0 e il flag O è impostato su 1 in un annuncio router ricevuto) consiste generalmente nei messaggi seguenti: Un messaggio di richiesta informazioni inviato dal client DHCPv6 per richiedere impostazioni di configurazione da un server e un messaggio di risposta inviato da un server, contenente le impostazioni di configurazione richieste.
Per una rete IPv6 che abbia router configurati in maniera tale da assegnare prefissi d'indirizzo senza controllo di stato agli host IPv6, lo scambio a due messaggi di DHCPv6 può essere utilizzato per assegnare server DNS, nomi di domini DNS, ed altre impostazioni di configurazione che non sono contenute nel messaggio di annuncio router.

Supporto DHCPv6 in Windows
Windows Vista™ e la prossima versione di Windows Server®, nome in codice "Longhorn," contengono un client DHCPv6. Il client DHCPv6 tenta una configurazione basata su DHCPv6 a seconda dei valori dei flag M e O nei messaggi di annuncio router ricevuti. Per utilizzare quindi il DHCPv6, si devono configurare i server e gli agenti di inoltro DHCPv6 in modo da revisionare ogni subnet IPv6 e configurare poi il router IPv6 per impostare questi due flag con i loro valori appropriati. Se ci sono annunci router multipli per una data subnet, questi devono essere configurati in modo da annunciare gli stessi prefissi degli indirizzi senza controllo di stato e i valori dei flag M e O. Gli host IPv6 che operano con Windows® XP o Windows Server 2003 non comprendono un client DHCPv6 e ignorano quindi i valori dei flag M e O negli annunci router ricevuti.
Un router IPv6 che opera con Windows Vista o Windows Server "Longhorn" può essere configurato in maniera da impostare il flag M su 1 negli annunci router con il comando "netsh interface ipv6 set interface InterfaceName managedaddress=enabled". Allo stesso modo, è possibile impostare il flag O su 1 negli annunci router con il comando "netsh interface ipv6 set interface InterfaceName otherstateful=enabled".
La versione Beta 2 di Window Server "Longhorn" supporta un agente di inoltro DHCPv6 e una configurazione senza controllo di stato di DHCPv6 col servizio del server DHCP. Il servizio del server DHCP può essere configurato affinché le opzioni di DHCPv6 siano distribuite a tutti i client DHCPv6 nello scambio di messaggi a due messaggi di DHCPv6 precedentemente descritto. Microsoft ha in progetto di includere il supporto per l'operazione DHCPv6 con controllo di stato, includendo la capacità di creare ambiti per l'indirizo IPv6 nello snap-in DHCP, nella versione Beta 3 di Windows Server "Longhorn".
Risorsa RFC su DHCPv6
Alcune RFC relative a DHCPv6 (in inglese):
  • RFC 3315: Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
  • RFC 2462: IPv6 Stateless Address Autoconfiguration
  • RFC 3633: IPv6 Prefix Options for DHCP version 6
  • RFC 3646: DNS Configuration Options for DHCPv6
  • RFC 3736: Stateless DHCP Service for IPv6

Joseph Daviesè un autore tecnico di Microsoft. Dal 1992 tiene corsi e scrive su argomenti legati alle reti Microsoft. Ha scritto cinque libri per Microsoft Press ed è autore della rubrica mensile Cable Guy su TechNet.


 Windows Powershell: Potenza delle variabili
Windows Powershell
Potenza delle variabili
Don Jones

Se si utilizza un linguaggio di scripting basato su Windows, come VBScript o KiXtart, si è già fatta l'abitudine a variabili che rappresentano solo una specie di meccanismo di archiviazione dei dati. Anche in Windows PowerShell sono disponibili delle variabili, ma sono molto più potenti delle variabili dei linguaggi di script precedenti. Le variabili di Windows
PowerShell sono associate alle classi sottostanti in Microsoft® .NET Framework. All'interno del framework le variabili sono degli oggetti, ovvero contengono dei dati che possono essere manipolati in vari modi. In effetti, proprio le notevoli capacità delle variabili di Windows PowerShell™ sono il motivo per cui il linguaggio di scripting di Windows PowerShell non prevede funzioni intrinseche di manipolazione dei dati. Queste funzioni non sono necessarie, dal momento che le variabili già assolvono ai medesimi compiti.

Dichiarazione delle variabili
Sebbene il cmdlet New-Variable in Windows PowerShell consenta di dichiarare una variabile e di assegnarle un valore iniziale, non è necessario utilizzare il cmdlet. Per creare una nuova variabile in modo immediato, è sufficiente assegnarle un valore:
$var = "Hello"

In Windows PowerShell i nomi di variabile iniziano sempre con un simbolo di dollaro ($) e possono contenere una combinazione di lettere, numeri , simboli o addirittura spazi (anche se quando si utilizzano degli spazi, è necessario racchiudere la variabile tra parentesi, in questo modo ${Variabile} = "Ciao"). Nell'esempio viene creata una nuova variabile denominata $var a cui viene assegnato il valore iniziale "Hello". Poiché in questo caso il valore è una stringa di caratteri, Windows PowerShell utilizzerà il tipo di dati String per memorizzare il valore. In termini di .NET Framework, si tratta della classe System.String, che forse dispone della funzionalità più integrata di qualunque altro tipo di variabile. Se, ad esempio, si desidera visualizzare una versione tutta in minuscolo del valore in $var, è possibile utilizzare il codice:
PS C:\> $var.ToLower()
hello
PS C:\>
Il metodo ToLower è incorporato nella classe System.String e produce una rappresentazione tutta in minuscolo del valore della stringa, senza tuttavia modificare il contenuto effettivo della variabile $var. Per visualizzare un elenco completo di tutte le operazioni che è possibile eseguire con la classe System.String, passare una variabile di tipo stringa al cmdlet Get-Member, come la seguente:
$var | get-member
Nella Figura 1 è illustrato l'output, con un paio di dozzine di metodi da utilizzare per la manipolazione delle stringhe. Quasi tutte le funzionalità garantite dalla funzione di manipolazione delle stringhe di VBScript, in Windows PowerShell vengono fornite tramite i metodi della variabile di stringa.
Figura 1 Output della classe System.String
Figura 1 Output della classe System.String (Fare clic sull'immagine per ridurla)
Figura 1 Output della classe System.String
Figura 1 Output della classe System.String (Fare clic sull'immagine per ingrandirla)

In un contesto di amministrazione molte delle funzionalità delle variabili di tipo stringa sono più utili delle funzioni di stringa di un linguaggio come VBScript. Si supponga di aver creato uno script che consenta di leggere i percorsi UNC (Universal Naming Convention) da un file e di eseguire una determinata azione su tali percorsi. Si desidera quindi verificare, prima di tentare di utilizzare il percorso, se il percorso letto è effettivamente di tipo UNC. Il metodo StartsWith consente di ottenere la conferma che un valore di stringa inizia con i caratteri di barra rovesciata necessari per un percorso UNC:
PS C:\> $path = "\\Server\Share"
PS C:\> $path.StartsWith("\\")
True
PS C:\>
Poiché il metodo StartsWith restituisce un valore True o False, è possibile utilizzarlo nei costrutti logici:
if ($path.StartsWith("\\")) {
 # code goes here
}
In Windows PowerShell è inoltre disponibile una forma di completamento automatico per i metodi delle variabili, che consente di ridurre la quantità di testo da digitare. Se $var contiene una stringa, è possibile digitare
$var.
e premere Tab, per visualizzare il primo nome di metodo per la variabile $var. Se si preme di nuovo Tab, si passerà al metodo successivo, mentre se si preme Maiusc+Tab si tornerà al metodo precedente. In questo modo è possibile passare da un metodo disponibile all'altro, fino a individuare il metodo desiderato.

Confusione variabile
Fino a ora gli esempi proposti hanno consentito a Windows PowerShell di determinare il tipo di dati delle variabili. L'assegnazione di una stringa a una variabile forza essenzialmente la definizione di una variabile di classe System.String. L'assegnazione di un numero a una variabile, d'altra parte, in genere comporta la creazione di una variabile di tipo Integer (più propriamente, Int32 in cui è possibile memorizzare un intervallo di valori specifico). Ad esempio:
PS C:\> $int = 5
PS C:\> $int | get-member

  TypeName: System.Int32
In questo output troncato si nota come Windows PowerShell tratti $int come un Int32, che il proprio set di metodi e proprietà. Infatti, i metodi e le proprietà disponibili sono molto meno di quelli del tipo stringa.
La variabile $int viene definita come Int32 perché il valore non è compreso tra virgolette e perché il valore è costituito da soli numeri. Quando viene inserita tra virgolette, la variabile viene interpretata come una System.String.
Se si delega a Windows PowerShell la decisione del tipo di dati di utilizzare, non si otterrà sempre il risultato desiderato. Si supponga di dover leggere da un file dei valori che si desidera trattare come stringhe. Alcuni dei valori, tuttavia, potrebbero contenere solo cifre, facendo aumentare le possibilità che Windows PowerShell consideri la variabile come Int32 o di altro tipo numerico. Questo comportamento può causare problemi per gli script. Se Windows PowerShell non riconosce il valore come una stringa, non saranno disponibili tutti i metodi della classe System.String (e il funzionamento dello script potrebbe essere basato proprio su uno dei metodi non disponibili).
Come soluzione alternativa, è possibile forzare Windows PowerShell a trattare una variabile come di un certo tipo dichiarando il tipo al primo utilizzo della variabile. Ecco un esempio:
[string]$var = 5
In genere $var sarebbe stata una variabile di tipo Int32, ma qui si è forzato Windows PowerShell in modo che interpreti $var come una stringa, garantendo la disponibilità di tutti i metodi associati alla classe System.String. La dichiarazione del tipo di variabile è anche un pratico metodo di autodocumentazione del codice, poiché ora è ovvio il tipo di dati destinati alla variabile $var. Può risultare utile dichiarare sempre un tipo specifico per tutte le variabili, sottraendo completamente la decisione a Windows PowerShell. In tal modo si rende più prevedibile il comportamento degli script e, in alcuni casi, si evitano lunghe sessioni di debug.
Come prevedibile, la dichiarazione forzata delle variabili ha delle ripercussioni, ma non necessariamente negative. Nell'esempio seguente non si dichiara il tipo della variabile:
PS C:\> $me = 5
PS C:\> $me = "Don"
La variabile $me era inizialmente di tipo Int32, ma Windows PowerShell l'ha modificata in una variabile di tipo stringa all'aggiunta del valore "Don". Windows PowerShell può modificare il tipo di una variabile in base alle esigenze, purché la variabile non è stato già stata impostata esplicitamente come di un tipo specifico.
In questo esempio si è forzato $me come variabile di tipo Int32 utilizzando il nome tipo [int]:
PS C:\> [int]$me = 5
PS C:\> $me = "Don"
Cannot convert value "Don" to type
"System.Int32". Error: "Input string
was not in a correct format."
At line:1 char:4
+ $me <<<< = "Don"
Quando si è quindi tentato di assegnare alla variabile un valore di stringa, è stato visualizzato un messaggio di errore. Poiché la variabile $me è stata esplicitamente forzata come variabile Int32, Windows PowerShell ha tentato di convertire la stringa "Don" in un valore di numero intero. L'operazione era impossibile, né era possibile modificare il tipo di $me in variabile di stringa.

Di tutti i tipi
In Windows PowerShell sono disponibili molti tipi di variabile. È possibile utilizzare qualsiasi tipo .NET Framework (e i tipi disponibili sono centinaia). Tuttavia, in Windows PowerShell i tipi più comuni di dati sono accessibili tramite scelte rapide. Nella Figura 2 è riportato un elenco parziale, con 10 delle scelte rapide del tipo comunemente utilizzate. Per un elenco completo, consultare la documentazione di Windows PowerShell.
Figure 2 Scelte rapide comuni per i tipi (Close Figure 2)

Scelta rapida | Tipo di dati
[datetime] | Data oppure ora
[string] | Stringa di caratteri
[char] | Carattere singolo
[double] | Numero a doppia precisione a virgola mobile
[single] | Numero a precisione singola a virgola mobile
[int] | Numero intero a 32 bit
[wmi] | Istanza o insieme WMI (Windows Management Instrumentation)
[adsi] | Oggetto dei servizi di Active Directory
[wmiclass] | Classe WMI
[Boolean] | Valore True o False
È possibile dichiarare il tipo della variabile anche utilizzando il nome completo della classe .NET Framework, come segue:
[System.Int32]$int = 5
Questa tecnica consente di utilizzare i tipi che sono in .NET Framework, ma per i quali non sono disponibili scelte rapide specifiche in Windows PowerShell.

Estensione dei tipi
Forse l'aspetto più interessante di Windows PowerShell è la possibilità di estendere le funzionalità dei tipi di variabili. Nella cartella di installazione di Windows PowerShell (in genere %systemroot\system32\windowspowershell\v1.0, ma nei sistemi a 64 bit il percorso è leggermente diverso), è presente il file types.ps1xml. È possibile modificare il file in Blocco note o in un editor XML, come PrimalScript. Per impostazione predefinita, la classe System.String non è riportata, sebbene lo siano molti altri tipi. Tuttavia, è possibile aggiungere una nuova funzionalità al tipo System.String modificando il file types.ps1xml.
Dopo la modifica, è necessario chiudere e riavviare Windows PowerShell. È inoltre necessario verificare che i criteri di esecuzione locali degli script consentano l'esecuzione di script non firmati, poiché types.ps1xml non è firmato:
Set-executionpolicy remotesigned
Dopo il riavvio di Windows PowerShell, sarà possibile utilizzare la nuova funzionalità come segue:
PS C:\> [string]$comp = "localhost"
PS C:\> $comp.canping
True
PS C:\>
Come è possibile notare, si è aggiunta una proprietà CanPing alla classe System.String. Viene restituito un valore True o False a indicare se il computer locale è in grado di eseguire il ping dell'indirizzo contenuto nella stringa. Nella Figura 3 si noterà che la query WMI utilizza una variabile speciale, $this. La variabile $this rappresenta il valore corrente contenuto nella stringa ed è il modo in cui il contenuto della variabile di stringa viene passato nella query WMI.
Figure 3 Estensione del tipo System.String (Close Figure 3)
<Type>
  <Name>System.String</Name>
  <Members>
    <ScriptProperty>
      <Name>CanPing</Name>
      <GetScriptBlock>
      $wmi = get-wmiobject -query "SELECT *
FROM Win32_PingStatus WHERE Address = '$this'"
      if ($wmi.StatusCode -eq 0) {
        $true
      } else {
        $false
      }
      </GetScriptBlock>
    </ScriptProperty>
  </Members>
</Type>

Variabili al lavoro
In Windows PowerShell sono disponibili tipi di variabili flessibili e ricchi di funzionalità e un sistema altrettanto flessibile per l'estensione delle funzionalità dei tipi. Tali funzionalità ampliano in modo sorprendente le potenzialità degli script. Le variabili possono di fatto diventare la base di complessi script, superando in molti casi le funzionalità avanzate di solito disponibili in funzioni più complesse.
Ulteriori informazioni in linea
Per ottenere ulteriori informazioni sulle funzionalità di scripting di Windows PowerShell, è possibile ascoltare le trasmissioni webcast messe a disposizione degli utenti ogni secondo martedì del mese. Per iscriversi, visitare il sito Microsoft.com/events/series/donjonesscripting.mspx (in inglese).

20 febbraio 2007, Windows PowerShell: The Scripting Crash Course
Questa trasmissione webcast è un corso intensivo su variabili, costrutti, script e le funzioni di Windows PowerShell. Il corso dura un'ora e consente di toccare con mano quanto il semplice ma efficace linguaggio di scripting di Windows PowerShell renda più rapida l'automazione dell'amministrazoine di Windows®. Si esaminano inoltre i diversi strumenti di terze parti che rendono la creazione di script in Windows PowerShell ancora più indolore.

20 marzo 2007, Windows PowerShell: Functions, Filters, and Efficiency
Per imparare a creare del codice efficace e modulare in funzioni e filtri di Windows PowerShell. Durante la trasmissione si analizzano le robuste regole di ambito in Windows PowerShell che consentono di incapsulare completamente le funzioni e i filtri e si spiega come riutilizzare facilmente funzioni e filtri in progetti diversi. Si dimostra infine come sia possibile aggiungere le proprie funzioni personalizzate all'ambito globale in Windows PowerShell, in modo da facilitare la creazione di una raccolta di funzioni di utilità sempre a portata di mano.

17 aprile 2007, Windows PowerShell e WMI
Windows PowerShell può sfruttare tutta la potenza e le funzionalità di WMI. Durante la trasmissione si illustra non solo come utilizzare Windows PowerShell per accedere a WMI, ma anche come passare oggetti e insiemi di WMI tramite la pipeline di Windows PowerShell. Si descrive inoltre l'utilizzo di proprietà e metodi di WMI negli script di Windows PowerShell e si illustrano le funzionalità di protezione e configurazione sottostanti di WMI.

22 maggio 2007, Windows PowerShell: Converting from VBScript
Si desidera convertire gli script, o anche solo le proprie competenze, da VBScript a Windows PowerShell? In questa trasmissione webcast si spiega come si fa. Si illustra come in Windows PowerShell siano compresi tutti i costrutti e le funzionalità principali di VBScript e quanto sia semplice tradurre le proprie competenze di VBScript in questo nuovo ambiente di amministrazione. Viene inoltre descritta la conversione degli strumenti di VBScript nel linguaggio di scripting nativo di Windows PowerShell. Si esamina infine l'originale struttura di Windows PowerShell e si mostra come iniziare a utilizzare il linguaggio di scripting di Windows PowerShell nel modo più efficace ed efficiente possibile.

19 giugno 2007, Windows PowerShell: Under-the-Hood Extensions
In questa trasmissione webcast si scopre come Windows PowerShell utilizzi la potenza e flessibilità di .NET Framework per gestire i dati, mettendo a disposizione degli utenti centinaia di funzioni incorporate per la gestione di stringhe, date e altri tipi di dati. La novità di Windows PowerShell è la possibilità di estendere queste funzioni utilizzando gli script e nella trasmissione si illustra come creare variabili di stringhe che non solo contengano un nome di computer, ma consentano anche di ottenere informazioni sullo stato di funzionamento del computer. La trasmissione inoltre si propone di insegnare agli utenti come si creano variabili di data e ora in grado di formattare automaticamente i propri dati, senza utilizzare funzioni esterne. Ascoltare l'intera sessione per scoprire come creare in pochi minuti tutti i nuovi tipi di funzionalità in Windows PowerShell, rendendo l'amministrazione di Windows più rapida e semplice.

Don Jones è il Responsabile progetti e servizi di SAPIEN Technologies e coautore di Windows PowerShell: TFM (SAPIEN Press). È possibile contattare Don all'indirizzo www.ScriptingAnswers.com (in inglese).


 Hey, Scripting Guy!: Risposte alle domande sull'unit&#224; organizzativa...per soli 5 centesimi
Hey, Scripting Guy!
Risposte alle domande sull'unità organizzativa...per soli 5 centesimi
Gli Scripting Guys di Microsoft
Scarica il codice per questo articolo: HeyScriptingGuy2007_03.exe (151KB)

D Come posso visualizzare una finestra di dialogo che mi consenta di selezionare una OU da Active Directory?

Di certo, se noi Scripting Guys avessimo ricevuto un nichelino per ogni volta che ci è stata posta quella domanda avremmo guadagnato solo $37,15. Ma se guadagnassimo un nichelino per ogni persona che volesse rivolgerci questa domanda, senza aver mai trovato il tempo di farla effettivamente, saremmo ricchi. Dopotutto, non siamo diventati Scripting Guys per denaro, ma per la soddisfazione di aiutare le persone a svolgere le loro attività di amministrazione del sistema in modo più semplice e veloce.
Nota: dal punto di vista tecnico siamo diventati Scripting Guys per denaro. Ma poi il nostro manager ci ha detto, "Voi ragazzi potete guadagnare molto denaro, ma solo se siete disposti a lavorare sodo e a produrre soltanto software di qualità superiore". Quello è stato il momento in cui abbiamo deciso che il denaro non era tutto.
Non importa. Il punto è che molte persone vorrebbero sapere come visualizzare una finestra di dialogo che consenta loro di scegliere una OU e, per estensione, eseguire la connessione a tale OU utilizzando uno script. In un recente messaggio di posta elettronica era scritto "È stato illustrato come visualizzare una finestra di dialogo che ci consenta di scegliere delle cartelle e dei file. Perché non è stato illustrato come visualizzare una finestra di dialogo che consenta di scegliere una OU da Active Directory®?"
Bene, tanto per cominciare, è vero che abbiamo illustrato come visualizzare una finestra di dialogo che consenta di scegliere una cartella ed è possibile trovare un esempio proprio qui. Abbiamo anche illustrato come visualizzare una finestra di dialogo che consenta di scegliere i file; in caso di dubbi consultare microsoft.com/technet/scriptcenter/resources/qanda/jan05/hey0128.mspx. Entrambi gli articoli appena indicati sono stati ricevuti correttamente e gli utenti stanno utilizzando tali tecniche nei loro script. Quindi, per quale motivo non abbiamo illustrato come visualizzare una finestra di dialogo che consenta la selezione di una OU da Active Directory? Esiste una cospirazione da parte di Microsoft o c'è un altro motivo?
No di certo. Un momento: è esattamente quello che direbbe qualcuno coinvolto in una cospirazione. La verità è che esiste effettivamente una buona ragione perché non abbiamo illustrato come visualizzare una finestra di dialogo che consente di scegliere una OU da Active Directory: non esiste alcuna finestra di dialogo. Come si dice nel baseball, non si può colpire ciò che non si può vedere. E come diciamo nello script, non è possibile visualizzare ciò che non esiste.
Pertanto riteniamo che sia così per l'articolo di questo mese. Alla prossima.
Che fortuna! Secondo gli editor di TechNet Magazine, non è così per questo mese. "Allora cosa possiamo fare se non esiste una finestra di dialogo come questa"? hanno detto. "Voi siete gli Scripting Guys, perbacco. Non potete creare una finestra di dialogo proprio per risolvere questo problema? Noi pensavamo che voi ragazzi poteste fare qualunque cosa relativa allo script".
Inutile dirlo, gli editor alla TechNet Magazine sono stati mal informati. Vi occupate di tutto ciò che si riferisce allo script? Non esattamente. La verità è che noi Scripting Guys, quando si tratta dello script, sappiamo come fare solo una cosa.
Fortunatamente, tuttavia, quella cosa consiste nel creare una finestra di dialogo che consente di scegliere una OU da Active Directory. Date un'occhiata alla Figura 1.
Si tratta di un tipo di script lungo, vero? Come si dice: non si può fare un'omelette senza rompere delle uova. Analogamente, non si può costruire una finestra di dialogo personalizzata senza rompere delle uova (abbiamo avuto fame a metà strada durante la stesura di questo articolo e dovevamo fermarci per fare uno spuntino). Adesso siamo sazi e vedremo se possiamo spiegare come funziona questa operazione.
Stiamo cercando di utilizzare il modello a oggetti di Internet Explorer® per creare una pseudo finestra di dialogo. L'intento è quello di creare un’istanza di Internet Explorer, raccogliere delle OU da Active Directory e visualizzare tali OU in una casella di riepilogo all’interno di una finestra di Internet Explorer. Attenderemo finché l'utente non seleziona una OU, non recupera l'ADsPath dell’elemento selezionato e non chiude "la finestra di dialogo"; a quel punto procederemo con l’operazione.
Nota: questa finestra di dialogo sarà la più elaborata e la più bella mai creata? Sì, se per "più elaborata e più bella" si intende un qualcosa di talmente semplice da non presentare nemmeno un pulsante OK o Annulla. Ma, a nostra difesa, l'idea è di fornire semplicemente il framework di base. Se si vuole abbellire o modificare la finestra di dialogo, lo si può fare autonomamente.
Se avessimo avuto un nichelino per ogni volta che abbiamo detto "Spiacente, dovete cavarvela da soli," saremmo ricchi. Inviate le donazioni a The Scripting Guys c/o TechNet Magazine.
Per far rientrare la spiegazione relativa alla nostra tecnica nello spazio assegnatoci, dovremo sorvolare su alcune cose. Ad esempio, tutto ciò che diremo sul seguente blocco di codice è che questo crea un’istanza di Internet Explorer di 350-400 pixel e, di conseguenza, nasconde ad esempio la barra degli indirizzi e la barra di stato:
Set objExplorer = CreateObject( _
    "InternetExplorer.Application")

objExplorer.Navigate "about:blank"
objExplorer.ToolBar = 0
objExplorer.StatusBar = 0
objExplorer.Width= 350
objExplorer.Height = 400
objExplorer.Left = 400
objExplorer.Top = 400
objExplorer.Visible = 1
Naturalmente, in questo modo otterremo una finestra di Internet Explorer vuota. Per ottenere l'elenco delle OU nel nostro dominio, è necessario effettuare una ricerca di Active Directory. Non è possibile spiegare i pro e i contro della ricerca di Active Directory; per informazioni, dare un'occhiata alla serie in due parti nello Script Center (microsoft.com/technet/scriptcenter/resources/tales/sg0405.mspx). Quello che possiamo fare è indicare il codice da utilizzare per recuperare il Nome e l’ADsPath per ogni OU nel dominio fabrikam.com:
objCommand.CommandText = _
    "SELECT Name, ADsPath FROM 'LDAP://DC=fabrikam,DC=com' WHERE objectCategory=
    'organizationalUnit' ORDER BY Name"
E proprio per semplificare le cose, abbiamo anche sistemato in ordine alfabetico le OU in base al nome. Si tratta della clausola ORDER BY Name (Ordina per nome). (Nessun problema; dopotutto, questo è il nostro compito.)
Quando viene richiamato il metodo Execute, viene restituito un recordset composto da tutte le OU trovate in fabrikam.com. Il passaggio successivo consiste nel visualizzare ciascuna di quelle OU in una casella di riepilogo.
Dunque come viene eseguita questa operazione? Innanzitutto, è necessario creare l’intera casella di riepilogo in memoria. Per chi comincia, ciò significa utilizzare questa riga di codice per memorizzare il tag <SELECT> in una variabile denominata strHTML:
strHTML = "<select size = '20' name='OUList' style='width:300px'>"
Cosa facciamo con questa riga di codice? Creiamo semplicemente una casella di riepilogo HTML standard (operazione eseguibile con il tag <SELECT>). Durante l’operazione, alla casella di riepilogo viene assegnato il nome OUList e viene configurata con una larghezza di 300 pixel (300px) per visualizzare 20 elementi alla volta. Se si conosce il codice HTML, il codice su indicato dovrebbe risultare familiare.
Successivamente, è necessario aggiungere alcuni elementi (ossia, alcune OU) alla casella di riepilogo. Per fortunata coincidenza, il nostro recordset contiene informazioni su ciascuna OU nel dominio. Per questo motivo, è possibile impostare un ciclo Do Until che scorre in ciclo l’intero recordset, recupera le informazioni e aggiunge ciascuna OU alla casella di riepilogo. All’interno del ciclo, viene utilizzato il seguente codice (si tratta sempre del codice HTML standard per l'aggiunta di elementi a una casella di riepilogo) per aggiungere ciascuna OU, configurando l'elemento in modo che il nome della OU sia visualizzato nell'elenco e, se si fa clic su quella OU nella casella di riepilogo, l'ADsPath venga inviato allo script:
strHTML = strHTML & "<option value= " & _
    Chr(34) & objRecordSet.Fields
    ("AdsPath").Value & Chr(34)
strHTML = strHTML & ">" & objRecordSet.
    Fields("Name").Value
Perché inviare l'ADsPath allo script? È facile. Supponiamo invece di aver inviato il nome della OU. Se il Nome è, per esempio, Finanza, sarà difficile associarla a quella OU; dopotutto, "Finanza" non è una stringa di associazione ADSI (Active Directory Services Interface) valida. Tuttavia, se viene restituito ADsPath (LDAP://ou=Finance,dc=fabrikam,dc=com), l’associazione diventa facile. Questo perché l'ADsPath è esattamente ciò di cui abbiamo bisogno per individuare ed effettuare una connessione a un oggetto in Active Directory.
Casualmente, viene visualizzato il Nome nella casella di riepilogo perché si presuppone che le OU selezionate abbiano nomi unici. Potrebbe non essere questo il caso; ad esempio, le OU Nord America\Ricerca ed Europa\Ricerca hanno lo stesso nome (Ricerca). Se le OU selezionate hanno nomi duplicati, nella casella di riepilogo si potrebbe utilizzare una proprietà differente, ADsPath o distinguishedName. È una decisione da prendere in autonomia. (Ecco un altro nichelino!)
Comunque, si noti che stiamo ancora creando la casella di riepilogo nella memoria: ogni elemento aggiunto alla casella viene aggiunto alla variabile strHTML. Rientra tutto nel progetto: l’intero codice per la casella di riepilogo viene salvato nella variabile strHTML, il valore di tale variabile viene utilizzato per aggiungere effettivamente la casella di riepilogo alla nostra istanza di Internet Explorer.
Dopo aver aggiunto tutte le OU, si utilizza questa riga di codice per indicare la fine della casella di riepilogo:
strHTML = strHTML & "</select>"
A questo punto, la variabile strHTML contiene tutta la codifica HTML richiesta per creare una casella di riepilogo e, meglio ancora, una casella di riepilogo in cui ogni elemento rappresenta una OU in Active Directory. Ciò significa che ora è possibile assegnare il valore di strHTML alla proprietà InnerHTML del nostro documento di Internet Explorer:
objExplorer.Document.Body.InnerHTML = strHTML
L’operazione fornisce una casella di riepilogo che visualizza tutte le OU in un dominio.
Ma aspettate, non abbiamo ancora finito. È necessario, ad esempio, un codice che consenta di sospendere lo script fino a quando l'utente non avrà selezionato una OU nella finestra di dialogo; senza di essa, la casella di riepilogo può essere visualizzata e lo script continua l’esecuzione indipendentemente dal fatto che l'utente effettui o meno una selezione. Attenzione! Per evitare che si verifichi uno scenario di questo tipo, utilizzare questo blocco di codice:
Do While objExplorer.Document.Body.All.OUList.Value = ""
    Wscript.Sleep 300
Loop
In pratica, il nostro lavoro consiste nel controllare il valore della casella di riepilogo (che, come si può ricordare, è stato denominato OUList, lo stesso nome che uno degli Scripting Guys ha dato a sua figlia). Se il valore è una stringa vuota (cioè se non è stato selezionato alcun elemento), si sospende semplicemente lo script per 300 millisecondi poi il ciclo prosegue e si effettua nuovamente il controllo. Questa operazione continua: a) per sempre; b) finché l'utente seleziona un elemento nella lista di controllo; c) finché l'utente chiude la finestra di Internet Explorer.
Si supponga che l'utente selezioni una OU nella casella di controllo. In tal caso, prendere il Valore (ossia ADsPath della OU) e assegnarlo a una variabile denominata strTargetOU:
strTargetOU = objExplorer.Document.Body.All.OUList.Value
Utilizzare poi il metodo Quit per eliminare l'istanza di Internet Explorer come mostrato di seguito:
objExplorer.Quit
A questo punto, l'operazione è quasi terminata. Controllare innanzitutto se strTargetOU è uguale a una stringa vuota:
If strTargetOU = "" Then
    Wscript.Quit
End If
Se così fosse, significa che l’utente ha chiuso Internet Explorer senza selezionare una OU; quindi, utilizzare il metodo Wscript.Quit per terminare lo script. (Se l'utente non ha selezionato alcuna OU si presuppone che non sia realmente interessato a eseguire lo script.) Se strTargetOU non è uguale a una stringa vuota, tuttavia, è sufficiente restituire il valore della variabile:
Wscript.Echo strTargetOU
Naturalmente, in uno script reale è possibile proseguire ed eseguire l’associazione alla OU in Active Directory invece di restituire semplicemente ADsPath. Il senso è chiaro: devi cavartela da solo.
Come indicato e come si può vedere nella Figura 2, non è la finestra di dialogo più elegante, ma funziona ed è più facile che dover digitare un ADsPath (supponendo che si conosca anche l'ADsPath). Inoltre, consente di personalizzare il codice e la finestra di dialogo in modo da adattarli alle esigenze personali.
Figura 2 Una semplice finestra di dialogo di script
Figura 2 Una semplice finestra di dialogo di script

A questo punto, se avessimo un nichelino per ogni articolo scritto sulla visualizzazione di una finestra di dialogo che consente di selezionare una OU da Active Directory guadagneremmo 5 centesimi in più rispetto a quanto percepito generalmente da TechNet Magazine.
Ma attenzione, non ci lamentiamo.

Gli Scripting Guys di Microsoft lavorano o, per meglio dire, sono stipendiati da Microsoft. Quando non si dedicano al baseball (o a varie altre attività) da giocatori, allenatori o semplici spettatori essi gestiscono il TechNet Script Center. Consultare la pagina www.scriptingguys.com.


 Exchange Queue &amp; A: Log delle transazioni, cmdlet, gestione remota e molto di pi&#249;
Exchange Queue & A
Log delle transazioni, cmdlet, gestione remota e molto di più
KC Lemson and Nino Bilic

D Perché sono state diminuite le dimensioni del log delle transazioni a 1 MB in Microsoft® Exchange Server 2007?
R In Exchange 2007 esiste la cosiddetta distribuzione dei log, che è la tecnologia di supporto di un paio di nuove funzionalità chiamate Replica continua locale (LCR) e Replica continua cluster (CCR). Quando tale funzionalità è attivata a livello dei gruppi di archiviazione, i log delle transazioni dei gruppi di archiviazione sono copiati dai gruppi di archiviazione in esecuzione alla copia. I log sulla copia dei gruppi di archiviazione sono ripetuti nel database per tenerlo aggiornato. Questa è ovviamente una spiegazione semplificata di cosa accade, ma rende l'idea.
Il problema è che i log delle transazioni non possono essere inviati alla copia dei gruppi di archiviazione, a meno che il log non sia chiuso sui gruppi di archiviazione di produzione. In breve, il log e00 (il log corrente nel primo gruppo di archiviazione) non può essere inviato finché non è pieno, non è stato chiuso e rinominato. Inoltre, dal momento che occorre fare un compromesso tra disponibilità e prestazioni, è possibile effettuare alcune impostazioni per controllare quanti log possono essere impiegati in questo processo. Queste impostazioni sono disponibili eseguendo il cmdlet Set-MailboxServer in Exchange Management Shell. Nel file della guida sono forniti i dettagli dei parametri esatti necessari.
Riassumendo, abbiamo diminuito la dimensione del log delle transazioni per minimizzare il numero di dati che non possono essere in sincronia tra due copie del gruppo di archiviazione. Ciò accade quando il disco rigido del database di produzione subisce un arresto e si richiede l'adozione di misure particolari per avviare il gruppo di archiviazione dalla copia. I log delle transazioni più piccoli potrebbero far perdere meno dati.
Ciò non significa che è possibile garantire una perdita di dati di solo 1 MB. Questi log sono, tuttavia, log delle transazioni, quindi è possibile che la perdita del log file di 1 MB contenga, ad esempio, una transazione COMMIT di 5 MB di dati. In tal caso, si perderebbero 5 MB di dati sulla copia: anche se si fossero ricevuti cinque log con i dati, l'ultimo log contenente pochi dati e la transazione COMMIT è essenziale.
In definitiva, spetta all'utente valutare il rischio, considerando i bisogni dell'azienda. Una piccola perdita di dati con un tempo di ripristino di pochi minuti potrebbe essere perfettamente accettabile, se paragonata all'alternativa di molte ore per il ripristino. Tratteremo in modo più esauriente questo argomento in futuro!

D Adesso che i log delle transazioni sono più piccoli, si "esauriranno" più velocemente?
R Quando si parla di Exchange, l'esaurimento si riferisce ai nomi dei log delle transazioni. In Exchange Server 2003, i nomi dei log delle transazioni sono:
E nn fffff.log
nn è il prefisso che cambia da un gruppo di archiviazione all'altro. Poiché nn rimarrà invariato per tutta la durata del gruppo di archiviazione, il numero dei log delle transazioni con nome univoco che possono essere creati per il gruppo di archiviazione è essenzialmente il valore "fffff", che corrisponde approssimativamente a un milione di log (nota: fare tante grasse risate). Alcuni dei nostri clienti hanno riscontrato questo limite sui server di posta occupati.
A partire da Exchange Server 2000, abbiamo fornito un aggiornamento rapido per visualizzare un evento nel log delle applicazioni quando ci si avvicina a tale limite. Per ulteriori informazioni, vedere support.microsoft.com/kb/896001.
A parte questo, cosa succede in Exchange 2007? Abbiamo appena detto che i log delle transazioni sono stati ridotti da 5 MB (la dimensione nelle versioni precedenti di Exchange) a 1 MB (la dimensione in Exchange 2007). Viene da chiedersi se occorre solo un quinto dei dati per esaurire i nomi personalizzati dei log delle transazioni.
La risposta è no. In Exchange 2007, il nome del log delle transazioni è in questo formato:
E nn ffffffff.log
notare che è possibile lavorare su "ffffffff" log, invece che sui "fffff" delle versioni precedenti di Exchange. A causa dei calcoli interni di Extensible Storage Engine (ESE), Exchange 2007 non è in grado di creare tutti i log "ffffffff". Crea, invece, "7fffffec" log, che sono sempre un numero notevole (se non ci credi, prova a fare la conversione da esadecimale a decimale).
Che cosa significa in realtà? In realtà, con Exchange 2007 è possibile creare circa 2048 volte tanti log rispetto alle versioni precedenti di Exchange. Assumendo che i log siano un quinto della dimensione:
2048 / 5 = 409.6
come si vede, il nuovo schema per denominare i log è in grado di gestire 409 volte più dati rispetto a quello vecchio. Ciò vale per il gruppo di archiviazione, non per il server, perché ogni gruppo di archiviazione avrà un prefisso di file di registro diverso (come e00, e01, e così via). È inoltre possibile creare 50 gruppi di archiviazione per server sulla versione Enterprise di Exchange 2007. Non è tanto facile esaurire velocemente i log delle transazioni!

D Come è possibile gestire i server Exchange 2007 in modalità remota?
R Ci sono molte opzioni per gestire il server Exchange 2007 in modalità remota. Innazitutto, è possibile installare gli strumenti di gestione Exchange 2007 su un computer separato dal server Exchange, se in tale computer viene eseguita sia la versione a 32 bit che quella a 64 bit di Windows® Server 2003 Service Pack 1 (SP1) o versioni successive, Windows Server 2003 R2 o Windows XP SP2 o versioni successive. Notare che l'installazione di qualunque dei ruoli del server (accesso client, cassetta postale, edge e cosi via) su un hardware a 32 bit non è supportata negli ambienti di produzione, ma è supportata l'installazione degli strumenti di gestione su un computer a 32 bit. Notare inoltre che nella versione iniziale di Exchange Server 2007 gli strumenti di gestione non sono supportati da Windows Vista™.
In alcune organizzazioni, il reparto IT crea un singolo server come server di gestione, installando tutti gli strumenti di gestione necessari per vari prodotti su questo server. In seguito, gli amministratori che hanno bisogno di utilizzare quegli strumenti accedono al server di gestione via Terminal Server per eseguire l'amministrazione remota. Nelle altre impostazioni, gli utenti installano gli strumenti di gestione sul desktop.
Dalla console o dalla shell è possibile eseguire alcune operazioni sui server della propria organizzazione. Nella console, i server sono visibili, in modo che si possano eseguire operazioni su di essi in modalità remota. Nella shell, molte delle attività supportano un flag di filtro di tipo -server per indirizzare un'operazione a un singolo server. Ci sono poche eccezioni, comunque, per i comandi eseguibili localmente, come il comando Get-NetworkConnectionInfo.

D Nell'ultima rubrica, si parlava di quanta RAM è consigliata per un server Exchange 2007. E per quanto riguarda la dimensione del file di paging?
R Per evitare eventuali errori di esaurimento della memoria virtuale sui server Exchange 2007, si consigliano le linee guida seguenti per determinare la dimensione del file di paging di sistema.
Se il server dispone di meno di 8 GB di RAM, la dimensione minima del file di paging dovrebbe essere la somma della RAM più 10 MB. Cosí, se il server ha 4 GB di RAM, la dimensione minima è 4 GB più 10 MB. La dimensione consigliata del file di paging, comunque, è la RAM moltiplicata per 1,5. Quindi, per un server da 4 GB, la dimensione è 6 GB.
Inoltre, la dimensione minima per il file di paging per un server con più di 8 GB di RAM è calcolata allo stesso modo, ovvero la RAM più 10 MB. La dimensione consigliata è, tuttavia, determinata diversamente. In sostanza, su un server con più di 8 GB di RAM, è bene moltiplicare per 1,5 la somma della RAM, se riscontrano errori di esaurimento della memoria virtuale con i file di paging più piccoli.
Notare che gli errori menzionati in questo caso non hanno niente a che fare con la frammentazione della memoria virtuale (un problema dei server Exchange 2000 ed Exchange 2003). Questi ultimi sono errori di popup reali registrati dal sistema che avvertono che la dimensione del file di paging è aumentata o il file di paging è troppo piccolo.

D Vorrei imparare a utilizzare Exchange Management Shell ma non ho mai utilizzato una riga di comando per amministrare i miei sistemi prima d'ora. Da dove dovrei iniziare?
R Innanzitutto, iniziamo con alcune nozioni fondamentali. Ogni cmdlet nell'Exchange Management Shell è costituito da un solo verbo ed un solo sostantivo. Ci sono soltanto pochi verbi usati da Exchange Management Shell: "Get" è utilizzato per recuperare le proprietà degli oggetti, "Set" per modificare le proprietà di un oggetto, "New" per creare nuovi oggetti e così via. I sostantivi di Exchange Management Shell includono molti concetti con i quali tutti gli amministratori Exchange sono già familiari (per esempio, Mailbox, Contact, Queue e OWAVirtualDirectory). Ci sono anche dei concetti nuovi per Exchange Server 2007 (come TransportRule, StorageGroupCopy e UMAutoAttendant). In pratica quindi, un cmdlet di base assomiglierà a qualcosa come New-Mailbox (che creerà una cassetta postale) o Get-Mailbox (che recupererà un elenco di cassette postali nell'organizzazione).
La maggior parte dei cmdlet, comunque, avrà bisogno di più informazioni specifiche su ciò che si sta cercando di realizzare esattamente. Se, ad esempio, si vuole modificare una proprietà di una cassetta postale, occorrerà specificare quale cassetta postale e quale proprietà. È possibile farlo attraverso i parametri. Se New-Sandwich fosse un cmdlet, i parametri potrebbero essere -NumeroDiFetteDiPomodoro 4, -Grano di Pane, e una varietà di altre opzioni simili che specificano in maniera più dettagliata la forma che si vuole conferire al sandwich (-SofficeBenLievitato$true-ahhhh slurp).
Una volta capita la divisione verbo-sostantivo, è possibile utilizzare l'esposizione della riga di comando nella procedura guidata Exchange Management Console (EMC) per familiarizzare con i cmdlet con i quali eseguire le operazioni. In EMC, vedere la creazione guidata di un nuovo utente. Al termine della procedura guidata, completata l'operazione, si visualizzerà una copia del comando che la procedura guidata ha eseguito all'interno del sistema (vedere la Figura 1). Premere Ctrl+C per copiare il contenuto della finestra di dialogo, incollare il cmdlet nel Blocco note e realizzare semplici file batch.
Figura 1 Esposizione della riga di comando per creare un nuovo utente
Figura 1 Esposizione della riga di comando per creare un nuovo utente (Fare clic sull'immagine per ridurla)
Figura 1 Esposizione della riga di comando per creare un nuovo utente
Figura 1 Esposizione della riga di comando per creare un nuovo utente (Fare clic sull'immagine per ingrandirla)
Se si vuole far pratica utilizzando i cmdlet (senza causare danni), un bel trucco è quello di mettere -WhatIf alla fine del comando. In tal caso, il sistema dirà che cosa accadrebbe se si esegue il comando, senza apportare effettivamente alcune modifiche al sistema.
Una volta che si ha familiarità con i cmdlet di base, come *-Mailbox, probabilmente se ne vorrà provare altri. Per trovare più cmdlet, utilizzare il cmdlet Get-ExCommand. Verrà visualizzato un elenco di tutti i cmdlet di gestione di Exchange. Per effettuare questa operazione Exchange Management Shell deve essere in esecuzione. Microsoft Command Shell o Windows PowerShell™ non è sufficiente per eseguire questa o qualunque altra attività di gestione di Exchange. Dal momento che l'elenco è molto lungo, utilizzare jolly di corrispondenza per trovare ciò che si cerca. Per esempio, Get-ExCommand *database* fornirà un elenco di tutti i cmdlet Exchange che contengono "database" nel nome come Dismount-Database, Move-DatabasePath e New-MailboxDatabase.
Se si pensa di conoscere parte del nome che si sta cercando, è possibile scorrere le opzioni. Ad esempio, è possibile digitare Get-Mailbox e premere il tasto TAB per cercare in tutti i cmdlet che hanno mailbox nel nome dell'attività. È possibile inoltre combinare la corrispondenza jolly e il completamento tramite tab. Per esempio, è possibile digitare Get-*Mailbox* e spostarsi con il tasto TAB attraverso le opzioni possibili.
Un altro semplice trucco è utilizzare la conferma. Ogni cmdlet ha una serie di parametri necessari per impostazione predefinita, i parametri fondamentali necessari per eseguire l'operazione. I cmdlet "Get", come Get-Mailbox, non richiedono nessun parametro. Per impostazione predefinita, Get-Mailbox restituirà un elenco di tutte le cassette postali di tutta l'organizzazione. L'elenco è limitato a 1.000 per impostazione predefinita. Per modificare questo limite massimo è possibile, ad esempio, digitare Get-Mailbox -ResultSize 2000. I cmdlet che creano o modificano oggetti (come Set o New) richiederanno le informazioni necessarie per l'oggetto che si vuole creare o modificare. Se si esegue New-Mailbox, per esempio, la shell chiederà password, database, nome e così via.
Per saperne di più sui parametri possibili su un certo cmdlet, utilizzare la guida: Help Move-DatabasePath. È anche possibile digitare solamente Move-DatabasePath, Move-DatabasePath -?, e così via. La guida fornirà una descrizione del cmdlet e un elenco dei parametri con lo scopo di ciascuno di essi. È possibile avere accesso alla guida anche con il cmdlet Get-Help. Non è fantastico digitare solo Get-Help? Non sarebbe bello eseguire quel cmdlet nel mondo reale con quelli che conosciamo?
Un altro modo di scoprire i possibili parametri su un cmdlet è utilizzare il completamento tramite tab sui nomi dei parametri. Digitare Get-Mailbox -S e premere TAB per scorrere i possibili parametri che iniziano con S.
E inoltre, c'è la guida estesa. Se non si trova ciò che si sta cercando offline, non dimenticare di controllare il contenuto della guida regolarmente aggiornato su go.microsoft.com/fwlink/?linkid=79421 e la guida di riferimento rapido su go.microsoft.com/fwlink/?linkid=64647.
Quando detto in precedenza costituisce un'introduzione a Exchange Management Console; queste informazioni rappresentano solamente una semplice infarinatura sulla potenza e la flessibilità della riga di comando. Tratteremo questo argomento in seguito in modo più approfondito.

D In Exchange Server 2003 ESM (Gestore di sistema di Exchange), era possibile vedere facilmente la dimensione della cassetta postale di tutti gli utenti. Quella funzionalità sembra essere scomparsa in Exchange 2007. C'è una funzione simile in Exchange 2007?
R Nella nuova console Exchange 2007, è possibile ottenere la dimensione di una cassetta postale sulla pagina proprietà generale della cassetta postale. Se si vuole visualizzare questa informazione per più utenti, si deve utilizzare Exchange Management Shell.
Se si esegue Get-MailboxStatistics, si ottengono i dati di un intero server (non solo un database specifico). Per impostazione predefinita, la dimensione non viene visualizzata: per ottenerla, eseguire il cmdlet con Format-List:
get-mailboxstatistics | format-list
Potrebbe essere preferibile scegliere ciò che si vuole visualizzare e trasmetterlo a una tabella. In questo esempio, si ottengono il nome visualizzato della cassetta postale, la dimensione totale dell'elemento, la dimensione totale dell'elemento eliminato e il database della cassetta postale:
Get-MailboxStatistics | Select-Object
displayname,totalitemsize,
totaldeleteditemsize,databasename
| Format-Table
A seconda delle informazioni ricercate, è possibile utilizzare una formattazione diversa per l'output. In questo esempio, il Format-Table sembra funzionare meglio di Format-List

KC Lemson è lead program manager del team Exchange Server. Il PIN della sua carta bancaria è 0000: non usarlo sempre nello stesso posto.
Nino Bilic Technical Lead, impiega il tempo libero ricevendo assegni da $1.000 da Bill in cambio dell'inoltro dei messaggi di posta elettronica.


 Controllo della protezione: Distribuzione di EFS: Parte 2
Controllo della protezione
Distribuzione di EFS: Parte 2
John Morello

Qualunque distribuzione di EFS (Encrypting File System) è composta essenzialmente di due parti: una parte che prevede la progettazione back-end che si concentra sugli agenti di gestione e recupero dei certificati e una parte che si concentra sull'implementazione di EFS rivolta all'utente. Il mese scorso ci siamo occupati della parte back-end, delle opzioni per il recupero di chiavi e dati
e del provisioning di certificati per i client. In questa sede, ci concentreremo sugli aspetti della distribuzione visti dall'utente finale, come i miglioramenti a Windows® Explorer, la scelta del percorso di file system da crittografare e la modalità di gestione delle opzioni di crittografia con Criteri di gruppo.

Stato di utilizzo di EFS
Una volta deciso di distribuire EFS, la prima fase consiste nel determinarne lo stato attuale d'utilizzo nell'organizzazione. EFS può essere utilizzato in modalità autonoma, in cui l'utente finale è l'unico responsabile della creazione e del backup delle chiavi di crittografia. Alcuni utenti avanzati dell'organizzazione potrebbero avere già utilizzato EFS in questa modalità, per cui è importante determinare chi siano per assicurare una transizione senza problemi a una distribuzione più gestita.
La prima volta che EFS viene utilizzato da un utente su un computer, Windows crea la seguente voce del registro di sistema seguente in HKEY_CURRENT_USER:
HKCU\Software\Microsoft\Windows NT\CurrentVersion\EFS\CurrentKeys\CertificateHash
È possibile utilizzare Microsoft ® Systems Management Server (SMS), gli script di accesso di Active Directory o altri strumenti per verificare la presenza di questa voce sulle macchine dell'organizzazione. Se questa voce del registro di sistema è presente, significa che l'utente ha già utilizzato EFS. Ciò non indica necessariamente che qualcuno stia utilizzando attualmente EFS né che vi siano dati crittografati. Se sul computer viene rilevata questa chiave di registro di sistema, esaminarlo attentamente per determinare la presenza di file crittografati.
Utilizzare cipher.exe e le opzioni /U e /N per creare un report sullo stato di crittografia di file e directory del computer. Ad esempio, per determinare se i dati del sistema sono crittografati, eseguire questo comando:
cipher /U /N
Il controllo del Registro di sistema e il report di crittografia potrebbero essere combinati in un unico script per verificare la presenza del valore del Registro di sistema e, in tal caso, generare un report dei file crittografati presenti sul computer. Una volta creati i report, sarà chiaro quali sono gli utenti a possedere file crittografati e sarà possibile migrarli verso la gestione centrale.
Per controllare l'applicazione di Criteri di gruppo durante l'implementazione, è utile creare due gruppi di protezione nel dominio per separare i computer in cui è in uso EFS da quelli in cui non lo è. I gruppi potrebbero essere ad esempio "SG-ComputersUsingEFS" per gli account computer delle macchine che già utilizzano EFS e "SG-ComputersNotUsingEFS" per quelle che non utilizzano EFS.

Controllo dell'utilizzo di EFS mediante Criteri di gruppo
Una volta chiaro chi utilizza o meno EFS, la fase successiva della distribuzione client consiste nel disattivare l'utilizzo autonomo di EFS per chi non lo sta attualmente impiegando. Questo è un passaggio importante nel processo di implementazione perché attivare e configurare EFS correttamente la prima volta è più semplice che eseguire la migrazione degli utenti che utilizzano certificati autofirmati. Completare questo passaggio solo dopo avere determinato quali utenti utilizzano già EFS, perché disattivando EFS tramite Criteri di gruppo gli utenti non saranno in grado di accedere ai file attualmente crittografati. Questi criteri sono disponibili in Editor oggetti criteri di gruppo in Configurazione computer\Impostazioni di Windows\Impostazioni di protezione\Criteri chiave pubblica\Crittografia File System.
Come illustrato in precedenza, questo valore dovrebbe essere abilitato soltanto sui computer dove EFS non è attualmente in uso, per non interrompere l'attività di chi già utilizza EFS. Nell'esempio citato quindi l'elenco di controllo di accesso (ACL) nell'Oggetto Criteri di gruppo che disattiva EFS consente soltanto al gruppo "SG-ComputersNotUsingEFS" di applicare Criteri di gruppo.

Crittografare o non crittografare
Una volta determinati i sistemi che utilizzano attualmente EFS e disattivato EFS su tutti gli altri fino alla distribuzione gestita, la fase successiva consiste nel determinare cosa crittografare in tale distribuzione gestita. In base alla modalità con cui vengono gestiti i sistemi client, il processo potrebbe variare da semplice a complesso.
La prima cosa da considerare quando si pensa a quali file crittografare è se gli utenti sono amministratori del sistema. Se gli utenti sono amministratori locali, è possibile soltanto istruirli e incoraggiarli a crittografare i dati riservati, ma non sarà possibile controllare la crittografia in modo gestito. Il motivo è semplice: un amministratore locale può creare file e directory ovunque nel file system. Così, se da una parte è possibile crittografare i percorsi comuni come Documenti, se l'utente crea una nuova directory in un altro percorso e vi salva delle informazioni riservate, è abbastanza difficile assicurarne la protezione. Oltre ai vantaggi per la sicurezza che si ottengono quando gli utenti finali non sono amministratori locali, questa opzione rende EFS più gestibile e protetto.
Un'altra informazione da tenere a mente su EFS è che si tratta di una crittografia per utente. In altre parole, tutto ciò che viene crittografato da un determinato utente può essere decrittografato solo da quello stesso utente, compreso l'account SYSTEM (fatta eccezione per Agente recupero dati o DRA). Ciò significa che se un file eseguibile o DLL viene crittografato con una chiave dell'utente e un'altra entità sul sistema tenta di accedervi, l'entità riceverà un errore di accesso negato. Pertanto, si sconsiglia di crittografare file o directory che contengono codice eseguibile a cui potrebbero richiedere l'accesso più entità su un sistema. Windows eviterà la crittografia di file in %SystemRoot% o file con attributo SYSTEM, ma non è insolito per i fornitori di software installare file binari in %Programmi% per servizi che potrebbero essere eseguiti dall'account SYSTEM. Ad esempio, tale approccio è comune tra i fornitori di portatili da utilizzare durante l'installazione di software di gestione di alimentazione e periferiche eseguite come servizi.
Tenendo conto di queste informazioni, quali sono le procedure consigliate per la crittografia EFS? La risposta dipende dalla configurazione dei sistemi dell'utente. In un ambiente ben gestito con un'immagine del sistema operativo standardizzata, è possibile automatizzare il processo di crittografia per utenti in base a percorsi di archiviazione dati predeterminati dall'immagine. Ad esempio, se gli utenti possono salvare i dati solo in %profilo utente%\Documenti, potrebbe essere necessario crittografare solo quella directory. (Nota: fare attenzione alla crittografia di Documenti se si utilizza il reindirizzamento della cartella). Se Documenti viene reindirizzato a un server, sarà necessario che tale server sia trusted per delega e che abbia accesso al profilo dell'utente. In casi di questo tipo è generalmente più facile crittografare la cache File non in linea (trattata più avanti).
In un ambiente meno gestito (dove gli utenti possono scrivere in più percorsi del file system), potrebbe essere interessante automatizzare la crittografia di alcuni percorsi di archiviazione comuni e istruire gli utenti su come crittografare gli altri percorsi in autonomia. Indipendentemente dall'ambiente è necessario eseguire la crittografia sempre a livello di directory piuttosto che di file per assicurare che tutti i file creati nella directory, compresi quelli temporanei, siano crittografati.

Percorsi di crittografia consigliati
Come regola generale, i percorsi da crittografare sono: %profilo utente%\Documenti, %profilo utente%\Dati applicazioni\Microsoft\Outlook (presupponendo che si utilizzi Microsoft Office Outlook® come client di messaggistica) e %profilo utente%\Desktop. La crittografia di Documenti consente di proteggere il percorso predefinito dei file salvati in Windows XP. La protezione della directory di Outlook assicura la crittografia dei messaggi di posta elettronica memorizzati localmente; fondamentale per gli utenti che eseguono Outlook 2003 in modalità cache predefinita. Infine, il desktop è spesso utilizzato come directory temporanea in cui gli utenti possono collocare i documenti a cui stanno lavorando o presentazioni che utilizzano spesso. È possibile che nell'organizzazione i percorsi predefiniti di queste directory siano stati modificati, pertanto le scelte di crittografia di EFS devono riflettere i percorsi utilizzati di solito nell'organizzazione.
Oltre a queste procedure consigliate generali, è necessario determinare l'eventuale presenza di applicazioni che potrebbero salvare informazioni riservate in percorsi alternativi. Ad esempio, alcune applicazioni salvano le informazioni utente in %Programmi%\Nomeappl piuttosto che nel profilo dell'utente. È importante determinare se tali applicazioni sono presenti sui sistemi client in modo da proteggere correttamente i dati in uso. In una situazione ottimale, è possibile configurare l'applicazione in modo da salvare le modifiche in un percorso specifico del profilo utente (come Documenti), in cui non sono necessarie ulteriori modifiche di EFS. Nella peggiore delle ipotesi, se l'applicazione richiede che i dati siano memorizzati nella directory Programmi, è possibile utilizzare EFS per crittografare soltanto la sottodirectory specifica di Programmi.
Infine, un'attenzione particolare merita la crittografia della directory temporanea (%TMP % e %TEMP%). Molti programmi di installazione di applicazioni utilizzano questa directory per l'espansione dei contenuti del pacchetto di installazione ed eseguono poi le operazioni di spostamento di file sui file espansi per collocarli nell'adeguato percorso in %Programmi%. Poiché un file spostato nello stesso volume conserva gli attributi originali, il file continuerà a essere crittografato anche dopo essere stato posizionato in %Programmi%. Se un utente diverso da quello che esegue il programma di installazione tenta di utilizzare questo file, gli sarà negato l'accesso. Spesso, tali problemi non si manifestano in messaggi di errore chiari che indicano la causa principale. Per questo motivo si consiglia di crittografare %TMP% soltanto negli ambienti ben gestiti, dove gli utenti finali non installano applicazioni autonomamente.

Protezione di file non in linea
File non in linea è una funzionalità disponibile a partire da Windows 2000 che consente agli utenti di eseguire una copia locale dei dati memorizzati su un file server. File non in linea consente agli utenti di lavorare su questi dati rimanendo disconnessi dal server e di sincronizzare le modifiche nel server alla connessione successiva. File non in linea non è soltanto una directory che contiene le copie di file del server. Si tratta di un database condiviso a livello di sistema eseguito nel contesto dell'account SYSTEM. In Windows XP, tale database può essere protetto con EFS. Alla luce di quanto detto prima e considerando la specificità per utente di EFS sorge una domanda. Come è possibile crittografare un database utilizzato da entità di protezione multiple tramite la tecnologia EFS?
Quando un utente che esegue Windows XP sceglie l'opzione per la crittografia dei file non in linea di Esplora risorse, la routine di crittografia utilizzata è diversa da quella impiegata per le altre operazioni di crittografia avviate dall'utente. Piuttosto che utilizzare la coppia di chiavi EFS personale dell'utente per il processo (che impedirebbe a SYSTEM di accedere ai file), l'account SYSTEM genera una coppia di chiavi da utilizzare con EFS e la utilizza per crittografare la memoria lato client. Si tratta di implicazioni critiche sulla protezione in quanto se un utente è in grado di eseguire il codice come SYSTEM, può decrittografare i dati della cache. Se un portatile viene rubato un utente malintenzionato è in grado di reimpostare con facilità la password amministratore e accedere come amministratore. Con i privilegi di amministratore attivi può eseguire il codice come SYSTEM e accedere alla cache. (Questo comportamento è cambiato in Windows Vista™ dove si utilizza adesso la chiave del singolo utente per crittografare File non in linea specifici dell'utente).
Per proteggersi da questo tipo di attacco, è possibile configurare il portatile per memorizzare la chiave di crittografia per il database Gestione account di protezione (SAM) non linea, come password da immettere all'avvio (modalità 2) o su dischetto durante il processo di avvio (modalità 3). Entrambi gli approcci possono essere complessi poiché richiedono l'interazione non automatica col computer all'avvio, creando problemi potenziali con la gestione automatica dei sistemi. Tuttavia, se EFS deve essere utilizzato su un computer con File non in linea è importante che sia utilizzata una di queste opzioni per proteggere i dati della cache. In genere è preferibile utilizzare la password all'avvio (vedere la Figura 1) perché un utente a cui viene sottratto il laptop terrà probabilmente il dischetto nel computer o nella borsa.
Figura 1 Automatizzare le operazioni di EFS
Figura 1 Automatizzare le operazioni di EFS

Attivazione di EFS
Una volta determinato cosa crittografare nel client, la fase successiva è eseguire l'operazione di crittografia. A tal fine utilizzare uno script di accesso o un altro processo che esegua uno script sul client per richiamare cipher.exe ed eseguire l'operazione di crittografia. Se nell'ambiente sono presenti utenti di EFS autonomi, come indicato nell'esempio precedente, si consiglia di iniziare la migrazione da questi.
Per eseguire la migrazione degli utenti autonomi, la prima fase è il provisioning dei sistemi client con certificati gestiti, come discusso nell'articolo di febbraio 2007 (microsoft.com/technet/technetmag/issues/2007/02/SecurityWatch). Una volta iscritti tutti i sistemi a questi certificati gestiti, eseguire la crittografia con l'opzione /U per aggiornare tutti i file esistenti con le nuove chiavi di agente di recupero e di crittografia. A questo punto, tutti i sistemi nel gruppo SG-ComputersUsingEFS dovrebbero utilizzare EFS in modo gestito, anche per le chiavi emesse (e potenzialmente archiviate) centralmente nonché per gli agenti di recupero gestiti centralmente.
Per distribuire EFS per gli utenti che non lo utilizzano attualmente occorre rimuovere i Criteri di gruppo che ne impediscono l'uso. Una volta eseguita l'operazione e dopo che gli utenti si sono iscritti ai certificati gestiti, è possibile eseguire uno script di accesso per crittografare i percorsi principali citati sopra. Ecco un esempio di script semplificato:
cipher /e /s /a "%userprofile%\My Documents"

cipher /e /s /a "%userprofile%\Application Data\Microsoft\Outlook"

cipher /e /s /a "%userprofile%\Desktop"
Dopo avere attivato EFS sulle directory desiderate, considerare due opzioni aggiuntive per aumentare la protezione della distribuzione di EFS, entrambe correlate ai dati paginati dalla memoria su disco. Per ciascuno di questi scenari la quantità di dati che potrebbe essere potenzialmente recuperata da un utente malintenzionato si limita a quanto caricato nella memoria o su disco durante l'uso legittimo. Ossia, i dati riservati protetti mediante EFS sul computer che non sono stati visualizzati (e non sono stati quindi caricati nella memoria) non sono a rischio di attacco.
Il file di paging viene utilizzato da Windows come memoria virtuale (spesso chiamato spazio di swapping in altri sistemi operativi) e contiene dati in memoria scritti come testo normale nel disco rigido. Ciò potrebbe mettere a rischio i dati riservati presenti su un sistema protetto da EFS perché un utente malintenzionato che riesce a recuperare il file di paging potrebbe utilizzare potenzialmente degli strumenti forensi per estrarre dati utilizzabili. Poiché il file di paging non può essere crittografato in Windows XP (ma può esserlo in Windows Vista) l'opzione migliore è forzare Windows a cancellarlo all'arresto del sistema. Questa operazione può essere eseguita tramite Criteri di gruppo, come illustrato nella Figura 2.
Figura 2 Impostazione di Criteri di gruppo
Figura 2 Impostazione di Criteri di gruppo (Fare clic sull'immagine per ridurla)
Figura 2 Impostazione di Criteri di gruppo
Figura 2 Impostazione di Criteri di gruppo (Fare clic sull'immagine per ingrandirla)
Il lato negativo dell'impostazione consiste nel significativo aumento del tempo necessario ad arrestare il computer, soprattutto se dispone di una memoria di grandi dimensioni. Per impostazione predefinita, la dimensione del file di paging è direttamente proporzionale alla memoria fisica del computer. Questo perché per cancellare il file di paging Windows deve scrivere fisicamente in ogni pagina sul disco prima dell'arresto del sistema.
Il file di sospensione in Windows contiene un'immagine della memoria fisica del computer quando la modalità di risparmio energia è impostata per attivare la sospensione. Quando si verifica la sospensione, Windows scrive il contenuto completo della memoria fisica sul disco nel file di sospensione, consentendo il ripristino del computer esattamente sul medesimo stato quando l'utente è pronto a procedere. Come il file di paging, il file di sospensione non può essere crittografato in Windows XP. Ma a differenza del file di paging, la sospensione non può essere disattivata direttamente da un oggetto Criteri di gruppo. Occorre invece utilizzare uno script per richiamare powercfg.exe con l'opzione /HIBERNATE per disattivare (o riattivare) la sospensione.
Una volta completate le attività di crittografia e configurazione iniziali, si consiglia di cancellare lo "slack space" dai dischi della distribuzione. Questo processo può essere molto lungo e problematico, ma presenta un vantaggio di protezione in ambienti a protezione elevata. Lo "slack space" è l'area del disco che non conserva i dati attivi nel sistema, ma che, a causa della modalità di funzionamento del disco fisso, può contenere informazioni riservate provenienti di file utilizzati in precedenza. In altre parole, poiché un'operazione di cancellazione di file non sovrascrive effettivamente tutti i settori occupati da un file su un disco (rimuove soltanto l'indicatore dalla tabella di file), i dati che sono stati cancellati continuano a esistere sul disco. In questi casi, i dati possono essere recuperati da strumenti forensi in grado di leggere questo slack space e riassemblare i file. Per cancellare questi dati residui in modo sicuro, eseguire la crittografia con l'opzione /W. L'operazione forza la crittografia a sovrascrivere ripetutamente tutti i settori contrassegnati come disponibili sul disco. Finché tutte le operazioni di file future sui dati riservati si verificano nelle directory protette da EFS, non sarà necessario eseguire questo comando regolarmente.

Ottimizzazione di Esplora risorse per EFS
Per impostazione predefinita, le opzioni di crittografia e decrittografia di file e directory si trovano nei menu di proprietà avanzate di Esplora risorse. Per migliorare l'esperienza dell'utente finale con EFS, è possibile inserire "Crittografa" e "Decrittografa" nel menu di scelta rapida di Esplora risorse (visualizzato facendo clic con il pulsante destro del mouse). Inoltre, è possibile configurare Esplora risorse in modo che visualizzi file e directory protetti da EFS in un colore diverso (verde) rispetto agli altri file. Ciò consente agli utenti di sapere se un file o una directory è crittografato senza dover scorrere il menu delle proprietà avanzate. Se lo si desidera, è possibile aggiungere un'opzione per definire quali utenti hanno accesso al file o alla directory. Per abilitare tale opzione, eseguire le
following changes in the registry via a script calling reg.exe:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Advanced]

"EncryptionContextMenu"=dword:00000001

"ShowCompColor"=dword:00000001

[HKEY_CLASSES_ROOT\*\Shell\Encrypt To User...\Command]
@="rundll32 efsadu.dll,AddUserToObject %1"

EFS in Windows Vista
EFS ha subito numerosi miglioramenti in Windows Vista che semplificano la distribuzione, la gestione e l'aumento della sicurezza. Primo fra questi è il supporto completo per la memorizzazione delle chiavi EFS su smart card. Si tratta di una funzionalità particolarmente utile per le organizzazioni che già utilizzano l'accesso della smart card, in quanto la stessa scheda può essere utilizzata anche per memorizzare le chiavi EFS degli utenti. Il supporto per le smart card viene esteso anche ai certificati dell'agente di recupero, per cui anche i certificati DRA riservati possono essere memorizzati nelle schede.
Windows Vista supporta anche la crittografia di elementi precedentemente impossibili o complessi da crittografare in Windows XP. Windows Vista esegue la crittografia del file di paging, eliminando la necessità di impostare l'opzione che consente di cancellare il file di paging della memoria virtuale. L'intero sistema dei File non in linea è stato rielaborato in Windows Vista. Oltre a prestazione e stabilità migliori (e a un'interfaccia più intuitiva), il caching lato client avviene adesso per utente, consentendo di crittografare la cache in modo protetto senza ricorrere alle modalità SYSKEY 2 o 3. Questi due miglioramenti eliminano i principali ostacoli alla distribuzione degli attuali ambienti basati su Windows XP.
Infine, Windows Vista consente agli amministratori di configurare la crittografia della cartella Documenti direttamente da Criteri di gruppo, senza dover utilizzare uno script separato. Nella Figura 3 sono illustrate le nuove proprietà EFS disponibili tramite Oggetto Criteri di gruppo in Windows Vista.
Figura 3 Proprietà EFS di Windows Vista
Figura 3 Proprietà EFS di Windows Vista (Fare clic sull'immagine per ridurla)
Figura 3 Proprietà EFS di Windows Vista
Figura 3 Proprietà EFS di Windows Vista (Fare clic sull'immagine per ingrandirla)

Conclusione
EFS fornisce agli amministratori Windows un'opzione altamente protetta per proteggere i dati mobili. EFS è scalabile, facile da gestire e offre meccanismi di ripristino dei dati flessibili. In Windows Vista EFS è stato potenziato con funzionalità per la gestione e la distribuzione semplificate, come il supporto dell'archiviazione di chiavi basato su smart card. Per le organizzazioni che desiderano proteggere i dati, anche nel caso di un computer fisicamente perso, EFS fornisce una soluzione che fa già parte della piattaforma Windows esistente.
Ulteriori informazioni
Per ulteriori informazioni sugli argomenti trattati in questa sede, consultare le risorse seguenti:
  • Articolo Controllo protezione di febbraio 2007
  • Encrypting File System in Windows XP and Windows Server 2003 (in inglese)
  • Come utilizzare l'utilità SysKey per proteggere il database Gestione account di protezione di Windows

John Morello si è laureato con lode presso la LSU e lavora in Microsoft da sei anni coprendo diversi ruoli. Come consulente senior, ha progettato soluzioni di protezione per le aziende Fortune 100 nonché per i clienti della difesa e civili americani. Attualmente è Program Manager presso il gruppo Windows Server e si dedica alle tecnologie di protezione e accesso remoto.


 Desktop File: Panoramica su PsTools
Desktop File
Panoramica su PsTools
Wes Miller
Scarica il codice per questo articolo: MillerTheDesktopFiles2007_03.exe (150KB)

Winternals Software è una società che stata acquisita da Microsoft nel 2006. La Winternals ha venduto il software commerciale, ma i fondatori dell'azienda, Mark Russinovich e Bryce Cogswell erano anche titolari di un'altra società, Sysinternals, che ha distribuito molti strumenti come freeware. Alcune di queste applicazioni freeware si sono
evolute fino a diventare componenti della Winternals Administrator's Pak. Mark e Bryce hanno anche concesso in licenza questi strumenti ad aziende che volevano utilizzarli al di fuori delle normali condizioni di licenza freeware.
Uno degli strumenti preferiti della Sysinternals, anzi un vero e proprio gruppo completo di strumenti, è quella che adesso è diventata la famiglia di prodotti PsTools, rintracciabile all'indirizzo microsoft.com/technet/sysinternals/utilities/pstools.mspx. Mark ha aggiunto il prefisso "ps" all'utilità di elenco dei processi UNIX. Come indicato nel sito per il download degli strumenti, sono disponibili utilità della riga di comando Windows® integrate che possono eseguire alcune delle stesse funzioni di questi strumenti. Tuttavia, oltre a importanti funzionalità uniche, la differenza principale consiste nel fatto che la famiglia di prodotti PsTools può essere utilizzata in modalità locale o remota (purché i sistemi remoti siano configurati correttamente). Ancora meglio, il processo di esecuzione remota è semplice quasi come l'esecuzione locale.
La famiglia di prodotti PsTools contiene diverse applicazioni singole elencate nella Figura 1. Come per le altre utilità Sysinternals, non esiste alcun programma di installazione, ma soltanto applicazioni. È sufficiente inserirle in una cartella sul percorso desiderato e procedere.
Figure 1 Utilità PsTools (Close Figure 1)

Strumento | Descrizione
PsExec | Consente di eseguire processi in qualunque contesto utente.
PsFile | Mostra i file aperti in remoto su un sistema.
PsGetSid | Visualizza l'identificatore di protezione Windows (SID) di un computer o un utente.
PsInfo | Elenca le informazioni su un sistema Windows.
PsKill | Elimina i processi per nome o ID del processo.
PsList | Elenca informazioni dettagliate sui processi in esecuzione.
PsLoggedOn | Mostra tutti gli utenti registrati in locale come pure tutti gli utenti che condividono risorse remote.
PsLogList | Esegue il dump dei record del Registro eventi di Windows.
PsPasswd | Modifica le password di account utente.
PsService | Visualizza e controlla i servizi Windows.
PsShutdown | Arresta, riavvia, sospende, mette in stand-by un computer.
PsSuspend | Sospende i processi in esecuzione.
Si noti che alcune di queste funzionalità (soprattutto PsLogList) possono essere realizzate anche tramite Strumentazione gestione Windows (WMI) e con alcuni script complessi. Ma la cosa importante della famiglia di prodotti PsTools è che ogni utilità è progettata per realizzare un'attività specifica e lo fa in modo semplice.
In seguito, verranno passati in rassegna i singoli strumenti, con semplici esempi che descrivono il motivo e la modalità con cui vengono utilizzati. Prima però, una breve introduzione per descrivere come funzionano gli strumenti e che tipo di prerequisiti sono necessari per poterli utilizzare.

Come funzionano gli strumenti?
Generalmente, gli strumenti funzionano tutto nello stesso modo. Sul sistema host viene avviato lo strumento PsTool desiderato. Sebbene molti strumenti possano essere eseguiti localmente, generalmente sono della massima utilità quando vengono eseguiti su un sistema remoto o su diversi sistemi contemporaneamente. PsExec è un'eccezione specifica, come si vedrà nell'esempio seguente. Mediante l'argomento della riga di comando, l'utilità viene copiata sulla risorsa amministrativa condivisa del sistema remoto, che è la stessa di %SystemRoot % (directory di Windows) sul sistema remoto.
Una volta copiata nella directory remota, l'applicazione si avvia e installa un servizio Windows. Questo servizio Windows esegue l'attività richiesta, utilizzando le credenziali fornite al momento dell'avvio. Se lo strumento specifico richiede una UI per l'utente finale sul sistema client, questo servizio avvia un ulteriore file binario nel contesto dell'utente. I servizi non possono avviare le UI interattive dirette. Il servizio comunica tutte le informazioni necessarie alla console che lo ha avviato e, infine, si disinstalla.
Come si può notare, gli strumenti sono potenti e indipendenti. Nonostante coinvolgano diversi file binari e processi multipli, l'utente non deve preoccuparsi, è sufficiente avviare semplicemente lo strumento desiderato.
Per poter utilizzare gli strumenti, sono necessari i seguenti prerequisiti: sistema operativo Windows NT®, Windows 2000, Windows XP o Windows Server ® 2003 (sono supportate le versioni x86 o x64 di Windows, ma non le versioni Itanium); deve essere abilitata la condivisione di rete amministrativa predefinita sul sistema remoto in cui sono in esecuzione gli strumenti (admin$); le porte per la condivisione di file e stampanti devono essere aperte sul sistema remoto (se si utilizza Windows Firewall, Internet Connection Firewall o un altro firewall).

PsExec
PsExec è uno degli strumenti che preferisco, ma probabilmente non per la ragione che ci si potrebbe aspettare. Per gran parte degli ultimi due anni, ho utilizzato il sistema accedendo come utente e non come Amministratore. Al suo posto, dispongo di uno script denominato run.vbs che utilizzo per eseguire le applicazioni come Amministratore locale (tali applicazioni potevano essere eseguite facilmente da qualsiasi utente). La Figura 2 illustra il contenuto dello script (disponibile anche sul sito TechNet Magazine all'indirizzo technetmagazine.com/code07.aspx). Lo script presuppone che gli strumenti PsTools si trovino nella variabile di sistema Path.
Figure 2 Run.vbs (Close Figure 2)
SET WshShell = WScript.CreateObject("WScript.Shell")
SET WshSysEnv = WshShell.Environment("SYSTEM")
SET FSO = CreateObject("Scripting.FileSystemObject")
IF WScript.Arguments.Count <> 0 Then
    FOR EACH arg IN WScript.Arguments
        iArgCount = iArgCount + 1
        strCmdArg = (arg)
        strCmdArray = Split(strCmdArg, " ", 2, 1)
        IF iArgCount = 1 THEN
        strExe = strCmdArray(0)
        ELSEIF iArgCount = 2 THEN
        strRun = strCmdArray(0)
        ELSE
        strParams = strParams&" "&strCmdArray(0)
        END IF
    NEXT
END IF
'/t:0A && title ***** Admin *****
        strExt = LCase(Right(strExe, 3))

IF strExt <> "exe" AND strExt <> "bat" AND strExt <> "cmd" THEN
WshShell.Run "psexec.exe -d -i -e -u COMPUTERNAME\USER -p PASSWORD  cmd /c start "&strExe&"
    "&strRun&" "&strParams, 0, FALSE
ELSE
WshShell.Run "psexec.exe -d -i -e -u COMPUTERNAME\USER -p PASSWORD "&strExe&" "&strRun&"
    "&strParams, 0, FALSE
END IF

    SET WshShell = NOTHING
    SET WshSysEnv = NOTHING
    SET FSO = NOTHING
Questo semplice script è un esempio di utilizzo di PsExec con la funzionalità aggiunta da Mark durante l'elaborazione del prodotto Protection Manager in Winternals: la possibilità per un utente limitato di fornire credenziali privilegiate per avviare PsExec localmente. L'utilizzo più comune di PsExec consiste nell'esecuzione in modalità remota, ad esempio l'esecuzione di un'utilità che non fornisce un framework remoto, di script o di automazione. Tra le funzionalità principali di PsExec, la capacità di copiare sui sistemi remoti un file binario da eseguire, oltre alla capacità di stabilire l'affinità processori. Un'altra funzionalità utile di PsExec consiste nel codificarlo simultaneamente su molte macchine fornendo un file di script.
Di seguito una descrizione dell'uso semplificato di PsExec:
PsExec \\computer -u username -p password command
È possibile ampliare questa descrizione usando le opzioni illustrate nella Figura 3.
Figure 3 Opzioni PsExec (Close Figure 3)

Opzione | Descrizione
-a | Specifica le affinità processori.
-c | Indica se l'applicazione deve essere copiata sul sistema remoto.
-d | Specifica di non aspettare il termine del processo prima di uscire (non attendere un messaggio di esito positivo o di errore).
-e | Carica utilizzando il profilo dell'account specificato.
-f | Copia l'applicazione anche se già esiste sul sistema remoto. Verifica che si sta eseguendo la versione corrente (o una specifica).
-i | Esegue l'applicazione in modo interattivo sul sistema remoto (necessario se si desidera che un utente finale possa visualizzare un'interfaccia utente dall'applicazione).
-l | Esegue l'applicazione come utente limitato. Rimuove il token del gruppo Administrators e riporta i privilegi del processo al livello adeguato per un membro del gruppo Utenti. Utile per eseguire applicazioni Internet a rischio elevato con privilegi minimi.
-n | Specifica il timeout, ossia il tempo di attesa prima di un errore di connessione ai computer remoti.
-priority | Esegue il processo con la priorità specificata. Ovvero specifica la modalità con cui Windows deve impostare la priorità del processo per un'attività specifica (-low, -belownormal, -abovenormal, -high o -realtime).
-s | Esegue il processo utilizzando l'account di sistema (utile per eseguire Regedit per accedere alle chiavi del registro di sistema privilegiate).
-v | Copia l'applicazione soltanto se è più nuova di quella preesistente.
-x | Visualizza l'interfaccia utente sul desktop di protezione Winlogon; funziona solo sul sistema locale.
@file | Esegue il comando su tutti i computer specificati nel file di testo.

PsFile
PsFile è uno strumento più preciso di PsExec. Viene utilizzato specificatamente per controllare quali file sono aperti e da chi, su un sistema remoto. È molto utile se si vuole tenere traccia dei file aperti prima di riavviare un server. Se si desidera scoprire quale utente ha bloccato il file, per evitarne la modifica o la cancellazione, è possibile indicarli manualmente o chiuderli tramite PsFile. Di seguito viene descritto l'utilizzo di PsFile:
PsFile \\computer -u username -p password
Restituisce semplicemente un elenco di handle di file aperti nel sistema remoto. Oltre all'uso standard, è anche possibile aggiungere all'argomento un parametro ID, specificando il nome del file di cui si richiedono informazioni o che si desidera chiudere. È anche possibile aggiungere l'opzione -c che chiude il file identificato col parametro ID.

PsGetSid
Anche PsGetSid è uno strumento con scopi molto specifici. PsGetSid indica l'identificatore di protezione (SID) di un computer, un utente o un gruppo. Può essere utile se si desidera controllare che i sistemi nel dominio non abbiano ID di protezione duplicati o se si intende verificare semplicemente gli ID di protezione di tutti gli utenti o gruppi in un sistema. L'utilizzo di PsGetSid è il seguente:
PsGetSid \\computer -u username -p password account
Si noti che l'account può specificare un utente, un computer o un gruppo. Sebbene la sintassi di PSGetSid sia semplice, sono disponibili anche due parametri aggiuntivi. Il parametro SID specifica l'account (il gruppo o il computer) relativo a un SID specifico, mentre @file esegue il comando su tutti i computer elencati nel file di testo specificato.

PsInfo
PsInfo viene utilizzato per fornire informazioni di sistema dettagliate. Si tratta, ovviamente, dello strumento più utile quando viene utilizzato per sistemi multipli remoti dove l'output viene inviato a un file (un file Excel® e un file CSV più adatto per i database). Si noti che questa utilità agisce sfruttando un concetto importante che è diverso dalla maggior parte degli altri strumenti: Se non viene fornito il nome di un computer, PsInfo, per impostazione predefinita, tenta di eseguire delle query su tutti i computer nel dominio. Di seguito viene indicato l'utilizzo di PsInfo:
PsInfo  \\computer -u username -p password
Sebbene la sintassi sia semplice, sono disponibili anche opzioni e parametri aggiuntivi illustrati nella Figura 4
Figure 4 Opzioni PsInfo (Close Figure 4)

Opzione | Descrizione
-h | Visualizza tutti gli aggiornamenti Windows.
-s | Visualizza tutte le applicazioni installate sul sistema.
-d | Visualizza le informazioni sul disco o volume del sistema.
-c | Genera il risultato in formato CSV.
-t | Specifica un altro delimitatore per il file CSV diverso dal valore predefinito di \t.
Filtro | Visualizza soltanto i dati che corrispondono a un determinato filtro.
@file | Esegue il comando su tutti i computer elencati nel file di testo specificato.

PsKill
PsKill è un'utilità importante per interrompere i processi sia su un sistema locale che su un sistema remoto. L'uso è molto semplice e consente di eliminare rapidamente un processo con tutti relativi figli. L'utilizzo di PsKill è molto simile a quello degli altri strumenti descritti:
PsKill -t \\computer -u username -p password process id | process name
Si noti che è possibile specificare l'ID del processo o il nome del processo che si desidera terminare.

PsList
Chi utilizza abitualmente Process Explorer non sfrutterà molto PsList (per ulteriori informazioni vedere microsoft.com/technet/sysinternals/ProcessesAndThreads/ProcessExplorer.mspx). Ma poiché non esiste una versione remota di Process Explorer, PsList diventa un'alternativa molto simile per alcune delle funzionalità principali fornite da Process Explorer. PsList è di fatto un elenco in remoto di uno o più processi in esecuzione su un sistema remoto.
L'uso di PsList è semplice:
PsList \\computer -u username -p password account
Come con gli altri strumenti, il parametro di account può specificare un utente, un computer o un gruppo. I parametri aggiuntivi sono illustrati nella Figura 5.
Figure 5 Opzioni PsList (Close Figure 5)

Opzione | Descrizione
-t | Visualizza le informazioni a livello del thread.
-m | Fornisce informazioni dettagliate sulla memoria per ogni processo.
-x | Visualizza le informazioni su processo, memoria e thread.
-t | Visualizza le informazioni sotto forma di struttura processi (come la visualizzazione ad albero di Process Explorer).
-s [n] | Effettua l'esecuzione in modalità gestione attività per i secondi specificati. In questo modo è possibile visualizzare quasi in tempo reale le informazioni remote sul processo.
-r [n] | Specifica la frequenza (in secondi) di aggiornamento durante l'esecuzione in modalità gestione attività.
name | Visualizza le informazioni sui processi che iniziano col nome specificato.
-e | Corrisponde esattamente al nome del processo.
pid | Visualizza le informazioni su un processo specifico.
PsList è uno strumento potente ma facile da utilizzare; senza utilizzare il desktop remoto, consente di visualizzare in dettaglio i processi remoti. Con queste informazioni è possibile passare a PsKill o PsSuspend se, ad esempio, è necessario ricontrollare un processo.

PsLoggedOn
Il presupposto di PsLoggedOn è autoesplicativo. L'utilità visualizza gli utenti registrati in un sistema sia che si tratti di accessi locali (interattivi) o accessi alla condivisione di rete. Come per PsFile, questa funzionalità può essere utile per stabilire chi sta utilizzando un server su cui è necessario eseguire operazioni di manutenzione. L'uso è molto semplice:
PsLoggedOn \\computer
PsLoggedOn dispone soltanto di due parametri facoltativi: -l mostra soltanto gli accessi locali (non gli accessi di rete) e -x esclude l'orario di accesso.
Benché sia uno strumento molto semplice, PsLoggedOn consente di visualizzare facilmente le informazioni che generalmente vengono ricercate in diverse posizioni di Windows.

PsLogList
Una delle utilità più utili in generale, PsLogList, è uno strumento che consente di eseguire il dump del registro eventi di Windows in un formato di testo che può essere utilizzato da lettori registro, database o da qualsiasi altro programma. Il vantaggio principale è che converte le voci del registro eventi dal formato binario in qualcosa che può essere facilmente trasformato o automatizzato. (Naturalmente, in Windows Vista™ i registri eventi sono originariamente disponibile in formato XML, ma questo è un altro argomento da affrontare in un'altra occasione).
L'uso di PsLogList è:
PsLogList \\computer -u username -p password
Sono anche disponibili numerose opzioni e parametri aggiuntivi come illustrato nella Figura 6.
Figure 6 Opzioni PsLogList (Close Figure 6)

Opzione | Descrizione
-a | Scarica soltanto gli eventi successivi alla data specificata.
-b | Scarica soltanto gli eventi antecedenti alla data specificata.
-c | Azzera il registro eventi definitivamente dopo aver scaricato l'output desiderato.
-d | Visualizza soltanto le informazioni per il numero specificato di giorni specificato.
-e | Esclude gli eventi con l'ID evento specificato (è possibile specificare fino a 10 ID).
-f | Filtra i tipi di evento (avviso, errore e così via).
-g | Esporta il registro eventi come un file EVT; è richiesta l'opzione -c.
-h | Visualizza soltanto le informazioni per il numero di ore specificato.
-l | Scarica dal file EVT specificato.
-m | Visualizza soltanto le informazioni per il numero di minuti specificato.
-n | Visualizza soltanto il numero specificato degli eventi più recenti.
-o | Visualizza soltanto gli eventi di una data sorgente (ad esempio, -o SRService per Windows System Restore Service).
-q | Esclude gli eventi da una data sorgente (il contrario di -o).
-r | Inverte l'ordine degli eventi del registro dal meno recente al più recente.
-s | Elenca i record di ogni riga nei campi delimitati.
-t | Specifica qualcosa di diverso da una virgola come delimitatore per l'output -s.
-w | Attende che nuovi eventi vengano popolati e scaricati in tempo reale. Applicabile solo al sistema locale.
-x | Scarica i dati estesi dai registri eventi.
eventlog | Specifica quale registro eventi scaricare. Il valore predefinito è System.
@file | Esegue il comando su tutti i computer specificati nel file di testo.
Il registro eventi di Windows può essere uno strumento di diagnostica incredibilmente potente, ma il vero trucco è estrarre i dati in modo da poterli modificare o consolidare. PsLogList esegue esattamente questa funzione.

PsPasswd
PsPasswd è un'utilità semplice ma potente progettata con alcune delle caratteristiche di Net.exe, ma tenendo presente il funzionamento in remoto e automatizzato.
PsPasswd  \\computer -u username -p password Username Newpassword
È possibile specificare un computer, nessun computer (il sistema locale) oppure se si specifica il computer come \\* l'utilità verrà eseguita su tutti i computer nel dominio corrente. PsPasswd dispone di un solo parametro aggiuntivo: @file, che esegue il comando su tutti i computer specificati nel file di testo. Anche questa è un'utilità molto semplice estremamente utile in ambienti multi-sistema.

PsService
PsService consente di visualizzare e modificare le informazioni di Gestione controllo servizi (SCM) su uno o più sistemi della rete, inoltre può anche cercare un determinato nome servizio sui sistemi in rete.
PsService \\computer -u username -p password command options
Quando si esegue PsService, il comando rappresenta uno dei comandi elencati nella Figura 7 e le opzioni specificano un attributo applicabile a un determinato comando. Se non viene fornita alcuna opzione di comando aggiuntiva, PsService fornisce un dump completo delle informazioni SCM.
Figure 7 Comandi PsService (Close Figure 7)

Comando | Descrizione
query | Esegue una query su un determinato servizio.
/config | Esegue una query per le informazioni di configurazione di un determinato servizio.
setconfig | Imposta le informazioni di configurazione di un determinato servizio.
start | Avvia un servizio.
stop | Arresta un servizio.
restart | Riavvia (arresta e avvia) un servizio.
pause | Sospende un servizio.
cont | Riprende un servizio sospeso.
depend | Mostra quali servizi dipendono dal servizio specifico.
find | Ricerca nella rete una determinata istanza del servizio.
security | Fornisce le informazioni di protezione per un determinato servizio.
PsService può essere considerato come una versione potente e remota della riga di comando di Services.msc, che consente anche di cercare in rete i servizi (probabilmente quelli potenzialmente pericolosi) e di impostare le informazioni di configurazione.

PsShutdown
PsShutdown è un altro degli strumenti preferiti. Anche se qualcuno potrebbe affermare che Microsoft include uno strumento che gestisce questa attività (shutdown.exe), il funzionamento non e proprio lo stesso. La differenza principale consiste nella potenza di PsShutdown: vale a dire, può arrestare o riavviare un sistema remoto. Inoltre, ha la capacità di mettere un sistema in modalità standby o di sospensione (non solo arrestare o riavviare), di bloccare e riavviare un sistema dopo aver visualizzato un messaggio all'utente per un determinato periodo di tempo.
PsShutdown \\computer -u username -p password
Sono anche disponibili numerosi parametri aggiuntivi come illustrato nella Figura 8.
Figure 8 Opzioni PsShutdown (Close Figure 8)

Opzione | Descrizione
-a | Interrompe un arresto del sistema già in corso avviato da PsShutdown.
-c | Autorizza un utente interattivo a interrompere l'arresto.
-d | Sospende il computer (standby).
-e | Arresta i codici motivo. Si consiglia di consultare il sito Web Microsoft per assistenza su tali parametri, in quanto il loro utilizzo può risultare problematico, sia con PsShutdown che con il comando integrato shutdown.exe. Per ulteriori informazioni vedere msdn2.microsoft.com/en-us/library/aa376885.aspx.
-f | Forza l'arresto di tutte le applicazioni in esecuzione.
-h | Sospende il computer.
-k | Spegne il computer (riavvia se la funzione di spegnimento non è supportata).
-l | Blocca il computer.
-m | Specifica il messaggio da visualizzare da tutti gli utenti interattivi.
-n | Specifica il timeout, ossia il tempo di attesa prima di un errore di connessione ai computer remoti.
-o | Scollega la console dell'utente.
-r | Riavvia il computer.
-s | Arresta, ma non spegne.
-t | Conto alla rovescia prima che il comando di arresto venga eseguito o tempo necessario per lo spegnimento.
-v | Visualizza il messaggio agli utenti fino all'arresto del sistema.
@file | Esegue il comando su tutti i computer specificati nel file di testo.
PsShutdown è un'utilità per il controllo del risparmio di energia del sistema molto potente e completamente configurabile ma allo stesso tempo facile utilizzare.

PsSuspend
PsSuspend è un'utilità pratica che consente di tenere temporaneamente sotto controllo un processo anomalo o semplicemente di disattivare temporaneamente l'elevato utilizzo della CPU senza perdere dati o il contesto dell'applicazione.
PsSuspend \\computer -u username -p password process ID
È possibile ottenere l'ID del processo utilizzando PsList. Una volta sospeso un processo, è possibile utilizzare l'opzione -r per riattivarlo. Si noti che il concetto di sospendere e riattivare un processo è anche implementato da Process Explorer, nonostante questo funzioni solo localmente. Ovviamente, PsSuspend può sospendere e riattivare i processi in remoto e in locale, pertanto presenta un margine di vantaggio rispetto all'implementazione integrata di Process Explorer.

Conclusioni
Trovo la famiglia di prodotti PsTools un insieme di utilità dal valore inestimabile. Insieme alle altre utilità Sysinternals (ossia, Regmon, Filemon, Process Explorer e Process Monitor), i prodotti PsTools sono i primi programmi da utilizzare per la reinstallazione di Windows su qualsiasi sistema. Spero che questo articolo abbia permesso di far conoscere PsTools a chi non lo conosceva ancora, offrendo anche qualche informazione in più a chi già aveva sentito parlare del programma. Ringrazio Mark Russinovich per aver fornito questi strumenti gratuitamente per tutti questi anni e per la collaborazione alla stesura del presente articolo.

Wes Miller è un responsabile di sviluppo presso Pluck (www.pluck.com), Austin (Texas). Wes ha lavorato in precedenza per Winternals Software ad Austin e in Microsoft come Program Manager e Product Manager di Windows. È possibile contattarlo all'indirizzo technet@getwired.com.


 All'interno di Microsoft.com: Guida introduttiva al mirroring del database
All'interno di Microsoft.com
Guida introduttiva al mirroring del database
Saleem Hakani

La mancanza di disponibilità del database è un grave problema. Ma grazie a SQL Server 2005 con SP1 e al mirroring del database è possibile evitare un simile disastro. Questa nuova tecnologia ad alta disponibilità consente di mantenere una copia hot standby del database pronta per l'uso quando il server del database di produzione non
è disponibile. La funzione di mirroring del database opera trasferendo i record del registro delle transazioni di un database dal server primario al server secondario, che svolge la funzione di hot standby. Con il mirroring del database, le modifiche di dati sono registrate nel registro delle transazioni prima di essere apportate alle pagine di dati effettive, analogamente a quanto avviene con gli aggiornamenti di SQL Server™. I record del registro sono memorizzati inizialmente nel buffer di registro del database principale, quindi salvati in modo permanente nel disco. I registri delle transazioni vengono copiati e riprodotti nel database del server mirror. In questo modo le modifiche del database principale vengono duplicate nel database mirror. Notare che soltanto il database principale è accessibile alle connessioni client. Quando il database principale riceve le modifiche richieste dai client, il server principale invia le modifiche attive al server mirror; il database mirror non esegue tali azioni. Una volta abilitato il mirroring del database, quando nel database principale si verifica un errore, il database mirror diventa disponibile.

Funzionamento del mirroring del database
Il mirroring del database funziona con tutto l'hardware standard che supporta SQL Server 2005 e garantisce che non si verifichino perdite di dati nel caso di errori del database. Il database mirror è sempre aggiornato con la transazione in fase di elaborazione sul server del database primario. Nella Figura 1 è illustrato il flusso di dati.
Se il server principale ha un problema, il server mirror fornisce una copia precisa e aggiornata del database principale risalente all'ultima transazione per cui è stato eseguito il commit. Così, il server mirror è sempre pronto ad assumere il ruolo di server principale.
Figura 1 Replica di dati nel mirror
Figura 1 Replica di dati nel mirror (Fare clic sull'immagine per ridurla)
Figura 1 Replica di dati nel mirror
Figura 1 Replica di dati nel mirror (Fare clic sull'immagine per ingrandirla)
Nella topologia del mirroring del database, occorre un terzo server chiamato server di controllo per attivare il failover automatico tra il server mirror e quello principale e viceversa. Un server di controllo è un qualunque computer in grado di supportare SQL Server 2005.

Modalità di funzionamento
La topologia di mirroring del database utilizzata dipenderà dalla protezione della transazione e dalle modalità di funzionamento scelte. Le modalità di funzionamento supportate dal mirroring del database includono una protezione (con o senza failover automatico) e prestazioni molto elevate.
Protezione elevata con failover automatico: questa modalità supporta i massimi livelli di disponibilità del database con trasferimento di dati sincrono e failover automatico al database mirror. Questa modalità operativa è consigliata in presenza di comunicazione veloce e affidabile tra i server mirror e principale e quando il failover automatico è richiesto per un solo database. In questo schema, il database principale non esegue il commit per la transazione finché non riceve un messaggio dal server mirror comunicante che quest'ultimo ha attivato la protezione del registro delle transazioni nel disco.
Protezione elevata senza failover automatico: questa modalità supporta i massimi livelli di disponibilità del database con trasferimento di dati sincrono senza failover automatico al database mirror. In questa modalità, se l'istanza del server mirror non è più disponibile, quella del server principale continua a funzionare ma non sarà in grado di effettuare il mirroring di dati. Se il server principale ha dei problemi, il mirroring del database viene sospeso, ma è possibile forzare manualmente il servizio per eseguire il failover.
Alte prestazioni: in questa modalità di funzionamento il trasferimento di dati è asincrono. Il server principale non attende il riconoscimento dal server mirror come accade nelle due modalità sopra descritte. Il server mirror cerca di rimanere al passo dell'originale, ma non è garantito che tutte le transazioni recenti del server principale siano protette nel registro delle transazioni del server mirror. Se il server principale ha dei problemi, il mirroring del database viene sospeso, ma è possibile forzare manualmente il servizio per eseguire il failover.

Configurazione di base
La preparazione del mirror del database è un processo semplice se vengono poste solide basi e si seguono alcune procedure consigliate.
Edizione del server Accertarsi che entrambi i server eseguano la stessa edizione di SQL Server 2005, Standard o Enterprise.
Disponibilità del server di controllo Se si intende utilizzare la protezione elevata con failover automatico, accertarsi che il server di controllo sia disponibile e che SQL Server 2005 sia installato (qualunque edizione). Il server di controllo può essere eseguito su un qualunque computer affidabile in grado di supportare SQL Server 2005.
Immagine mirror Assicurarsi che l'istanza del server mirror condivida processi, account di accesso, pacchetti SQL Server Integration Services (SSIS), partizioni del disco, posizioni dei file e configurazione del server con l'istanza del server principale. Se si configura il server mirror esattamente come il server principale si avrà la garanzia che esso funzionerà esattamente come il primo.
Recupero con registrazione completa È importante che tutti i database che partecipano al mirroring del database siano impostati sul modello di recupero con registrazione completa (FULL).
Master e TempDB Verificare che tutte le istanze del server nella topologia di mirroring si avvalgano delle regole di confronto e della tabella codici Master e TempDB. Le differenze tra regole di confronto e tabella codici potrebbero causare dei problemi durante la configurazione del mirroring del database.
Backup Se il database soggetto a mirroring è grande, occorre eseguire un backup completo del database, quindi ripristinarlo sull'istanza del server mirror utilizzando l'opzione NORECOVERY.
Pianificazione Determinare in anticipo tutti i nomi, i numeri di porta, gli account di protezione dei server e le posizioni del database e documentarli. Per un elenco di controllo, vedere "Procedure consigliate per il mirroring del database" nella barra laterale.
Una volta verificati questi elementi di base, è possibile passare alla configurazione del mirroring del database nell'ambiente in uso.
Procedure consigliate per il mirroring del database
  1. Utilizzare server partner che abbiano CPU, memoria, archiviazione e capacità di rete identiche.
  2. Assicurarsi che entrambi i partner abbiano la stessa edizione del sistema operativo, di SQL Server, compresi service pack e aggiornamenti.
  3. Installare SQL Server sulle stesse directory e strutture di unità su entrambe le istanze del server, mirror e principale.
  4. Se le prestazioni rappresentano un problema, prendere in considerazione una scheda di interfaccia di rete dedicata per separare il carico.
  5. Come per i partner server, accertarsi che entrambe le istanze del server, mirror e principale, siano identiche in termini di CPU, memoria, archiviazione e capacità di rete. Verificare che entrambi i server abbiano la stessa struttura di directory, lo stesso schema di partizione del disco e la medesima configurazione di SQL Server per evitare di dover modificare il partner mirror durante o dopo il failover.
  6. Assicurarsi che tutte le applicazioni siano in grado di connettersi e di eseguire tutte le azioni necessarie e che tutti gli accessi SQL Server attivi (e le relative autorizzazioni) sull'istanza del server principale siano presenti anche sull'istanza del server mirror. Per farlo, è possibile utilizzare l'attività Trasferisci account di accesso di SQL Server 2005 Integration Services.
  7. Copiare processi e avvisi di SQL Server Agent, pacchetti SSIS, database di supporto, definizioni del server collegate, periferiche di backup, progetti di manutenzione, profili di posta del database e così via dal server principale al server mirror.
  8. Definire una procedura che consenta di ripetere o replicare automaticamente eventuali modifiche del server principale (modifiche hardware, software, impostazioni SQL Server o oggetti di database) e di trasferirle all'istanza del server mirror.
  9. Eseguire più prove di failover prima di quella effettiva.

Configurazione
Questa configurazione del mirroring del database è del tipo Protezione elevata con failover automatico (come spiegato, sarà necessario implementare un server di controllo). Sono utilizzati nell'esempio i nomi di server e database riportati nella Figura 2, in cui è anche specificato il ruolo di ogni server.
Poiché la configurazione può avere un impatto sulle prestazioni durante la copia del registro delle transazioni in sospeso dal server principale al server mirror, potrebbe essere preferibile eseguire la configurazione iniziale del mirroring del database lontano dalle ore di punta.
La configurazione del mirroring si divide in tre fasi: creazione di endpoint nei server partecipanti, esecuzione di backup e ripristino del database principale, attivazione delle sessioni di mirroring su tutti i server partecipanti.
Prima di stabilire una sessione di mirroring del database, occorre stabilire il meccanismo di comunicazione tra tutti i server che partecipano al mirroring del database. Per farlo, è necessario creare degli endpoint su tutti i server eseguendo questa istruzione sul ServerA e ServerB:
Create Endpoint Mirroring_Endpoint
State= Started as TCP (Listener_Port=5001)
For Database_Mirroring (Role=Partner);
Per il ServerC (che agirà da server di controllo), occorre modificare (Role=Partner) in (Role=Witness) ed eseguire l'istruzione. In questo modo si controlla la porta TCP di attesa per le singole istanze.
Per il prossimo passaggio, occorre eseguire un backup del database completo, un backup del registro del database DBM_Demo dal server principale, quindi ripristinare il backup sull'istanza del server mirror utilizzando l'opzione NORECOVERY. L'uso di NORECOVERY assicura che il database mirror rimanga nello stato di ripristino per l'applicazione del registro delle transazioni.
Ecco l'istruzione T-SQL per eseguire il backup completo del database per il database DBM_Demo del ServerA (istanza del server principale):
Backup Database DBM_Demo to DISK='E:\MSSQL\Bak\DBM_Demo_FULL.bak';
Se dopo il backup completo del database sono apportate modifiche, eseguire un backup del registro del database.
Se necessario, utilizzare l'istruzione T-SQL che segue per eseguire un backup del registro del database DBM_Demo del ServerA:
Backup Log DBM_Demo to Disk='E:\MSSQL\Bak\DBM_Demo_Log.bak';
Una volta eseguiti tutti i backup, spostare i file di backup nel ServerB o in una posizione condivisa per il ripristino sul ServerB. Dopo averlo fatto, ripristinare eventuali backup del registro delle transazioni eseguiti a partire dall'ultimo backup del database completo del ServerA.
Utilizzare l'istruzione T-SQL seguente per ripristinare il backup completo e il backup del registro sul ServerB utilizzando l'opzione NORECOVERY:
--Restore full database backup on the mirror --server instance
Restore Database DBM_Demo from Disk='E:\MSSQL\Bak\DBM_Demo_FULL.bak' with NORECOVERY;
Infine, utilizzare l'istruzione T-SQL seguente per ripristinare il backup del registro sul server mirror utilizzando l'opzione NORECOVERY:
Restore Log DBM_Demo from Disk='E:\MSSQL\Bak\DBM_Demo_Log.bak' with NORECOVERY;
Una volta ripristinati tutti i backup, è possibile passare alla fase finale e attivare la sessione di mirroring del database su tutti i server partecipanti.
Per preparare una sessione di mirroring del database occorre un indirizzo di rete server per ogni istanza del server. Questo indirizzo deve identificare l'istanza fornendo un indirizzo di sistema e il numero di porta di attesa per l'istanza. La sintassi di un indirizzo di rete server è simile alla seguente:
TCP://<System-address>:<port>
<Indirizzo del sistema>: Nome di dominio completo o indirizzo IP; questa informazione è reperibile eseguendo IPCONFIG sul computer locale dal prompt dei comandi.
La <Porta> è stata definita durante la creazione degli endpoint.
È possibile iniziare la sessione di mirroring del database sul ServerB:
Alter Database DBM_Demo
Set Partner= 'TCP://ServerA.com:5001';
Eseguire quindi l'istruzione T-SQL seguente per iniziare la sessione sul ServerA:
Alter Database DBM_Demo
Set Partner='TCP://ServerB.com:5001';
Attivare la sessione di mirroring sul ServerC (il server di controllo):
Alter Database DBM_Demo
Set Witness='TCP://ServerC.com:5001';
Il mirroring del database è adesso pronto per essere eseguito nell'ambiente in uso. Qualunque oggetto di database aggiunto o modificato sul database DBM_Demo sarà trasferito alla copia ServerB. In caso di assenza di disponibilità del database del ServerA, potrebbe verificarsi un failover, modificando il ruolo del database mirror in ruolo principale.
Adesso che il mirroring del database è funzionante, sarà sempre disponibile un database hot standby per ovviare ai problemi del database di produzione.

Saleem Hakani è senior database engineer presso Microsoft e vanta oltre 14 anni di esperienza nel settore dei sistemi di database. Ha fondato e conduce la Microsoft SQL Community ed è responsabile degli standard e dell'automazione SQL Server nell'organizzazione Windows Live. Saleem possiede le certificazioni MCTS, MCDBA e MCSA. Per contattarlo, scrivere a Saleem@sqlcommunity.net.


 Appunti: Il dottore &#232; al lavoro
Appunti
Il dottore è al lavoro
Matt Hester

È ACCADUTO DI RECENTE Recentemente mi sono reso conto che un professionista IT è un po' come un medico. Ho avuto questa rivelazione la prima volta che ho utilizzato Windows Vista™. Avevo problemi di connettività di rete. Dopo ore di ping, ipconfig e un certo numero di riavvii, ho visto un nuovo termine che ha stimolato la naturale curiosità condivisa da tutti i professionisti IT: "diagnostica". Generalmente, quando lavoro su un sistema operativo, trovo parole del tipo "riparazione", "stato", "task manager" e "invia report di errore", che mi aiutano a muovermi tra i meandri del sistema. Ma vedere la parola "diagnostica" mi ha fatto pensare alle analogie fra le due professioni.
In primo luogo, sia i medici sia i professionisti IT hanno sostenuto esami e ottenuto certificati di abilitazione che consentono loro di aggiungere certi titoli dopo il cognome. Questi titoli identificano le specializzazioni e, si spera, suscitano un certo rispetto se affissi sulla porta di casa o stampati sui biglietti da visita.
Come i medici, i professionisti IT possono avvalersi di molte risorse per risolvere i problemi. I dottori si consultano con i colleghi e ricercano informazioni nelle pubblicazioni professionali e su Internet. Noi professionisti IT ci consultiamo ugualmente con i colleghi e ricerchiamo Internet e pubblicazioni tecniche (in particolare TechNet Magazine ovviamente) per riuscire a meglio risolvere i problemi.
Inoltre, sia i medici che i professionisti IT fanno affidamento su strumenti fidati. I dottori possiedono strumenti concreti e comprovati come lo stetoscopio; noi abbiamo il ping. Entrambi ci consentono di "auscultare" per scoprire qual è il problema.
L'ultimo punto in comune è di natura sociale. Quando partecipano a serate mondane, sia i medici sia i professionisti IT desiderano ardentemente nascondere la loro identità professionale. Ahimè, a una festa recente, alcune persone hanno scoperto quale sia la mia professione e improvvisamente mi cercavano tutti. Ma quella popolarità aveva un prezzo: Ho perso la mia identità di essere umano affascinante, diventando semplicemente "quello del computer" e, di conseguenza, lo specialista riluttante di supporto per tutti gli invitati: "Perché il mio computer si è piantato questa mattina"? "Dove si trova il tasto Any"?, "Verrebbe ad aggiustarmi il Mac?" Per ironia della sorte, ho visto un dottore dall'altra parte della stanza che sogghignava guardandomi, continuando tranquillamente a danzare senza interruzioni.
Ma ritorniamo al mio problema di connettività: dopo circa tre ore di tentativi infruttuosi per connettermi, ho fatto clic sul pulsante Esegui diagnosi e ripristina, da me scoperto di recente. Sono stato sopraffatto dallo shock e dall'imbarazzo quando ho visto la schermata di risposta visualizzata qui sotto:

(Fare clic sull'immagine per ridurla)
A bocca aperta e con le guance in fiamme, mi sono guardato intorno per assicurarmi di non essere visto. Poi ho allungato la mano dietro al computer e ho inserito il cavo nello slot. Da quel giorno, ho lavorato ancora con Windows Vista e ho utilizzato ampiamente la funzionalità di diagnostica. Mi ha fatto risparmiare una quantità enorme di tempo nello scoprire la causa principale di molti problemi. Si integra molto bene col pannello di controllo Segnalazione di problemi e soluzioni, che consente di ricercare ulteriori informazioni in linea. Vale la pena di darvi un'occhiata prima di iniziare a strapparsi i capelli.
Più tardi quella sera a letto, felice di avere identificato e risolto con successo il mio problema di connettività di rete, mi sono chiesto: ciò significa forse che potrò giocare di più a golf e guidare una nuova auto sportiva?

Matt Hester è presentatore di TechNet per il team Microsoft Across America. Per ulteriori informazioni sulle sue presentazioni vedere technetevents.com/mhester. È possibile inoltre visitare il suo blog in blogs.technet.com/matthewms.


 Windows Confidential: Sembrare intelligenti senza esserlo
Windows Confidential
Sembrare intelligenti senza esserlo
Raymond Chen

QUANDO SI inserisce un CD nel computer, Windows® potrebbe chiedere nuovamente come procedere nonostante le indicazioni ricevute l'ultima volta. Perché Windows dimentica le impostazioni di riproduzione automatica? Non le dimentica, semplicemente le ricontrolla.
I problemi legati alla gestione della riproduzione automatica di CD in Windows XP erano due. Innanzitutto dopo l'installazione di un programma che supportava la riproduzione automatica di CD, molti utenti non sapevano come fare per impostarlo come predefinito. Se cioè avevano scelto precedentemente un programma e selezionato di eseguirlo come predefinito, non esisteva un modo semplice per annullare tale impostazione, visualizzare nuovamente la finestra di dialogo di riproduzione automatica di CD e impostare il nuovo programma come predefinito.
Secondariamente, alcuni programmi dalle prestazioni scarse al momento dell'installazione intaccavano segretamente le impostazioni di riproduzione automatica di CD non documentate per imporsi come gestore predefinito, ignorando la scelta dell'utente.
In poche parole, per gli utenti i due problemi erano i seguenti: "Ho installato questo programma e voglio che diventi il mio programma di riproduzione automatica di CD" oppure "Ho installato questo programma e non lo voglio come programma di riproduzione automatica di CD".
Windows Vista tratta le impostazioni di riproduzione automatica a livello globale
Windows Vista tratta le impostazioni di riproduzione automatica a livello globale (Fare clic sull'immagine per ridurla)
Windows Vista tratta le impostazioni di riproduzione automatica a livello globale
Windows Vista tratta le impostazioni di riproduzione automatica a livello globale (Fare clic sull'immagine per ingrandirla)
Windows XP Service Pack 2 (SP2) ha introdotto un nuovo comportamento nella riproduzione automatica di CD nel tentativo di risolvere questi problemi. Se individua un nuovo gestore di riproduzione automatica di CD disponibile, Windows mostra ancora una volta la finestra di dialogo di riproduzione automatica CD. In questo modo è possibile selezionare o deselezionare il nuovo programma appena installato.
La finestra di dialogo viene visualizzata anche la prima volta che si inserisce un CD dopo l'aggiornamento a Windows XP SP2. Si tratta di una finestra di dialogo diretta a eventuali gestori installati prima dell'aggiornamento a Windows XP SP2.
In passato, il sistema operativo doveva preoccuparsi soltanto di supportare l'interfaccia degli sviluppatori con una funzionalità. Ma, nel panorama di software attuale, deve anche preoccuparsi di bloccare i programmatori che tentano di abusare dell'interfaccia.
C'è un altro caso in cui sembra che Windows dimentichi le impostazioni di riproduzione automatica. Quando si inserisce un dispositivo di archiviazione rimovibile, ad esempio un'unità USB, viene visualizzata la richiesta anche se è stata selezionata l'opzione Always perform this action (Esegui sempre questa operazione). Ciò non accade perché Windows ha dimenticato le impostazioni, ma perché le ricorda fin troppo bene.
Quando si sceglie un'opzione per un dispositivo di archiviazione rimovibile, Windows la ricorda. Collegando un dispositivo diverso, viene visualizzata una nuova richiesta poiché non è stato specificato il comportamento che il dispositivo deve seguire. L'intento è quello di lasciare all'utente la libertà di specificare ad esempio se la macchina fotografica digitale deve entrare per impostazione predefinita in modalità "Visualizza immagini" o il lettore musicale in modalità "Riproduci musica". Se il dispositivo non ha un numero di serie e viene inserito in una porta USB differente, viene trattato come un dispositivo diverso.
In risposta alla confusione creata da Windows XP, questo comportamento è stato modificato in Windows Vista™. Le impostazioni di riproduzione automatica sono adesso trattate a livello globale piuttosto che per dispositivo. Se non viene specificata alcuna azione, Windows Vista non agisce, a prescindere dal dispositivo inserito o dal punto in cui è stato inserito. Talvolta per fare funzionare il sistema in modo intelligente occorre farlo sembrare meno efficiente.

Raymond Chen The Old New Thing (blogs.msdn.com/oldnewthing) e il libro dal titolo omonimo (Addison-Wesley, 2007) parlano della storia di Windows e della programmazione Win32. Nel tempo libero Raymond Chen scrive relazioni per gli studenti delle scuole medie.