 TechNet Magazine April 2008

TechNet Magazine April 2008

SQL Server 2008:: novità

La nuova versione di SQL Server offre molte nuove funzionalità e miglioramenti che promettono prestazioni ottimizzate, maggiore sicurezza e una vita più facile per gli amministratori dei database. Ecco una panoramica sulle novità principali e su ciò che è lecito attendersi da SQL Server 2008.

Randy Dyess SQL Server 2008:: sicurezza

La sicurezza continua a essere un'area di miglioramento importante per SQL Server. Questo è un viaggio nelle modifiche più importanti relative alla sicurezza apportate in SQL Server 2008, dai miglioramenti di crittografia e autenticazione alla gestione basata su criteri e al nuovo sistema di controllo che aiuta a garantire la conformità ai requisiti normativi.

Rick Byham SQL Server 2008:: nuovi tipi di dati

SQL Server 2008 consente di gestire sette nuovi tipi di dati, in modo che si possa lavorare con dati più complessi e semplificare la gestione di dati strutturati, semistrutturati e anche non strutturati. Uno sguardo approfondito su questi nuovi tipi di dati e sulle relative modalità di utilizzo per una migliore gestione dei dati nella propria infrastruttura.

Kelly Wilson SQL Server 2008: Prestazioni delle query nel data warehouse

SQL Server 2008 offre nuove e utili funzionalità di data warehousing relazionale. Analizziamo le innovative funzionalità di data wherehousing relative alle prestazioni e scopriamo come è possibile utilizzare questa tecnologia per ottimizzare le prestazioni delle query.

S. Agarwal, T. Grabs, and J. Hammer SQL Server: Ridurre al minimo i blocchi in SQL Server

I blocchi sono essenziali per il supporto di attività di lettura e scrittura contemporanee su un database, ma possono influire negativamente sulle prestazioni del sistema. Nell'articolo sono riportate alcune informazioni su come ottimizzare il database SQL Server in modo da ridurre al minimo i blocchi, oltre a suggerimenti per un miglior monitoraggio del sistema per comprendere come i blocchi influiscano sulle prestazioni.

Cherié Warren Microsoft Office: Integrazione dei database di Access con SharePoint

In molte aziende si utilizza ancora Microsoft Access. Per fortuna, Microsoft Office SharePoint Server 2007 consente di integrare i dati legacy di Access. Ecco come si possono utilizzare questi strumenti per creare nuove soluzioni per l'organizzazione.

Peter Serzo Dal redattore: Agli amici, vecchi e nuovi

Joshua Hoffman Lettere: La parola ai lettori

Casella degli strumenti: Nuovi prodotti per professionisti IT

Greg Steen Domande e risposte su SQL: Database che crescono, IFilter e connessione in modalità remota

Informazioni su come far crescere i database a livello di programmazione, sull'utilizzo di IFilters e sulle impostazioni del firewall che supportano le connessioni SQL Server remote.

Edited by Matthew Graven Utilità in primo piano: WCAT (Web Capacity Analysis Tool)

I registri Web e l'analisi del traffico possono fornire un'idea chiara del tipo di traffico che è possibile aspettarsi nel corso del tempo. Tuttavia, come si può determinare il volume di traffico che un'infrastruttura è in grado di gestire? Lo strumento Web Capacity Analysis Tool, disponibile gratuitamente, consente di verificare il livello di prestazioni dei propri sistemi in condizioni di stress.

Greg Steen The Cable Guy: Risoluzione dei problemi relativi all'imposizione di Protezione accesso alla rete

La risoluzione dei problemi relativi ai metodi di imposizione nella piattaforma Protezione accesso alla rete può rivelarsi un'attività impegnativa. Nella rubrica The Cable Guy viene illustrato come eseguire la valutazione del criterio di integrità di Protezione accesso alla rete e viene descritto come risolvere i problemi più comuni.

Joseph Davies Windows PowerShell: Firmare qui, prego

Una panoramica sulla firma degli script che consente di migliorare la sicurezza.

Don Jones Hey, Scripting Guy!: Il ritorno degli script del database

Una panoramica su come la firma degli script possa garantire una maggiore sicurezza.

The Microsoft Scripting Guys Controllo della protezione: Dove sono le mie informazioni personali?

Per poter garantire una protezione efficace delle informazioni personali, è necessario prima individuare la posizione in cui sono archiviate sul PC. Nel presente articolo viene presentata la procedura da seguire per scrivere script che consentiranno di individuare i dati personali archiviati nel computer. La gamma di potenzialità offerta da questi script è davvero sorprendente.

Frank Simorjay File desktop: Distribuzione di Windows XP con WAIK

Windows Automated Installation Kit è stato progettato pensando principalmente a Windows Vista e Windows Server 2008. Ma forse i lettori non sanno che può essere anche utilizzato per distribuire Windows XP e Windows Server 2003. Nell'articolo viene illustrato tutto ciò che serve sapere per iniziare.

Wes Miller Taccuino: Un'iniziativa meravigliosa

Il nuovo programma Microsoft Authorized Refurbisher (MAR) può aiutare le aziende a risolvere complessi problemi correlati alle licenze software quando si rigenerano i vecchi computer.

Neil Fawcett Windows Confidential: Condivisioni e simili

"Rimuovere questo file condiviso?" Raymond Chen spiega perché nel programma di disinstallazione viene visualizzato un messaggio di questo tipo durante la rimozione di un programma.

Raymond Chen


 SQL Server 2008:: novit&#224;
SQL Server 2008: Randy Dyess

novità
Panoramica:
  • Gestione più efficace
  • Prestazioni e scalabilità ottimizzate
  • Maggiore sicurezza e disponibilità
  • Modifiche per gli sviluppatori

Microsoft ha rilasciato ancora una volta una nuova versione di SQL Server che promette una vita più facile per gli amministratori dei database. La versione più recente, SQL Server 2008, offre un'ampia gamma di nuove
caratteristiche e funzionalità che consentiranno di migliorare considerevolmente le attività di amministrazione.
Gli amministratori di database che hanno utilizzato SQL Server® 2005 per un certo periodo di tempo si imbatteranno in molte delle stesse funzionalità che utilizzano per lo svolgimento delle relative attività quotidiane. Tuttavia, nel giro di poco tempo scopriranno che questi strumenti familiari sono stati migliorati in SQL Server 2008. Le nuove funzionalità basate sulle funzionalità esistenti contribuiscono in modo significativo alla riduzione del numero di soluzioni alternative o personalizzazioni in precedenza necessarie per utilizzare diverse funzionalità nei complessi ambienti di database.
Le nuove funzionalità in SQL Server 2008 coinvolgono un'ampia gamma di ruoli specifici dei database, rendendone difficoltosa la classificazione. Poiché le funzionalità vengono organizzate in base ad argomenti differenti, è possibile che alcuni lettori si domandino perché la Funzionalità X sia stata classificata sotto la Categoria Y, quando invece è evidente che appartiene alla Categoria Z. Questa classificazione può essere affrontata da diverse prospettive ed è influenzata dalla modalità di gestione delle attività commerciali da parte dell'azienda.
Non vi è alcun dubbio che gli amministratori dei database spesso svolgono diversi ruoli, ma tenterò di suddividere le nuove funzionalità nelle seguenti categorie generiche: gestione, scalabilità, prestazioni, disponibilità elevata, sicurezza, sviluppo e Business Intelligence.

Novità per la gestione
Per gli amministratori di database (come me), la funzionalità di gestione aggiuntiva rende SQL Server 2008 un prodotto molto interessante. La nuova gestione dei criteri, l'esecuzione di query su più server, i server di configurazione e il warehouse di gestione/raccolta dati offrono nuove e potenti funzionalità per gli amministratori dei database, responsabili, in genere, della gestione di ambienti di database grandi e complessi con centinaia o migliaia di database su decine o persino centinaia di server.
La nuova funzionalità Gestione criteri di SQL Server 2008, denominata Declarative Management Framework nelle versioni CTP (Community Technology Preview), consente di creare ed eseguire i criteri di configurazione su uno o più server di database. Con questi criteri, è possibile garantire che le impostazioni di configurazione standard vengano applicate e gestite su ciascuno dei server e dei database di destinazione. Un esempio di questa funzionalità viene illustrato nella Figura 1.
Figura 1 Criterio relativo alle procedure consigliate per la posizioni di file di log e dati
Figura 1 Criterio relativo alle procedure consigliate per la posizioni di file di log e dati
I criteri vengono creati da una serie predefinita di facet. Ogni facet contiene un sottogruppo di impostazioni di configurazione di SQL Server 2008 e altri eventi che è possibile controllare. Per creare un criterio, è necessario associare questi facet a determinate condizioni. Le condizioni rappresentano i valori consentiti per le proprietà di un facet, le impostazioni di configurazione o altri eventi contenuti all'interno del facet.
Le condizioni rappresentano inoltre i valori utilizzati per i filtri di criteri. Si supponga che si desideri eseguire il criterio solo su un determinato database. In questo caso, è possibile creare una condizione che contiene il nome del database e aggiungerla al criterio. In tal modo, il criterio sarà applicabile solo al database in questione. Sebbene la funzionalità Gestione criteri di SQL Server 2008 possa sembrare complessa, una volta provata, si scoprirà che in realtà è piuttosto intuitiva.
Quando è necessario eseguire query su più server contemporaneamente, particolarmente utili si rivelano le nuova funzionalità di interazione con più server e dei server di configurazione. È possibile registrare i server in Management Studio e riunirli in un unico raggruppamento. Quando occorre eseguire un criterio o una query su tutti i server nel raggruppamento, fare semplicemente clic con il pulsante destro del mouse sul raggruppamento.
Un ulteriore vantaggio è rappresentato dalla possibilità di configurare questa funzionalità per la restituzione di un unico set di risultati per ciascun server o per la fusione di tutti i risultati in un unico grande set di risultati. È possibile inoltre specificare se si desidera che i nomi dei server e dei database vengano restituiti come parte dei risultati in modo da poter separare i singoli risultati da ciascun server. La possibilità di archiviare i server registrati sul server di configurazione anziché nel Management Studio di ciascun utente rappresenta un enorme vantaggio.
Un'altra interessante funzionalità di gestione è rappresentata dall'agente di raccolta dati. Gli amministratori di database hanno in genere la necessità di raccogliere i dati di gestione da numerosi server; pertanto, molti di questi DBA hanno creato una soluzione personalizzata per l'esecuzione di questa attività. L'agente di raccolta dati è un meccanismo incorporato che semplifica l'attività di raccolta dei dati correlati alla gestione. Consente di utilizzare SQL Server Agent e SQL Server Integration Services (SSIS) per creare un framework che raccoglie e archivia i dati, fornendo al tempo stesso gestione di errori, controllo e cronologia dei dati raccolti.
A differenza degli strumenti di terze parti e dei processi personalizzati, l'agente di raccolta dati sarà compreso con facilità dalla maggior parte degli amministratori di database, in quanto prevede l'utilizzo di SQL Server Agent e SSIS per creare un insieme di processi e pacchetti per la gestione delle connessioni, della raccolta e dell'archiviazione dei dati, come illustrato nella Figura 2. Una volta archiviati i dati in una posizione centrale, definita warehouse di gestione, è possibile visualizzarli e classificarli tramite un insieme di istruzioni T-SQL e i report di Reporting Services di SQL Server 2008. Questo archivio di dati centrale semplifica notevolmente l'analisi e la visualizzazione delle metriche di gestione globali dell'ambiente di database.
Figura 2 File di log relativo all'utilizzo del disco dell'agente di raccolta dati
Figura 2 File di log relativo all'utilizzo del disco dell'agente di raccolta dati

Novità per la scalabilità
Nel corso degli anni, gli amministratori di database di SQL Server hanno assistito a un costante aumento delle dimensioni dei relativi ambienti di database. Questo aumento delle dimensioni dell'ambiente di database implica la necessità di utilizzare nuovi metodi e strumenti per raggiungere il livello di scalabilità richiesto dalla maggior parte delle aziende. SQL Server 2008 ha introdotto diverse nuove e utili funzionalità.
SQL Server 2008 dispone di una funzionalità di compressione incorporata che consente di comprimere i file di database e i file di log delle transazioni associati al database compresso. Con SQL Server 2005 è stata introdotta la capacità di comprimere i dati su un file di sola lettura o un filegroup, ma questa forma di compressione prevedeva semplicemente l'utilizzo della funzionalità di compressione di Windows® NTFS. SQL Server 2008 ora offre la funzionalità di compressione a livello di riga e a livello di pagina, fornendo vantaggi che non è possibile ottenere con la compressione a livello di file di dati.
La compressione a livello di riga e di pagina consente di ridurre la quantità di spazio di archiviazione dei dati e la quantità di memoria necessarie, in quanto i dati restano compressi mentre sono in memoria. I dati compressi in memoria determinano un maggiore utilizzo della memoria, il che garantisce un miglioramento della scalabilità di molti sistemi.
SQL Server 2008 introduce inoltre la compressione a livello di backup. Sebbene i backup dei database prevedano solo il backup della parte attiva del database, questo comporta comunque la necessità di utilizzare centinaia di gigabyte o persino decine di terabyte. Negli ambienti di database che prevedono più copie di un file di backup di svariati terabyte, questi backup in genere occupano una quantità preziosa di spazio di archiviazione che potrebbe essere utilizzato in modo più efficiente. Consentendo agli amministratori di database di comprimere i relativi file di backup, SQL Server 2008 libera parte di questo spazio, che può essere quindi utilizzato per i dati attivi.
Un'altra interessante funzionalità è rappresentata da Resource Governor. Questa nuova funzionalità consente di definire la quantità di risorse che può essere utilizzata da un singolo o da diversi carichi di lavoro durante l'esecuzione. Con Resource Governor, è possibile creare un ambiente in cui diversi carichi di lavoro coesistono su un singolo server, senza il timore che questi carichi di lavoro possano sopraffare il server e ridurre le prestazioni degli altri carichi di lavoro.
Il vantaggio di questa funzionalità è rappresentato dalla possibilità di utilizzare in modo più efficace la quantità totale di risorse disponibili sui server di database. Nella Figura 3 viene illustrato un esempio di utilizzo della funzionalità Resource Governor per limitare l'attività su un server.
Figure 3 Limitazione dell'attività con Resource Governor (Close Figure 3)
USE master
go

--Drop function
IF OBJECT_ID('rgclassifier_demo','Function') IS NOT NULL
DROP FUNCTION rgclassifier_demo
go

--Create a classifier function for report group
CREATE FUNCTION rgclassifier_demo() RETURNS SYSNAME
WITH SCHEMABINDING
AS
BEGIN
    DECLARE @group_name AS SYSNAME
  IF (USER_NAME() LIKE '%Launch_Demo%')
         SET @group_name = 'demogroup'
    RETURN @group_name
END
GO

--Drop workload group for anything coming from Management Studio
IF EXISTS (SELECT name FROM sys.resource_governor_workload_groups
  WHERE name = 'demogroup')
BEGIN
  DROP WORKLOAD GROUP demogroup
END
GO

--Create workload group
CREATE WORKLOAD GROUP demogroup
GO

--Register the classifier function with
--Resource Governor
ALTER RESOURCE GOVERNOR WITH (CLASSIFIER_FUNCTION= dbo.rgclassifier_demo)
GO

--Alter the dbogroup workload group to only
--allow 10% of CPU for each workload request
ALTER WORKLOAD GROUP demogroup
WITH (REQUEST_MAX_CPU_TIME_SEC = 10)
GO

--Create a new resource pool and set a maximum CPU limit for all workloads.
IF EXISTS (SELECT name FROM sys.resource_governor_resource_pools
  WHERE name = 'pooldemo')
DROP RESOURCE POOL pooldemo
GO

CREATE RESOURCE POOL pooldemo
WITH (MAX_CPU_PERCENT = 40)
GO

--Configure the workload group so it uses the
--new resource pool.
ALTER WORKLOAD GROUP demogroup
USING pooldemo
GO

--Apply the changes to the Resource Governor
--in-memory configuration.
ALTER RESOURCE GOVERNOR RECONFIGURE
GO

Novità per le prestazioni
Le prestazioni generali dei database risultano migliorate con SQL Server 2008. Grazie a diverse nuove funzionalità disponibili in SQL Server 2008, è possibile controllare e monitorare le prestazioni dei database e le applicazioni eseguite su di essi.
In situazioni in cui ogni secondo viene eseguito un numero elevato di transazioni, il blocco che in genere si verifica durante queste transazioni può avere un impatto negativo sulle prestazioni delle applicazioni di database. SQL Server è progettato per ridurre il numero totale di blocchi che un processo mantiene effettuando l'escalation dai blocchi a livello di riga e a livello di pagina di piccole dimensioni ai blocchi a livello di tabella di grandi dimensioni. Tuttavia, è importante comprendere che questa escalation di blocchi può causare problemi. Ad esempio, una singola transazione può bloccare un'intera tabella e impedire che la tabella venga utilizzata da altre transazioni.
SQL Server 2008 prevede l'utilizzo del meccanismo di partizionamento delle tabelle, introdotto in SQL Server 2005, per consentire che il motore di SQL Server esegua l'escalation dei blocchi prima a livello di partizione e successivamente a livello di tabella. Questo livello intermedio di blocco può ridurre in modo significativo gli effetti dell'escalation dei blocchi sui sistemi che devono elaborare centinaia di migliaia di transazioni al secondo.
SQL Server 2008 offre diversi nuovi miglioramenti al processore delle query per le situazioni in cui la query interagisce con le tabelle partizionate. Query Optimizer ora è in grado di eseguire ricerche tramite query sulle partizioni allo stesso modo in cui vengono eseguite nei singoli indici, utilizzando solo l'ID di partizione anziché il meccanismo di partizionamento a livello di tabella.

Novità per la disponibilità elevata
In conseguenza dell'aumento della complessità degli ambienti di database e dell'incremento delle dimensioni dei database, è sempre più difficile garantire la disponibilità dei database. I noti meccanismi utilizzati in passato per ottenere un livello elevato di disponibilità sono ancora presenti in SQL Server 2008. Tuttavia, alcune di queste funzionalità sono state migliorate in SQL Server 2008 e ne sono state aggiunte altre.
Con SQL Server 2005, per ottenere la disponibilità elevata, molti amministratori hanno iniziato a implementare il mirroring del database. SQL Server 2008 offre numerosi miglioramenti per l'attività di mirroring del database. Ad esempio, in passato, il mirroring del database presentava occasionalmente problemi di prestazioni correlati al trasferimento dei dati del log delle transazioni dal database principale al database con mirroring. In risposta, SQL Server 2008 ora consente di ridurre la quantità di informazioni trasferite in rete dal log delle transazioni del database principale al log delle transazioni del mirror comprimendo le informazioni prima di inviarle al log delle transazioni del database mirror per la protezione avanzata.
Ora è possibile ripristinare le pagine di dati danneggiate sul database principale. Se un database principale presenta pagine di dati danneggiate a causa degli errori 823 e 824, il database principale può richiedere una copia aggiornata di tali pagine ai server con mirroring. Questa richiesta di pagine di dati aggiornate è un processo automatico che avviene in modo trasparente per qualsiasi utente che acceda ai database principali.
Un'altra nuova funzionalità, l'aggiunta di CPU a caldo, consente di aggiungere ulteriori CPU a un server di database senza influire sulla disponibilità dei database che risiedono su tale server. Tuttavia, tenere presente che l'aggiunta di CPU a caldo presenta alcune limitazioni, in quanto è utile solo quando si esegue Windows Server® 2008 Enterprise Edition o Datacenter Edition per sistemi basati su Itanium a 64 bit e richiede l'utilizzo di SQL Server 2008 Enterprise Edition.

Novità per la sicurezza
Con SQL Server 2005 è stato introdotto il supporto per la crittografia dei dati a garanzia della sicurezza dei dati. Con SQL Server 2008, la crittografia è stata notevolmente migliorata con l'introduzione di due funzionalità: Extensible Key Management e Transparent Data Encryption.
Extensible Key Management offre una struttura avanzata per archiviare in sicurezza le chiavi utilizzate nell'infrastruttura di crittografia, non solo all'interno del database ma anche all'esterno del database nei moduli software di terze parti o con un modulo di sicurezza hardware.
Transparent Data Encryption offre maggiore flessibilità per la crittografia dei dati facendo sì che la crittografia sia una proprietà del database e non solo il risultato di funzioni in una riga di codice. Ne consegue che gli amministratori non devono effettuare le numerose modifiche necessarie per la struttura del database e il codice dell'applicazione quando eseguono la crittografia a livello di dati. Nel codice nella Figura 4 viene illustrato come crittografare un database con Transparent Data Encryption.
Figure 4 Utilizzo di Transparent Data Encryption (Close Figure 4)
USE master;
GO

--Create a master key
CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'YouWillNeedToCreateAStrongPassword';
GO

--Create a certificate to use with TDE
CREATE CERTIFICATE TDECERT WITH SUBJECT = 'TDECert'
GO

--Change to the database to encrypt
USE AdventureWorks
GO

--Create your database master key
CREATE DATABASE ENCRYPTION KEY
WITH ALGORITHM = AES_128 --Use a strong algorithm
ENCRYPTION BY SERVER CERTIFICATE TDECERT
GO

--Alter the database to encrypt it with the
--master database key
ALTER DATABASE AdventureWorks
SET ENCRYPTION ON
GO

Novità relative agli sviluppatori
Gli amministratori di database non sono i soli a usufruire direttamente dei vantaggi delle modifiche introdotte in SQL Server 2008. Sono infatti disponibili numerose nuove funzionalità progettate per semplificare il lavoro degli sviluppatori di database. Queste funzionalità spaziano dai nuovi miglioramenti alle istruzioni T-SQL ai nuovi componenti che consentono agli sviluppatori di semplificare le attività di creazione e utilizzo delle query di database.
Molti sviluppatori di database sono responsabili della creazione delle query necessarie per restituire i dati richiesti per le relative applicazioni. Probabilmente, si conosce già lo strumento LINQ (Language Integrated Query), che consente agli sviluppatori di database di eseguire query su un database mediante un linguaggio di programmazione basato su Microsoft® .NET anziché utilizzare le normali istruzioni T-SQL. In SQL Server 2008 lo strumento LINQ è stato migliorato, in quanto viene fornito un nuovo provider LINQ to SQL che consente agli sviluppatori di database di eseguire i comandi LINQ direttamente su tabelle e colonne SQL Server. Questo consente di ridurre la quantità di tempo necessaria per creare nuove query di dati.
Quando eseguono lo sviluppo a fronte di database, gli sviluppatori utilizzano oggetti di livello più elevato che vengono mappati alle singole tabelle e colonne del database. Questi oggetti, noti anche come entità, rappresentano i dati necessari per le applicazioni di database e, pertanto, lo sviluppatore non ha la necessità di comprendere la struttura di archiviazione effettiva dei dati e dello schema del database. La nuova funzionalità Entity Framework di ADO.NET ora consente agli sviluppatori di creare le query di database utilizzando queste entità. L'astrazione della struttura di database sottostante consente di incrementare la produttività degli sviluppatori.
Con SQL Server 2008 numerosi miglioramenti sono stati apportati alle istruzioni T-SQL, che garantiscono una maggiore efficienza degli sviluppatori di database. Un esempio è rappresentato dall'istruzione MERGE, che consente allo sviluppatore di controllare l'esistenza di dati prima di tentare di inserire i dati. Questa verifica prima dell'esecuzione dell'istruzione INSERT consente di aggiornare i dati. Non è più necessario creare join complessi per aggiornare i dati esistenti e per inserire nuovi dati; ora si ha la possibilità di eseguire queste attività con un'unica istruzione.
Inoltre, la separazione dei dati relativi a data e ora dal tipo di dati combinato di data/ora è stata semplificata. In SQL Server 2008 sono stati introdotti due tipi di dati separati per la gestione dei dati relativi a data e ora. L'introduzione di diversi tipi di dati garantirà un miglioramento in termini di prestazioni delle query, in quanto non sarà più necessario eseguire un'operazione sui dati prima che possano essere utilizzati nella query.
Quando si creano nuove strutture di database, gli sviluppatori di database si trovano spesso nella necessità di estendere la struttura dei database al fine di implementare le applicazioni di mapping. SQL Server 2008 consente di risolvere questo problema con nuovi tipi di dati spaziali. I due tipi di dati spaziali, GEOGRAPHY e GEOMETRY, consentono agli sviluppatori di archiviare i dati specifici delle posizioni direttamente nel database senza dover suddividere questi elementi di dati in formati adatti ad altri tipi di dati standard. Il codice nella Figura 5 è un esempio di semplice tabella spaziale.
Figure 5 Una semplice tabella spaziale (Close Figure 5)
IF OBJECT_ID ( 'Demo_SpatialTable', 'Table' ) IS NOT NULL
    DROP TABLE Demo_SpatialTable
GO

--Create table to hold spatial data
CREATE TABLE Demo_SpatialTable
    ( SpatialID int IDENTITY (1,1),
    SpatialInputCol geography,
    SpatialOutputCol AS SpatialInputCol.STAsText() )
GO

--Insert data into table
INSERT INTO Demo_SpatialTable (SpatialInputCol)
VALUES (geography::STGeomFromText('LINESTRING(47.656 -122.360, 47.656 -122.343)', 4326));

INSERT INTO Demo_SpatialTable (SpatialInputCol)
VALUES (geography::STGeomFromText('POLYGON((47.653 -122.358, 47.649 -122.348, 47.658 -122.348, 47.658 -122.358, 47.653 -122.358))', 4326));
GO

--View data to see that data has been converted and stored in col2
SELECT * FROM Demo_SpatialTable
Un problema molto comune per gli sviluppatori di database in passato riguardava le modalità di archiviazione e di utilizzo di oggetti binari di grandi dimensioni, come documenti e file multimediali. Il metodo in genere utilizzato prevedeva l'archiviazione dei file all'esterno del database e l'archiviazione di un puntatore del database nel file esterno. Con questo metodo, tuttavia, quando si spostano il file, occorre ricordarsi di aggiornare anche il puntatore.
In SQL Server 2008 questo problema viene gestito con il nuovo tipo di dati FILESTREAM. Con questo tipo di dati, i file possono essere comunque archiviati all'esterno del database, ma, per garantire la coerenza delle transazioni, i dati vengono considerati parte del database. Questo consente l'utilizzo di operazioni di file comuni, mantenendo nello stesso tempo i vantaggi del database in termini di prestazioni e sicurezza.

Novità per le funzionalità di Business Intelligence
Il maggior utilizzo di SQL Server negli ultimi anni è stato guidato in larga parte dall'adozione delle strategie di Business Intelligence. Le strategie di Business Intelligence non sono una novità in SQL Server, ma SQL Server 2008 introduce nuove funzionalità.
Ad esempio, quando i dati vengono archiviati in data warehouse, gran parte dello spazio viene in genere sprecata a causa dei valori NULL. Le colonne in cui vengono archiviati i valori NULL occupano lo spazio delle massime dimensioni di dati consentite definite nella colonna. Ne consegue che una colonna con migliaia di valori NULL può utilizzare effettivamente molti MB di spazio senza archiviare alcun dato.
Con SQL Server 2008 vengono introdotte le colonne di tipo sparse, il che consente di archiviare i valori NULL senza occupare lo spazio fisico sul disco. Poiché le colonne di tipo sparse non prevedono l'utilizzo dello spazio effettivo, le tabelle contenenti tali colonne possono superare il limite di 1.024 colonne.
Con SQL Server 2008 viene introdotto inoltre un nuovo meccanismo, Change Data Capture, per la gestione di modifiche incrementali che devono essere caricate nel data warehouse. Questo consente di acquisire e posizionare i dati modificati in un insieme di tabelle di modifiche. L'acquisizione di dati aggiornati, eliminati e inseriti in uno schema di archiviazione di facile utilizzo consente il caricamento incrementale dei data warehouse da tali tabelle, eliminando la necessità di creare istruzioni di inserimento personalizzate per determinare le modifiche apportate alle righe di dati esistenti prima di aggiornare il data warehouse.

Conclusioni
In questo articolo è stata presentata solo una breve panoramica delle novità introdotte in SQL Server 2008. SQL Server 2008 fornisce un'ampia gamma di nuove funzionalità e una serie di aggiornamenti alle funzionalità esistenti che promettono una vita più facile per gli amministratori e gli sviluppatori di database. In definitiva, SQL Server 2008 offrirà prestazioni e scalabilità notevolmente migliorate per i database attuali sempre più esigenti.

Randy Dyess è mentore presso Solid Quality Mentors ed è specializzato nei sistemi OLTP di SQL Server. Randy è autore di TransactSQL Language Reference Guide, coautore di MCTS Self-Paced Training Kit: Microsoft SQL Server 2005 Implementation and Maintenance (Exam 70-431) e ha scritto numerosi articoli di riviste e newsletter. Randy è inoltre Program Director per il gruppo SQL Server Users nel Texas del Nord ed è un MVP di SQL Server. È possibile consultare il suo blog all'indirizzo blogs.solidq.com/EN/rdyess/default.aspx.
© 2007 Microsoft Corporation e CMP Media, LLC. Tutti i diritti riservati. È vietata la riproduzione completa o parziale senza autorizzazione.


 SQL Server 2008:: sicurezza
SQL Server 2008: Rick Byham

sicurezza
Panoramica:
  • Miglioramenti alla crittografia
  • Miglioramenti all'autenticazione
  • Controllo della sicurezza
  • Gestione basata su criteri

SQL Server 2008 fornisce numerosi miglioramenti e nuove funzionalità progettati per migliorare la sicurezza globale dell'ambiente di database. Introduce inoltre funzionalità di crittografia e autenticazione chiave e un nuovo sistema di controllo che
consente di creare report sul comportamento degli utenti e garantire la conformità ai requisiti normativi.
In questo articolo viene presentata una panoramica delle modifiche più importanti introdotte in SQL Server® 2008 a livello di sicurezza. Uno dei primi aspetti che si noterà è che lo strumento Configurazione superficie di attacco di SQL Server 2005 non è più supportato. Le opzioni di protocollo esposte dallo strumento Configurazione superficie di attacco ora sono disponibili nello strumento Gestione configurazione. Tuttavia, l'attivazione e la disattivazione delle funzionalità ora vengono eseguite mediante il nuovo framework per la gestione basata su criteri di SQL Server 2008.

Miglioramenti alla crittografia
Nell'area della crittografia sono stati introdotti due importanti miglioramenti. Primo, SQL Server ora supporta l'utilizzo delle chiavi di crittografia archiviate in un modulo di sicurezza hardware di terze parti esterno. Secondo, i dati archiviati in SQL Server possono essere crittografati in un metodo trasparente per le applicazioni che si connettono al database. Ne consegue che gli amministratori di database possono crittografare facilmente tutti i dati archiviati in un intero database senza dover modificare il codice dell'applicazione esistente.
Il primo miglioramento è reso possibile dalla nuova funzionalità Extensible Key Management (EKM), disponibile nelle edizioni Enterprise, Developer ed Evaluation di SQL Server 2008. EKM consente ai fornitori di soluzioni di gestione di chiavi a livello aziendale e di moduli di sicurezza hardware (HSM) di terze parti di registrare i relativi dispositivi in SQL Server. Una volta registrati i dispositivi, gli utenti possono utilizzare le chiavi di crittografia archiviate in questi moduli.
Questi fornitori possono esporre nei moduli persino funzionalità di crittografia avanzate, come la scadenza e la rotazione delle chiavi. In alcune configurazioni, questo consente di proteggere i dati da amministratori di database che non sono membri del gruppo sysadmin. Le istruzioni di crittografia T-SQL consentono quindi di crittografare e decrittografare i dati utilizzando le chiavi archiviate nel dispositivo EKM esterno.
Un'altra nuova funzionalità, la crittografia trasparente dei dati, consente di crittografare i file di database senza dover apportare modifiche ad alcuna applicazione. Questa funzionalità consente di eseguire la crittografia e la decrittografia I/O in tempo reale dei file di registro e di dati. La crittografia utilizza la chiave di crittografia del database (DEK, Database Encryption Key), che è archiviata nel record di avvio del database per la disponibilità durante il ripristino. La chiave di crittografia del database viene protetta con un certificato archiviato nel database master del server. Nel diagramma nella Figura 1 viene illustrata l'architettura che abilita la crittografia trasparente dei dati.
Figura 1 Architettura della crittografia trasparente dei dati
Figura 1 Architettura della crittografia trasparente dei dati
Questa architettura risulta particolarmente utile per la protezione dei dati inattivi. Sebbene sia possibile adottare diverse precauzioni per garantire la sicurezza del proprio database, come la crittografia di cespiti riservati e il posizionamento di un firewall intorno ai server di database, il supporto fisico su cui il database viene archiviato (anche i nastri di backup) presenta una vulnerabilità differente. Un utente malintenzionato potrebbe rubare questo supporto e accedere ai dati in esso archiviati.
La crittografia trasparente dei dati, tuttavia, consente di crittografare i dati riservati nel database e di proteggere le chiavi utilizzate per crittografare i dati con un certificato. Questo può consentire alle organizzazioni di garantire la conformità a gran parte delle leggi, delle normative e delle linee guida del settore correlate all'adeguata protezione dei dati.
La crittografia trasparente dei dati consente agli sviluppatori software di crittografare i dati utilizzando gli algoritmi di crittografia AES (Advanced Encryption Standard) e 3DES (Triple Data Encryption Standard). La crittografia del file di database viene eseguita a livello di pagina, ovvero le pagine vengono crittografate prima di essere scritte su disco e successivamente decrittografate quando vengono lette in memoria. I file di backup dei database per i quali la crittografia trasparente ei dati è attivata vengono crittografati anche utilizzando la chiave di crittografia del database.
Per ripristinare un database crittografato, è necessario accedere al certificato o alla chiave asimmetrica utilizzata per crittografare il database. Senza il certificato o la chiave asimmetrica, non è possibile ripristinare il database. Pertanto, accertarsi di conservare tutte le chiavi per le situazioni in cui potrebbe essere necessario accedere ai backup correlati.

Miglioramenti all'autenticazione
Come probabilmente si saprà, Kerberos è un protocollo di autenticazione di rete utilizzato per fornire un sistema a elevata sicurezza per l'autenticazione reciproca delle entità client e server (o entità di sicurezza) su una rete. Kerberos consente agli utenti di ridurre i rischi causati da vulnerabilità della sicurezza, come gli attacchi di elevazione di privilegi e di tipo man-in-the-middle. Rispetto all'autenticazione NTLM di Windows®, Kerberos è più sicuro e affidabile e offre prestazioni più elevate.
Per eseguire l'autenticazione reciproca di una connessione utilizzando Kerberos, è necessario che i nomi principali di servizio (SPN, Service Principal Name) di un'istanza di SQL Server vengano registrati in Active Directory® e che un driver client fornisca un SPN registrato durante la connessione. In SQL Server 2008, l'autenticazione Kerberos è stata estesa a tutti i protocolli di rete, compresi TCP, Named Pipe, Shared Memory e Virtual Interface Adapter (VIA). Per impostazione predefinita, il driver client deduce automaticamente un SPN corretto per un'istanza di SQL Server a cui si connette. È inoltre possibile specificare in modo esplicito un SPN nel parametro della stringa di connessione per garantire livelli di sicurezza e controllo più elevati oltre che una più efficace risoluzione dei problemi.
Internet Information Services (IIS) non fornisce più l'accesso ad ASP.NET, a Gestione report o al servizio Web ReportServer. In SQL Server 2008, Reporting Services gestisce tutta le richieste di autenticazione tramite un nuovo sottosistema di autenticazione che supporta l'autenticazione personalizzata e basata su Windows.
Reporting Services ora esegue l'hosting delle tecnologie di Microsoft® .NET Framework e ASP.NET incorporate nel CLR (Common Language Runtime) di SQL Server e utilizza le funzionalità HTTP.SYS del sistema operativo. Il server di report include un listener HTTP che accetta le richieste indirizzate a un URL e a una porta definiti durante la configurazione del server. La registrazione e le prenotazioni URL ora vengono gestite dal server di report tramite HTTP.SYS.

Controllo della sicurezza
SQL Server Audit è una nuova funzionalità che consente di creare controlli personalizzati degli eventi del motore di database. Questa funzionalità utilizza eventi estesi per registrare le informazioni per i controlli e fornisce gli strumenti e i processi necessari per attivare, archiviare e visualizzare i controlli su diversi oggetti di server e database.
SQL Server Audit, inoltre, offre prestazioni più elevate rispetto a SQL Server Trace, mentre SQL Server Management Studio consente di semplificare la creazione e il monitoraggio dei registri di controllo. È possibile eseguire il controllo a un livello di granularità maggiore, acquisendo le istruzioni SELECT, INSERT, UPDATE, DELETE, REFERENCES ed EXECUTE per i singoli utenti. Inoltre, SQL Server Audit è completamente configurabile tramite script con le istruzioni T-SQL CREATE SERVER AUDIT e CREATE SERVER AUDIT SPECIFICATION e le istruzioni correlate ALTER e DROP.
Per configurare il controllo, creare un controllo e specificare il percorso in cui gli eventi controllati verranno registrati. I controlli possono essere salvati nel registro eventi di sicurezza di Windows, nel registro applicazione di Windows o in un file nel percorso specificato. Assegnare un nome al controllo e configurarne le caratteristiche, come il percorso del file di controllo e la relativa dimensione massima. È inoltre possibile impostare SQL Server in modo che venga arrestato in caso di errore del controllo. Se è necessario registrare gli eventi controllati in più posizioni, creare semplicemente più controlli.
Il passaggio successivo consiste nel creare una o più specifiche del controllo. Una specifica di controllo del server raccoglie informazioni sull'istanza di SQL Server e contiene gli oggetti con ambito server, come account di accesso e appartenenze al ruolo del server. Include inoltre le informazioni di database gestite nel database master, come il diritto di accesso a un database. Quando si definisce una specifica di controllo, viene indicato il controllo che riceverà gli eventi monitorati. È possibile definire più controlli del server e più specifiche di controllo del server, ma ciascun controllo del server può includere una sola specifica di controllo del server attivata per volta.
È inoltre possibile creare specifiche di controllo del database che consentono di monitorare gli eventi in un singolo database. È possibile aggiungere a un controllo più specifiche di controllo del database, ma un controllo del server può attivare una sola specifica di controllo per ciascun database per volta.
Gli eventi delle azioni di controllo di SQL Server utilizzati per le specifiche di controllo del server vengono raggruppati in insiemi di eventi di azioni di controllo correlati. Questi insiemi vengono esposti come gruppi di azioni di controllo. Quando si aggiunge un gruppo alla specifica di controllo, vengono monitorati tutti gli eventi inclusi in tale gruppo. Esiste, ad esempio, un gruppo di azioni di controllo denominato DBCC_GROUP che espone i comandi DBCC. I comandi DBCC, tuttavia, non sono in grado di gestire il controllo singolarmente.
Sono disponibili 35 gruppi di azioni di controllo per il server, alcuni dei quali sono strettamente correlati tra loro. Sono disponibili, ad esempio, i gruppi SUCCESSFUL_LOGIN_GROUP, FAILED_LOGIN_GROUP e LOGOUT_GROUP. È inoltre disponibile il tipo di azione di controllo AUDIT_ CHANGE_GROUP, che è possibile utilizzare per controllare il processo di controllo.
Le specifiche di controllo del database consentono inoltre di specificare i gruppi di eventi di azioni di controllo raccolti nei gruppi di azioni di controllo a livello di database. Oltre ai gruppi di azioni di controllo, la specifica di controllo del database può contenere singoli eventi di azioni di controllo per controllare le istruzioni Data Manipulation Language (DML). È possibile configurare questi eventi per il monitoraggio dell'intero database o solo di specifici oggetti di database. L'azione di controllo SELECT, ad esempio, può essere utilizzata per controllare le query SELECT per una singola tabella o un intero schema. Questi eventi possono inoltre essere configurati per il monitoraggio delle azioni da parte di specifici utenti o ruoli, ad esempio tutti i ruoli db_writer.
È possibile utilizzare l'azione di controllo SELECT, ad esempio, per controllare le query SELECT per una singola tabella in base all'utente Mary o al ruolo di database FINANCE_DEPT o al ruolo di database pubblico. Ovviamente, questo offre un ampio margine di controllo e flessibilità per la creazione dei controlli necessari.

Creazione di report di dipendenze
La creazione dei report delle dipendenze è stata migliorata con una nuova vista del catalogo e nuove funzioni di sistema. Se si utilizza sys.sql_expression_dependencies, sys.dm_sql_referencing_entities e sys.dm_sql_referenced_entities, è possibile creare report su dipendenze tra server, dipendenze tra database e dipendenze SQL a livello di database per gli oggetti associati a schema e non associati a schema.

Nuovi ruoli di database
Sono state apportate modifiche ai ruoli di database inclusi nel database msdb. I ruoli db_dtsadmin, db_dtsltduser e db_dtsoperator sono stati rinominati rispettivamente in db_ssisadmin, db_ssisltduser e db_ssisoperator. Per supportare la compatibilità con le versioni precedenti, i ruoli precedenti vengono aggiunti come membri dei nuovi ruoli durante l'aggiornamento dei server.
Oltre a queste modifiche, sono stati aggiunti nuovi ruoli di database per fornire il supporto per le nuove funzionalità di SQL Server 2008. In particolare, il database msdb include nuovi ruoli per i gruppi di server (ServerGroupAdministratorRole e ServerGroupReaderRole), la gestione basata su criteri (PolicyAdministratorRole) e l'agente di raccolta dati (dc_admin, dc_operator e dc_proxy). Anche il database del data warehouse di gestione include nuovi ruoli per l'agente di raccolta dati (mdw_admin, mdw_writer e mdw_reader).

Sicurezza FILESTREAM
SQL Server ora fornisce il supporto per l'archiviazione FILESTREAM, che consente alle applicazioni SQL Server di archiviare dati non strutturati, come documenti e immagini, nel file system. Questo, a sua volta, implica che le applicazioni client possono sfruttare le API di flusso e le prestazioni del file system, garantendo nel contempo la coerenza delle transazioni tra i dati non strutturati e i dati strutturati corrispondenti.
I dati FILESTREAM devono essere archiviati in filegroup FILESTREAM, uno speciale filegroup che contiene le directory del file system anziché i file effettivi. Queste directory, denominate contenitori di dati, forniscono l'interfaccia tra l'archiviazione del motore di database e l'archiviazione del file system.
In termini di sicurezza, i dati FILESTREAM vengono protetti allo stesso modo degli altri dati; le autorizzazioni vengono concesse a livello di tabella o colonna. L'unico account a cui vengono concesse autorizzazioni NTFS per il contenitore FILESTREAM è l'account con cui viene eseguito l'account di servizio di SQL Server. Quando un database viene aperto, SQL Server limita l'accesso ai contenitori di dati FILESTREAM, eccetto quando l'accesso viene eseguito utilizzando le transazioni T-SQL e le API OpenSqlFilestream.

Gestione basata su criteri
La gestione basata su criteri di SQL Server 2008 fornisce un nuovo sistema per gestire SQL Server. È possibile creare criteri per testare e generare report su molti aspetti di SQL Server; i criteri possono essere applicati a un singolo database, a una singola istanza di SQL Server o a tutti i server SQL Server gestiti.
Con la gestione basata su criteri, è possibile testare le opzioni di configurazione di SQL Server e molte impostazioni di sicurezza. Per alcune impostazioni di sicurezza, è possibile creare criteri che consentono di rilevare i server di database non conformi e, successivamente, è possibile intraprendere le opportune azioni per renderli conformi.
In SQL Server 2008, numerose funzionalità che non sono considerate essenziali sono disattivate per impostazione predefinita, in modo da ridurre al minimo l'esposizione a possibili attacchi. È possibile utilizzare la gestione basata su criteri per attivare selettivamente eventuali funzionalità aggiuntive necessarie. È possibile quindi valutare la configurazione in base a una pianificazione, ricevendo avvisi nel caso in cui vengano rilevate impostazioni di configurazione non conformi ai criteri.
La gestione basata su criteri consente di raggruppare le proprietà correlate e di esporle in componenti denominati facet. Ad esempio, il facet Configurazione superficie di attacco contiene le proprietà per Query remote ad hoc, Integrazione con CLR, Posta elettronica database, Automazione OLE, Attiva DAC remote, SQL Mail, Pubblicazione guidata sul Web e xp_cmdshell. È possibile creare un criterio che consenta di attivare l'opzione Integrazione con CLR ma disattiva tutte le altre funzionalità. I criteri possono includere istruzioni di condizioni complesse, come la disattivazione di Posta elettronica database su tutte le istanze di SQL Server, a meno che non siano denominate Customer_Response.
Una volta creato il criterio, è possibile valutarlo su tutti i server per produrre un report in cui indicare i server non conformi. Fare clic sul pulsante Configura in modo che tutte le istanze non conformi vengano configurate con le impostazioni dei criteri. È opportuno inoltre pianificare l'esecuzione del criterio a intervalli periodici in modo da monitorare lo stato dei server. I facet Configurazione superficie di attacco vengono forniti per il Motore di database, Analysis Services e Reporting Services.
Notare, tuttavia, che la gestione basata su criteri non è un meccanismo di tutela della sicurezza. Nella maggior parte dei casi, un utente con privilegi sufficienti può eseguire istruzioni che violano un criterio o ignorare il criterio ed eseguire azioni di riconfigurazione che potrebbero violare i criteri di sicurezza. La gestione basata su criteri di SQL Server 2008 deve essere considerata semplicemente come un meccanismo di supporto per il monitoraggio delle impostazioni di sicurezza di SQL Server.
I facet si differenziano per la capacità di applicare le impostazioni, a seconda che le relative istruzioni DDL correlate possano essere eseguite o meno in modalità che non prevedono il commit automatico. A volte un facet può forzare un'impostazione di configurazione su un'istanza del Motore di database; tuttavia, un amministratore è comunque in grado di riconfigurare le impostazioni. Alcuni facet possono essere applicati da un trigger a livello di server; questo può impedire a utenti con privilegi ridotti di modificare l'impostazione e ridurre la possibilità che un amministratore modifichi accidentalmente l'impostazione. In questo caso, l'amministratore dovrebbe disattivare temporaneamente i criteri prima di modificare l'impostazione. Altri facet possono solo produrre report sullo stato di una proprietà ma non possono modificarlo. Questo è quanto avviene con un criterio che controlla la lunghezza di una chiave simmetrica o asimmetrica, come illustrato nella Figura 2.
Figura 2 Facet per chiavi asimmetriche
Figura 2 Facet per chiavi asimmetriche
Sono disponibili altri facet per la maggior parte dei tipi di oggetti di database, molti dei quali vengono utilizzati nell'ambito della sicurezza. Ad esempio, il facet di accesso può determinare se i criteri password vengono applicati per ciascun accesso, mentre il facet delle stored procedure è in grado di rilevare se vengono crittografate tutte le stored procedure. Altri facet sono in grado di testare proprietà di utenti, schemi, provider di servizi di crittografia, conformità ai criteri comuni e controllo C2.

Windows Server 2008
SQL Server 2008 è stato completamente testato con Windows Server® 2008, che viene fornito con il firewall attivato. Questo è il momento opportuno per esaminare la modalità di configurazione delle impostazioni del firewall. Windows Server 2008 fornisce inoltre la funzionalità di controllo di accesso utente già disponibile in Windows Vista®. Questa funzionalità limita i privilegi ricevuti automaticamente come utente con diritti di amministratore. Queste funzionalità avranno effetto su tutte le versioni di SQL Server.

Conclusioni
La sicurezza continua a essere un'area di miglioramento importante per SQL Server. I miglioramenti apportati alla crittografia e all'autenticazione forniscono nuove funzionalità, mentre il nuovo sistema di controllo e la gestione basata su criteri di SQL Server 2008 offrono nuovi strumenti per monitorare lo stato della conformità ai criteri di sicurezza.

Rick Byham è entrato in Microsoft nel 1995, dove ha lavorato come SQL Server Support Engineer presso il Servizio Supporto Tecnico Clienti e, successivamente, si è unito al team di SQL Server in Microsoft Learning. Nel 2003 è entrato a far parte del team per la documentazione in linea di SQL Server in qualità di technical writer, dove attualmente è responsabile della documentazione sulla sicurezza. È possibile contattare Rick all'indirizzo rick.byham@microsoft.com.


 SQL Server 2008:: nuovi tipi di dati
SQL Server 2008: Kelly Wilson

nuovi tipi di dati
Panoramica:
  • Nuovi tipi di dati relativi a data e ora
  • Rappresentazione della posizione in una gerarchia
  • Due modelli per l'utilizzo dei dati spaziali

La possibilità di operare con successo nell'economia globale attuale richiede sempre più l'utilizzo da parte delle aziende di nuovi tipi di dati, applicazioni e calcoli complessi. I sette nuovi tipi di dati incorporati in SQL Server 2008
consentono di lavorare con dati più complessi e di semplificarne la gestione.

Data e ora
Con il tipo di dati precedente, datetime, gli utenti di SQL Server® non avevano la possibilità di utilizzare le informazioni relative a data e ora separatamente. Quattro dei nuovi tipi di dati, date, time, datetime2 e datetimeoffset, cambiano questa situazione, semplificando l'utilizzo dei dati relativi a data e ora e fornendo maggiore supporto per l'intervallo di date, la precisione in secondi frazionari e il fuso orario. È opportuno che le nuove applicazioni di database utilizzino questi nuovi tipi di dati anziché il tipo di dati datetime precedente. Esaminiamo ora nei dettagli le nuove versioni.
Il tipo di dati date consente di archiviare una data senza un valore dell'ora. Questo tipo di dati include un intervallo compreso tra il 1 gennaio 1000 e il 31 dicembre 9999 (da 01-01-0001 a 31-12-9999). Ogni variabile relativa alla data richiede 3 byte di archiviazione e presenta una precisione di 10 cifre. L'accuratezza del tipo di data è limitata a un singolo giorno.
Dare un'occhiata alla Figura 1, in cui viene illustrato come creare e inizializzare le variabili Date negli script T-SQL. La variabile @myDate1 viene inizializzato da una stringa nel formato "MM/DD/YYYY". La variabile @myDate2 non viene inizializzata e avrà un valore NULL. La variabile @myDate3 viene inizializzata sulla data del sistema del computer locale. Il valore delle variabili può essere modificato in qualsiasi momento con le istruzioni SELECT o SET, modificando il valore di @myDate2, come illustrato nell'esempio. È inoltre possibile creare colonne di date in tabelle. Nella Figura 2 viene illustrato come creare una tabella con tre colonne di date.
Figure 2 Creazione di una tabella con tre colonne data (Close Figure 2)
USE TempDB
GO

CREATE TABLE myTable
(
    myDate1 date,myDate2 date,myDate3 date
)
GO

INSERT INTO myTable
VALUES('01/22/2005',
       '2007-05-08 12:35:29.1234567 +12:15',
       GetDate())

SELECT * FROM myTable

--Results
--myDate1    myDate2    myDate3
------------ ---------- ----------
--2005-01-22 2007-05-08 2007-11-20
Figure 1 Creazione e inizializzazione delle variabili del tipo di dati date in script T-SQL (Close Figure 1)
DECLARE @myDate1 date = '01/22/2005'
DECLARE @myDate2 date
DECLARE @myDate3 date = GetDate()

SELECT @myDate2 = '2007-05-08 12:35:29.1234567 +12:15'

SELECT @myDate1 AS '@myDate1',
       @myDate2 AS '@myDate2',
       @myDate3 AS '@myDate3'

--Results
--@myDate1   @myDate2   @myDate3
------------ ---------- ----------
--2005-01-22 2007-05-08 2007-11-20
Il tipo di dati time archivia l'ora del giorno senza alcun valore di data. È basato sul formato a 24 ore e, pertanto, supporta un intervallo compreso tra 00:00:00.0000000 e 23:59:59.9999999 (ore, minuti, secondi e secondi frazionari). È possibile specificare la precisione in secondi frazionari durante la creazione del tipo di dati. La precisione predefinita è 7 cifre; l'accuratezza è di 100 nanosecondi. La precisione influisce sulla quantità di spazio di archiviazione necessaria, che può essere di 3 byte per un massimo di 2 cifre, 4 byte per 3 o 4 cifre e 5 byte per un intervallo di cifre compreso tra 5 e 7.
Nello script T-SQL nella Figura 3 viene illustrato come la precisione della variabile sia influenzata da conversioni implicite di un valore di inizializzazione di una stringa. Nel codice T-SQL vengono create otto variabili time separate che vengono inizializzate su un valore identico. La precisione frazionaria di ciascuna variabile è equivalente al relativo nome. Ad esempio, @myTime3 ha una precisione frazionaria di tre posizioni decimali. I risultati mostrano che la precisione di ciascun tipo di dati time è equivalente alla precisione frazionaria con cui viene dichiarato. Le cifre che non rientrano nell'intervallo vengono troncate.
Figure 3 Visualizzazione della precisione della variabile del tipo di dati time (Close Figure 3)
DECLARE @myTime  time = '01:01:01.1234567 +01:01'
DECLARE @myTime1 time(1) = '01:01:01.1234567 +01:01'
DECLARE @myTime2 time(2) = '01:01:01.1234567 +01:01'
DECLARE @myTime3 time(3) = '01:01:01.1234567 +01:01'
DECLARE @myTime4 time(4) = '01:01:01.1234567 +01:01'
DECLARE @myTime5 time(5) = '01:01:01.1234567 +01:01'
DECLARE @myTime6 time(6) = '01:01:01.1234567 +01:01'
DECLARE @myTime7 time(7) = '01:01:01.1234567 +01:01'

SELECT @myTime  AS '@myTime',
       @myTime1 AS '@myTime1',
       @myTime2 AS '@myTime2',
       @myTime3 AS '@myTime3',
       @myTime4 AS '@myTime4',
       @myTime5 AS '@myTime5',
       @myTime6 AS '@myTime6',
       @myTime7 AS '@myTime7'

--Results
--@myTime          @myTime1   @myTime2    @myTime3     @myTime4
------------------ ---------- ----------- ------------ -------------
--01:01:01.1234567 01:01:01.1 01:01:01.12 01:01:01.123 01:01:01.1235
--
--@myTime5       @myTime6        @myTime7
---------------- --------------- ----------------
--01:01:01.12346 01:01:01.123457 01:01:01.1234567

DROP TABLE myTable
Un tipo di dati time può essere creato come colonna in una tabella. Nello script T-SQL DROP TABLE myTable nella Figura 4 viene creata una tabella denominata myTable1 a cui vengono aggiunte tre colonne ora. Nella tabella viene quindi inserito un record e il contenuto della tabella viene visualizzato con un'istruzione SELECT.
Figure 4 Creazione di myTable1 (Close Figure 4)
USE TempDB
GO

CREATE TABLE myTable1
(
    myTime1 time(1),
    myTime2 time(2),
    myTime3 time(3)
)
GO

INSERT INTO myTable1
VALUES('01:30:01.1234567',
       '02:34:01.1234567',
       '03:01:59.1234567')

SELECT * from myTable1

--Results
--myTime1    myTime2     myTime3
------------ ----------- ------------
--01:30:01.1000000 02:34:15.1200000 03:01:59.1230000

DROP TABLE myTable1

Datetimeoffset e Datetime2
Il tipo di dati datetimeoffset contiene informazioni sul fuso orario. Il tipo di dati time non contiene alcun fuso orario e prevede solo l'utilizzo dell'ora locale. Nell'economia globale, tuttavia, è spesso necessario essere informati sulla differenza di diversi fusi tra le diverse località del mondo. L'offset dei fusi orari è rappresentato in formato + o - hh:mm.
Nel seguente codice viene creata una variabile datetimeoffset che viene inizializzata sul valore di ora 8:52 (fuso orario del Pacifico):
DECLARE @date DATETIMEOFFSET = '2007-11-26T08:52:00.1234567-08:00'
PRINT @date
--Results
--2007-11-26 08:52:00.1234567 -08:00
La stringa che inizializza la variabile datetimeoffset (@date nello script) presenta un formato speciale, in cui gli elementi vengono ordinati a partire dal più significativo fino al meno significativo. Una singola lettera T in maiuscolo separa gli elementi relativi a data e ora. Un segno meno (-) separa gli elementi relativi all'ora dal fuso orario. Non ci sono spazi tra il segno meno e gli elementi relativi a ora o fuso orario. Questo formato corrisponde a uno dei due formati ISO 8601 supportati dal tipo di dati datetimeoffset. ISO 8601 è uno standard internazionale per la rappresentazione di valori relativi a data e ora.
La precisione del componente ora viene specificata allo stesso modo del tipo di dati time e utilizza come impostazione predefinita le stesse sette cifre, se non specificata. L'intervallo supportato è identico.
Il tipo di dati datetime2 è un'estensione del tipo di dati datetime originale. Supporta un intervallo di date più grande e una maggiore precisione in secondi frazionari, che può essere definita dall'utente. L'intervallo di date del tipo datetime2 è compreso tra il 1 gennaio 0001 e il 31 dicembre 9999, mentre il tipo datetime precedente supportava un intervallo compreso tra il 1 gennaio 1753 e il 31 dicembre 9999. Allo stesso modo del tipo time, questo tipo di dati fornisce una precisione di sette secondi frazionari. Il tipo datetime originale forniva una precisione di tre cifre e supportava un intervallo di ore compresso tra 00:00:00 e 23:59:59.999. Di seguito viene illustrato come creare una variabile datetime2 e come inizializzarla sulla data e l'ora del server locale:
DECLARE @datetime2 DATETIME2 = GetDate();
PRINT @datetime2

--Results
--2007-11-26 09:39:04.1370000
Nella sezione successiva verrà esaminato il nuovo tipo di dati hierarchyid. Questo tipo di dati supporta la relazione tra gli elementi di dati all'interno di una tabella, anziché uno specifico elemento di dati relativo a data o ora.

Tipo di dati hierarchyid
Il tipo di dati hierarchyid consente di creare delle relazioni tra gli elementi di dati all'interno di una tabella, appositamente per rappresentare una posizione in una gerarchia. Per esplorare questo tipo di dati, creare innanzitutto il database MyCompany e compilarlo con i dati relativi ai dipendenti, utilizzando lo script nella Figura 5.
Figure 5 Creazione e compilazione del database MyCompany (Close Figure 5)
USE MASTER
GO

CREATE DATABASE MyCompany
GO
USE MyCompany
GO

--Create a table called employee that will store
--the data for the employees for MyCompany.

CREATE TABLE employee
(
    EmployeeID int NOT NULL,
    EmpName    varchar(20) NOT NULL,
    Title      varchar(20) NULL,
    Salary     decimal(18, 2) NOT NULL,
    hireDate   datetimeoffset(0) NOT NULL,
)
GO

--These statements will insert the data for the employees of MyCompany.

INSERT INTO employee
VALUES(6,   'David',  'CEO', 35900.00, '2000-05-23T08:30:00-08:00')

INSERT INTO employee
VALUES(46,  'Sariya', 'Specialist', 14000.00, '2002-05-23T09:00:00-08:00')

INSERT INTO employee
VALUES(271, 'John',   'Specialist', 14000.00, '2002-05-23T09:00:00-08:00')

INSERT INTO employee
VALUES(119, 'Jill',   'Specialist', 14000.00, '2007-05-23T09:00:00-08:00')

INSERT INTO employee
VALUES(269, 'Wanida', 'Assistant', 8000.00, '2003-05-23T09:00:00-08:00')

INSERT INTO employee
VALUES(272, 'Mary',   'Assistant', 8000.00, '2004-05-23T09:00:00-08:00')
GO
--Results
--EmployeeID  EmpName Title      Salary   hireDate
------------- ------- ---------- -------- --------------------------
--6           David   CEO        35900.00 2000-05-23 08:30:00 -08:00
--46          Sariya  Specialist 14000.00 2002-05-23 09:00:00 -08:00
--271         John    Specialist 14000.00 2002-05-23 09:00:00 -08:00
--119         Jill    Specialist 14000.00 2007-05-23 09:00:00 -08:00
--269         Wanida  Assistant  8000.00  2003-05-23 09:00:00 -08:00
--272         Mary    Assistant  8000.00  2004-05-23 09:00:00 -08:00
Nella Figura 6 viene illustrato il semplice database risultante, composto da una singola tabella di dipendenti. Questa tabella di dipendente nel database MyCompany non presenta alcuna struttura imposta. Questo è normale per un database relazionale, in quanto la struttura viene imposta in modo dinamico da un'applicazione tramite il relativo codice di query e di elaborazione.
Figura 6 Tabella dei dipendenti del database MyCompany
Figura 6 Tabella dei dipendenti del database MyCompany
I dati aziendali, tuttavia, presentano in genere un tipo di struttura intrinseca. Ad esempio, ogni azienda prevede una struttura di reporting, come quella mostrata per MyCompany nella Figura 7. Tutti i dipendenti di MyCompany fanno riferimento a David, il CEO. Alcuni dipendenti riferiscono direttamente, come nel caso di Jill. Altri, come Mary, riferiscono attraverso un intermediario. In termini di programmazione, la struttura di reporting per MyCompany viene definita albero in quanto presenta una forma simile a un albero. David, in cima alla struttura, non riferisce a nessuno ed è l'elemento padre o predecessore. I dipendenti che riferiscono a David sono sotto. Tali nodi vengono definiti elementi figlio o discendenti. David può avere il numero di discendenti necessario per rappresentare i relativi report diretti.
Figura 7 Struttura organizzativa di MyCompany
Figura 7 Struttura organizzativa di MyCompany
Nello script nella Figura 8 viene ricreato il database MyCompany mediante il tipo di dati hierarchyid, creando una relazione che corrisponde alla struttura di reporting per MyCompany. l'istruzione ALTER TABLE viene utilizzata per aggiungere una colonna di tipo hierarchyid. Il nodo di David viene quindi inserito utilizzando il metodo GetRoot di hierarchyid. I dipendenti che riferiscono direttamente a David vengono aggiunti all'albero utilizzando il metodo GetDescendant.
Figure 8 Rigenerazione del database mediante hierarchyid (Close Figure 8)
DELETE employee
GO
ALTER TABLE employee ADD OrgNode hierarchyid NOT NULL
GO

DECLARE @child hierarchyid,
@Manager hierarchyid = hierarchyid::GetRoot()

--The first step is to add the node at the top of the
--tree. Since David is the CEO his node will be the
--root node.

INSERT INTO employee
VALUES(6,   'David',  'CEO', 35900.00,
       '2000-05-23T08:30:00-08:00', @Manager)

--The next step is to insert the records for
--the employees that report directly to David.

SELECT @child = @Manager.GetDescendant(NULL, NULL)

INSERT INTO employee
VALUES(46,  'Sariya', 'Specialist', 14000.00,
       '2002-05-23T09:00:00-08:00', @child)

SELECT @child = @Manager.GetDescendant(@child, NULL)
INSERT INTO employee
VALUES(271, ‚John',   ‚Specialist', 14000.00,
       '2002-05-23T09:00:00-08:00', @child)

SELECT @child = @Manager.GetDescendant(@child, NULL)
INSERT INTO employee
VALUES(119, ‚Jill',   ‚Specialist', 14000.00,
       ‚2007-05-23T09:00:00-08:00', @child)

--We can now insert the employee that reports to
--Sariya.
SELECT @manager = OrgNode.GetDescendant(NULL, NULL)
FROM employee WHERE EmployeeID = 46

INSERT INTO employee
VALUES(269, ‚Wanida', ‚Assistant', 8000.00,
       ‚2003-05-23T09:00:00-08:00', @manager)

--Next insert the employee that report to John.
SELECT @manager = OrgNode.GetDescendant(NULL, NULL)
FROM employee WHERE EmployeeID = 271

INSERT INTO employee
VALUES(272, ‚Mary',   ‚Assistant', 8000.00,
       ‚2004-05-23T09:00:00-08:00', @manager)
GO
Dopo aver aggiunto i record del database e dopo aver creato la gerarchia, il contenuto della tabella dei dipendenti può essere visualizzato con la seguente query:
SELECT EmpName, Title, Salary, OrgNode.ToString() AS OrgNode
FROM employee ORDER BY OrgNode
GO
--Results
--EmpName  Title      Salary    OrgNode
---------- ---------- --------- -------
--David    CEO        35900.00  /
--Sariya   Specialist 14000.00  /1/
--Wanida   Assistant  8000.00   /1/1/
--John     Specialist 14000.00  /2/
--Mary     Assistant  8000.00   /2/1/
--Jill     Specialist 14000.00  /3/
OrgNode è la colonna hierarchyid. Ciascuna barra (/) nel risultato indica un nodo nell'albero gerarchico. David è al livello radice, che viene rappresentato con una singola barra. Sariya, John e Jill riferiscono a David e sono contrassegnati da due barre, che indicano che essi rappresentano il secondo nodo della gerarchia. I numeri 1, 2 e 3 indicano l'ordine del rispettivo nodo figlio. Questo sistema è molto flessibile. I nodi figlio possono essere rimossi, inseriti o aggiunti in base alle esigenze. Se si aggiungesse un dipendente tra John e Jill, ad esempio, tale dipendente verrebbe elencato nel set di risultati come indicato di seguito: /2.1/.
Per rispondere alla domanda, ad esempio, "Chi riferisce a Sariya?", è possibile creare una query come illustrato nel seguente codice T-SQL:
DECLARE @Sariya hierarchyid

SELECT @Sariya = OrgNode
FROM employee WHERE EmployeeID = 46

SELECT EmpName, Title, Salary, OrgNode.ToString() AS 'OrgNode'
FROM employee
WHERE OrgNode.GetAncestor(1) = @Sariya
GO
--Results
--EmpName Title     Salary  OrgNode
--------- --------- ------- -------
--Wanida  Assistant 8000.00 /1/1/
La query utilizza il metodo GetAncestor di hierarchyid, che restituisce il nodo padre del nodo hierarchyid corrente. Nel codice precedente, la variabile @Sariya è impostata sul nodo della gerarchia relativo a Sariya. Questo avviene perché Sariya è il predecessore diretto di qualunque dipendente ai suoi ordini. Pertanto, la scrittura di una query che restituisce i dipendenti che riferiscono direttamente a Sariya prevede il recupero del nodo di Sariya dall'albero e la selezione di tutti i dipendenti il cui nodo predecessore corrisponde al nodo di Sariya.
Le colonne di hierarchyid sono molto compatte, in quanto il numero di bit necessari per rappresentare un nodo in un albero dipende dal numero medio degli elementi figlio per il nodo (in genere definito fanout del nodo). Ad esempio, un nuovo nodo in una gerarchia organizzativa di 100.000 dipendenti, con un fanout medio di sei livelli, richiederebbe circa cinque byte di spazio di archiviazione.
Il tipo di dati hierarchyid fornisce diversi metodi che semplificano l'utilizzo dei dati gerarchici. Un riepilogo di questi metodi è illustrato nella Figura 9. Informazioni dettagliate su tutti i metodi sono disponibili nella documentazioni in linea di SQL Server (msdn2.microsoft.com/ms130214).
Figure 9 Metodi forniti dal tipo di dati hierarchyid (Close Figure 9)

Metodo | Descrizione
GetAncestor | Restituisce un tipo hierarchyid che rappresenta il predecessore n del nodo hierarchyid corrente.
GetDescendant | Restituisce un nodo figlio del nodo hierarchyid corrente.
GetLevel | Restituisce un numero intero che rappresenta la profondità del nodo hierarchyid corrente nella gerarchia globale.
GetRoot | Restituisce il nodo hierarchyid radice dell'albero gerarchico corrente. Tipo statico.
IsDescendant | Restituisce true se il nodo figlio passato è un discendente del nodo hierarchyid corrente.
Parse | Converte una rappresentazione stringa di una gerarchia in un valore hierarchyid. Tipo statico.
Reparent | Sposta un nodo di una gerarchia in una nuova posizione all'interno della gerarchia.
ToString | Restituisce una stringa che contiene la rappresentazione logica del tipo hierarchyid corrente.

Tipi di dati spaziali
I dati spaziali sono dati che identificano forme e posizioni geografiche, principalmente sul pianeta Terra. Questi dati possono includere punti di riferimento, strade e persino la sede di un'azienda. Per consentire l'utilizzo di questo tipo di dati, in SQL Server 2008 vengono forniti dati di tipo geografico e di tipo geometrico.
I dati di tipo geografico prevedono l'utilizzo di soluzioni Round Earth. Il modello Round Earth prende in considerazione nei relativi calcoli la superficie curva della Terra. Le informazioni di posizione vengono fornite in longitudine e in latitudine. Questo modello risulta appropriato per applicazioni come spedizioni transoceaniche, pianificazione militare e applicazioni a breve raggio correlate al territorio geografico. Questo è il modello da utilizzare se i dati vengono memorizzati in termini di latitudine e longitudine.
I dati di tipo geometrico funzionano con il modello planare o Flat Earth. In questo modello, la Terra viene considerata come una proiezione piatta che ha inizio in un punto noto. Il modello Flat Earth non prende in considerazione la curvatura della terra e, pertanto, viene utilizzato principalmente per descrivere brevi distanze, ad esempio in un un'applicazione di database che esegue il mapping delle aree interne di un edificio.
I dati di tipo geografico e geometrico vengono creati da oggetti vettoriali, specificati in formato WKT (Well-Known Text) o WKB (Well-Known Binary). Questi sono formati di trasporto per i dati spaziali descritti dalla specifica Simple Features for SQL dell'Open Geospatial Consortium (OGC). Nella Figura 10 vengono elencati i sette tipi di oggetti vettoriali supportati da SQL Server 2008.
Figure 10 Oggetti vettoriali supportati da SQL Server 2008 (Close Figure 10)

Oggetto | Descrizione
Point | Una posizione.
MultiPoint | Una serie di punti.
LineString | Una serie di zero o più punti collegati da linee.
MultiLineString | Una serie di oggetti linestring.
Polygon | Una regione contigua descritta da una serie di oggetti linestring chiusi.
MultiPolygon | Una serie di poligoni.
GeometryCollection | Un insieme di tipi geometrici.
Per creare dati di tipo geografico con uno o più oggetti vettoriali, dichiarare prima il tipo geografico nello script T-SQL, come illustrato nella Figura 11. Chiamare quindi uno dei metodi riportati nella Figura 12 e passare la stringa di caratteri per l'oggetto vettoriale e il sistema SRID (Spatial Reference ID). SRID è il sistema di identificazione di riferimento spaziale, definito dall'European Petroleum Survey Group. Fa parte di una serie di standard sviluppati per la cartografia, l'analisi e l'archiviazione dei dati geodetici. Ogni SRID identifica un tipo specifico di ellissoide da utilizzare nei calcoli geografici. Questo è necessario in quanto la terra non è una sfera perfetta. SQL Server 2008 è in grado di eseguire solo calcoli su SRID identici.
Figure 12 Creazione di oggetti per la geografia e la geometria (Close Figure 12)

Metodo | Descrizione
STGeomFromText | Crea qualsiasi tipo di istanza geografica dal testo di input.
STPointFromText | Crea un'istanza Point di tipo geografico dal testo di input.
STMPointFromText | Crea un'istanza MultiPoint di tipo geografico dal testo di input.
STLineFromText | Crea un'istanza LineString di tipo geografico dal testo di input.
STMLineFromText | Crea un'istanza MultiLineString di tipo geografico dal testo di input.
STPolyFromText | Crea un'istanza Polygon di tipo geografico dal testo di input.
STMPolyFromText | Crea un'istanza MultiPolygon di tipo geografico dal testo di input.
STGeomCollFromText | Crea un'istanza GeometryCollection di tipo geografico dal testo di input.
Figure 11 Creazione di punti, di linee e della geometria del poligono (Close Figure 11)
DECLARE @geo1 geometry
SELECT @geo1 = geometry::STGeomFromText('POINT (3 4)', 0)
PRINT @geo1.ToString()

DECLARE @geo2 geometry
SELECT @geo2 = geometry::Parse('POINT(3 4 7 2.5)')
PRINT @geo2.STX;
PRINT @geo2.STY;
PRINT @geo2.Z;
PRINT @geo2.M;

DECLARE @geo3 geography;
SELECT @geo3 = geography::STGeomFromText(
    'LINESTRING(47.656 -122.360, 47.656 -122.343)', 4326);
SELECT @geo3.ToString();

--Results
--POINT (3 4)
--3
--4
--7
--2.5

DECLARE @gx geometry;
SET @gx = geometry::STPolyFromText(
    'POLYGON ((5 5, 10 5, 10 10, 5 5))', 0);
PRINT @gx.ToString();
--Results
--POLYGON ((5 5, 10 5, 10 10, 5 5))

Differenze tra i dati di tipo geografico e di tipo geometrico
I dati di tipo geografico e geometrico sono stati progettati per l'utilizzo di diversi tipi di dati; è necessario pertanto tenere presenti alcune differenze importanti. Con i dati di tipo geometrico, i valori delle distanze e delle aree vengono forniti nella stessa unità di misura delle coordinate delle istanze. Ad esempio, la distanza tra i punti (0.0) e (6.8) sarà sempre pari a 10 unità. Questo non avviene con i dati di tipo geografico, che prevedono l'utilizzo di coordinate ellissoidali che vengono espresse in gradi di latitudine e longitudine.
Il tipo di dati GEOMETRY restituisce risultati incoerenti quando le coordinate vengono espresse come coppie latitudine/longitudine. Nel seguente codice T-SQL viene calcolata la distanza tra POINTS (90 0) e (90 180). Entrambi questi punti fanno riferimento al Polo Nord e, pertanto, la distanza tra loro dovrebbe essere pari a 0. Nel caso del tipo GEOMETRY la distanza calcolata è pari a 180.
DECLARE @g1 GEOMETRY, @g2 GEOMETRY, @g3 GEOGRAPHY, @g4 GEOGRAPHY
SELECT @g1 = GEOMETRY::STGeomFromText('POINT (90 0)', 0)
SELECT @g2 = GEOMETRY::STGeomFromText('POINT (90 180)', 0)

SELECT @g3 = GEOGRAPHY::STGeomFromText('POINT (90 0)', 4326)
SELECT @g4 = GEOGRAPHY::STGeomFromText('POINT (90 180)', 4326)
SELECT @g2.STDistance(@g1) AS 'GEOMETRY',
       @g4.STDistance(@g3) AS 'GEOGRAPHY';

--Results
--GEOMETRY               GEOGRAPHY
------------------------ ----------------------
--180                    0
Anche l'orientamento dei dati spaziali è diverso per i due tipi di dati. Nel sistema planare utilizzato dai dati di tipo geometrico, l'orientamento del poligono non è un fattore importante. Ad esempio, un poligono con le coordinate ((0, 0), (10, 0), (0, 20), (0, 0)) viene considerato identico al poligono ((0, 0), (0, 20), (10, 0), (0, 0)). Tuttavia, nel modello di dati utilizzato dai dati di tipo geografico, un poligono non è ben definito se non ne viene specificato l'orientamento. Considerare, ad esempio, un anello intorno all'equatore. Il poligono descritto da questo anello fa riferimento all'emisfero settentrionale o meridionale? Il punto importante da considerare è che quando si utilizzando dati di tipo geografico, l'orientamento e la posizione devono essere descritti in modo accurato.
Esistono alcune restrizioni per i dati di tipo geografico in SQL Server 2008. Ad esempio, ogni istanza geografica deve rientrare in un singolo emisfero. Gli oggetti spaziali di maggiori dimensioni non sono consentiti e causano la generazione di un'eccezione ArgumentException. I dati di tipo geografico che richiedono due input restituiranno NULL se i risultati del metodo non possono essere inseriti in un singolo emisfero.
SQL Server fornisce diversi metodi che consentono l'esecuzione di operazioni su istanze geografiche e geometriche. Nella Figura 13 vengono illustrati alcuni esempi di utilizzo dei metodi forniti in SQL Server 2008 per lavorare con i dati spaziali. A causa dei limiti di spazio, questo argomento non verrà illustrato nei dettagli nel presente articolo, ma è possibile ottenere descrizioni complete in merito nella documentazione in linea di SQL Server.
Figure 13 Utilizzo di dati spaziali (Close Figure 13)
DECLARE @gm geometry;
DECLARE @gg geography;
DECLARE @h geography;

SET @gm = geometry::STGeomFromText('POLYGON((0 0, 13 0, 3 3, 0 13, 0 0),(2 2, 2 1, 1 1, 1 2, 2 2))', 0);
SELECT @gm.STArea();

--Results
--38

SET @gg = geography::STGeomFromText('LINESTRING(0 0, 5 5)', 4326);
--Calculate the distance to a point slightly offset from the LINESTRING.
SET @h = geography::STGeomFromText('POINT(4 4)', 4326);
SELECT @gg.STDistance(@h);

--Results
-- 430.182777043046

--Calculate the distance to a point on the LINESTRING.
SET @h = geography::STGeomFromText('POINT(5 5)', 4326);
SELECT @gg.STDistance(@h);

--Results
-- 0

DECLARE @temp table ([name] varchar(10), [geom] geography);

INSERT INTO @temp values ('Point', geography::STGeomFromText('POINT(
5 10)', 4326));
INSERT INTO @temp values ('LineString', geography::STGeomFromText(
'LINESTRING(13 5, 50 25)', 4326));
--Calculate the distance to a point on the LINESTRING.
--Display the number of dimensions for a geography object stored in a --table variable.
INSERT INTO @temp values ('Polygon', geography::STGeomFromText(
'POLYGON((47.653 -122.358, 47.649 -122.348, 47.658 -122.348, 47.658 -122.358, 47.653 -122.358))', 4326));

SELECT [name], [geom].STDimension() as [dim]
FROM @temp;

--Results
--name       dim
------------ -----------
--Point      0
--LineString 1
--Polygon    2
Mi auguro che queste informazioni sui sette nuovi tipi di dati disponibili in SQL Server 2008 siano state utili.

Kelly Wilson vanta oltre 20 anni di esperienza nel settore della progettazione software. I suoi crediti includono applicazioni in SQL Server, grafica 3D, giochi e scienza del colore. Kelly è attualmente Programming Writer nel gruppo SQL Server di Microsoft.


 SQL Server 2008: Prestazioni delle query nel data warehouse
SQL Server 2008 Sunil Agarwal and Torsten Grabs and Dr. Joachim Hammer

Prestazioni delle query nel data warehouse
Panoramica:
  • Ottimizzazione delle query con join a stella
  • Parallelismo tra tabelle partizionate
  • Compressione ROW e PAGE
  • Viste indicizzate con partizionamento allineato

SQL Server 2008 offre funzionalità di data warehouse relazionale molto più potenti, ma come utilizzare questa tecnologia per creare un data warehouse funzionante per il supporto decisionale su miliardi di righe? E come
è possibile capire quali tra queste funzionalità possono garantire le migliori prestazioni per report e query di supporto decisionale o ancora quali miglioramenti delle prestazioni si possono prevedere da questa nuova versione di SQL Server®?
Con l'avvicinarsi della data di rilascio le domande si moltiplicano. Ci auguriamo che questa analisi approfondita sulle principali funzionalità di data warehousing relative alle prestazioni in SQL Server 2008 si riveli utile.

Progettazione logica del database: modellazione dimensionale
Le applicazioni line-of-business transazionali seguono in genere uno schema di database normalizzato. La progettazione logica dello schema del database per i data warehouse relazionali invece tralascia la normalizzazione seguendo piuttosto l'approccio della modellazione dimensionale, reso popolare dal libro di Ralph Kimball e Margy Ross intitolato "The Data Warehouse Toolkit: The Complete Guide to Dimensional Modeling".
Chi già conosce l'ambiente del data warehousing avrà sicuramente familiarità con i modelli di schema comuni per i data warehouse relazionali (schemi a stella e a fiocco di neve). La modellazione dimensionale distingue le tabelle delle dimensioni dalle tabelle dei fatti. Le tabelle delle dimensioni contengono i dati principali (quali prodotti, clienti, negozi o paesi) mentre quelle dei fatti contengono i dati transazionali (come vendite, ordini, acquisti o resi).
Le tabelle di fatti e dimensioni sono collegate tramite relazioni di tipo chiave primaria (PK)/chiave esterna (FK). Molti data warehouse non si avvalgono dei vincoli FK come strumento per mantenere minimi i requisiti di archiviazione e risparmiare l'overhead di archiviazione degli indici sottostanti per mantenere ridotti i costi di gestione della tabella dei fatti. Le tabelle delle dimensioni di un data warehouse sono generalmente piccole (contengono da migliaia a diversi milioni di righe). Per contro, la tabella dei fatti raggiunge grandi dimensioni contenendo da centinaia di milioni a miliardi di righe. Pertanto la progettazione logica deve prestare attenzione ai requisiti di archiviazione della tabella dei fatti.
L'aspetto delle dimensioni influisce inoltre sulla scelta della chiave della tabella delle dimensioni utilizzata per la gestione della relazione tra quest'ultima e la tabella dei fatti. Le chiavi composite, basate sulla chiave business della dimensione (ossia l'identificatore dell'entità rappresentata dalla dimensione) coprono in genere diverse colonne. Ciò rappresenta un problema per la chiave esterna corrispondente presente nella tabella dei fatti, poiché la chiave composita su più colonne viene ripetuta per ogni riga della tabella dei fatti.
Per ovviare al problema, si ricorre all'uso di piccole chiavi surrogate, da implementare nelle relazioni tra le due tabelle. La chiave surrogata è una colonna di identità contenente dati integer che funge da chiave primaria artificiale della tabella delle dimensioni. Facendo riferimento alla piccola chiave surrogata, la tabella dei fatti riduce significativamente i requisiti di archiviazione nelle tabelle dei fatti più grandi. Nella Figura 1 viene illustrato lo schema di un data warehouse con modellazione dimensionale che utilizza tabelle di fatti e dimensioni e chiavi surrogate.
Figura 1 Esempio di schema a stella con una tabella dei fatti e due tabelle delle dimensioni
Figura 1 Esempio di schema a stella con una tabella dei fatti e due tabelle delle dimensioni
Lo schema a fiocco di neve distribuisce una o più dimensioni su più livelli (ad esempio cliente, paese e regione per la dimensione cliente) e così facendo normalizza le dimensioni più consistenti, soggette a un'eccessiva ridondanza di dati. I livelli sono rappresentati da tabelle separate che conferiscono allo schema la forma di un fiocco di neve. Per contro, lo schema a stella non distribuisce le dimensioni sulle tabelle, ma assume la forma di una stella in cui le tabelle delle dimensioni vengono raggruppate attorno a una tabella dei fatti centrale.
Negli schemi con modellazione dimensionale, siano essi a stella o a fiocco di neve, le query del supporto decisionale seguono un modello preciso: la query seleziona diverse misure di interesse dalla tabella dei fatti, unisce le righe dei fatti a una o più dimensioni utilizzando le chiavi surrogate, colloca i predicati del filtro sulle colonne business delle tabelle delle dimensioni, esegue il raggruppamento in base a una o più colonne business e aggrega le misure recuperate dalla tabella dei fatti in un determinato periodo di tempo. Questo modello è raffigurato di seguito ed è talvolta indicato con il termine query join a stella:
select ProductAlternateKey,
CalendarYear,sum(SalesAmount)
from FactInternetSales Fact
     join DimTime
on Fact.OrderDateKey = TimeKey
     join DimProduct
on DimProduct.ProductKey =
   Fact.ProductKey
where CalendarYear between 2003 and 2004
      and ProductAlternateKey like 'BK%'
group by ProductAlternateKey,CalendarYear

Progettazione fisica
Molte query SQL del data warehouse relazionale seguono la struttura della query join a stella. Tuttavia, le query di supporto decisionale spesso variano nel tempo poiché chi prende decisioni tenta di comprendere meglio i dati aziendali seguendo nuove modalità. Per questo motivo i carichi di lavoro per i data warehouse tendono ad avere un'alta percentuale di query ad hoc, cosa che rende particolarmente difficile la progettazione fisica delle query di supporto decisionale e di uno schema di data warehouse con modellazione dimensionale.
Con SQL Server, chi progetta i data warehouse parte generalmente da un modello o progetto fisico che viene gradualmente messo a punto con l'evolversi dei carichi di lavoro. Si consiglia di adottare questo progetto per l'ambiente data warehouse specifico e variarlo di conseguenza. Nel farlo, è importante tenere a mente le procedure consigliate seguite nella progettazione fisica dei database, quali l'impatto sulle prestazioni causato dalla manutenzione degli indici per gli aggiornamenti e i requisiti di archiviazione degli indici.

La tabella dei fatti
Il progetto anticipa la tipica forma della query a stella e crea gli indici sulla tabella dei fatti. L'indice cluster della tabella dei fatti utilizza come chiavi indice diverse colonne di chiavi surrogate della dimensione (colonne chiavi esterne). Le colonne utilizzate di frequente devono essere incluse nell'elenco delle chiavi indice. Potrebbe essere necessario verificare che ciò fornisca un buon percorso di accesso per le query più frequenti nel carico di lavoro specifico.
Inoltre, il progetto crea nella tabella dei fatti un indice non cluster di una sola colonna per ciascuna colonna di chiavi esterne surrogate della dimensione. Ciò offre un percorso di accesso altamente efficace per le query molto selettive in una delle relative dimensioni.
L'obiettivo dell'indice cluster è garantire prestazioni elevate per la maggioranza delle query del carico di lavoro. La serie di indici non cluster mira alle query che recuperano le misure dalla tabella dei fatti per un prodotto o un cliente specifico. Questi indici impediscono, ad esempio, di dover esaminare la tabella dei fatti per recuperare i dati di vendita per un solo cliente.

Tabelle delle dimensioni
Quando si applica il progetto alle tabelle delle dimensioni, è necessario creare gli indici per ogni tabella delle dimensioni. Essi includono un indice con vincolo di chiave primaria non cluster nella colonna delle chiavi surrogate della dimensione e un indice cluster nelle colonne delle chiavi business dell'entità della dimensione. Nella tabelle di grandi dimensioni, occorre anche considerare l'aggiunta di indici non cluster nelle colonne usate di frequente nei predicati altamente selettivi.
L'indice cluster facilita le operazioni di estrazione, trasformazione e caricamento (Extract, Transform, and Load, ETL) nella finestra della manutenzione del data warehouse, processo spesso critico rispetto al tempo. Ad esempio, nel caso di dimensioni che cambiano lentamente, mentre le righe esistenti vengono aggiornate quelle non ancora presenti nella dimensione vengono aggiunte alla tabella delle dimensioni. Per riuscire, questo modello di accesso necessita di buone funzioni di ricerca e aggiornamento per la tabella delle dimensioni da eseguire in contemporanea con le operazioni ETL.
Il progetto delineato serve come punto di inizio per i progetti fisici dei data warehouse relazionali creati con SQL Server. Partendo da questa configurazione tipica del data warehouse relazionale, possiamo adesso esplorare le nuove funzionalità chiave di SQL Server 2008.

Ottimizzazione delle query join a stella
In un data warehouse relazionale con modellazione dimensionale, l'elaborazione della tabella dei fatti rappresenta il costo principale nell'esecuzione di una query join a stella. Infatti, anche le query più selettive recuperano molte più righe dalla tabella dei fatti rispetto a quella delle dimensioni. Pertanto, l'uso del percorso di accesso migliore alla tabella dei fatti è essenziale per garantire ottime prestazioni delle query.
In SQL Server, Query Optimizer seleziona automaticamente tra le alternative disponibili il percorso di accesso con il costo stimato più basso. Nel contesto del data warehouse, l'obiettivo principale è accertarsi che Query Optimizer consideri alternative valide come percorsi di accesso per il piano di esecuzione della query join a stella. Query Optimizer di SQL Server prevede diverse funzionalità per fornire automaticamente piani di esecuzione delle query join a stella con prestazioni elevate.
Come descritto nella Figura 2, le query join a stella possono essere divise in tre classi diverse. Tali categorie aiutano il motore di SQL Server a meglio identificare il piano adatto per le query in questione. Il concetto principale sul quale si basa SQL Server è la selettività delle query a fronte della tabella dei fatti. Meno sono le righe della tabella dei fatti impiegate, più selettiva è la query. La percentuale di righe recuperate dalla tabella dei fatti consente di immaginare queste classi di query. Queste percentuali rappresentano i valori di distribuzioni standard, ma non sono da interpretare come parametri fissi nella definizione dei percorsi di accesso.
Figura 2 Spettro di selettività per le query join a stella
Figura 2 Spettro di selettività per le query join a stella
La prima classe riguarda le query altamente selettive, che elaborano fino al 10% delle righe della tabella dei fatti. La seconda classe, che ha una selettività media, consiste in query che elaborano tra il 10% e il 75% delle righe della tabella dei fatti. Le query della terza classe, con selettività bassa, elaborano oltre il 75% delle righe memorizzate nella tabella dei fatti. Le caselle della figura evidenziano, all'interno di ogni classe di selettività, le scelte del piano di esecuzione delle query di base.

Scelta del piano in base alla selettività
Poiché le query a stella ad alta selettività non recuperano più del 10% delle righe della tabella dei fatti, esse hanno un accesso casuale alla tabella dei fatti. I piani di query per questa classe si basano soprattutto su join di loop nidificati in combinazione con ricerche di indice (non cluster) e segnalibri nella tabella dei fatti. Poiché questi piani eseguono un volume di I/O casuale nella tabella dei dati, vengono superati da operazioni di I/O sequenziali man mano che si recuperano porzioni più grandi della tabella dei fatti. Pertanto sono necessari più piani di query poiché il numero di righe della tabella dei fatti aumenta oltre una certa soglia.
Le query a stella a media selettività elaborano una porzione significativa di righe della tabella dei fatti e per accedervi prediligono ricerche con hash join o scansioni di intervalli. SQL Server si avvale dei filtri bitmap per migliorare le prestazioni degli hash join.
Nella Figura 3 viene illustrata il modo in cui SQL Server utilizza i filtri bitmap per migliorare le prestazioni del join durante l'esecuzione di query join a stella. Viene mostrato un piano di query a fronte di due tabelle di dimensioni, Prodotto e Tempo, unite alla tabella dei fatti da chiavi surrogate. La query utilizza i predicati del filtro, come le clausole WHERE, su tutte e due le tabelle delle dimensioni in modo che una sola riga risulti idonea per ogni dimensione, come indicato dalle tabelline rosse accanto agli operatori join.
Figura 3 Piano di query join a stella con elaborazione di riduzione del join
Figura 3 Piano di query join a stella con elaborazione di riduzione del join
L'implementazione join per ogni join è un hash join, che consente a SQL Server di trasformare le informazioni sulle righe risultanti nelle tabelle delle dimensioni in quelle che chiamiamo informazioni sulla riduzione del join per entrambe le tabelle delle dimensioni. Le caselle verdi rappresentano le strutture dati di tali informazioni. Una volta popolati i dati con le tabelle delle dimensioni sottostanti, SQL Server trasferisce automaticamente le strutture dati durante l'esecuzione delle query all'operatore che elabora la tabella dei fatti, ad esempio la ricerca su tabella. L'operatore utilizza le informazioni sulle righe della tabella delle dimensioni per eliminare le righe della tabella dei fatti che non risultano idonee per le condizioni di join a fronte delle dimensioni.
SQL Server cancella tali righe in una fase iniziale dell'elaborazione, dopo averle recuperate dalla tabella dei fatti per consentire un maggiore risparmio della CPU e, potenzialmente, di I/O su disco dato che le righe cancellate non devono essere elaborate con altri operatori del piano di query. SQL Server utilizza una rappresentazione bitmap per implementare con efficacia le strutture dati con informazioni sulla riduzione del join al momento dell'esecuzione della query.

Pipiline di ottimizzazione del join a stella
Il processo di ottimizzazione impiega l'euristica standard dell'ottimizzazione delle query join per generare un set iniziale di alternative di piani di esecuzione query. Per generare più alternative del piano query vengono richiamate delle estensioni speciali.
In caso di data warehousing, l'estensione rileva lo schema a stella e a fiocco di neve e i modelli della query a stella, quindi valuta la selettività della query a fronte della tabella dei fatti. Se la forma e lo schema della query corrispondono ai modelli, SQL Server aggiunge automaticamente altri piani di query allo spazio dei piani, che viene elaborato dall'ottimizzazione basata sul costo per la scelta del piano più efficace.
Al momento dell'esecuzione della query, SQL Server monitora inoltre la selettività della riduzione del join in fase di runtime. Se il livello di selettività cambia, SQL Server riorganizza dinamicamente le strutture dati delle informazioni sulla riduzione del join, in modo da applicare per prima quella più selettiva.

Euristica del join a stella
Molti progetti fisici di data warehouse pur seguendo lo schema a stella non specificano le relazioni tra la tabella dei fatti e la tabella delle dimensioni, come nel caso sopra citato dei vincoli della chiave esterna. In assenza di vincoli specificati della chiave esterna, SQL Server deve ricorrere all'euristica per rilevare i modelli della query con schema a stella. L'euristica applicata è la seguente:
  1. La più grande tra le tabelle del join n-ario è considerata la tabella dei fatti. Esistono restrizioni aggiuntive sulle dimensioni minime della tabella dei fatti. Ad esempio, se neanche la tabella più grande supera un dato valore, il join n-ario non è considerato a stella.
  2. Tutte le condizioni join dei join binari in una query join a stella devono essere predicati di uguaglianza di una colonna singola. I join devono essere interni. Sebbene sembri un limite, in realtà la maggioranza dei join tra la tabella dei fatti e quella delle dimensioni sulla chiave surrogata negli schemi a stella tradizionali rientra in questa descrizione. I join che presentano condizioni e modelli più complessi rispetto a quelli citati sono esclusi dal join a stella. Ad esempio, un join a cinque vie può diventare un join a stella a tre vie (a cui se ne aggiungeranno due più avanti) se due dei join hanno predicati join più complessi.
Queste sono regole euristiche. Le circostanze effettive che portano l'euristica a selezionare una tabella delle dimensioni come tabella dei fatti sono in realtà poche. È la scelta del piano a essere influenzata non la sua correttezza. I join binari coinvolti in un join a stella vengono ordinati in ordine di selettività discendente. In questo contesto la selettività del join è definita come il rapporto tra la cardinalità in ingresso della tabella dei fatti e la cardinalità del risultato del join (la selettività del join indica di quanto una dimensione specifica riduce la cardinalità della tabella dei fatti). Come regola generale, è bene considerare dapprima i join con selettività più alta.
Il processore delle query in SQL Server applica automaticamente l'ottimizzazione alle query seguendo il modello join a stella e le condizioni sopra citate quando i piani di query risultanti presentano previsioni di costo interessanti. Pertanto, non occorre modificare l'applicazione affinché sfrutti questo significativo miglioramento. Si noti però che alcune ottimizzazioni del join a stella quali la riduzione join sono disponibili solo in SQL Server Enterprise Edition.

Risultati delle prestazioni dei join a stella
Come parte dello sviluppo dell'ottimizzazione del join a stella di SQL Server 2008 abbiamo eseguito una serie di studi sulle prestazioni basati su carichi di lavoro effettivi e benchmark. I risultati di tre di questi carichi di lavoro sono particolarmente interessanti.
Data warehouse organizzazione vendite Microsoft Questo carico di lavoro registra le prestazioni di un data warehouse utilizzato internamente per il supporto decisionale dell'organizzazione vendite di Microsoft. Abbiamo rilevato una snapshot di esempio del database con dimensioni pari a 750 GB (indici compresi). Le query di questo carico di lavoro sono molto complesse poiché molte presentano più di 10 join.
Cliente della vendita al dettaglio Questa serie di esperimenti si basa sul data warehouse di un cliente nel settore della vendita al dettaglio (con un negozio convenzionale e la presenza online). Il cliente è caratterizzato da uno schema a fiocco di neve con modellazione dimensionale e query join a stella tradizionali. Abbiamo utilizzato 100 GB di dati non elaborati per popolare una snapshot del warehouse per i nostri esperimenti.
Carico di lavoro del supporto decisionale Questa serie di esperimenti indaga sulle prestazioni di un carico di lavoro del supporto decisionale di un database con modellazione dimensionale da 100 GB. Nella Figura 4 vengono illustrati i risultati dei tre carichi di lavoro. Viene tracciata la media geometrica normalizzata del tempo di risposta alla query di tutte le query del carico di lavoro. Questa metrica è un buon indicatore delle prestazioni di query attese durante l'esecuzione di una query arbitraria dal carico di lavoro. Le barre della figura confrontano la linea base (1,0) delle prestazioni in mancanza dell'ottimizzazione del join a stella con le prestazioni ottimizzate per il join a stella. Tutte le esecuzioni sono state eseguite con SQL Server 2008.
Figura 4 Miglioramenti delle prestazioni con l'ottimizzazione del join a stella
Figura 4 Miglioramenti delle prestazioni con l'ottimizzazione del join a stella
Come mostrato dalla figura, tutti i carichi di lavoro migliorano significativamente, dal 12% al 30%. Con il variare del singolo utilizzo, prevediamo una crescita dei carichi di lavoro del supporto decisionale rispetto al motore SQL Server del 15%-20%, in base all'estensione delle ottimizzazioni specifiche dei join a stella aggiunte a SQL Server 2008.

Parallelismo tra tabelle partizionate
Per velocizzare l'elaborazione dati in grandi data warehouse, gli amministratori di database spesso eseguono la partizione di grandi tabelle dei fatti in base alla data. I dati vengono così suddivisi in filegroup diversi, per ridurre la quantità di informazioni su cui eseguire le ricerche durante l'elaborazione delle righe in un intervallo di dati specifico e per sfruttare le prestazioni concorrenti del sistema disco sottostante quando i filegroup vengono distribuiti su un ampio numero di dischi fisici.
SQL Server 2005 ha introdotto la possibilità di eseguire la partizione di una relazione di grandi dimensioni in parti logiche più piccole per migliorare la gestione e l'amministrazione delle tabelle più grandi. Un altro vantaggio che ha apportato è stato il miglioramento notevole dell'elaborazione di query, specialmente per le applicazioni di supporto decisionale più grandi.
Purtroppo però, alcuni clienti di SQL Server 2005 hanno notato dei problemi di prestazioni associati alle query su queste tabelle partizionate, soprattutto nei computer multiprocessori con memoria condivisa parallela. L'elaborazione di query parallele su tabelle partizionate in SQL Server 2005 presenta delle istanze in cui solo un sottoinsieme dei thread disponibili viene assegnato all'esecuzione della query.
Basti pensare a un computer a 64 core in cui le query potrebbero utilizzare fino a 64 thread in parallelo e una query interessa due partizioni. In SQL Server 2005, vengono ricevuti solo 2 dei 64 thread con un utilizzo di soli 2/64 (3,1%) della potenza della CPU del computer. Sono stati riferiti casi in cui le prestazioni in tabelle partizionate sono risultata di 10 volte inferiori rispetto all'esecuzione della stessa query nello stesso computer su una versione non partizionata della medesima tabella dei fatti.
Si noti che SQL Server 2005 è stato ottimizzato per le query che interessano una sola partizione. In tal caso il processore di query assegna tutti i thread disponibili all'operazione di ricerca. Dato che questa ottimizzazione speciale causa un notevole miglioramento nell'esecuzione di query a partizione singola nei computer multicore, è logico aspettarsi lo stesso comportamento dalle query che interessano partizioni multiple.
La nuova funzione PTP (Partitioned Table Parallelism) di SQL Server 2008 migliora le prestazioni delle query in presenza di partizioni utilizzando la capacità di elaborazione dell'hardware esistente indipendentemente dal numero delle partizioni interessate dalla query e dalle dimensioni delle singole partizioni. In un ambiente data warehouse comune con una tabella dei fatti partizionata, gli utenti possono assistere a un significativo miglioramento nelle query eseguite su piani paralleli, soprattutto se il numero dei core del processore disponibili è superiore al numero delle partizioni coinvolte dalla query. Questa nuova funzionalità è subito disponibile e non necessita alcuna configurazione o modifica.
Supponiamo di avere una tabella dei fatti che rappresenta i dati di vendita organizzati per data su quattro partizioni. Lo schema della Figura 5 permette di visualizzare l'esempio. Piuttosto che un unico indice cluster per l'intero intervallo di date, come nel caso di assenza di partizioni, esiste generalmente un indice cluster per la colonna della data per le singole partizioni della tabella dei fatti. Supponiamo adesso che una query Q riepiloghi le vendite degli ultimi sette giorni. Poiché nuovi dati di vendita continuano a essere inseriti nella tabella dei fatti attraverso l'ultima partizione (P4), la query interesserà partizioni diverse, a seconda di quando viene eseguita, come indicato nella prima riga dello schema, in cui la query Q1 interessa un'unica partizione, mentre la query Q2 interessa due partizioni poiché i dati rilevanti al momento dell'esecuzione sono distribuiti sulle partizioni P3 e P4.
Figura 5 La nuova funzionalità PTP
Figura 5 La nuova funzionalità PTP
Si supponga di avere otto thread a disposizione. L'esecuzione di Q1 e Q2 in SQL Server 2005 potrebbe generare un comportamento inatteso. L'ottimizzazione di SQL Server 2005 opera come segue: se al momento della compilazione è noto che solo una partizione sarà coinvolta dalla query, questa sarà trattata come una singola tabella non partizionata e verrà generato un piano per accedere alla tabella con tutti i thread disponibili.
Ne risulta che Q1 che interessa la singola partizione (P3) produrrà un piano elaborato da otto thread (non raffigurato). Nel caso di Q2 invece, che interessa due partizioni, l'utilità di esecuzione assegna un singolo thread a ogni partizione anche se ne esistono di altri disponibili. Pertanto, Q2 utilizza solo una frazione della potenza CPU disponibile e, molto probabilmente, avrà prestazioni decisamente ridotte rispetto a Q1.
L'esecuzione di Q1 e Q2 in SQL Server 2008 invece comporta un utilizzo migliore dell'hardware disponibile, registra prestazioni migliori e segue un comportamento più prevedibile. Nel caso di Q1, l'utilità di esecuzione assegna nuovamente tutti gli otto thread disponibili per elaborare i dati in P2 (non raffigurato). Q2, invece, produce un piano parallelo in cui l'utilità di esecuzione assegna tutti i thread disponibili a P3 e P4 in stile round robin, producendo l'effetto illustrato nella riga in basso del diagramma, in cui ciascuna delle due partizioni riceve quattro thread. La CPU rimane completamente utilizzata e le prestazioni di Q1 e Q2 sono le stesse.
L'assegnazione round robin dei thread consente alle query di ottenere prestazioni migliori con l'aggiunta di più core del processore rispetto al numero di partizioni utilizzate dalla query. Esistono tuttavia casi in cui l'assegnazione dei thread alle partizioni non è così diretta.
Altri esempi del miglioramento delle prestazioni da SQL Server 2005 a SQL Server 2008 nello scenario delle tabelle partizionate su computer con processore multicore sono illustrati nella Figura 6. Questo grafico evidenzia le prestazioni dell'analisi per le tabelle partizionate. Nel caso specifico, condotto su un sistema a 64 core e 256 GB di RAM, è stata partizionata una sola tabella da 121 GB in 11 partizioni da 11 GB l'una. Per la serie di test rappresentati nella figura è stata utilizzata un'organizzazione file heap con avvii del buffer a caldo e a freddo. Tutte le query eseguono ricerche semplici sui dati.
Figura 6 Prestazioni delle ricerche di SQL Server con la nuova funzionalità PTP attivata
Figura 6 Prestazioni delle ricerche di SQL Server con la nuova funzionalità PTP attivata
L'asse y indica il tempo di risposta (sec) e l'asse x il grado di parallelismo (DOP, Degree Of Parallelism), cioè il numero di thread assegnati alla query. In entrambi i casi (avvii a caldo e a freddo) il tempo di risposta continua a diminuire fino a quando il valore DOP raggiunge 22. A questo punto, il sistema I/O diviene saturato per gli avvii a freddo. Ciò è dovuto principalmente al fatto che la query dell'esempio è associata a I/O. Per più carichi di lavoro associati alla CPU questa limitazione potrebbe non esistere o verificarsi solo nel caso di livelli DOP superiori.
La curva che raffigura l'avvio a caldo, tuttavia, continua a mostrare cali nel tempo di risposta proporzionali all'aumento del livello DOP. In SQL Server 2005, entrambe le curve iniziano a stabilizzarsi attorno al valore DOP 11, poiché il numero di thread per partizione si limita a 1 nel caso di più partizioni.
In pratica, la riduzione dei tempi di risposta per numeri crescenti di DOP non è mai lineare. Piuttosto, il comportamento previsto ricorda una funzione a gradini, che riflette query in attesa nelle sezioni più lente. L'aggiunta di uno o più thread a una ricerca non migliorerà quindi il tempo di completamento della query, a meno che tutte le altre ricerche abbiano ricevuto un thread aggiuntivo per completare rapidamente l'operazione.
Sono stati eseguiti altri esperimenti per testare il comportamento del nuovo PTP per altre configurazioni file e hardware. In questa circostanza, abbiamo osservato un comportamento simile in termini di crescita della velocità effettiva proporzionale all'aumento di DOP su più thread/partizioni.
Infine, la nuova funzionalità PTP di SQL Server 2008 migliora la leggibilità dei piani di query e semplifica la comprensione dell'esecuzione di alcuni carichi di lavoro. Ad esempio, in quanto parte della funzione PTP, il modo in cui i piani parallelo e seriale vengono rappresentati in Showplan XML è stato migliorato insieme alle informazioni di partizione fornite nei piani di esecuzione in fase di compilazione e runtime.

Compressione dati
Con il diffondersi della Business Intelligence, le aziende riversano sempre più dati da esaminare nei propri data warehouse. Ne risulta una crescita esponenziale dei dati da gestire. Nel 1995, la prima indagine Winter Corporation sulle dimensioni dei database ha dichiarato che il sistema più grande del mondo conteneva 1 TB di dati. Dieci anni dopo il primato si aggirava su dimensioni 100 volte superiori. Il fatto sconcertante è che le dimensioni dei data warehouse si triplicano ogni due anni. Ciò crea nuove sfide in termini di gestione di grandi quantità di dati e di offerta di livelli di prestazioni accettabili nelle query su data warehouse che sono generalmente complesse, coinvolgono molti join e aggregati e accedono a grandi quantità di dati. Inoltre, spesso molte query del carico di lavoro sono associate a operazioni I/O.
La compressione dei dati nativi contribuisce a risolvere questo problema. SQL Server 2005 SP2 ha introdotto un nuovo formato di archiviazione a lunghezza variabile, detto vardecimal per dati numerici e decimali, in grado di ridurre notevolmente le dimensioni dei database. Grazie alle ottimizzazioni dello spazio, le prestazioni delle query associate a operazioni I/O vengono migliorate in due modi. Innanzitutto il numero di pagine da leggere è inferiore. Inoltre, i dati sono conservati nel pool di buffer, migliorando la permanenza presunta delle pagine (ossia le probabilità che la pagina richiesta si trovi nel buffer). Le ottimizzazioni dello spazio ottenute tramite la compressione dei dati implicano un costo in termini di CPU dovuto alla compressione e alla decompressione dei dati.
SQL Server 2008 si basa sul formato di archiviazione vardecimal e fornisce due tipi di compressione: ROW e PAGE. La compressione ROW estende il formato di archiviazione vardecimal memorizzando tutti i tipi di dati a lunghezza fissa in un formato di archiviazione a lunghezza variabile.
Alcuni esempi di tipi di dati a lunghezza fissa sono i dati integer, char e float. Anche se SQL Server memorizza questi tipi di dati in un formato a lunghezza variabile, la semantica rimane immutata (l'applicazione considera il tipo di dati a lunghezza fissa). Ciò significa che è possibile ottenere i vantaggi della compressione dati senza eseguire alcuna modifica nelle applicazioni.
La compressione PAGE riduce la ridondanza di dati nelle colonne di una o più righe di una data pagina. Utilizza un'implementazione proprietaria dell'algoritmo LZ78 (Lempel-Ziv), archiviando i dati ridondanti solo una volta nella pagina e facendovi riferimento da più colonne. Quando si utilizza la compressione PAGE, viene inclusa anche la compressione ROW.
Le compressioni ROW e PAGE possono essere attivate su una tabella o un indice oppure su una o più partizioni per le tabelle e gli indici partizionati. In questo modo viene garantita una flessibilità completa nella scelta di tabelle, indici e partizioni per la compressione, consentendo di raggiungere il giusto equilibrio tra ottimizzazione dello spazio e impatto sulla CPU. Nella Figura 7 viene illustrata una tabella vendite partizionata in diversi modi con indici allineati.
Figura 7 Tabella partizionata con diverse impostazioni di compressione
Figura 7 Tabella partizionata con diverse impostazioni di compressione
Ogni partizione rappresenta un trimestre e l'ultimo corrisponde a ottobre-dicembre. Si supponga che le due partizioni siano utilizzate raramente, la terza partizione sia moderatamente attiva e l'ultima partizione sia la più attiva. In questo caso, una configurazione possibile prevede l'abilitazione della compressione PAGE sulle prime due partizioni per ottenere la massima ottimizzazione dello spazio con il minimo impatto sulle prestazioni del carico di lavoro, della compressione ROW sulla terza partizione e di nessuna compressione nell'ultima partizione.
Per abilitare la compressione, sia online che offline, è possibile utilizzare istruzioni Alter Table o Alter Index DDL (Data Definition Language). SQL Server fornisce inoltre una stored procedure per stimare l'ottimizzazione dello spazio. L'ottimizzazione dello spazio ottenuta dipende dalla distribuzione dei dati e dallo schema dell'oggetto compresso.
Sulla base dei risultati ottenuti dai test con molti database di clienti, traspare che la maggior parte dei clienti potrebbe ridurre le dimensioni dei propri database del 50%-65% e migliorare notevolmente le prestazioni delle query associate a operazioni I/O. Tuttavia, la valutazione dell'impatto sulle prestazioni delle query associate alla CPU non è semplice da eseguire e dipende dalla complessità della query. In SQL Server, la decompressione implica un costo solo durante l'accesso all'indice o alle tabelle. Se il costo CPU relativo degli operatori di ricerca è basso rispetto al costo CPU globale della query, come spesso accade nel data warehouse, l'impatto sull'utilizzo della CPU dovrebbe essere inferiore del 20%-30%.

Viste indicizzate con partizionamento allineato
In SQL Server 2008, le viste indicizzate con partizionamento allineato consentono di creare e gestire meglio aggregati di riepilogo nel data warehouse relazionale e di utilizzarli in scenari in cui non potevano essere finora impiegati. Le prestazioni delle query ne risultano migliorate. In uno scenario standard, la tabella dei fatti è partizionata per data. Per velocizzare le query, le viste indicizzate (o aggregati di riepilogo) vengono definite in questa tabella. Quando si passa a una nuova partizione della tabella, le partizioni corrispondenti delle viste indicizzate con partizionamento allineato definite nella tabella partizionata seguono automaticamente.
Si tratta di un notevole miglioramento rispetto a SQL Server 2005, in cui per passare da una partizione all'altra occorre eliminare le viste indicizzate definite in una tabella partizionata, prima di utilizzare ALTER TABLE SWITCH. La funzionalità delle viste indicizzate con partizionamento allineato di SQL Server 2008 offre i vantaggi delle viste indicizzate su grandi tabelle partizionate evitando i costi della ricostruzione degli aggregati su un'intera tabella partizionata. Tali vantaggi includono la manutenzione automatica degli aggregati e l'abbinamento delle viste indicizzate.

Escalation blocchi a livello di partizione
SQL Server supporta il partizionamento per intervalli che consente di partizionare i dati per una migliore gestibilità dei dati o raggrupparli in base agli schemi d'uso. Ad esempio, è possibile eseguire la partizione dei dati di vendita ogni mese o trimestre oppure associare una partizione al relativo filegroup e il filegroup a un gruppo di file. I vantaggi che ne derivano sono principalmente due: innanzitutto, è possibile eseguire il backup e il ripristino di una partizione come unità indipendente. In secondo luogo, è possibile associare un filegroup a un sottosistema I/O lento o veloce, in base al modello d'uso o al carico della query.
Un aspetto interessante è rappresentato dal modello di accesso dei dati. Le query e le operazioni DML potrebbero richiedere solo l'accesso o la manipolazione di un subset di partizioni. Se ad esempio si stanno analizzando i dati di vendita del 2004, sarà necessario accedere solo alle partizioni rilevanti, in teoria, senza essere in alcun modo coinvolti, ad eccezione delle risorse di sistema, dalle query che accedono contemporaneamente ai dati di altre partizioni. In SQL Server 2005, l'accesso contemporaneo ai dati di altre partizioni può causare un blocco della tabella impedendo l'accesso ad altre partizioni.
Per ridurre questa interferenza, SQL Server 2008 introduce un'opzione a livello di tabella per controllare l'escalation blocchi a livello di partizione o di tabella. Per impostazione predefinita, come in SQL Server 2005, l'escalation blocchi è attivata a livello di tabella, tuttavia, è possibile ignorare questo criterio. Ad esempio:
Alter table <mytable> set (LOCK_ESCALATION = AUTO)
Questo comando indica a SQL Server di scegliere la granularità dell'escalation blocchi adatta allo schema della tabella. Se la tabella non è partizionata, l'escalation blocchi avviene a livello TABLE. Se la tabella è partizionata, la granularità dell'escalation blocchi si limita al livello della partizione. Questa opzione viene inoltre utilizzata come suggerimento da SQL Server per impedire la granularità blocchi a livello di tabella.

Conclusioni
La presente è solo una panoramica sulle nuove e migliorate funzionalità di SQL Server 2008 che consentono di ottenere prestazioni superiori per le query di supporto decisionale nei data warehouse relazionali. Nonostante l'importanza dei tempi di risposta competitivi per le query di supporto decisionale, esistono altri requisiti chiave che superano gli obiettivi di questo articolo.
Alcune delle funzionalità aggiuntive relative ai data warehouse relazionali includono:
  • il supporto per la sintassi MERGE in T-SQL per aggiornare, eliminare o inserire dati (dimensionali) con un'istruzione e round trip nel database.
  • Prestazioni di registrazione ottimizzate del motore SQL Server per operazioni ETL più efficaci.
  • Set di raggruppamento per semplificare la scrittura di query di supporto decisionale aggregate in T-SQL.
  • Compressione backup per ridurre i requisiti di I/O per backup completi e incrementali.
  • Controllo delle risorse per regolare l'assegnazione delle risorse di sistema a carichi di lavoro diversi.
Per informazioni dettagliate su queste interessanti funzionalità, consultare la pagina Web di SQL Server disponibile all'indirizzo microsoft.com/sql.
Si ringraziano Boris Baryshnikov, Prem Mehra, Peter Zabback e Shin Zhang per la consulenza tecnica.

Sunil Agarwal è Senior Program Manager del gruppo SQL Server Storage Engine in Microsoft. Si occupa di concorrenza, indici, tempdb, LOBS, supportabilità e importazione/esportazione bulk.
Torsten Grabs è Senior Program Manager Lead di Core Storage Engine nel team Microsoft SQL Server. Ha conseguito il titolo di PhD in sistemi di database e ha oltre 10 anni di esperienza in SQL Server.
Dr. Joachim Hammer è Program Manager del gruppo Query Processing in Microsoft. Si è specializzato in ottimizzazione delle query su applicazioni data warehouse su larga scala, esecuzione di query distribuita, ETL e integrazione delle informazioni.


 SQL Server: Ridurre al minimo i blocchi in SQL Server
SQL Server Cherié Warren

Ridurre al minimo i blocchi in SQL Server
Panoramica:
  • Perché si verifica l'escalation dei blocchi
  • Evitare i blocchi inutili
  • Ottimizzazione delle query
  • Controllo dell'impatto dei blocchi sulle prestazioni

I blocchi sono necessari per il supporto di attività di lettura e scrittura contemporanee su un database, ma possono influire negativamente sulle prestazioni del sistema, a volte in modi poco evidenti. Nell'articolo si illustrerà come sia possibile ottimizzare un database SQL Server 2005 o SQL Server 2008 per ridurre al minimo
i blocchi e come si possa monitorare il sistema in modo da comprendere meglio l'impatto che i blocchi hanno sulle prestazioni.

Blocchi ed escalation
SQL Server® sceglie il livello di blocco più appropriato, in base alla quantità di record interessati e alle attività simultanee esistenti sul sistema. Per impostazione predefinita, SQL Server sceglie il livello minimo possibile di blocco, riservando i livelli maggiori alle occasioni in cui questi consentono di utilizzare in modo più efficace la memoria di sistema. SQL Server esegue l'escalation di un blocco solo quando questa presenta dei vantaggi in termini di prestazioni complessive del sistema. Come illustrato dalla Figura 1, le escalation si verificano quando il numero di blocchi in una scansione particolare supera i 5.000 o quando la memoria utilizzata per i blocchi dal sistema supera la capacità disponibile:
Figura 1 Condizioni che provocano l'escalation dei blocchi
Figura 1 Condizioni che provocano l'escalation dei blocchi
  • 24% della memoria non AWE (Address Windowing Extension) utilizzata dal motore di database se l'impostazione dei blocchi è 0
  • 40% della memoria non AWE utilizzata dal motore di database se l'impostazione dei blocchi non è 0
Quando si verifica, l'escalation è sempre verso un blocco a livello di tabella.

Evitare i blocchi inutili
I blocchi si possono verificare a qualsiasi livello, ma l'esposizione ai blocchi aumenta quando si verificano escalation. L'escalation dei blocchi può essere un sintomo di un'applicazione progettata, codificata o configurata in modo poco efficiente.
L'adesione ai principi di base della progettazione dei database (come l'utilizzo di uno schema normalizzato con chiavi ristrette e la limitazione delle operazioni di massa sui dati in sistemi transazionali) è importante per evitare i blocchi. Se non si seguono questi principi (ad esempio, si separa il sistema di segnalazione dal sistema transazionale o l'elaborazione dei dati viene eseguita durante le ore di chiusura dell'ufficio), sarà difficile ottimizzare il sistema.
L'indicizzazione può rivelarsi un fattore chiave per la quantità di blocchi necessari per accedere ai dati. Un indice può ridurre il numero di record a cui accede una query, riducendo il numero di ricerche interne eseguite dal motore di database. Quando, ad esempio, si seleziona una singola riga da una tabella su una colonna non indicizzata, ciascuna riga della tabella deve essere temporaneamente bloccata fino a che il record desiderato non viene identificato. Al contrario, quando la colonna è indicizzata, è necessario un solo blocco.
SQL Server 2005 e SQL Server 2008 contengono entrambi viste a gestione dinamica (sys.dm_db_missing_index_group_stats, sys.dm_db_missing_index_groups, sys.dm_db_missing_index_details) che rivelano tabelle e colonne che si avvantaggerebbero dell'uso degli indici, in base alle statistiche d'uso accumulate.
Anche la frammentazione può causare problemi di prestazioni, poiché in tal caso il motore di database deve accedere a più pagine del necessario. Inoltre, delle statistiche non esatte possono indurre Query Optimizer a scegliere un piano meno efficiente.
Se da un lato accelerano l'accesso ai dati, gli indici possono dall'altro rallentare la modifica dei dati, perché oltre alla modifica dei dati sottostanti si rende necessario anche l'aggiornamento degli indici. La vista di gestione dinamica sys.dm_db_index_usage_stats evidenzia la frequenza nell'uso degli indici. Un esempio tipico di indicizzazione poco efficiente sono gli indici composti, in cui la stessa colonna è indicizzata sia singolarmente che in combinazione. Poiché SQL Server accede agli indici da sinistra a destra, l'indice viene utilizzato fintanto che le colonne più a sinistra sono utili.
Con un partizionamento delle tabelle è possibile sia ottimizzare il sistema (con una minore esposizione ai blocchi) che suddividere i dati in oggetti fisici separati a cui si può accedere separatamente. L'attivazione delle partizioni di riga è un metodo ovvio di separazione dei dati, ma un'altra opzione da considerare è la partizione orizzontale dei dati. È possibile scegliere di denormalizzare intenzionalmente dividendo una tabella in tabelle separate con lo stesso numero di righe e chiavi, ma con colonne diverse, per ridurre le probabilità che processi diversi tentino di accedere contemporaneamente ai dati in modo esclusivo.
Maggiori sono i modi in cui un'applicazione può accedere a una specifica riga di dati e maggiori sono le colonne che possono essere incluse in tale riga, più l'approccio di partizionamento delle colonne può risultare interessante. Questo tipo di approccio può talvolta essere utile per le tabelle di stato e di coda delle applicazioni. SQL Server 2008 aggiunge la possibilità di disattivare le escalation dei blocchi la partizione (o per tabella quando le partizioni non sono attivate per la tabella).

Ottimizzazione delle query
L'ottimizzazione delle query svolge un ruolo importante per il miglioramento delle prestazioni. Di seguito sono riportati tre possibili approcci da adottare:
Abbreviare le transazioni Uno dei modi più importanti per ridurre i blocchi, come pure per migliorare le prestazioni globali, è assicurarsi che le transazioni abbiano le minori dimensioni possibili. Qualsiasi elaborazione che non è fondamentale per l'integrità della transazione (come la ricerca di dati correlati, l'indicizzazione e lo scrubbing dei dati) dovrebbe essere eliminata per ridurne la dimensione.
SQL considera qualsiasi istruzione come una transazione implicita. Se l'istruzione influisce su molte righe, un'unica istruzione può costituire tuttavia una transazione di grandi dimensioni, soprattutto se coinvolge molte colonne o se le colonne contengono tipi di dati di grandi dimensioni. Una singola istruzione potrebbe causare anche divisioni di pagina se il fattore di riempimento è elevato o se un'istruzione UPDATE compila una colonna con un valore maggiore di quanto allocato. In tali circostanze, può essere utile dividere la transazione in gruppi di righe, elaborandone una per volta fino al completamento dell'operazione. La suddivisione in batch dovrebbe essere presa in considerazione solo quando la singola istruzione o i gruppi di istruzioni possono essere suddivisi in batch più piccoli che possono essere tuttavia considerati unità di lavoro complete se vengono elaborati più o meno correttamente.
Sequenza delle transazioni All'interno di una transazione, l'organizzazione in sequenza delle istruzioni può diminuire la probabilità di blocchi. È necessario considerare due principi. In primo luogo, accedere agli oggetti nello stesso ordine all'interno di tutto il codice SQL nel sistema. Senza un ordine coerente, potrebbero verificarsi deadlock quando due processi concorrenti accedono ai dati con un ordine diverso, causando un errore di sistema per uno dei processi. In secondo luogo, collocare gli oggetti cui si accede di frequente o gli oggetti l'accesso ai quali risulta più costoso alla fine della transazione. SQL aspetta prima di bloccare gli oggetti finché sono necessari nelle transazioni. Ritardare l'accesso alle aree sensibili consente l'applicazione di blocchi su questi oggetti per una minore percentuale di tempo.
Uso delle indicazioni di blocco È possibile utilizzare le indicazioni di blocco a livello di sessione o a livello di istruzione per una specifica tabella o vista. Uno scenario tipico per l'utilizzo di un'indicazione di blocco a livello di sessione è un'elaborazione batch in un data warehouse, in cui lo sviluppatore sa che quel processo sarà l'unico a essere eseguito in un determinato momento su quell'insieme di dati. Utilizzando un comando come SET ISOLATION LEVEL READ UNCOMMITTED all'inizio della stored procedure, SQL Server non riserverà alcun blocco in lettura, riducendo in tal modo l'overhead complessivo derivante dai blocchi e consentendo un miglioramento delle prestazioni.
Uno scenario tipico per l'uso di indicazioni di blocco sarebbe quando uno sviluppatore sa che una lettura dirty può essere eseguita senza problemi (ad esempio quando viene letta una singola riga da una tabella in cui nessun altro processo concorrente necessiterà mai della stessa riga) o quando tutti gli altri tentativi di ottimizzazione delle prestazioni non sono riusciti (progettazione di schemi, progettazione e manutenzione di indici e ottimizzazione delle query) e lo sviluppatore desidera forzare il compilatore a utilizzare un tipo specifico di indicazione.
Le indicazioni di blocco a livello di riga sono utili se il monitoraggio dimostra che blocchi con un maggiore livello di dettaglio si sono verificati laddove pochi record sono coinvolti nella query, poiché questo potrebbe ridurre i blocchi. Le indicazioni di blocco a livello di tabella sono utili se il monitoraggio evidenzia la presenza di blocchi con un maggior livello di dettaglio (e non soggetti a escalation) quando quasi tutti i record della tabella sono coinvolti nella query, poiché questo potrebbe ridurre le risorse di sistema necessarie per contenere i blocchi. Anche quando si specifica un'indicazione di blocco, non esistono garanzie sulla non esecuzione dell'escalation del blocco quando il numero di blocchi raggiunge la soglia per la memoria di sistema. Tuttavia, in tal modo si eviteranno tutte le altre escalation.

Regolazione della configurazione
Come illustrato dalla Figura 2, è necessario prendere in considerazione numerosi fattori quando si configura un sistema SQL Server.
Figura 2 Modalità di determinazione in SQL Server della quantità di memoria che può essere utilizzata per i blocchi
Figura 2 Modalità di determinazione in SQL Server della quantità di memoria che può essere utilizzata per i blocchi
Memoria I blocchi sono sempre nella memoria non AWE, quindi l'aumento delle dimensioni della memoria non AWE comporterà l'aumento della capacità del sistema di contenere blocchi.
Quando è necessario aumentare la capacità per i blocchi, un'architettura a 64 bit diventa la prima scelta, poiché nell'architettura a 32 bit la memoria non AWE è limitata a 4 GB mentre in quella a 64 bit non esiste alcun limite.
Nei sistemi a 32 bit è possibile ricavare un gigabyte di memoria aggiuntivo dal sistema operativo per SQL Server aggiungendo l'opzione /3GB al file Boot.ini.
Impostazioni di configurazione di SQL Server È possibile definire una serie di impostazioni tramite sp_configure per influire sui blocchi. Le impostazioni dei blocchi consentono di configurare la quantità di blocchi che un sistema può contenere prima di generare un errore. Per impostazione predefinita, l'impostazione è 0, vale a dire che il server regolerà dinamicamente i blocchi riservati con gli altri processi che competono per l'accesso alla memoria. SQL riserva inizialmente 2.500 blocchi e ciascun blocco occupa 96 byte di memoria. La memoria di paging non viene utilizzata.
Le impostazioni di memoria minima e massima riservano la quantità di memoria utilizzata da SQL Server, configurando così il server in modo da occupare in modo statico la memoria. Poiché l'escalation dei blocchi è correlata alla memoria disponibile, se si riserva la quantità di memoria dai processi in competizione, si influisce sull'effettivo verificarsi delle escalation.
Impostazioni di connessione Per impostazione predefinita, i blocchi non sono soggetti a timeout, ma è possibile utilizzare l'impostazione @@LOCK_TIMEOUT, in modo da provocare la generazione di un errore quando viene superata la soglia di attesa specificata per il rilascio di un blocco.
Flag di traccia Due flag di traccia in particolare sono correlati alle escalation dei blocchi. Uno è il flag di traccia 1211, che disattiva le escalation dei blocchi. Se il numero di blocchi utilizzati supera la memoria disponibile, viene generato un errore. L'altro flag di traccia è il 1224, che disattiva le escalation dei blocchi per le singole istruzioni.

Osservazione del sistema
Ulteriori letture
  • Inside Microsoft SQL Server 2005: The Storage Engine di Kalen Delaney
  • Come monitorare i blocchi in SQL Server 2005 e SQL Server 2000
  • Script per ottenere statistiche sulle prestazioni di SQL Server 2005
  • Come risolvere i problemi dei blocchi causati dall'escalation dei blocchi in SQL Server
  • Escalation dei blocchi (Motore di database)

L'impatto che i blocchi hanno sulle prestazioni globali del sistema può essere monitorato per i blocchi eseguendo a intervalli regolari il polling dei dati sullo stato (magari ogni ora) e acquisendo le statistiche correnti sui blocchi gestiti. Le informazioni chiave da acquisire sono:
  • Oggetto interessato, livello di dettaglio tipo di blocco
  • Blocco e durata del blocco
  • Comando SQL inviato (nome della stored procedure, istruzione SQL interna)
  • Informazioni sulla catena di blocco, ove pertinente
  • Modalità di utilizzo da parte del sistema della capacità di blocco disponibile
Per acquisire queste informazioni, è possibile eseguire uno script simile a quello nella Figura 3, scrivendolo in una tabella con il relativo timestamp. Per suddividere ulteriormente il ResourceId dei dati bloccati, è possibile eseguire uno script come quello riportato nella Figura 4.
Figure 4 Ulteriori informazioni sui dati bloccati (Close Figure 4)
DECLARE @SQL                           nvarchar(max)
      , @CallingResourceType           varchar(30)
      , @Objectname                    sysname
      , @DBName                        sysname
      , @resource_associated_entity_id int

-- TODO: Set the variables for the object you wish to look up

SET @SQL = N'
USE     ' + @DbName + N'
DECLARE @ObjectId int

SELECT  @ObjectId = CASE
                    WHEN @CallingResourceType = ''OBJECT''
                    THEN @resource_associated_entity_id
                    WHEN @CallingResourceType IN (''HOBT'', ''RID'', ''KEY'',''PAGE'')
                    THEN (SELECT  object_id
                          FROM    sys.partitions
                          WHERE   hobt_id = @resource_associated_entity_id)
                    WHEN @CallingResourceType = ''ALLOCATION_UNIT''
                    THEN (SELECT  CASE
                                     WHEN type IN (1, 3)
                                     THEN (SELECT  object_id
                                           FROM    sys.partitions
                                           WHERE   hobt_id = allocation_unit_id)
                                     WHEN type = 2
                                     THEN (SELECT  object_id
                                           FROM    sys.partitions
                                           WHERE   partition_id = allocation_unit_id)
                                     ELSE NULL
                                     END
                          FROM    sys.allocation_units
                          WHERE   allocation_unit_id = @resource_associated_entity_id)
                    ELSE NULL
                    END

SELECT  @ObjectName = OBJECT_NAME(@ObjectId)'

EXEC    dbo.sp_executeSQL
        @SQL
      , N'@CallingResourceType varchar(30)
      , @resource_associated_entity_id int
      , @ObjectName sysname OUTPUT'
      , @resource_associated_entity_id = @resource_associated_entity_id
      , @CallingResourceType = @CallingResourceType
      , @ObjectName = @ObjectName OUTPUT
Figure 3 Acquisizione delle statistiche sui blocchi (Close Figure 3)
SELECT  er.wait_time                      AS WaitMSQty
      , er.session_id                     AS CallingSpId
      , LEFT(nt_user_name, 30)            AS CallingUserName
      , LEFT(ces.program_name, 40)        AS CallingProgramName
      , er.blocking_session_id            AS BlockingSpId
      , DB_NAME(er.database_id)           AS DbName
      , CAST(csql.text AS varchar(255))   AS CallingSQL
      , clck.CallingResourceId
      , clck.CallingResourceType
      , clck.CallingRequestMode
      , CAST(bsql.text AS varchar(255))   AS BlockingSQL
      , blck.BlockingResourceType
      , blck.BlockingRequestMode
FROM    master.sys.dm_exec_requests er WITH (NOLOCK)
        JOIN master.sys.dm_exec_sessions ces WITH (NOLOCK)
          ON er.session_id = ces.session_id
        CROSS APPLY fn_get_sql (er.sql_handle) csql
        JOIN (
-- Retrieve lock information for calling process, return only one record to
-- report information at the session level
              SELECT  cl.request_session_id                 AS CallingSpId
                    , MIN(cl.resource_associated_entity_id) AS CallingResourceId
                    , MIN(LEFT(cl.resource_type, 30))       AS CallingResourceType
                    , MIN(LEFT(cl.request_mode, 30))        AS CallingRequestMode
-- (i.e. schema, update, etc.)
              FROM    master.sys.dm_tran_locks cl WITH (nolock)
              WHERE   cl.request_status = 'WAIT' -- Status of the lock request = waiting
              GROUP BY cl.request_session_id
              ) AS clck
           ON er.session_id = clck.CallingSpid
         JOIN (
              -- Retrieve lock information for blocking process
              -- Only one record will be returned (one possibility, for instance,
              -- is for multiple row locks to occur)
              SELECT  bl.request_session_id            AS BlockingSpId
                    , bl.resource_associated_entity_id AS BlockingResourceId
                    , MIN(LEFT(bl.resource_type, 30))  AS BlockingResourceType
                    , MIN(LEFT(bl.request_mode, 30))   AS BlockingRequestMode
              FROM    master.sys.dm_tran_locks bl WITH (nolock)
              GROUP BY bl.request_session_id
                    , bl.resource_associated_entity_id
              ) AS blck
           ON er.blocking_session_id = blck.BlockingSpId
          AND clck.CallingResourceId = blck.BlockingResourceId
        JOIN master.sys.dm_exec_connections ber WITH (NOLOCK)
          ON er.blocking_session_id = ber.session_id
        CROSS APPLY fn_get_sql (ber.most_recent_sql_handle) bsql
WHERE   ces.is_user_process = 1
        AND er.wait_time > 0
Si può inoltre monitorare il proprio sistema per tenere sotto controllo le escalation tramite SQL Profiler (evento Lock:Escalation), vista di gestione dinamica dm_db_index_operational_stats (index_lock_promotion_count) o polling regolare delle informazioni sui blocchi del sistema. L'informazione da ottenere mediante il monitoraggio dell'escalation è se l'elaborazione garantisce un'escalation; se non la garantisce, le relative stored procedure possono diventare una causa primaria di problemi di prestazioni. Per una corretta valutazione, tabelle con grandi quantità di dati o alti tassi di utilizzo contemporaneo devono essere al centro dell'analisi.
Dopo aver raccolta dati su blocchi ed escalation, è possibile passare all'analisi dei dati per determinare i tempi di blocco complessivi (numero di incidenze moltiplicato per la durata delle incidenze) per l'oggetto. In genere, è possibile avviare un ciclo iterativo di regolazione delle prestazioni in cui le modifiche vengano distribuite, monitorate, analizzate e, all'occorrenza, modificate nuovamente. A volte è sufficiente una semplice modifica, come l'aggiunta di un indice, per ottenere miglioramenti significativi delle prestazioni e intervenire sull'area del sistema che costituisce il collo di bottiglia più stretto per le prestazioni.
Altre informazioni sulla riduzione dei blocchi in SQL Server sono riportati nell'intestazione laterale "Ulteriori letture". Se si presta attenzione nel mantenere delle dimensioni accettabili per le transazioni in ogni parte del progetto, del codice e delle fasi di stabilizzazione, sarà possibile ridurre al minimo i problemi causati dai blocchi. Anche un hardware appropriato contribuisce a ridurre in modo considerevole la probabilità di escalation superflue. In tutti i casi, una valutazione costante dei blocchi sul sistema consente di individuare rapidamente all'origine i problemi di prestazione.

Cherié Warren è Senior Development Lead per Microsoft IT. È attualmente responsabile di uno dei più grandi database transazionali in Microsoft. Cherié viene anche consultata di frequente per l'individuazione delle cause e la risoluzione dei problemi di prestazioni correlati ai blocchi. In oltre 10 anni di lavoro, si è specializzata sui database SQL Server delle grandi aziende.


 Microsoft Office: Integrazione dei database di Access con SharePoint
Microsoft Office Peter Serzo

Integrazione dei database di Access con SharePoint
Panoramica:
  • Vantaggi dell'integrazione di Access e SharePoint
  • Migrazione di dati da Access a SharePoint
  • Estensione delle funzionalità di Access con SharePoint

Quando parlo con gli utenti finali di Microsoft Office SharePoint Server (MOSS) 2007, chiedo sempre loro di illustrarmi gli strumenti che utilizzano e il modo in cui li utilizzano. Senza dubbio, qualcuno all'interno
dell'organizzazione utilizza Microsoft® Office AccessTM per soddisfare al meglio le esigenze aziendali critiche. Access è ancora uno strumento valido e costituisce una risorsa importante in molte aziende.
MOSS 2007 consente di utilizzare le applicazioni basate su Access e di integrarle in SharePoint® per creare una nuova soluzione con ulteriori potenzialità. Lo scopo di questo articolo è illustrare come e dove MOSS si integra con Access e in che modo un utente finale può configurare questi due prodotti per creare una soluzione.
La tecnologia sottostante che MOSS introduce in Access incorpora il flusso di lavoro, un repository comune (SQL Server®) e un'interfaccia basata sul Web (il browser). Le funzionalità di SharePoint includono la gestione di documenti, le aree di lavoro e la capacità di impostare elenchi personalizzati nonché di utilizzare flussi di lavoro incorporati e web part standard, che coprono qualsiasi aspetto, dall'annuncio di eventi alla creazione di un elenco di contatti o un elenco di problemi e alla gestione di moduli creati dall'utente. Inoltre, la facilità di utilizzo e le tecnologie familiari di Office contribuiranno a incrementare il senso di "empowerment" dell'utente finale. Come si vedrà, MOSS non rappresenta affatto una minaccia per le soluzioni attualmente implementate. Al contrario, MOSS garantisce una maggiore efficienza, in quanto elimina la necessità di riscrivere le applicazioni, consentendo agli utenti finali di focalizzare l'attenzione sulla risoluzione dei problemi legati al business anziché dei problemi tecnici.
Questo rappresenta un vantaggio non solo per l'utente finale. Non sono pochi infatti i problemi che i reparti IT e gli amministratori devono affrontare per assistere gli utenti finali nella gestione di tutti i database personalizzati all'interno di un'azienda. Molti di loro non sanno neppure che Access viene utilizzato per risolvere problemi aziendali di importanza critica fino a quando non insorgono problemi specifici, come limiti di archiviazione, accesso multiutente, sicurezza, ripristino di database danneggiati, utilizzo del Web, versioni di Access non compatibili e distribuzione di modifiche su più desktop. SharePoint fornisce una risposta per ciascuno di questi problemi.
Sebbene Access presenti alcuni limiti, è un'applicazione potente e di facile utilizzo, in particolare per coloro che non sono sviluppatori professionisti. In un'unica soluzione è possibile creare tabelle relazionali configurabili, eseguire query semplici e complesse, disporre di una funzionalità di creazione di moduli front-end tramite trascinamento, usufruire di report basati sui dati e avere la possibilità di configurare più utenti. La creazione di soluzioni basate su Access e SharePoint si rivela utile sia per le organizzazioni che intendono riunire risorse e talento che per i singoli utenti che desiderano sfruttare le applicazioni e le esperienze create nel corso degli anni.

Introduzione
Access 2007 fornisce diversi punti per l'integrazione con MOSS 2007 che, come illustrato nella Figura 1, includono: importazione di dati da un elenco di SharePoint, pubblicazione di dati in un sito di SharePoint, creazione di un elenco di SharePoint, utilizzo di dati SharePoint come origine esterna, migrazione di un database di Access a un sito SharePoint nuovo o esistente e accesso in modalità non in linea ai dati SharePoint.
Figura 1 Access 2007 fornisce semplici punti di ingresso per l'integrazione con SharePoint
Figura 1 Access 2007 fornisce semplici punti di ingresso per l'integrazione con SharePoint
La creazione di un elenco di SharePoint da una tabella di Access rappresenta un buon punto d'inizio. Un elenco di SharePoint è molto simile a una tabella di Access. Viene salvato nel database dei contenuti di SQL Server, contiene specifici attributi di campo e supporta le ricerche.
Di seguito vengono riportate alcune limitazioni da prendere in considerazione quando si crea un elenco di SharePoint: Per ottenere prestazioni ottimali, Microsoft consiglia un limite di 2.000 elementi per ogni visualizzazione; SharePoint non prevede l'applicazione dell'integrità referenziale; gli oggetti OLE non vengono esportati in SharePoint; la convalida dei dati è limitata.
Per creare un elenco di SharePoint da una tabella di Access, scegliere la scheda Dati esterni, quindi fare clic sul pulsante Elenco SharePoint attivato sotto la casella di gruppo Esporta. A questo punto, per specificare il sito di SharePoint in cui questo elenco sarà attivo, compilare la finestra di dialogo Esporta - Sito di SharePoint, illustrata nella Figura 2, o fare clic con il pulsante destro del mouse sulla tabella e scegliere Esportare i dati in un elenco di SharePoint. Tenere presente che se la tabella è una tabella figlio in una relazione, verranno esportate anche tutte le tabelle padre.
Figura 2 I dati di Access verranno esportati nel sito di SharePoint specificato
Figura 2 I dati di Access verranno esportati nel sito di SharePoint specificato
Una volta completato il processo di esportazione, è possibile salvare la procedura di esportazione in modo da evitare di ripeterla. A questo punto, è possibile accedere al sito di SharePoint e visualizzare i dati caricati. Questa semplice operazione è utile per spostare i dati in SharePoint e renderli accessibili agli utenti. I vantaggi che ne derivano sono una maggiore sicurezza, in quanto i dati ora vengono salvati in un database di SQL Server, e una maggiore semplicità di accesso, in quanto le informazioni sono disponibili tramite il browser.
Tuttavia, un'altra operazione, il collegamento degli elenchi di SharePoint come tabelle di Access, rappresenta un metodo molto più efficace per l'integrazione di Access e SharePoint. A tal fine, fare clic sulla scheda Dati esterni in Access e selezionare Elenco SharePoint nella casella di gruppo Importa. Verrà visualizzata la finestra di dialogo illustrata nella Figura 3.
Figura 3 Collegamento di Access con SharePoint
Figura 3 Collegamento di Access con SharePoint
Selezionare il sito che contiene l'elenco di SharePoint che verrà utilizzato come origine dati collegata, quindi selezionare l'elenco che si desidera collegare. Una volta completata questa operazione, l'elenco verrà visualizzato come tabella collegata in Access e, nell'angolo inferiore destro dell'applicazione, verrà visualizzato l'indicatore "In linea con SharePoint". A questo punto, viene eseguita la sincronizzazione bidirezionale tra Access e SharePoint, che fornisce il supporto per le operazioni di aggiunta, modifica ed eliminazione da SharePoint o Access. Come si vedrà, per fornire funzionalità aggiuntive, è possibile scrivere il codice a fronte della tabella.
Quando si esegue il collegamento agli elenchi di SharePoint in Access, per impostazione predefinita, viene importata e collegata anche un'altra tabella, Elenco informazioni utente di Windows® SharePoint Services (WSS). Viene inoltre creata una tabella di problemi denominata "Problemi durante lo spostamento al sito di SharePoint". In questa tabella è possibile esaminare eventuali conflitti con i dati.
Per ulteriori informazioni sulla migrazione dei dati e sulla modalità di gestione dei tipi di dati durante la conversione, vedere "Modalità di conversione tra i tipi di dati in Access e SharePoint" (office.microsoft.com/en-us/access/HP010477131033.aspx) e la sezione "Limitazioni della migrazione " in "Spostamento delle tabelle di un database di Access in un sito di SharePoint e collegamento tra il sito e le tabelle" (office.microsoft.com/en-us/access/HA101314681033.aspx).
Un terzo metodo per integrare le tabelle e gli elenchi può essere implementato tramite SharePoint. Selezionare un elenco e nella scheda Azioni fare clic su "Apri con Access". Verrà visualizzata una finestra di dialogo in cui viene richiesto il nome del database (nuovo o esistente). Dopo aver immesso il nome del database, specificare se eseguire semplicemente il collegamento ai dati nel sito di SharePoint o esportarli direttamente in Access (vedere la Figura 4).
Figura 4 Come rendere raggiungibili i dati SharePoint tramite Access
Figura 4 Come rendere raggiungibili i dati SharePoint tramite Access

Spostamento di un database in SharePoint
Finora è stato illustrato come importare un elenco di SharePoint come tabella collegata e come esportare le tabelle in SharePoint sotto forma di elenchi. Tuttavia, come bisogna procedere se si desidera accedere all'intero database? Molte organizzazioni in cui le applicazioni critiche per le strategie aziendali vengono eseguite in Access hanno l'esigenza che tali applicazioni siano disponibili in modalità remota, in modo da consentire ai singoli utenti di eseguire report e query e di immettere dati. In tali situazioni, non è sempre possibile riscrivere l'applicazione, in quanto la scelta di questo approccio si basa sia sulle risorse economiche che sul livello delle conoscenze disponibili. Con SharePoint e Access questo problema viene risolto grazie all'opzione "Migrazione guidata a sito di SharePoint", disponibile nella scheda Elenchi SharePoint di Access. Questa opzione è simile all'opzione per lo spostamento di dati in SQL Server utilizzando l'Upsize guidato, introdotto per la prima volta con Access 97.
Lo spostamento di un intero database di Access in SharePoint fornisce diversi vantaggi: tutte le tabelle vengono convertite in elenchi di SharePoint; viene eseguito un backup del database di Access; gli elenchi diventano automaticamente tabelle collegate in Access; è possibile spostare l'intero database, non solo le tabelle; il database funziona allo stesso modo in cui funzionava prima dello spostamento.
Quando si fa clic sul pulsante per lo spostamento in SharePoint, viene visualizzata la finestra di dialogo riportata nella Figura 5. Una volta specificato il sito, è necessario specificare se selezionare l'opzione per salvare il database. In tal caso, l'intero database verrà salvato nella raccolta documenti selezionata. Questo significa che l'intero database, compresi maschere, report, query e macro, viene salvato in SharePoint e viene reso disponibile sul server. Quando un utente desidera accedere al database, è sufficiente fare clic sulla raccolta in cui si trova e il database viene automaticamente distribuito sul relativo desktop.
Figura 5 Specificare il sito di SharePoint in cui si desidera spostare il database
Figura 5 Specificare il sito di SharePoint in cui si desidera spostare il database
Quando si sceglie di spostare l'intero database, viene visualizzata la barra dei messaggi Pubblica modifiche sotto la barra multifunzione. Questo consente di mantenere le modifiche locali al progetto e di garantire la sincronizzazione dei dati con la copia sul server. Se si sceglie di non selezionare questa opzione, solo le tabelle verranno convertite in elenchi e collegate in Access. In questo caso, l'intero database non sarà disponibile alla comunità di utenti e non ne verrà eseguito il backup come oggetto in SharePoint.
Dopo aver specificato una di queste opzioni, il database e le informazioni associate saranno disponibili tramite il sito di SharePoint selezionato. Viene di nuovo creata automaticamente una tabella denominata "Problemi durante lo spostamento al sito di SharePoint". In questa tabella vengono documentati tutti i conflitti dovuti alla migrazione. È possibile esaminare tutti i problemi che si verificano in Access durante il caricamento della tabella nel sito di SharePoint.

Visualizzazioni, moduli e report
Una volta spostato il database, è opportuno testarne le funzionalità. Assicurarsi che l'indicatore "In linea con SharePoint" sia visibile prima di iniziare. Notare che le query di Access diventano visualizzazioni di SharePoint; una visualizzazione di SharePoint è molto simile a una query di Access.
Quando si sposta l'intero database, le query esistenti vengono copiate in SharePoint come visualizzazioni. Gli utenti di Access sono consapevoli del fatto che la scrittura di query consente di visualizzare un sottoinsieme di dati. L'acquisizione delle conoscenze necessarie per eseguire questa operazione in una visualizzazione di SharePoint consentirà di comprendere il modo in cui i dati vengono organizzati in un elenco di SharePoint.
Una delle visualizzazioni più utili che è possibile creare è una visualizzazione di Access. A tal fine, accedere all'elenco in cui si desidera creare la visualizzazione, quindi scegliere Visualizzazioni e Crea visualizzazione. Verrà visualizzata l'opzione Visualizzazione di Access, che consente di creare maschere e report in base a un elenco. Quando si fa clic su questa opzione e si seleziona il database di Access, viene visualizzata una finestra di dialogo simile a quella riportata nella Figura 6. Come si può osservare, ora è possibile definire il formato (tipo di modulo, PivotChart, PivotTable o Report) e, al termine del processo, verrà creata una maschera o un report collegato nel database di Access.
Figura 6 Creazione di una visualizzazione di Access
Figura 6 Creazione di una visualizzazione di Access

Access non in linea
Nel mondo reale, l'estensione delle potenzialità di un'applicazione critica per le strategie aziendali si traduce in un ritorno sull'investimento sostenuto. Per estendere le potenzialità di un'applicazione Access/SharePoint integrata, è bene tenere presente che non è necessario essere connessi a SharePoint per utilizzarlo. Per garantire una maggiore flessibilità sotto questo aspetto, con Access 2007 è stata introdotta la possibilità di lavorare in modalità non in linea. Le informazioni vengono memorizzate nella cache della copia locale del database fino a quando non vengono associate al server. Per portare un database in modalità non in linea, fare clic sul pulsante Non in linea in Dati esterni|Elenchi SharePoint nella barra multifunzione.
Quando si è pronti per riconnettersi a SharePoint, è possibile scegliere di lavorare in modalità in linea o eseguire la sincronizzazione. Entrambe le opzioni consentono di caricare i dati e i conflitti presenti per la revisione; con l'opzione Sincronizza, tuttavia, i dati vengono caricati ma l'applicazione resta in modalità non in linea.
Un altro elemento disponibile in Elenchi SharePoint da tenere presente è Ignora modifiche, che fornisce due opzioni. La prima consente di ignorare tutte le modifiche senza aggiornare i dati di SharePoint in Access. La seconda opzione consente di ignorare tutte le modifiche e di aggiornare i dati di SharePoint (elenchi collegati).

Modelli di Access
Access 2007 dispone di diversi modelli incorporati per assistere gli utenti nella rapida creazione delle soluzioni aziendali, come è possibile osservare facendo clic sul pulsante Elenchi SharePoint nella scheda Crea in Tabelle (vedere la Figura 7). Se si seleziona una di queste opzioni, verrà automaticamente definito lo schema per una tabella collegata in SharePoint. Attualmente solo le opzioni Contatti, Attività, Problemi ed Eventi sono supportate. Ne consegue che, se si esporta una tabella che contiene uno di questi tipi di informazioni, i dati verranno convertiti nel tipo di contenuto WSS corrispondente, ad esempio Problemi in Problemi.
Figura 7 Selezione del tipo di elenco
Figura 7 Selezione del tipo di elenco
È inoltre possibile creare modelli personalizzati che possono essere utilizzati per gli elenchi SharePoint o creare modelli di siti di SharePoint con il collegamento automatico dei database di Access 2007. Per eseguire questa operazione è necessario utilizzare Access 2007 Developer Extensions e impostare la proprietà WSSTemplateID della tabella. Questa proprietà tiene traccia delle tabelle che contengono l'equivalente del modello di elenchi di SharePoint.

Metadati e Access
Le aziende che tradizionalmente utilizzano le applicazioni Access potrebbero non sempre essere in grado o essere disposte a spostare tutte queste applicazioni in SharePoint. In tali casi, è opportuno a volte scrivere il codice in Access per aggiornare SharePoint. Il codice consente di integrare SharePoint e Access.
Un esempio semplice è rappresentato dal database di Northwind Trader, in cui vengono archiviate informazioni su prodotti, fornitori e ordini di clienti. A ogni prodotto è in genere associata una scheda prodotto fornita dal fornitore sotto forma di file .pdf. Il database di Access tiene traccia di tutte le informazioni contenute nella scheda del prodotto, come posizione geografica, numero del prodotto, cronologia delle revisioni e codice del reparto aziendale. Queste informazioni devono essere disponibili ai fornitori tramite la rete Extranet di SharePoint.
Viene configurato un sito di SharePoint e tutti i documenti vengono trasferiti in una raccolta documenti collegata, ma i campi di metadati sono vuoti (vedere la Figura 8), in quanto i dati vengono riportati in Access (l'utente che monitora questo processo si trova a proprio agio con Access e non è disposto a cambiare).
Figura 8 Documento Northwind visualizzato in SharePoint, con i metadati mancanti
Figura 8 Documento Northwind visualizzato in SharePoint, con i metadati mancanti
Come illustrato nella Figura 9, è possibile aggiungere il codice Visual Basic® for Applications (VBA) per aggiornare i metadati tramite l'applicazione Access. Non è necessario riscrivere l'applicazione. Il dipendente può continuare a utilizzare uno strumento con cui ha familiarità ed esplorare il Web, mentre i fornitori possono accedere alla rete Extranet in base alle relative autorizzazioni (in modo che possano visualizzare solo i dati consentiti) senza che si verifichi alcun problema correlato alla concorrenza o alle dimensioni del database.
Figura 9 Aggiornamento dei metadati mediante il codice
Figura 9 Aggiornamento dei metadati mediante il codice

Sicurezza integrata
Uno dei maggiori vantaggi dello spostamento delle applicazioni Access in SharePoint è rappresentato dalla possibilità di utilizzare il modello di sicurezza di SharePoint, in cui è integrata l'autenticazione basata su Active Directory®. Ne consegue che non è più necessario preoccuparsi di come implementare la sicurezza nelle applicazioni Access attraverso la creazione di schemi e tabelle e l'aggiunta di utenti. Con gli elenchi di SharePoint, è possibile utilizzare la limitazione per motivi di protezione, una funzionalità integrata in SharePoint, in base alla quale gli utenti possono visualizzare solo i dati che sono loro consentiti. Inoltre, non è necessario spostare determinati componenti del database in SharePoint, se non si desidera.
SharePoint fornisce un modello di sicurezza granulare e basato sui ruoli. Dopo aver determinato come e dove spostare un database, è opportuno progettare il sito e la sicurezza prima del processo di migrazione. Questo consentirà di semplificare l'impostazione e il test delle autorizzazioni nonché di ridurre i problemi di migrazione, garantendo una maggiore efficienza del database di Access in termini di prestazioni.

Integrità referenziale
Peccherei certamente di negligenza se non affrontassi in questo articolo il concetto di integrità referenziale. A differenza di Access, SharePoint non prevede l'applicazione dell'integrità referenziale. Molte installazioni vengono normalizzate fino a un certo livello. Perché i database di Access critici per le strategie aziendali funzionino in modo corretto, è necessario prendere in considerazione questo aspetto. Per fortuna, sono disponibili alcune soluzioni alternative che possono essere interpretate come miglioramenti al sistema esistente
In precedenza è stato notato che durante lo spostamento di un database in SharePoint, se si spostano tabelle figlio, vengono spostate anche le tabelle padre. Inoltre, i campi di ricerca vengono utilizzati in SharePoint quando un'opzione di un campo viene riconosciuta come basata su un'altra tabella. Si supponga, ad esempio, che un cliente venga selezionato e un ordine venga emesso nel database Northwind Traders. Se queste tabelle venissero spostate in SharePoint, il campo relativo al cliente rappresenterebbe un campo di ricerca nell'elenco degli ordini.
E per quanto riguarda gli aggiornamenti o le eliminazioni a catena e altre operazioni più complesse? È in tale contesto che SharePoint e i relativi flussi di lavoro devono essere considerati come una potenziale soluzione. Tornando al database Northwind Traders, si supponga che un cliente chiami e annulli un ordine esistente, il che determina l'attivazione di una serie di azioni: l'inventario deve essere ripristinato, i fornitori devono essere informati, il dipendente associato all'ordine deve condurre un follow-up presso il cliente, la spedizione deve essere annullata e la contabilità deve essere aggiornata. È necessario coordinare pertanto diversi tipi di attività.
Utilizzando SharePoint Designer, è possibile creare un flusso di lavoro in SharePoint che esegua tutte queste attività non appena lo stato dell'ordine viene modificato. Sono disponibili 22 flussi di lavoro predefiniti che possono essere combinati e associati a centinaia di azioni. SharePoint Designer è uno strumento straordinario per la personalizzazione del sito e la creazione di flussi si lavoro.
L'aspetto più interessante è che l'utilizzo di SharePoint Designer per creare i flussi di lavoro richiede conoscenze e competenze di cui gli utenti esperti nella programmazione in Access già dispongono. Questo significa che gli utenti che creano applicazioni Access possono estendere il relativo ambito di competenze alla creazione dei flussi di lavoro senza troppi sforzi. L'utilizzo di SharePoint Designer per i flussi di lavoro non richiede la scrittura di codice e la distribuzione dei flussi di lavoro è piuttosto semplice.

Peter Serzo è Senior Engineer per CDW Berbee. Si occupa in particolare della progettazione di soluzioni SharePoint Enterprise per le aziende in tutto il mondo.


 Dal redattore: Agli amici, vecchi e nuovi
Dal redattore
Agli amici, vecchi e nuovi

Il numero di questo mese si apre con una nota agrodolce. Sfortunatamente, è giunto il momento di salutare Joseph Davies, l'autore della rubrica The Cable Guy, che conclude la sua rubrica per TechNet Magazine in questo numero. Siamo stati estremamente fortunati ad avere un esperto del calibro di Joseph che ci ha istruito su una miriade di argomenti relativi alle tecnologie di rete Windows. Joseph ha intrapreso di recente un nuovo ruolo di responsabilità in Microsoft che lo obbliga a rinunciare a un'attività altrettanto impegnativa come la redazione di una rubrica mensile. Tutti noi in TechNet Magazine lo ringraziamo per il prezioso contributo che ci ha fornito nel corso degli anni e gli auguriamo la massima fortuna nel suo nuovo progetto.
Per quanto il suo commiato ci riempia di tristezza, lo spettacolo deve continuare. Pertanto, nel nostro prossimo numero debutteremo con una nuova rubrica dal titolo "All'interno di SharePoint". L'anno scorso abbiamo ricevuto un'enorme quantità di feedback da parte degli utenti che richiedevano una maggiore formazione su SharePoint. Dal momento che SharePoint è una tecnologia molto interessante e in rapida evoluzione, nessun altro argomento è più meritevole di una rubrica mensile. Pav Cherny darà avvio a questa nuova rubrica, il cui primo numero sarà dedicato a una panoramica sull'architettura dell'infrastruttura di SharePoint. Gli articoli dei mesi successivi si occuperanno di sicurezza, disponibilità, prestazioni, risoluzione di problemi e tanti altri argomenti. Se avete argomenti relativi a SharePoint che vorreste vedere trattati in questa rubrica, non esitate a contattarci scrivendo un messaggio di posta elettronica all'indirizzo tnmag@microsoft.com.
Dobbiamo inoltre estendere un enorme debito di gratitudine a due dei nostri redattori senior, Terrence Dorsey e Nancy Michell. Terry e Nancy hanno collaborato alla nostra rubrica sin dall'inizio e hanno contribuito con il loro enorme talento e la loro ampia esperienza al successo di TechNet Magazine. Tuttavia, a partire da questo numero Terry e Nancy si occuperanno della pubblicazione consorella, MSDN Magazine. Due dei nostri redattori senior più esperti, Matthew Graven e Sharon Terdeman, dovranno rinunciare alle mansioni svolte per MSDN Magazine per dedicarsi totalmente a TechNet Magazine. Fortunatamente, Terry e Nancy non andranno lontano e, pertanto, è nostra intenzione continuare a sfruttare le loro conoscenze e competenze, in quanto TechNet Magazine continua a crescere.
A questo punto, vi auguro una buona lettura con il numero di questo mese. Dedicato in gran parte al rilascio imminente di SQL Server 2008, nel numero di questo mese verranno illustrate un'ampia gamma di nuove funzionalità che consentiranno di semplificare le attività di archiviazione, protezione, gestione e utilizzo dei dati che, considerata la relativa espansione in termini di volume e di ambito, rappresentano indiscutibilmente la risorsa più preziosa per le attività aziendali. -Joshua Hoffman


 Lettere: La parola ai lettori
Lettere
La parola ai lettori

Host forti e vulnerabili
Nell'articolo della serie The Cable Guy di settembre 2007 (technetmagazine.com/issues/ 2007/09/CableGuy) "Modelli host forti e vulnerabili" si è accennato alla possibilità di attivare o disattivare l'utilizzo dell'host vulnerabile, ma non è stato specificato come eseguire questa operazione. Questo tipo di operazione implica semplicemente l'attivazione o la disattivazione del firewall o l'impostazione di un parametro del Registro di sistema? È disponibile un parametro del Registro di sistema associato a tale operazione?
Inoltre, la configurazione dell'accesso locale richiede due tipi di informazioni: l'indirizzo IP e la maschera IP. Perché Microsoft considera non valida una configurazione che non contiene il parametro di gateway facoltativo?
—Milt B.
È possibile configurare il comportamento di host forte o vulnerabile in Windows Vista® e Windows Server® 2008 con i comandi elencati nella figura (pubblicati per la prima volta nel numero di settembre 2007). Non esistono voci del Registro di sistema corrispondenti. Non è possibile configurare il comportamento di host forte o vulnerabile in Windows® XP e Windows Server 2003. IPv4 supporta solo il modello host vulnerabile.
Quanto alla seconda domanda, in base alle nostre conoscenze, la configurazione IPv4 o IPv6 su un'interfaccia non richiede la configurazione di un router o un gateway predefinito, tramite l'interfaccia utente o la riga di comando.


 Casella degli strumenti: Nuovi prodotti per professionisti IT
Casella degli strumenti
Nuovi prodotti per professionisti IT
Greg Steen

Gestione di più monitor
UltraMon
realtimesoft.com
Con il costante calo dei prezzi dei pannelli a cristalli liquidi, molti amministratori di sistema iniziano a utilizzare due, se no più, monitor collegati alla workstation, per tenere meglio d'occhio i diversi pannelli di controllo di amministrazione (chi non ci ha ancora provato, non sa quanto la vita possa diventare facile). Ma con l'aggiunta di uno o più monitor, si inizia anche a utilizzare il mouse in modo più estensivo e le operazioni potrebbero risultarne rallentate. Una buona utilità, facile da usare, per la gestione dei monitor con tasti di scelta rapida da tastiera può essere di grande aiuto. Uno dei migliori strumenti di questo tipo è UltraMon di Realtime Soft, un'utilità che supporta da Windows® 98 a Windows Vista®, sia a 32 bit che a 64 bit.
Al primo avvio di UltraMon, si noteranno probabilmente le due piccole icone nell'angolo di ogni applicazione Windows. La prima icona consente di espandere rapidamente la finestra dell'applicazione su tutti i monitor, mentre la seconda consente di spostare l'applicazione all'altro monitor. Si noterà anche che la barra delle applicazioni è presente in tutti i monitor e contiene le applicazioni attive per ciascuno dei monitor. Questo significa che non è necessario tornare al monitor principale per espandere un'applicazione e che è possibile sapere immediatamente dove verrà visualizzata l'applicazione dopo l'ingrandimento o la riduzione a icona.
In ciascuno dei collegamenti dell'applicazione una nuova scheda di UltraMon consente di definire il monitor e la posizione in cui l'applicazione deve essere avviata, quindi è possibile, ad esempio, visualizzare sempre Microsoft® Outlook® sul monitor a sinistra e Internet Explorer® sul monitor a destra. I professionisti IT si connettono spesso alla propria workstation in modalità remota, da posizioni diverse, come un computer portatile o il desktop di casa; è utile sapere, in questi casi, che per ciascuna di queste connessioni remote è probabilmente necessaria una lieve modifica al desktop e alla risoluzione di visualizzazione.
Per fortuna, UltraMon supporta anche i profili di visualizzazione, che consentono di passare rapidamente da una visualizzazione personalizzata all'altra dei propri monitor. Un grande aiuto quando si condivide il proprio computer con altre persone che desiderano o devono personalizzare le proprie visualizzazioni oppure quando si rende necessario modificare la visualizzazione in base all'attività.
Se si usa Windows 2000 o Windows XP, si può anche attivare una funzione di "mirroring" perfetta per le presentazioni, poiché consente di utilizzare sul monitor principale una risoluzione maggiore rispetto alla presentazione, pur rispecchiando le attività dell'applicazione su entrambi i monitor. Se invece non si è ancora passati a Windows Vista, è possibile espandere la schermata dell'applicazione su più monitor (operazione che in Windows Vista viene eseguita per impostazione predefinita).
Le ulteriori funzionalità di visualizzazione, come una scorciatoia per la finestra Impostazioni schermo, la possibilità di impostare e cambiare rapidamente il monitor principale del sistema e di passare a un altro profilo di visualizzazione, sono alcune delle attività frequenti di rapido accesso disponibili mediante l'icona nella barra delle applicazioni di UltraMon. È inoltre possibile, tra l'altro, avviare la finestra UltraMon Options, in cui si può personalizzare la "Smart Taskbar", impostare i tasti di scelta rapida per spostare e modificare le finestre e spostare il mouse su un punto specificato.

Prezzo: si parte da 39,95 dollari per una singola licenza.
La finestra delle opzioni in UltraMon consente di impostare i tasti di scelta rapida e gestire Smart Taskbar
La finestra delle opzioni in UltraMon consente di impostare i tasti di scelta rapida e gestire Smart Taskbar

Recensione
Microsoft SQL Server 2005 Analysis Services
informit.com
Disporre di moltissimi dati nella propria base clienti è un conto, comprendere e manipolare tali dati in modo da estrarne statistiche utili e significative sui clienti è tutt'altra cosa. Per ottenere viste e proiezioni calcolate, serve una soluzione di Business Intelligence dinamica e potente. Parte della risposta Microsoft alle esigenze di Business Intelligence e OLAP è SQL Server® 2005 Analysis Services. Il volume Microsoft SQL Server 2005 Analysis Services è un valido sussidio al completo ed efficace utilizzo di questa soluzione.
Il libro di Py Bateman, Alexander Berger, Irina Gorbach ed Edward Melomed è indirizzato a chi ha in programma una nuova distribuzione di data mining, intende passare ad Analysis Services 2005 da Analysis Services 2000 o ha mansioni di amministratore di database con interessi relativi a ciò che questi strumenti possono fare per l'organizzazione. Invece di restare nel regno dell'approccio teorico alla Business Intelligence, il libro offre un punto di vista immediato e approfondito sull'utilizzo, lo sviluppo, la distribuzione e la gestione di Analysis Services nel mondo reale. Molti degli esempi offerti sono basati su Food Mart 2005, un database di esempio fornito con il software, quindi è possibile iniziare subito a eseguire esperimenti nell'ambiente di prova.
Nella sezione introduttiva del libro vengono illustrare le novità della versione 2005, compresa l'architettura client-server con la comunicazione XML for Analysis (XMLA) dei servizi Web, il modello UDM e i miglioramenti in termini di scalabilità nella nuova versione. Viene anche presentata un'introduzione al database di esempio Food Mart e gli elementi di base dei database multidimensionali. Si passa quindi alla creazione di modelli di dati, con informazioni approfondite su XML come linguaggio di definizione dei dati (DDL), su attributi e gerarchie delle dimensioni e su cubi e analisi multidimensionali. È presente anche un'introduzione alla progettazione e allo sviluppo tramite Business Intelligence Development Studio della postazione di lavoro del professionista di Business Intelligence in 2005 Analysis Services.
Dopo aver assimilato questi concetti di progettazione, si passa alla manipolazione dei dati mediante le espressioni multidimensionali (MDX). Oltre a chiari esempi sulla creazione di query con MDX, vengono fornite informazioni preziose sull'utilizzo di funzioni e proprietà di membro e cellula di MDX, sulla gestione di insiemi vuoti e valori null, selezioni secondarie e sottocubi e su come creare e utilizzare i calcoli MDX basati su cubi ed estendere le query con le stored procedure. Il libro quindi si inoltra nei campi di indicatori delle prestazioni chiave (KPI), drill-through e scorecard, che consentono tutti di approfondire la conoscenza di aspetti quali la crescita commerciale, le misurazioni e le destinazioni.
L'ottima sezione successiva del libro prende in analisi i processi di estrazione, trasformazione e caricamento (ETL) dei dati, illustrando non solo come si portano i dati nel sistema ma anche come si ottimizza il progetto di aggregazione e si utilizza la memorizzazione nella cache proattiva per migliorare le prestazioni. Nella stessa sezione si analizza inoltre il modello di dati fisico di cubi e dimensioni e si scopre come funziona l'elaborazione di ciascuno con 2005 Analysis Services. Inoltre, si apprende come scalare una distribuzione per soddisfare le esigenze di crescita dell'azienda, con cenni al bilanciamento del carico di rete, alle farm OLAP, a gruppi di misure collegati e di dimensioni e all'elaborazione di partizioni remote.
L'attenzione quindi si sposta sull'esecuzione pratica di query per garantire la migliore comprensione possibile delle operazioni sottostanti e aiutare i lettori a ottimizzare le prestazioni dell'applicazione. Vengono esplorati l'accesso ai dati dal punto di vista del client e le numerose opzioni disponibili a tale scopo, come XMLA, ADOMD.net e gli oggetto AMO (Analysis Management Objects). Per trarre il meglio da questa sezione, occorre liberare il creatore di codice che il lettore si porta dentro e provare a utilizzare Visual Studio e gli IDE di Business Intelligence per creare applicazioni di data warehouse personalizzate.
Nell'ultima sezione si affrontano argomenti relativi alla gestione dell'installazione di Analysis Services, tra cui l'utilizzo dello strumento di analisi, dell'utilità Traccia eventi e di SQL Server Profiler per monitorare le prestazioni e l'integrità del sistema. Infine, vengono illustrate alcune opzioni per il backup e il ripristino della distribuzione, con sezioni dedicate all'utilizzo di un comando DDL per eseguire il backup del database, l'automazione tramite SQL Server Agent o SQL Server Integration Services (SSIS) e le tecniche per il recupero dei dati persi o danneggiati. In definitiva, questo volume su SQL Server 2005 Analysis Services di rivela una guida completa e ad ampio spettro.

Prezzo: $59.99.

Diagnosi dei problemi di database
ApexSQL Audit
apexsql.com/sql_tools_audit.asp
È probabile che chi legge sappia già che la prima operazione da eseguire per l'individuazione dei problemi o di una potenziale violazione consiste nel raccogliere informazioni pertinenti relative all'evento che ha provocato il problema. Chi, inoltre, lavora al supporto degli utenti finali, conosce probabilmente bene le richieste di aiuto relativa a sistemi che "hanno perso i dati". Uno strumento che può aiutare ad azzerare rapidamente i problemi dei database in SQL Server è ApexSQL Audit di ApexSQL, che supporta completamente le versioni da SQL Server 7.0 a SQL Server 2005.
Come suggerisce il nome, l'applicazione registra l'attività dei database specificati dall'utente e consente quindi di creare report personalizzati sull'audit trail per l'analisi. Le voci di controllo vengono aggiunte tramite trigger SQL e memorizzate in uno schema generato automaticamente. È possibile decidere di memorizzare le informazioni di controllo nello stesso database dei dati monitorati oppure in un database a parte per garantire l'isolamento.
L'installazione (e la rimozione) dello schema (o architettura, come viene chiamata) di controllo è un'operazione molto semplice eseguita tramite un'interfaccia utente grafica. Anche la preparazione di un progetto di controllo per un database è abbastanza semplice: si sceglie il database, si scelgono le tabelle e i campi da controllare, quindi si fa clic sul pulsante per avviare la generazione dei trigger.
L'applicazione consente di modificare i modelli di trigger per il progetto e ho trovato molto utile il fatto che l'editor del modello sia dotato di funzionalità di tipo IntelliSense® per il modello di controllo, semplificando la personalizzazione sia del momento in cui deve essere avviato il trigger che delle informazioni che verranno memorizzate. Un'altra interessante funzionalità consente di fare facilmente riferimento alle tabelle di ricerca in modo che le informazioni di controllo siano comprensibili, invece di risultare come un'oscura raccolta di ID. È possibile associare i nomi dei campi controllati a nomi di campi di controllo per mappare le colonne.
Una volta installata e impostata l'applicazione, l'interfaccia utente consente di esplorare rapidamente i trigger di controllo applicati e, se necessario, attivare e disattivare con un clic dei trigger specifici. Si può esaminare la copertura del controllo con la comoda visualizzazione a tabella dell'interfaccia.
Come noto, le informazioni di controllo tendono a essere fin troppo dettagliate ed è necessario adottare qualche forma di gestione delle informazioni per l'archiviazione e la riduzione dei database di controllo. ApexSQL Audit è dotato di uno strumento di gestione dei dati che consente di eliminare tutte le informazioni con un clic, specificare una serie di criteri e procedere quindi all'eliminazione o pianificare un'eliminazione dei dati basata su criteri.
I processi pianificati vengono creati automaticamente come pacchetti di Data Transformation Service (DTS) e pianificati tramite SQL Agent. Avere a disposizione tutte queste informazioni di controllo non significa necessariamente poterle utilizzare in modo fruttuoso. Per fortuna, in ApexSQL Audit è disponibile un ottimo componente di creazione dei report che consente di generare viste filtrate e personalizzate di dati di controllo singoli e aggregati. Dopo aver generato il report, è possibile stamparlo facilmente o esportare l'output in un file HTML, Microsoft Excel o di testo.

Prezzo: a partire da 599 dollari.
Le tabelle di ricerca in ApexSQL Audit forniscono informazioni di controllo complete
Le tabelle di ricerca in ApexSQL Audit forniscono informazioni di controllo complete

Automatizzazione dei promemoria di scadenza delle password
Password Reminder PRO v1.4
sysoptools.com/password-reminder-pro.html
Chi ha notato un aumento delle chiamate al supporto tecnico quando i criteri di scadenza delle password raggiungono un gruppo dell'organizzazione? Chi ha notato questo fenomeno, dovrebbe dotarsi di Password Reminder PRO di SysOp Tools. Questo semplice strumento si integra con Active Directory® e notifica agli utenti finali che gli account o le password stanno per scadere.
È possibile preparare tre diversi promemoria, ciascuno con un particolare modello di posta elettronica in formato HTML o basato su testo. Si possono inoltre configurare una validità massima della password allo stesso numero di giorni della configurazione di Active Directory e l'ora in cui devono essere inviati i promemoria, in modo da non contribuire al traffico degli orari di picco. La modalità di test consente di visualizzare in anteprima gli effetti, senza coinvolgere realmente gli utenti finali e per verificare che tutto sia configurato in modo corretto.
L'utilità dispone anche di una console di report, in cui vengono illustrate in una tabella le classi di utenti diversi: account in scadenza, utenti inattivi, nuovi account, account disattivati e altro. Dalla console di report si possono esportare tutte le informazioni in un file XLS per una revisione successiva. Per un ulteriore controllo dei messaggi di posta elettronica che vengono inviati, Password Reminder PRO invia un report quotidiano con i promemoria inviati e i relativi destinatari.

Prezzo: si parte da 249 dollari per 100 licenze.
Password Reminder PRO consente di visualizzare in anteprima le configurazioni prima della distribuzione
Password Reminder PRO consente di visualizzare in anteprima le configurazioni prima della distribuzione

Risoluzione remota dei problemi semplificata
UltraVnc SC
uvnc.com/pchelpware/sc
Il metodo più semplice per risolvere un problema o guidare l'utente nel processo di risoluzione è, di solito, essere fisicamente presenti al computer. Ma nelle aziende globali distribuite di oggi, questo non è sempre possibile. Gli strumenti di Windows Connessione desktop remoto e Assistenza remota possono aiutare a connettersi ad alcuni dei computer del proprio ambiente. Ma per coprire tutte le basi, può essere interessante provare l'utilità gratuita UltraVNC SC, dai produttori del progetto UltraVNC.
Come la versione precedente, UltraVNC SC consente di visualizzare e controllare un computer remoto; tuttavia, questa versione è costituita da un piccolo server UltraVNC da 166 KB che si configura e invia all'utente finale. Non si utilizzano voci del registro di sistema, l'utilità non viene eseguita come un servizio e non è necessario alcun programma di installazione, quindi l'utente finale non deve eseguire alcuna installazione o configurazione. L'utente fa doppio clic sull'eseguibile per avviare il miniserver VNC, quindi è possibile connettersi al suo computer per le attività di supporto e amministrazione.
Mentre il server UltraVNC standard supporta il trasferimento di file e directory, attualmente UltraVNC SC supporta solo il trasferimento di file. In termini di sicurezza, la comunicazione è crittografata fino al livello dell'API di crittografia Microsoft (40 o 128 bit). Inoltre, il miniserver non consente connessioni in entrata, l'istanza può essere creata solo dall'utente finale e la connessione avviene esclusivamente al computer specificato nella configurazione eseguita prima dell'invio all'utente finale.
Per creare visualizzazioni personalizzate, adattare alcuni file di configurazione di testo e grafica ed eseguire quindi un file batch dall'installazione di un altro componente aggiuntivo del progetto, denominato PCHelpware, per generare l'eseguibile. La documentazione non è molto esaustiva, ma illustra come eseguire le procedure relativamente semplici. Infine, l'applicazione viene automaticamente disinstallata quando, dopo l'uso, viene chiusa la connessione, quindi non vengono lasciate tracce o falle nel sistema di sicurezza.

Prezzo:gratuito.

Greg Steen è un professionista IT oltre a essere un appassionato imprenditore. È sempre alla ricerca di nuovi strumenti che aiutino a rendere più semplici le operazioni, il controllo della qualità e lo sviluppo per i professionisti IT.


 Domande e risposte su SQL: Database che crescono, IFilter e connessione in modalit&#224; remota
Domande e risposte su SQL
Database che crescono, IFilter e connessione in modalità remota
A cura di Matthew Graven

Suggerimento: cancellazione della cache
Chi non si è mai chiesto perché una stored procedure funziona bene nell'ambiente di test e poi evidenzia pessime prestazioni dopo la distribuzione sul SQL Server di produzione? La causa potrebbe essere un problema correlato alla cache. Prima di distribuire le stored procedure nell'ambiente di produzione, sottoporre le procedure a test nell'ambiente di test dopo aver cancellato i piani di query memorizzati nella cache, in modo da poter verificare il funzionamento della stored procedure in un ambiente a cache "fredda". Ecco un paio di suggerimenti davvero utili.
Per cancellare la cache delle procedure in un SQL Server:
DBCC FREEPROCCACHE
Go
Eseguire una query per ottenere un elenco con tutti i piani memorizzati nella cache:
Select * from sys.dm_exec_cached_plans
Go

D Ho un database che produce un traffico intenso durante il giorno e non vorrei utilizzare l'aumento di dimensioni automatico, per evitare timeout quando SQL Server® decide di eseguire l'operazione durante le ore di picco. Vorrei implementare un processo periodico per espandere il file di database di una percentuale dello spazio utilizzato specifica. Come è possibile eseguire questa operazione?
R L'aumento di dimensioni del file è un'operazione a I/O su disco intensivo e, quando SQL Server deve attendere che si completi l'espansione di un file di dati o di registro, si nota un calo nelle prestazioni e un peggioramento dei tempi di risposta. L'incremento di crescita predefinito è di 1 MB per i file di dati e del 10% per i file di registro, che possono rivelarsi incrementi insufficienti per dei sistemi molto sfruttati. Inoltre, quando si utilizza l'aumento automatico delle dimensioni, si può verificare una maggiore frammentazione del disco, perché i file di dati o di registro non sono contigui su disco. Ne risultano tempi di risposta più lunghi del necessario, dal momento che i dati sono fisicamente sparsi sul disco.
Una soluzione per l'ottimizzazione delle prestazioni è l'allocazione proattiva di spazio di archiviazione sufficiente per i file di dati e di registro. A tal fine sono spesso necessarie analisi delle tendenze e previsioni di crescita, ma le prestazioni se ne avvantaggiano perché i file saranno contigui sul disco e si eviteranno i costi in termini di I/O necessario per l'aumento automatico delle dimensioni durante i periodi di punta. È opportuno tenere l'aumento automatico delle dimensioni attivato, perché dei file di dati o di registro completamente pieni impediscono del tutto l'accesso al database. Ma, appunto, l'aumento automatico delle dimensioni deve essere considerato una rete di protezione piuttosto che una funzionalità di gestione del database.
È inoltre preferibile evitare espansioni dei file del database su base regolare, perché ne possono derivare file non contigui su disco con un ovvio peggioramento delle prestazioni. Il controllo proattivo si può ottenere eseguendo uno script per determinare la percentuale di spazio libero per ciascun database (eseguito da un processo di SQL Agent) e avviando quindi un'azione (come l'invio di un avviso di posta elettronica tramite Posta elettronica database). Il codice nella figura costituisce uno script di esempio con cui si illustra come recuperare informazioni sulla percentuale di spazio libero per il database corrente.
Dopo la generazione di un avviso, è possibile creare uno script per l'aumento di dimensioni una tantum dei file con il comando ALTER DATABASE e si può utilizzare un processo di SQL Agent per pianificare l'azione in modo che non venga avviata nelle ore di picco. Provare a far crescere il file di una dimensione che sia sufficiente per il futuro prevedibile, in modo da evitare ulteriori piccole espansioni future. È anche utile verificare che la compattazione automatica non sia attivata su alcun database, poiché potrebbe avviare inutili cicli di aumento delle dimensioni e compattazione del database.
—Justin Langford
Determinazione dello spazio libero in un database
-- Script to gather size, free space and
-- calculate % free space for current
-- USER database
DECLARE @size DEC(15,2)
DECLARE @free DEC(15,2)
DECLARE @result DEC(15,2)

SELECT @size = SUM(size)*1.0/128
FROM sys.database_files

SELECT @free =
(SUM(unallocated_extent_page_count)*1.0/128)
FROM sys.dm_db_file_space_usage

PRINT 'DB Size ' + CONVERT(VARCHAR(15), @size)
PRINT 'Free Space ' +
CONVERT(VARCHAR(15), @free)

SELECT @result = (@free/@size)*100

PRINT '% Free Space ' +
CONVERT(VARCHAR(15), @result)

D Nella mia azienda vengono archiviati file in formati diversi all'interno di un database, utilizzando le colonne varbinary e image. Ho sentito dire che in SQL Server è integrata una funzionalità che consente di eseguire ricerche in questi formati di file diversi. Come si configura SQL Server a questo scopo?
R La funzionalità in questione è incorporata nel servizio di indicizzazione full-text. Il servizio garantisce la flessibilità necessaria per utilizzare le interfacce IFilter, rendendo possibile lo sviluppo e il caricamento di filtri che consentono di estrarre informazioni utili dai dati proprietari. Le interfacce IFilter vengono anche utilizzate per altri prodotti, come Microsoft® Office Sharepoint® Server, per raccogliere informazioni sui file sottoposti a ricerca per indicizzazione.
Un IFilter viene fornito dal creatore del formato di file o da terze parti. SQL Server contiene già alcuni IFilter, che vengono caricati quando si installa FulltextService (FTS), ad esempio filtri per i file HTML e DOC. È comunque possibile aggiungere altri IFilter, in base alle proprie esigenze. I filtri per Adobe PDF, ad esempio, sono disponibili sul sito Web di Adobe e alla fine del 2007 è stato pubblicato un nuovo pacchetto di filtri per le estensioni di Office System 2007. È sempre necessario conoscere la versione di IFilter da utilizzare. Per esempio, un IFilter progettato per i sistemi a 32 bit non funziona con le installazioni di SQL Server a 64 bit.
Dopo l'esecuzione del pacchetto di installazione sul client, l'IFilter viene in genere registrato nell'ecosistema del sistema operativo. Con i frammenti registrati nel sistema operativo, è sufficiente eseguire poche operazioni per mettere FTS in condizione di caricare i filtri. Dopo l'avvio dello strumento di esecuzione delle query, passare i comandi seguenti:
  • sp_fulltext_service 'load_os_resources',1 (questa consentirà a FTS di caricare i frammenti registrati per l'elaborazione, compresi i componenti come wordbreaker e stemmer).
  • sp_fulltext_service 'verify_signature',0 (con questa istruzione si eviterà di controllare con SQL Server se i filtri utilizzati sono firmati, poiché molti fornitori non firmano i propri filtri secondo lo standard).
  • Riavviare l'istanza di SQL Server e l'istanza di FTS.
  • Creare il proprio indice full-text sulle colonne che hanno la colonna di dati binari come contenuto su cui l'IFilter può eseguire la ricerca per indicizzazione e la colonna di estensioni (vale a dire, la colonna con i tipi di estensione, come DOCX) in cui SQL Server può scegliere il filtro a cui reindirizzare il contenuto.
Ulteriori informazioni in merito sono disponibili all'indirizzo go.microsoft.com/?linkid=7912971.
—Jens Suessmeyer

D Non riesco a connettermi a un SQL Server remoto. È necessario configurare il firewall sul computer client o server?
R Le connessioni remote a SQL Server 2005 possono non riuscire per molte ragioni, ma la configurazione dei firewall è uno dei problemi più comuni. Il blog SQL Protocols (blogs.msdn.com/sql_protocols) è un'eccellente risorsa di informazioni sulle connessioni SQL.
L'installazione predefinita di SQL Server 2005 non consente le connessioni remote. Dal computer su cui si esegue SQL, nel menu Start, scegliere Microsoft SQL Server 2005 | Strumenti di configurazione | Configurazione superficie di attacco di SQL Server. Passare a Configurazione superficie di attacco per servizi e connessioni, scegliere Connessioni remote e scegliere il pulsante di opzione "Usa sia TCP/IP che named pipe". Per applicare le modifiche, riavviare SQL.
Per impostazione predefinita, SQL Server utilizza la porta 1433. Per verificare se la porta è aperta, utilizzare il comando telnet seguente, sostituendo <ipaddress> con l'indirizzo IP reale del computer su cui viene eseguito SQL Server:
telnet <ipaddress> 1433
Se si ottiene una risposta di connessione non riuscita, aprire Windows® Firewall, passare alla scheda Eccezioni, scegliere Aggiungi porta e aggiungere la porta TCP 1433. Il comando telnet ora avrà esito positivo (Telnet non viene installato per impostazione predefinita su Windows Vista®).
—Rick Anderson
Un ringraziamento ai seguenti esperti di SQL Server per il contributo offerto alla redazione dell'articolo:
Justin Langford lavora in Coeo Ltd. ed è uno specialista dell'integrazione di sistemi e un Microsoft Certified Partner che risiede in Inghilterra. Jens Suessmeyer è un consulente per i database in Microsoft e vive in Germania. Rick Anderson lavora presso il Developer User Education in Microsoft. Saleem Hakani è Senior Database Engineer e SQL Server Community Lead in Microsoft.


 Utilit&#224; in primo piano: WCAT (Web Capacity Analysis Tool)
Utilità in primo piano
WCAT (Web Capacity Analysis Tool)
Greg Steen

I registri Web e l'analisi cronologica del traffico possono fornire informazioni importanti sul tipo di traffico che è possibile aspettarsi nel corso del tempo. Tuttavia, in che modo è possibile determinare il volume di traffico che la propria infrastruttura è in grado di gestire? A tal fine, è necessario uno strumento che consenta di spingere l'infrastruttura e il relativo stack di applicazioni fino al punto di rottura. Uno strumento di questo tipo è Web Capacity Analysis Tool (WCAT), un'utilità gratuita e legger per la generazione del carico, che riproduce le richieste HTTP controllate da script su un server Web (o una server farm con bilanciamento del carico) e raccoglie statistiche sulle prestazioni per un'analisi successiva. La versione più recente (6.3.1 al momento della creazione di questo documento) è disponibile per i sistemi Windows x86 e x64 (x86: iis.net/downloads/1466/ItemPermaLink.ashx; x64: iis.net/downloads/1467/ItemPermaLink.ashx) e fornisce il supporto per le reti IPv6. Inoltre, WCAT è uno strumento multithreading e supporta più client di test del carico controllati da una singola origine, consentendo di simulare migliaia di utenti simultanei.
Questa utilità consente di riutilizzare i vecchi computer come client di test, ciascuno dei quali può generare più client virtuali (il numero massimo di client virtuali varia in base alle schede di rete e ad altri componenti hardware del computer client). È possibile scegliere richieste HTTP 1.0 o HTTP 1.1, con o senza SSL. Se lo scenario di test lo richiede, è possibile utilizzare l'autenticazione NTLM o di base tramite script per ottenere l'accesso alle aree del sito con restrizioni. Se il sito in uso prevede l'utilizzo dell'autenticazione basata su cookie, form o sessione, è possibile creare la richiesta GET o POST corretta per autenticare l'utente test. WCAT gestisce inoltre qualsiasi cookie configurato nel sito e, pertanto, le informazioni sul profilo e sulla sessione verranno mantenute.
WCAT consente di testare i limiti dell'infrastruttura del sito Web
WCAT consente di testare i limiti dell'infrastruttura del sito Web
WCAT viene fornito con un interessante manuale per l'utente, che mi ha assistito nella creazione di un'applicazione console Microsoft® .NET Framework che generava uno script per il client di test in base ai dati sul traffico dell'utente presenti nella cronologia di controllo del traffico del sito, consentendomi di simulare il traffico reale su una nuova base di codice prima della distribuzione. Se il personale della propria azienda include un programmatore che utilizza il linguaggio C, è possibile creare funzioni personalizzate e gestori di riposta che possono essere chiamati dai file di scenario per adattare le relative funzionalità all'ambiente in uso.
Per utilizzare WCAT, è necessario configurare due file: un file del controller che contiene le impostazioni di test generali, come il numero di client, i client virtuali per ciascun client, i contatori delle prestazioni di cui tenere traccia e il server Web su cui si esegue il test, e un file di scenario che contiene lo scenario di test, i parametri di richiesta predefiniti e qualsiasi riferimento a funzioni e librerie personalizzate.
L'applicazione registra i risultati del test in un file XML a cui è possibile applicare il foglio di stile XSL per ottenere una catalogazione ben organizzata dei risultati quando visualizzati in Internet Explorer®. Il report contiene informazioni di riepilogo, come il numero di transazioni eseguite, le commutazioni di contesto verificatesi, la percentuale di utilizzo di tutte le CPU e il numero totale di errori rilevati. Il report include inoltre una sezione in cui vengono elencati i risultati dei contatori delle prestazioni configurati nel file delle impostazioni (vedere la schermata per un esempio), un'analisi dei tempi di risposta, un report di statistiche per ciascuna transazione, una sezione di scomposizione per ciascun client e informazioni relative alla modalità di configurazione del test. Inoltre, è possibile visualizzare la configurazione hardware del server Web remoto da testare, oltre a un elenco di tutti gli aggiornamenti installati. Questo è un metodo eccezionale per determinare e verificare se una patch avrà effetti significativi sulle prestazioni del sito.
In conclusione, se si gestisce l'infrastruttura di un sito Web, l'utilità WCAT può fornire informazioni importanti sul livello di prestazioni della piattaforma in condizioni di stress prima del rilascio della versione principale successiva.

Greg Steen è un professionista IT oltre ad essere un appassionato imprenditore. È sempre alla ricerca di nuovi strumenti che aiutino a rendere più semplici le operazioni, il controllo della qualità e lo sviluppo per i professionisti IT.


 The Cable Guy: Risoluzione dei problemi relativi all'imposizione di Protezione accesso alla rete
The Cable Guy
Risoluzione dei problemi relativi all'imposizione di Protezione accesso alla rete
Joseph Davies

La nuova piattaforma Protezione accesso alla rete incorporata in Windows Vista, Windows Server 2008 e Windows XP SP3 consente di proteggere la rete Intranet privata implementando la conformità ai requisiti di integrità del computer. I componenti principali di Protezione accesso alla rete sono i client di Protezione accesso alla rete, i punti di imposizione Protezione accesso alla rete e i server criteri di integrità Protezione accesso alla rete.
Un client di Protezione accesso alla rete è un computer in grado di fornire informazioni sullo stato di integrità per la valutazione dell'integrità del sistema. Un punto di imposizione Protezione accesso alla rete è un computer o un dispositivo di accesso alla rete che utilizza Protezione accesso alla rete o può essere utilizzato con Protezione accesso alla rete per richiedere la valutazione dello stato di integrità di un client di Protezione accesso alla rete e imporre restrizioni agli accessi o alle comunicazioni in rete. Un server criteri di integrità Protezione accesso alla rete è un computer che esegue Windows Server® 2008 e il servizio Server dei criteri di rete, che consente di archiviare i criteri dei requisiti di integrità ed eseguire le valutazioni dell'integrità dei client di Protezione accesso alla rete. Il server criteri di integrità Protezione accesso alla rete e i punti di imposizione Protezione accesso alla rete si scambiano le informazioni sull'integrità del sistema e le istruzioni sull'accesso limitato con messaggi server e proxy RADIUS (Remote Authentication Dial-In User Service).
In questo articolo vengono descritti i componenti di un criterio relativo ai requisiti di integrità, viene illustrato come il servizio Server dei criteri di rete elabora le richieste in ingresso per la valutazione di Protezione accesso alla rete e viene spiegato come risolvere i problemi più comuni correlati all'imposizione di Protezione accesso alla rete.

Criteri dei requisiti di integrità
Esecuzione della valutazione dell'integrità di Protezione accesso alla rete
Il servizio Server dei criteri di rete sul server criteri di integrità Protezione accesso alla rete prevede l'utilizzo del seguente processo per eseguire una valutazione dell'integrità:
  1. Il servizio Server dei criteri di rete confronta il messaggio di richiesta in ingresso con l'insieme configurato dei criteri di richiesta di connessione. Per Protezione accesso alla rete, il messaggio di richiesta deve essere conforme a un criterio di richiesta di connessione che specifica che il servizio Server dei criteri di rete deve eseguire l'autenticazione e l'autorizzazione a livello locale.
    2. Il criterio di richiesta di connessione può inoltre imporre requisiti di connessione. Ad esempio, per l'imposizione 802.1X e VPN, il criterio di richiesta di connessione richiede l'utilizzo di un metodo di autenticazione basato sul protocollo PEAP (Protected Extensible Authentication Protocol). Se il client che stabilisce la connessione non utilizza il protocollo PEAP, la richiesta di connessione verrà rifiutata.
  2. Il servizio Server dei criteri di rete valuta le informazioni di integrità nel messaggio di richiesta, che è costituito da un rapporto di integrità del sistema (SSoH) contenente informazioni sullo stato di integrità. Il servizio Server dei criteri di rete passa le informazioni sullo stato di integrità alle relative istanze di Convalida integrità sistema installate, che restituiscono le informazioni sulla valutazione dell'integrità al servizio Server dei criteri di rete.
  3. Il servizio Server dei criteri di rete confronta il messaggio di richiesta e le informazioni sulla valutazione dell'integrità restituite dalle istanze di Convalida integrità sistema all'insieme corretto di criteri di rete. Le informazioni sulla valutazione dell'integrità vengono confrontate con la condizione relativa al criterio di integrità dei criteri di rete basati su Protezione accesso alla rete. La condizione relativa al criterio di integrità specifica le condizioni per la conformità o la non conformità ai criteri di integrità. Il servizio Server dei criteri di rete applica il primo criterio di rete corrispondente al messaggio di richiesta.
  4. In base al criterio di rete corrispondente basato su Protezione accesso alla rete e alle impostazioni di Protezione accesso alla rete associate, il servizio Server dei criteri di rete crea una risposta al rapporto di integrità del sistema (SSoHR). Questa risposta contiene le informazioni sulla valutazione dell'integrità restituite dalle istanze di Convalida integrità sistema e indica se il client di Protezione accesso alla rete ha accesso illimitato o limitato e se deve tentare automaticamente di monitorare e aggiornare il relativo stato di integrità.
  5. Il servizio Server dei criteri di rete invia un messaggio di risposta RADIUS con la risposta al rapporto di integrità del sistema al punto di imposizione Protezione accesso alla rete. Se al client è stato concesso accesso limitato, il messaggio di risposta può contenere anche le istruzioni che specificano il livello di restrizione dell'accesso del client di Protezione accesso alla rete.
  6. Il punto di imposizione Protezione accesso alla rete invia la risposta al rapporto di integrità del sistema al client di Protezione accesso alla rete.

Un criterio relativo ai requisiti di integrità è una combinazione di un criterio di richiesta di connessione, uno o più criteri di rete, uno o più criteri di integrità e delle impostazioni di Protezione accesso alla rete per un metodo di imposizione Protezione accesso alla rete. Per creare un criterio relativo ai requisiti di integrità, utilizzare la procedura guidata per la configurazione di Protezione accesso alla rete nello snap-in Server dei criteri di rete (per ulteriori informazioni sul processo di valutazione, vedere l'intestazione laterale "Esecuzione della valutazione dell'integrità di Protezione accesso alla rete).
Criteri di richiesta di connessione Questi criteri sono set ordinati di regole che consentono al servizio Server dei criteri di rete di determinare se una richiesta di connessione in ingresso deve essere elaborata localmente o deve essere inoltrata a un altro server RADIUS. Un server criteri di integrità Protezione accesso alla rete elabora le richieste di connessione localmente.
Le richieste RADIUS in ingresso dai punti di imposizione Protezione accesso alla rete basati su Windows® possono contenere un tag di origine che specifica il tipo di punto di imposizione Protezione accesso alla rete, come un server DHCP (Dynamic Host Configuration Protocol) o un server VPN (Virtual Private Network).
Se il messaggio di richiesta in ingresso contiene un tag di origine, il servizio Server dei criteri di rete sul server criteri di integrità Protezione accesso alla rete tenta di rendere conforme la richiesta solo ai criteri di richiesta di connessione con un'origine corrispondente (tutti gli altri criteri di richiesta di connessione vengono ignorati). Se il messaggio di richiesta in ingresso non contiene un tag di origine, il servizio Server dei criteri di rete tenta di confrontare la richiesta con i criteri di richiesta di connessione con un'origine non specificata (tutti gli altri criteri di richiesta di connessione che specificano le origini vengono ignorati).
Ad esempio, le richieste in ingresso da un server DHCP abilitato all'utilizzo di Protezione accesso alla rete specificano un tag di origine di DHCP. Il servizio Server dei criteri di rete tenta di rendere le richieste del server DHCP conformi ai criteri di richiesta di connessione con l'origine di DHCP. Le richieste in ingresso da punti di accesso wireless e commutatori 802.1X non specificano un tag di origine. Il servizio Server dei criteri di rete tenta di rendere queste richieste conformi ai criteri di richiesta di connessione senza un'origine specificata.
Il criterio di richiesta di connessione utilizzato per la valutazione dell'elaborazione locale o remota rappresenta il primo criterio di richiesta di connessione corrispondente nell'elenco ordinato del sottoinsieme di criteri relativi alla richiesta in ingresso. Se non corrisponde ad alcun criterio di richiesta di connessione, la richiesta verrà rifiutata.
Criteri di rete Questi criteri sono set ordinati di regole che specificano le circostanze in cui i tentativi di connessione corrispondenti ai messaggi di richiesta in ingresso vengono autorizzati o rifiutati. Per ciascuna regola, esistono un'autorizzazione di accesso che concede o nega l'accesso, un insieme di condizioni, una serie di vincoli e impostazioni di criteri di rete. Se una connessione viene autorizzata, le impostazioni e i vincoli dei criteri di rete possono specificare una serie di restrizioni di connessione. Per Protezione accesso alla rete, i criteri di rete possono specificare una condizione relativa ai criteri di integrità per controllare i requisiti di integrità e le impostazioni dei metodi di imposizione.
Analogamente ai criteri di richiesta di connessione, i criteri di rete utilizzano un tag di origine per determinare i criteri di rete a cui rendere conforme la richiesta in ingresso. Se il messaggio di richiesta in ingresso contiene un tag di origine, il servizio Server dei criteri di rete tenta di rendere conforme la richiesta solo ai criteri di rete con un'origine corrispondente (tutti gli altri criteri di rete vengono ignorati). Se il messaggio di richiesta in ingresso non contiene un tag di origine, il servizio Server dei criteri di rete tenta di rendere conforme la richiesta ai criteri di rete con un'origine non specificata (tutti gli altri criteri di rete che specificano le origini vengono ignorati).
Il criterio di rete utilizzato per l'autorizzazione o la valutazione dell'integrità rappresenta il primo criterio di rete corrispondente nell'elenco ordinato del sottoinsieme dei criteri relativi al tentativo di connessione. Se non è conforme ad alcun criterio di rete, la richiesta verrà rifiutata.
Criteri di integrità Questi criteri consentono di specificare i requisiti di integrità in termini di istanze di Convalida integrità sistema installate, che vengono utilizzate nella valutazione dell'integrità, e di determinare se una o tutte le istanze di Convalida integrità sistema selezionate devono avere esito positivo o negativo sui client di Protezione accesso alla rete. Ad esempio, un criterio di integrità per i client di Protezione accesso alla rete conformi può specificare che il client deve superare tutti i controlli di integrità. Un criterio di integrità per i client di Protezione accesso alla rete non conformi può specificare che il client non deve superare almeno un controllo di integrità o tutti i controlli di integrità.
Impostazioni di Protezione accesso alla rete Queste impostazioni sono costituite dalla configurazione delle istanze di Convalida integrità sistema installate nel server criteri di integrità Protezione accesso alla rete per i requisiti di integrità e le condizioni di errore, nonché dai gruppi di server di monitoraggio e aggiornamento, che specificano i gruppi di server accessibili ai client di Protezione accesso alla rete non conformi con accesso di rete limitato per i metodi di imposizione DHCP e VPN.

Ambito dei problemi relativi all'imposizione di Protezione accesso alla rete
Durante la risoluzione di un problema, può essere utile adottare un approccio logico. Ecco alcune domande comuni che occorre porsi durante la risoluzione di un problema: Cosa funziona? Cosa non funziona? Qual è la correlazione tra i componenti che funzionano in modo corretto e quelli che non funzionano? I componenti che non funzionano hanno mai funzionato correttamente in precedenza? In tal caso, cosa è cambiato sin da quando funzionavano in modo corretto?
È ovvio che queste domande diventano più specifiche quando si gestiscono i problemi correlati all'imposizione di Protezione accesso alla rete. La connessione o la connettività funzionava in modo corretto prima della distribuzione del metodo di imposizione di Protezione accesso alla rete? Ad esempio, l'isolamento di server o domini IPsec (Internet Protocol security) funzionava in modo corretto prima della distribuzione dell'imposizione IPsec? L'autenticazione 802.1X funzionava in modo corretto prima della distribuzione dell'imposizione 802.1X? L'accesso remoto VPN funzionava in modo corretto prima della distribuzione dell'imposizione VPN? DHCP funzionava in modo corretto prima della distribuzione dell'imposizione DHCP?
Inoltre, uno specifico metodo di imposizione di Protezione accesso alla rete funzionava in modo corretto in precedenza? In tal caso, cosa è cambiato sul client di Protezione accesso alla rete, sul punto di imposizione Protezione accesso alla rete o sul server criteri di integrità Protezione accesso alla rete? Le risposte a queste domande possono indicare il punto da cui partire per la risoluzione dei problemi, consentendo eventualmente di isolare il componente, il livello o la configurazione all'origine del problema.
Per la risoluzione dei problemi generali correlati all'imposizione di Protezione accesso alla rete, è necessario determinare l'ambito del problema. Il primo passaggio consiste nel determinare se il problema è effettivamente correlato all'imposizione di Protezione accesso alla rete. Per l'imposizione IPsec, determinare se il client di Protezione accesso alla rete include l'insieme corretto di criteri IPsec per la protezione dei dati e la negoziazione del peer IPsec. Per l'imposizione DHCP, stabilire se il client di Protezione accesso alla rete può scambiare messaggi DHCP con un server DHCP. Per l'imposizione 802.1X e VPN, determinare se il client di Protezione accesso alla rete può eseguire l'autenticazione. Ad esempio, se i client VPN non possono eseguire l'autenticazione per la connessione VPN, verificare le impostazioni di autenticazione e le credenziali dei client VPN.
Una volta stabilito che il problema identificato è correlato all'imposizione di Protezione accesso alla rete, determinarne la portata. Il problema in questione ha effetto su tutti i client di Protezione accesso alla rete per tutti i metodi di imposizione di Protezione accesso alla rete? Il problema influisce su tutti i client di Protezione accesso alla rete per uno specifico metodo di imposizione? Il problema influisce su tutti i client di Protezione accesso alla rete per uno specifico metodo di imposizione e un punto di imposizione Protezione accesso alla rete? Il problema influisce su tutti i client di Protezione accesso alla rete che sono membri di uno specifico gruppo? Il problema influisce solo su uno specifico client di Protezione accesso alla rete?
Ad esempio, se su tutti i client di Protezione accesso alla rete si verificano problemi relativi a tutti i tipi di metodi di imposizione di Protezione accesso alla rete, è possibile che siano presenti problemi di configurazione sui server criteri di integrità Protezione accesso alla rete. Se su tutti i client di Protezione accesso alla rete si verificano problemi relativi a uno specifico metodo di imposizione di Protezione accesso alla rete, è possibile che siano presenti problemi di configurazione per le impostazioni di Criteri di gruppo per i client di Protezione accesso alla rete o problemi relativi ai criteri dei requisiti di integrità per lo specifico metodo di imposizione di Protezione accesso alla rete sui server criteri di integrità Protezione accesso alla rete. Se solo su specifici client di Protezione accesso alla rete si verificano problemi relativi all'imposizione di Protezione accesso alla rete, è possibile che su tali client siano presenti problemi di configurazione dell'imposizione di Protezione accesso alla rete.

Problemi comuni relativi all'imposizione di Protezione accesso alla rete
Risorse per Protezione accesso alla rete
  • Introduzione a Protezione accesso alla rete
  • Architettura della piattaforma Protezione accesso alla rete
  • Criteri di Protezione accesso alla rete in Windows Server 2008
  • Protezione accesso alla rete di Server dei criteri di rete

Accesso illimitato Quando un client di Protezione accesso alla rete ha accesso illimitato (senza restrizioni), questo potrebbe essere dovuto al fatto che il client di Protezione accesso alla rete è stato valutato come conforme dal server criteri di integrità Protezione accesso alla rete. Questo è esattamente il risultato desiderato. Tuttavia, è possibile che l'accesso illimitato sia stato concesso perché il client di Protezione accesso alla rete non ha ricevuto una risposta al rapporto di integrità del sistema, cosa che in genere accade quando una valutazione di integrità non viene eseguita per il client di Protezione accesso alla rete. Se non viene eseguita alcuna valutazione di integrità di Protezione accesso alla rete, non viene inviata alcuna risposta al rapporto di integrità del sistema al client di Protezione accesso alla rete e quest'ultimo ottiene accesso illimitato.
Ad esempio, un client di Protezione accesso alla rete configurato per l'imposizione DHCP invierà la relativa risposta al rapporto di integrità del sistema al server DHCP. Se il server DHCP che esegue Windows Server 2008 non è configurato per Protezione accesso alla rete, non invierà i messaggi di richiesta della valutazione di integrità a un server criteri di integrità Protezione accesso alla rete. Inoltre, un server DHCP su cui viene eseguito Windows Server 2008 configurato per Protezione accesso alla rete e non in grado di raggiungere un server criteri di integrità Protezione accesso alla rete assegna, per impostazione predefinita, una configurazione dell'indirizzo per l'accesso illimitato.
L'accesso illimitato potrebbe anche essere ottenuto quando il server criteri di integrità Protezione accesso alla rete non esegue una valutazione di integrità, in quanto la richiesta in ingresso è conforme a un criterio di rete che non richiede la valutazione di integrità di Protezione accesso alla rete. Per informazioni sulla determinazione dei criteri di rete che corrispondono alla richiesta di un client di Protezione accesso alla rete, vedere la sezione "Istruzioni dettagliate per la risoluzione dei problemi relativi all'imposizione di Protezione accesso alla rete" in questo articolo.
Accesso limitato Un client di Protezione accesso alla rete con accesso limitato è stato valutato come non conforme dal server criteri di integrità Protezione accesso alla rete. Se il client di Protezione accesso alla rete ha accesso limitato ma dovrebbe avere accesso illimitato, verificare lo stato di integrità del client di Protezione accesso alla rete in base alle impostazioni dei criteri di integrità corrispondenti al criterio di rete a cui la richiesta del client di Protezione accesso alla rete è conforme.
Impossibilità di eseguire il monitoraggio e l'aggiornamento automatici Quando configurati correttamente, i client di Protezione accesso alla rete sono in grado di eseguire automaticamente il monitoraggio e l'aggiornamento del relativo stato di integrità. Se i client di Protezione accesso alla rete non sono in grado di eseguire il monitoraggio e l'aggiornamento automatici, verificare che la casella di controllo Consenti monitoraggio e aggiornamento automatici dei computer client sia selezionata per le impostazioni di Imposizione Protezione accesso alla rete del criterio di rete che soddisfa la richiesta del client di Protezione accesso alla rete.
Un altro problema che può influire sul monitoraggio e sull'aggiornamento automatici è correlato a una situazione in cui il client di Protezione accesso alla rete con accesso limitato non può raggiungere i server di monitoraggio e aggiornamento per scaricare gli aggiornamenti. Per l'imposizione IPsec, verificare che ai server di monitoraggio e aggiornamento siano applicati i criteri IPsec corretti. Per l'imposizione 802.1X, verificare le impostazioni nel criterio di rete corrispondente che prevedono l'assegnazione dell'elenco di controllo di accesso (ACL) o dell'identificatore di rete della rete locale virtuale (VLAN ID) e verificare la configurazione dell'ACL o della VLAN per i commutatori o i punti di accesso wireless. Per l'imposizione VPN o DHCP, controllare le impostazioni nel criterio di rete corrispondente per il gruppo di server di monitoraggio e aggiornamento e assicurarsi che tutti i server di monitoraggio e aggiornamento siano configurati come membri del gruppo. Per l'imposizione DHCP, assicurarsi che le opzioni di ambito di DHCP per i client di Protezione accesso alla rete siano configurate correttamente, come il valore dell'opzione Gateway predefinito per la classe utente di Protezione accesso alla rete.
Valutazione non compatibile con Protezione accesso alla rete Per qualsiasi metodo di imposizione di Protezione accesso alla rete, verificare che il client di imposizione corrispondente sia attivato sul client di Protezione accesso alla rete. Per l'imposizione 802.1X e VPN, verificare che il client di Protezione accesso alla rete esegua il controllo dell'integrità del sistema per verificare che il metodo di autenticazione PEAP sia attivato sia nel criterio di richiesta di connessione che sul client di Protezione accesso alla rete (la casella di controllo Attiva controlli quarantena nella finestra di dialogo Proprietà PEAP è selezionata).
Client di Protezione accesso alla rete senza restrizioni ma non in grado di raggiungere la rete Intranet Per l'imposizione IPsec, verificare che i criteri IPsec per i client di Protezione accesso alla rete conformi e i criteri IPsec dei computer della rete Intranet dispongano di una serie comune di impostazioni di negoziazione e protezione. Per l'imposizione 802.1X, verificare che i criteri di rete per i client di Protezione accesso alla rete conformi specifichino l'ACL o il VLAN ID per la rete Intranet, anziché la rete con restrizioni. Verificare la configurazione dell'ACL o del VLAN ID per la rete Intranet nei commutatori o nei punti di accesso wireless. Per l'imposizione VPN, assicurarsi che non vi siano filtri pacchetti IP configurati nel criterio di rete per i client di Protezione accesso alla rete conformi che limitino il traffico dei client VPN.

Istruzioni dettagliate per la risoluzione dei problemi relativi all'imposizione di Protezione accesso alla rete
Un metodo per risolvere un problema con l'imposizione di Protezione accesso alla rete per uno specifico client di Protezione accesso alla rete consiste nel verificare innanzitutto la configurazione del client di Protezione accesso alla rete, nel controllare il registro eventi del client di Protezione accesso alla rete e nell'accedere al server criteri di integrità Protezione accesso alla rete per determinare in che modo il servizio Server dei criteri di rete ha elaborato la richiesta del client di Protezione accesso alla rete.
Passaggio 1: verificare la configurazione del client di Protezione accesso alla rete La configurazione del client di Protezione accesso alla rete è costituita da servizi Windows, client di imposizione e impostazioni specifiche per l'imposizione di Protezione accesso alla rete. Per visualizzare le informazioni sullo stato e sulla configurazione dei client di Protezione accesso alla rete, utilizzare i comandi netsh nap client show state e netsh nap client show configuration.
Notare che, se le impostazioni dei client di Protezione accesso alla rete vengono fornite da Criteri di gruppo, tutte le impostazioni dei client di Protezione accesso alla rete verranno specificate da Criteri di gruppo, mentre tutte le impostazioni dei client di Protezione accesso alla rete locali verranno ignorate. In tal caso, utilizzare il comando netsh nap client show grouppolicy per visualizzare la configurazione dei client di Protezione accesso alla rete basata su Criteri di gruppo e apportare modifiche tramite Criteri di gruppo.
Per l'imposizione IPsec su un computer che esegue Windows Vista®, utilizzare il comando net start per verificare che i servizi Agente protezione accesso alla rete, Moduli di definizione chiavi IPSec IKE e AuthIP e Agente criteri IPsec vengano avviati. Utilizzare il comando netsh nap client show configuration per verificare che il client di imposizione del componente che applica Protezione accesso alla rete tramite IPSec sia attivato. Se necessario, utilizzare lo snap-in Configurazione client di Protezione accesso alla rete per attivare il client di imposizione del componente che applica Protezione accesso alla rete tramite IPSec o utilizzare il comando netsh nap client set enforcement 79619 enabled. I comandi netsh nap client set enforcement devono essere eseguiti da un prompt dei comandi con privilegi elevati.
Per l'imposizione 802.1X su un computer che esegue Windows Vista, utilizzare il comando net start per verificare che i servizi Extensible Authentication Protocol, Agente protezione accesso alla rete, Configurazione automatica reti cablate (per l'imposizione 802.1X su connessioni cablate) e Configurazione automatica WLAN (per l'imposizione 802.1X su connessioni senza fili) vengano avviati.
Utilizzare il comando netsh nap client show configuration per verificare che il client di imposizione quarantena EAP sia attivato. Se necessario, utilizzare lo snap-in Configurazione client di Protezione accesso alla rete per attivare il client di imposizione quarantena EAP o utilizzare il comando netsh nap client set enforcement 79623 enabled. Verificare che la casella di controllo Attiva controlli quarantena sia selezionata per le proprietà del metodo di autenticazione PEAP per la connessione cablata o senza fili.
Per l'imposizione VPN su un computer che esegue Windows Vista, utilizzare il comando net start per verificare che i servizi Extensible Authentication Protocol, Agente protezione accesso alla rete e Connection Manager di Accesso remoto vengano avviati.
Utilizzare il comando netsh nap client show configuration per verificare che il client di imposizione quarantena accesso remoto sia attivato. Se necessario, utilizzare lo snap-in Configurazione client di Protezione accesso alla rete per attivare il client di imposizione quarantena accesso remoto o utilizzare il comando netsh nap client set enforcement 79618 enabled. Verificare che la casella di controllo Attiva controlli quarantena sia selezionata per le proprietà del metodo di autenticazione PEAP per la connessione VPN.
Per l'imposizione DHCP su un computer che esegue Windows Vista, utilizzare il comando net start per verificare che i servizi Agente protezione accesso alla rete e Client DHCP vengano avviati. Se necessario, utilizzare lo snap-in Servizi o lo strumento Sc.exe per avviare questi servizi e configurarli per l'avvio automatico.
Utilizzare il comando netsh nap client show configuration per verificare che il client di imposizione quarantena DHCP sia attivato. Se necessario, utilizzare lo snap-in Configurazione client di Protezione accesso alla rete per attivare il client di imposizione quarantena DHCP o utilizzare il comando netsh nap client set enforcement 79617 enabled.
Passaggio 2: controllare il registro eventi del client di Protezione accesso alla rete Utilizzare lo snap-in Visualizzatore eventi per controllare gli eventi nel registro eventi creato dal servizio Agente protezione accesso alla rete. Sui computer che eseguono Windows Vista, utilizzare lo snap-in Visualizzatore eventi per visualizzare gli eventi in Registri applicazioni e servizi\Microsoft\Windows\Protezione accesso alla rete\Operativo. Sui computer che eseguono Windows XP con SP3, utilizzare lo snap-in Visualizzatore eventi per visualizzare gli eventi di Protezione accesso alla rete nel registro eventi di sistema.
Utilizzare gli eventi dei client di Protezione accesso alla rete per ottenere l'ID di correlazione per la valutazione dell'integrità dei client di Protezione accesso alla rete. Per trovare l'evento per la valutazione dell'integrità corrispondente sul server criteri di integrità Protezione accesso alla rete, è possibile utilizzare l'ID di correlazione o il nome del computer del client di Protezione accesso alla rete. Nella Figura 1 viene illustrato un esempio di un evento per un client di Protezione accesso alla rete non conforme con l'ID di correlazione.
Figura 1 Esempio di un evento del client di Protezione accesso alla rete di Windows Vista
Figura 1 Esempio di un evento del client di Protezione accesso alla rete di Windows Vista
Passaggio 3: controllare il registro eventi di Server dei criteri di rete Sul server criteri di integrità Protezione accesso alla rete utilizzare lo snap-in Visualizzatore eventi per visualizzare gli eventi nei registri di Windows o nel registro di sicurezza creato dal servizio Server dei criteri di rete. Per visualizzare gli eventi di Server dei criteri di rete, nel Visualizzatore eventi, aprire Visualizzazioni personalizzate e Ruoli server, quindi fare clic su Servizi di accesso e criteri di rete. Per visualizzare un argomento della Guida in linea associato all'evento, fare clic sul collegamento "Guida in linea registro eventi" nella scheda Generale dell'evento.
Agli eventi per la valutazione dell'integrità di Protezione accesso alla rete tipici è associato l'ID di evento 6278 (per l'accesso illimitato) o 6276 (per l'accesso limitato). Trovare l'evento del server criteri di integrità Protezione accesso alla rete corrispondente in base al nome del computer del client di Protezione accesso alla rete (il campo Nome Account nella sezione relativa ai computer client della descrizione dell'evento) o all'ID di correlazione (il campo Identificatore di sessione nella sezione delle informazioni di quarantena della descrizione dell'evento).
Gli eventi del registro eventi di Server dei criteri di rete 6278 e 6276 contengono informazioni sulla valutazione dell'integrità di Protezione accesso alla rete, come il nome del criterio di richiesta di connessione corrispondente (il campo Nome criterio proxy nella sezione dei dettagli di autenticazione della descrizione dell'evento) e il criterio di rete corrispondente (il campo relativo al nome del criterio di rete nella sezione dei dettagli di autenticazione della descrizione dell'evento). Nella Figura 2 viene illustrato un esempio della scheda Dettagli di un ID di evento 6276, con il nome del criterio del prefisso, il nome del criterio di rete e l'ID di correlazione, denominato QuarantineSessionID. Questo è l'evento dei criteri di integrità di Protezione accesso alla rete corrispondente all'evento del client di Protezione accesso alla rete di Windows Vista nella Figura 1.
Figura 2 Esempio di un evento del server criteri di integrità Protezione accesso alla rete
Figura 2 Esempio di un evento del server criteri di integrità Protezione accesso alla rete
Se non è presente alcun evento corrispondente all'evento del client di Protezione accesso alla rete, verificare che il servizio Server dei criteri di rete sia avviato e che il punto di imposizione Protezione accesso alla rete sia configurato correttamente per Protezione accesso alla rete e per l'utilizzo del server criteri di integrità Protezione accesso alla rete come server RADIUS. Verificare che i messaggi RADIUS possano essere inviati tra il punto di imposizione Protezione accesso alla rete e il server criteri di integrità Protezione accesso alla rete.
Se si seguono questi tre passaggi, si sarà sulla strada giusta per determinare il motivo per cui l'imposizione di Protezione accesso alla rete non funziona nel modo previsto. Per ulteriori informazioni su Protezione accesso alla rete, vedere l'intestazione laterale "Risorse per Protezione accesso alla rete".

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


 Windows PowerShell: Firmare qui, prego
Windows PowerShell
Firmare qui, prego
Don Jones

Nell'articolo di gennaio 2008 di Windows PowerShell, ho sottolineato l'importanza della firma digitale negli script di Windows PowerShell. Ho anche descritto scenari in cui un qualsiasi criterio di esecuzione diverso da AllSigned può creare vulnerabilità della sicurezza significative nell'ambiente.
Un argomento che non ho affrontato nel dettaglio è come firmare gli script nella pratica. L'articolo di gennaio è all'indirizzo technetmagazine.com/issues/2008/01/PowerShell. Non è difficile indovinare quale sarà l'argomento di questo mese.

Più di una semplice firma
La parola firma è il termine tecnicamente corretto per indicare l'argomento dell'articolo, ma non è una descrizione davvero soddisfacente di ciò che succede quando si utilizza una firma. Apporre una firma a uno script non significa che lo si approva o autorizza, come accade con un contratto o con una ricevuta della carta di credito. Nel mondo della sicurezza digitale, l'apposizione della firma equivale ad associare la propria identità a qualcosa e a garantire che lo stato o la condizione di tale "qualcosa" non è stato in alcun modo modificato. Tutto si basa sulla crittografia e la crittografia (almeno in questo caso) inizia da una coppia di chiavi di crittografia.
Le chiavi vengono definite come chiavi asimmetriche, perché sono una diversa dall'altra. La coppia è costituita da una chiave privata, accessibile solo a chi la emette, e da una chiave pubblica, che è accessibile a tutti. Questa è una semplificazione, ma fondamentalmente tutto ciò che è crittografato con la chiave privata può essere decrittato esclusivamente con la chiave pubblica corrispondente.
Il processo è più o meno tutto qui e le semplificazioni hanno l'ovvio scopo di far procedere rapidamente la discussione. Si immagini di disporre di uno script di Windows PowerShell® da firmare e di un certificato che contiene una chiave privata da utilizzare per firmare lo script. In Windows PowerShell esiste un cmdlet, che verrà illustrato a breve, che consente di unire script e certificato ed eseguire la firma effettiva. Windows PowerShell in questi casi crittografa lo script utilizzando la chiave privata. La copia crittografata viene visualizzata come del testo senza senso che viene aggiunto alla fine dello script, come una serie di commenti (vedere la Figura 1). Anche l'identità dell'autore dello script viene codificata, ma non crittografata, nei commenti e può essere letta senza ricorrere alla decrittazione.
Figura 1 Blocco della firma memorizzato alla fine dello script
Figura 1 Blocco della firma memorizzato alla fine dello script
In seguito, quando analizza la firma, Windows PowerShell decifra l'identità e la utilizza per ottenere la chiave pubblica. Poiché solo questa specifica chiave pubblica consente di decrittare il resto della firma, per Windows PowerShell è evidente che, se è possibile decrittare la firma, significa che il firmatario corrisponde. Se il firmatario fosse un altro, la chiave pubblica non consentirebbe di decrittare la firma. Dopo aver decrittato la firma, Windows PowerShell confronta lo script alla copia crittografata nella firma. Se corrispondono, la firma viene considerata intatta. Se i due script differiscono, la firma viene considerata violata e non valida.
È così che le firme proteggono gli script di testo dalla modifica non autorizzata. Mentre lo script può essere facilmente modificato, la firma non può essere falsificata in modo da corrispondere allo script modificato senza utilizzare la chiave privata dell'autore, che ne è l'unico possessore.
Anche questa è indubbiamente una semplificazione del processo tecnico che sottende la firma. Nella realtà, le firme possono contenere ulteriori informazioni, come una copia della chiave pubblica, l'autorità di certificazione (CA) che ha emesso le chiavi e così via. Ma la descrizione fatta finora aiuta di certo a delineare le parti importanti del processo e a evidenziare il fatto che una firma protegge lo script dalla modifica non autorizzata.
Un fattore di sicurezza critico è la protezione assoluta della chiave privata, che non deve finire in altre mani. Quando si installa la chiave in Windows, è necessario proteggerla immediatamente con una password, in modo che un processo dannoso non possa utilizzarla contro la volontà del proprietario della chiave. Le smart card garantiscono condizioni di sicurezza ancora migliori, poiché contengono la chiave privata. Con una smart card, la chiave privata non lascia mai la scheda. Invece, i dati da crittografare vengono trasmessi alla smart card mediante l'hardware del lettore, mentre la crittografia e il successivo invio del risultato vengono eseguiti dai circuiti della smart card.

Come ottenere un certificato
Cmdlet del mese: Export-CSV
I frequentatori dei forum di PowerShellCommunity.org spesso chiedono se Windows PowerShell consente di eseguire esportazioni in Microsoft Excel®. Certo che lo consente! Basta usare il cmdlet Export-CSV, dal momento che Excel può aprire, modificare e salvare in modalità nativa i file CSV. Per esportare un elenco di servizi, ad esempio, è sufficiente eseguire Get-Service | Export-CSV MyServices.csv. Infatti, si può aggiungere Export-CSV alla fine di qualsiasi pipeline e tutti gli oggetti della pipeline vengono aggiunti al file CSV specificato. Per impostazione predefinita, Export-CSV aggiunge una riga di intestazione all'inizio del file, che viene quindi utilizzata per specificare il tipo di oggetto esportato. Questa riga è commentata, in modo da non impedire a Excel di aprire il file. Se non si desidera che vengano esportate le informazioni sul tipo, è sufficiente aggiungere il parametro -notype a Export-CSV. Inoltre, è possibile aggiungere il parametro -force per forzare la sovrascrittura di un file CSV esistente con lo stesso nome senza conferme (l'impostazione predefinita prevede una richiesta di conferma) oppure aggiungere il parametro -noClobber per evitare la sovrascrittura di un file esistente.

Per firmare gli script, è necessario un tipo specifico di certificato (un certificato Class III Authenticode Code-Signing) ed è possibile ottenerlo principalmente in tre modi. Il primo consiste nell'utilizzare l'infrastruttura a chiave pubblica, o PKI, interna dell'organizzazione se ne esiste una. Una PKI ben implementata prevede un certificato CA radice considerato attendibile da tutti i computer dell'organizzazione (questo è necessario perché i certificati emessi dall'autorità di certificazione siano utilizzabili nell'organizzazione).
Windows Server® viene fornito con un proprio software di server per certificati fin dai tempi di Windows® 2000 ed è possibile utilizzare tale software per creare una propria PKI. Un'implementazione completa di PKI richiede molta pianificazione, ma quando la PKI serve al solo scopo di emettere certificati di firma codice, non è necessario tanto lavoro. Si può utilizzare semplicemente Criteri di gruppo per inviare in modalità push il certificato CA radice ai computer dell'organizzazione, in modo che venga considerato attendibile.
Una seconda opzione consiste nell'utilizzare un'autorità di certificazione commerciale. Un vantaggio nell'utilizzo di un'autorità di certificazione commerciale è che, se si sceglie una delle autorità più presenti sul mercato, i computer dell'organizzazione sono probabilmente già configurati per accettare come attendibili i certificati dell'autorità di certificazione specifica. In Windows XP vengono accettati come attendibili molti certificati per impostazione predefinita, molti più che in Windows Vista®. Un'autorità di certificazione commerciale molto nota è VeriSign (verisign.com). Esistono altre aziende su cui vale la pena raccogliere ulteriori informazioni, come CyberTrust (cybertrust.com) e Thawte (thawte.com).
La terza opzione per ottenere un certificato di firma codice consiste nel crearsi da soli il proprio certificato utilizzando uno strumento come Makecert.exe. Lo strumento viene fornito con Windows Platform SDK, viene installato in alcune edizioni di Microsoft® Office e può essere trovato in molti altri luoghi. Il vantaggio di un certificato auto-firmato è che è gratuito e non richiede alcuna infrastruttura. Lo svantaggio, tuttavia, è che può essere davvero utilizzato solo sul computer su cui è stato generato. Ma se si tratta solo di attivare l'esecuzione di script sul proprio computer, per dei test o altri esperimenti con la firma del codice, Makecert.exe è un'ottima opzione. La documentazione su questo strumento è all'indirizzo go.microsoft.com/fwlink/?LinkId=108538. È però importante ricordare che, nel corso del tempo, si sono succedute molte versioni di questo strumento, quindi è possibile che sul computer si utilizzi già una versione meno recente che non funziona esattamente come descritto dalla documentazione.
Una volta ottenuto Makecert.exe, è possibile creare un certificato auto-firmato eseguendo del codice come il seguente dalla riga di comando di Windows PowerShell (si spera non più cmd.exe, almeno non i lettori di questo articolo):
makecert -n "CN=MyRoot" -a sha1 –eku
1.3.6.1.5.5.7.3.3 -r -sv root.pvk root.cer
–ss Root -sr localMachine
Quindi eseguire:
makecert -pe -n "CN=MyCertificate" -ss MY
–a sh1 -eku 1.3.6.1.5.5.7.3.3 -iv root.pvk
–c root.cer
Makecert.exe chiede di immettere una password per proteggere la chiave, quindi viene creato il certificato. Si può verificare l'installazione eseguendo questo codice in Windows PowerShell:
gci cert:\CurrentUser\My -codesigning
Viene visualizzato un elenco di tutti gli elementi nel CERT: unità (ovvero l'archivio certificati di Windows) che sono certificati di firma codice. Tutto quanto qui esposto, è anche documentato in Windows PowerShell. Per trovare tale documentazione, eseguire help About_Signing e leggere le schermate visualizzate.

Firma di uno script
A questo punto esistono un certificato e uno script (a fine di test, se ne può creare rapidamente uno, se necessario), ovvero tutto il necessario per firmare uno script. Con Windows PowerShell è davvero molto facile. Immettere:
$cert = @(gci cert:\currentuser\my
-codesigning)[0]
Set-AuthenticodeSignature myscript.ps1 $cert
Con la prima parte si recupera il primo certificato di firma codice installato (se sono stati installati più certificati e si desidera utilizzarne uno diverso dal primo, sostituire "0" con il numero desiderato). Con la seconda parte si firma il file (ovviamente, si deve modificare il nome del file in modo che corrisponda al proprio). Tutto qui! A essere completamente onesti, tuttavia, bisogna dire che il nome del cmdlet Set-AuthenticodeSignature è un po' più lungo del necessario ed è per questo che è stato creato un alias denominato Sign. A questo punto, basta eseguire:
Sign myscript.ps1 $cert
Se si apre lo script, si noterà il blocco della firma inserito alla fine. Provare a eseguire lo script con i propri criteri di esecuzione impostati su AllSigned (Set-ExecutionPolicy AllSigned) e tutto funzionerà a dovere. Provare quindi a modificare lo script e salvarlo, senza firmarlo di nuovo. Windows PowerShell ora semplicemente si rifiuta di eseguire la versione modificata, perché la firma non è più valida.

Vale la pena
Ma alla fine ne vale davvero la pena? È chiedere troppo poter creare uno script con poche attività amministrative senza dover spendere 500 Dollari per un certificato o implementare un elemento di infrastruttura completamente nuovo? Dal punto di vista di un amministratore quale sono io, comprendo i dubbi che sono alla base di queste domande. Ma la risposta è semplice ed è che i vantaggi che si ottengono valgono decisamente lo sforzo fatto per ottenerli.
La sicurezza prevede sempre qualche fatica o problema aggiuntivo da affrontare e risolvere. Il software antivirus può creare fastidi, ma nessuno pensa di poterne fare a meno. I firewall software diventano spesso un ostacolo ma, come noto, non è consigliabile farne a meno. Anche Controllo dell'account utente di Windows Vista a volte è un impiccio, ma rende i computer più sicuri. E l'obiettivo di tutti noi non è proprio la massima sicurezza?
Windows PowerShell è uno strumento potente e, come per qualunque altro strumento, esiste sempre la possibilità che un utente malintenzionato lo utilizzi per i propri fini. È per questo motivo che è importante adottare ogni precauzione per rendere inoffensivi gli utenti malintenzionati.
La firma del codice è la soluzione migliore che si può adottare e non ha molte implicazioni. Io utilizzo, ad esempio, un editor di script grafico che firma automaticamente gli script ogni volta che salvo, quindi la firma del codice per me è praticamente trasparente.
È possibile renderlo altrettanto trasparente anche senza un editor elaborato. Si può creare, ad esempio, un profilo di Windows PowerShell (creare il file Microsoft.PowerShell_profile.ps1 in una cartella denominata WindowsPowerShell, che si trova sotto la cartella dei documenti) e aggiungere quindi questa funzione al profilo:
function sign ($filename) {
  $cert = @(gci cert:\currentuser\my
-codesigning)[0]
Set-AuthenticodeSignature $filename $cert
}
Ora per firmare uno script è sufficiente immettere:
Sign c:\scripts\myscript.ps1
Ovviamente lo script del profilo sarà il primo a essere firmato. L'idea di fondo è eseguire poche operazioni che rendano quanto più comoda possibile la firma degli script, in modo che non risulti un fastidio.
La distribuzione di una PKI a server singolo con l'unico scopo di emettere un certificato di firma codice non è poi un gran lavoro. È utile ricordare, tuttavia, che è davvero necessario progettare una PKI che preveda la protezione del certificato CA radice e garantire il ripristino di emergenza, soprattutto se non sarà utilizzato per altri fini. Se il creatore degli script deve essere l'unico utente autorizzato a eseguire gli script nel proprio ambiente, è sempre disponibile Makecert.exe. L'argomento della guida di Windows PowerShell About_Signing contiene anche informazioni su come proteggere il certificato prodotto da Makecert.exe.

Don Jones è l'autore di Windows PowerShell: TFM and VBScript, WMI, and ADSI Unleashed. È possibile contattarlo tramite il sito Web PowerShellCommunity.org.


 Hey, Scripting Guy!: Il ritorno degli script del database
Hey, Scripting Guy!
Il ritorno degli script del database
Gli Scripting Guy di Microsoft
Scarica il codice per questo articolo: HeyScriptingGuy2008_04.exe (151KB)

Si sa, se gli Scripting Guy hanno un punto debole (ed è bene sottolineare "se"), è probabilmente questo: si preoccupano troppo delle possibili conseguenze delle azioni che intraprendono. Invece di agire nel proprio interesse, capita in genere che antepongano gli interessi degli altri ai propri, senza prendere in considerazione le possibili conseguenze.
Sono un esempio gli articoli relativi agli script di database. A essere sinceri, gli Scripting Guy ritengono che gli articoli sugli script di database non siano affatto semplici da scrivere. Questo non dipende dalla complessità degli script di database; al contrario, si tratta di script piuttosto semplici. Il problema è che gli Scripting Guy non hanno molte opportunità di lavorare con i database; per questo motivo, ogni volta che si accingono a scrivere articoli sui database, devono fermarsi un momento e pensare alle conseguenze di questa azione. Come si sarà intuito un po' di tempo fa, pensare non è certamente un requisito per diventare Scripting Guy.
In realtà, se avessero mai posseduto la "capacità di pensare", probabilmente gli Scripting Guy non esisterebbero affatto.
Dunque, se la scrittura di articoli sugli script di database risulta così difficoltosa per gli Scripting Guy, perché continuare a scriverli? La risposta è semplice: c'è preoccupazione per ciò che potrebbe succedere al resto del mondo se gli Scripting Guy smettessero di scrivere questi articoli. Quando Sir Arthur Conan Doyle decise di far morire Sherlock Holmes (facendolo cadere da un precipizio nel racconto "Il problema finale"), pensò che si stava semplicemente liberando di un personaggio di cui non voleva più scrivere. Invece, si sollevò un'enorme protesta in tutto il mondo. Secondo alcuni reportage, quando appresero la notizia della sua morte, alcune persone a Londra decisero di indossare il lutto. Il racconto "Il problema finale" fu pubblicato su The Strand Magazine nel 1893; in risposta, 20.000 persone annullarono gli abbonamenti alla rivista.
Ahi!
La preoccupazione degli Scripting Guy è che la decisione di smettere di scrivere articoli sugli script di database potrebbe avere un effetto simile in tutto il mondo. L'idea di diventare causa di cotanta disperazione non è sopportabile e tantomeno lo è l'idea che 20.000 lettori annullino l'abbonamento a TechNet Magazine. Quindi, ecco la buona novella: gli Scripting Guy continueranno a scrivere articoli sugli script di database. Quando? Perché non subito?

Aggiunta di record a un database
Nell'articolo di questo mese verranno illustrati alcuni ingegnosi suggerimenti per l'utilizzo dei database. Questi suggerimenti vengono forniti a complemento dei suggerimenti riportati nell'articolo di settembre 2007 (technetmagazine.com/issues/2007/09/HeyScriptingGuy); persino gli Scripting Guy non si abbassano a scrivere lo stesso articolo due volte.
Bisogna comunque ammettere che l'idea è passata per un attimo per le loro menti.
Allora, si inizia illustrando un metodo semplice per aggiungere un record a un database. Si supponga di disporre di un database, C:\Scripts\Inventory.mdb, con una tabella denominata Computers. La tabella Computers contiene i seguenti campi:
  • ComputerName
  • SerialNumber
  • UserName
  • Department
Come è possibile aggiungere un nuovo computer a questo database? Basta guardare il codice riportato nella Figura 1.
Figure 1 Aggiunta di un record alla tabella Computers (Close Figure 1)
Const adOpenStatic = 3
Const adLockOptimistic = 3

Set objConnection = CreateObject("ADODB.Connection")
Set objRecordSet = CreateObject("ADODB.Recordset")

objConnection.Open _
    "Provider = Microsoft.Jet.OLEDB.4.0; " & _
        "Data Source = C:\Scripts\Inventory.mdb"

objRecordSet.Open "INSERT INTO Computers (ComputerName, SerialNumber, UserName, Department)" &  _
    "VALUES ('atl-ws-07', '11234', 'Ken Myer', 'Finance')", _
        objConnection, adOpenStatic, adLockOptimistic
Le prime righe dello script non verranno trattate nei dettagli; pertanto, chi desidera ottenere informazioni generali in merito a tali righe, può fare riferimento ad alcune delle risorse disponibili in Script Center all'indirizzo microsoft.com/technet/scriptcenter. È sufficiente dire che le costanti adOpenStatic e adLockOptimistic vengono utilizzate per controllare il tipo di cursore e il blocco dei record per il recordset. Contrariamente alle apparenze, si tratta di codice molto semplice. Dopo aver completato la creazione delle istanze degli oggetti ADODB.Connection e ADODB.Recordset, utilizzare il seguente comando per aprire il database:
objConnection.Open _
"Provider = Microsoft.Jet.OLEDB.4.0; " & _
"Data Source = C:\Scripts\Inventory.mdb"
In effetti, questo comando consente di aprire un database di Microsoft® Access® 2003. Per aprire un database di Access 2007, utilizzare il seguente comando:
objConnection.Open _
"Provider = Microsoft.ACE.OLEDB.12.0; " & _
"Data Source = C:\Scripts\Inventory.accdb"
Per aprire invece un database di SQL Server®, è possibile utilizzare un comando simile al seguente:
objConnection.Open _
"Provider=SQLOLEDB;" & _
"Data Source=atl-sql-01;" & _
"Trusted_Connection=Yes;" & _ "InitialCatalog=Inventory;" & _
"User ID=fabrikam\kenmyer;Password=34DE6t4G!;"
Tutto il codice illustrato finora è standard e, come si scoprirà presto, quasi tutti gli script di database iniziano con queste stesse righe di codice. La parte su cui occorre focalizzare l'attenzione è la seguente riga:
objRecordSet.Open _
  "INSERT INTO Computers " & _
  "(ComputerName, SerialNumber, " & _
  "UserName, Department) " & _
    "VALUES ('atl-ws-07', 'A14B1234', " & _
      "'Ken Myer', 'Finance')", _
        objConnection, adOpenStatic, _
        adLockOptimistic
In questa riga viene utilizzata una query INSERT INTO per inserire un nuovo record nella tabella Computers. Dopo il nome della tabella, vengono inclusi i nomi di tutti i campi per i quali si dispone di valori, separando i nomi con virgole e racchiudendoli tutti tra parentesi.
È possibile che il lettore si chieda che cosa intendano dire gli Scripting Guy con la frase "tutti i campi per i quali si dispone di valori". Ottima domanda. Si supponga che al nuovo computer non sia stato ancora assegnato un valore Department. Presupponendo che il database consenta di inserire un valore Null nel campo Department, è possibile non includere Department nell'elenco e non assegnare alcun valore a tale campo. In altre parole, si potrebbe scrivere una query simile alla seguente:
objRecordSet.Open _
  "INSERT INTO Computers " & _
  "(ComputerName, SerialNumber, " & _
  "UserName) " & _
    "VALUES ('atl-ws-07', 'A14B1234', " & _
      "'Ken Myer')", _
        objConnection, adOpenStatic, _
        adLockOptimistic
A proposito dell'assegnazione di valori, attenzione agli elementi che seguono i nomi dei campi: la parola chiave VALUES seguita dai valori che si desidera assegnare a ciascun campo (anch'essi racchiusi tra parentesi). I nomi dei campi possono essere elencati in qualsiasi ordine; ad esempio, è possibile inserire ComputerName per primo, anche nel caso in cui non rappresenti il primo campo del database. Questa è una procedura valida per i nomi dei campi, ma non per i valori. I valori devono essere elencati nello stesso ordine in cui vengono visualizzati i campi. Se il primo campo elencato è ComputerName, il primo valore deve corrispondere al nome del computer. In caso contrario, potrebbero verificarsi dei problemi. Si potrebbe finire, ad esempio, con l'assegnare il nome utente o il numero di serie al campo ComputerName.
Come è possibile osservare, l'assegnazione di valori non è un'attività molto complessa; è sufficiente accertarsi di formattare i valori in base al tipo di dati: le date e i valori stringa devono essere racchiusi tra virgolette singole; i valori numerici e booleani non devono essere racchiusi tra virgolette singole.
Se si dispone di un valore che già prevede una virgoletta singola, come il nome O'Brien, è necessario aggiungere alla virgoletta in questione un carattere di escape, raddoppiandola:
'O''Brien'
È folle, ma vero.

Eliminazione di record da un database
Molto interessante: è possibile aggiungere un record a un database eseguendo una singola query SQL. Esiste qualcosa di meglio al mondo? Agli Scripting Guy non viene in mente altro.
In verità un'eccezione esiste, ed è la possibilità di eliminare più record da un database utilizzando una singola query.
Si supponga che la propria azienda decida di eliminare il reparto Human Resources (no, niente scherzi; gli Scripting Guy già hanno abbastanza problemi con l'ufficio del personale di Microsoft). Come è possibile eliminare tutti i computer Human Resources dal database Inventory? Nella Figura 2 viene illustrato un metodo per eseguire questa operazione.
Figure 2 Eliminazione di più record (Close Figure 2)
Const adOpenStatic = 3
Const adLockOptimistic = 3

Set objConnection = CreateObject("ADODB.Connection")
Set objRecordSet = CreateObject("ADODB.Recordset")

objConnection.Open _
    "Provider = Microsoft.Jet.OLEDB.4.0; " & _
        "Data Source = C:\Scripts\Inventory.mdb"

objRecordSet.Open "DELETE * FROM Computers Where Department='Human Resources'", _
    objConnection, adOpenStatic, adLockOptimistic
Come si può osservare, questo specifico script inizia esattamente come lo script per l'aggiunta di un nuovo record: definizione di alcune costanti, creazione di due oggetti e connessione al database Inventory.mdb. In seguito, è sufficiente utilizzare una query DELETE per eliminare tutti i record (*) dalla tabella Computers o almeno tutti i record in cui il campo Department è impostato su Human Resources:
objRecordSet.Open _
  "DELETE * FROM Computers " & _
   "Where Department='Human Resources'", _
    objConnection, adOpenStatic, _
    adLockOptimistic
È semplice quanto cadere in un precipizio.
Senza offesa, Sherlock Holmes.

Aggiornamento di record in un database
Senza dubbio, tutti i lettori concorderanno che sarebbe davvero divertente riuscire a eliminare tutte le tracce del proprio ufficio del personale. Nota per l'ufficio del personale Microsoft: naturalmente sarebbe divertente per altre aziende e il relativo reparto. Non per noi. Gli Scripting Guy non ne trarrebbero alcun piacere personale. Tuttavia, l'eliminazione di tutti i computer HR dal database Inventory potrebbe non essere la migliore cosa da fare. Perché no? In effetti, a meno che i dipendenti dell'ufficio del personale non siano scappati con tutto l'hardware (evento comunque da non escludere), tali computer restano ancora proprietà dell'azienda, il che significa che i computer devono essere comunque riportati nel database. Premesso questo, si può procedere con le seguenti operazioni. Invece di eliminare i record dal database, aggiornare semplicemente ciascun record; il nome del reparto per ciascun computer verrà modificato da Human Resources a None. In altre parole, verrà eseguito lo script illustrato nella Figura 3.
Figure 3 Aggiornamento di record (Close Figure 3)
Const adOpenStatic = 3
Const adLockOptimistic = 3

Set objConnection = CreateObject("ADODB.Connection")
Set objRecordSet = CreateObject("ADODB.Recordset")

objConnection.Open _
    "Provider = Microsoft.Jet.OLEDB.4.0; " & _
        "Data Source = C:\Scripts\Inventory.mdb"

objRecordSet.Open "UPDATE Computers Set Department = 'None' " & _
    "Where Department = 'Human Resources'", _
    objConnection, adOpenStatic, adLockOptimistic
L'unico elemento di diversità in questo script è la query SQL. In questo caso, viene utilizzata una query UPDATE per aggiornare i record nella tabella Computers. Oltre alla parla chiave UPDATE, è necessario aggiungere due parametri che indicano alla query come aggiornare i record e quali record aggiornare:
  • Set Department = 'None'. Con questa impostazione si specifica semplicemente il nuovo valore per il campo Department. È possibile impostare contemporaneamente più valori di campo utilizzando la seguente sintassi: Set Department = 'None', UserName = 'None'. Come è possibile osservare, i campi Department e UserName vengono impostati entrambi su None.
  • Where Department = 'Human Resources'. Questa è una clausola Where standard che indica quali record aggiornare; in questo caso occorre aggiornare tutti i record il cui campo Department sia impostato su Human Resources. L'operazione viene eseguita per un motivo semplice: l'obiettivo non è modificare tutti i record del database, ma solo i record (computer) che in precedenza appartenevano al reparto Human Resources.
Di seguito viene illustrata un'attività molto interessante che è possibile eseguire con le query Update. Si supponga che la propria azienda abbia deciso di dare a ogni dipendente un aumento del 10% (gli Scripting Guy hanno in comune con Sir Arthur Conan Doyle almeno un aspetto: negli scritti entrambi esplorano i meandri più remoti della fantasia). Di seguito è riportato uno script che consente di aprire una tabella denominata Employees e di modificare il campo Salary per ciascun dipendente. Su quale valore viene impostato il campo Salary? La query consente di impostare questo campo sullo stipendio corrente del dipendente x 1,1; in altre parole, offre a ogni dipendente un aumento del 10% (magari fosse così semplice)! Ecco la query:
objRecordSet.Open _
  "Update Employees " & _
  "Set Salary = (Salary * 1.1)", _
    objConnection, adOpenStatic, _
    adLockOptimistic
L'aspetto interessante? Come si può vedere, è possibile eseguire i calcoli nelle query Update. Nel caso in cui si sia deciso di estendere il contratto per tutti i dipendenti temporanei per altri 60 giorni, può essere utile utilizzare una query simile alla seguente:
objRecordSet.Open _
  "Update TempEmployees " & _
  "Set ContractExpirationDate = " & _
  "(ContractExpirationDate + 60)", _
    objConnection, adOpenStatic, _
    adLockOptimistic

Metodi interessanti per il recupero dei dati
A proposito di query che potrebbero rivelarsi utili, è opportuno esaminare alcuni interessanti metodi per il recupero di dati da un database. Di seguito viene riportato uno script semplice ma molto utile. Si supponga che il database Inventory contenga un campo denominato Price, un campo che, ovviamente, rappresenta il prezzo del computer. Si desidera sapere quali sono i cinque computer più costosi all'interno dell'organizzazione? A tal fine, dare un'occhiata allo script di esempio nella Figura 4.
Figure 4 Ordinamento del recordset (Close Figure 4)
Const adOpenStatic = 3
Const adLockOptimistic = 3

Set objConnection = CreateObject("ADODB.Connection")
Set objRecordSet = CreateObject("ADODB.Recordset")

objConnection.Open _
    "Provider = Microsoft.Jet.OLEDB.4.0; " & _
        "Data Source = C:\Scripts\Test.mdb"

objRecordSet.Open "SELECT Top 5 * FROM Computers Order By Price", _
     objConnection, adOpenStatic, adLockOptimistic

objRecordSet.MoveFirst

Do Until objRecordset.EOF
    Wscript.Echo objRecordset.Fields.Item("ComputerName")
    objRecordset.MoveNext
Loop

objRecordSet.Close
objConnection.Close
In questa query SQL sono state eseguite due operazioni: il recordset è stato ordinato in base al prezzo (Order By Price) e si è richiesto solo il prezzo dei primi cinque computer più costosi; questa è la funzione svolta da SELECT Top 5. Se avessimo desiderato un elenco dei 10 computer più costosi, sarebbe stato necessario utilizzare la seguente query:
objRecordSet.Open _
  "SELECT Top 10 * FROM Computers " & _
  "Order By Price", _
    objConnection, adOpenStatic, _
    adLockOptimistic
Notare inoltre che è stato aggiunto il codice necessario per scorrere in ciclo il recordset e visualizzare il nome di ciascun computer. Questo codice non è stato necessario negli script precedenti, poiché questi non prevedevano la restituzione e la visualizzazione di dati.
In alternativa, è possibile ottenere il 10% dei computer più costosi utilizzando la seguente query:
objRecordSet.Open _
  "SELECT Top 10 PERCENT * " & _
  "FROM Computers Order By Price", _
    objConnection, adOpenStatic, _
    adLockOptimistic
Se invece desiderassimo visualizzare i computer più economici? Nessun problema; occorre utilizzare lo stesso approccio, con la differenza che questa volta il recordset verrà elencato in ordine decrescente, ovvero dal prezzo più basso al prezzo più alto. In altre parole, si utilizzerà la seguente query, in cui DESC indica che il recordset deve essere elencato in ordine decrescente:
objRecordSet.Open _
  "SELECT Top 5 * FROM Computers " & _
  "Order By Price DESC", _
    objConnection, adOpenStatic, _
    adLockOptimistic
Visto? Queste query sono davvero utili.
Ecco altre due query molto interessanti. Si supponga che il database contenga un campo denominato Budgeted che tiene traccia dell'importo preventivato in origine per il computer. Si desidera operare un confronto tra il costo effettivo e l'importo preventivato? La seguente query restituisce un elenco di computer con un costo superiore all'importo preventivato:
objRecordSet.Open _
  "SELECT * FROM Computers " & _
  "Where (Budgeted < Price)", _
    objConnection, adOpenStatic, _
    adLockOptimistic
Allo stesso tempo, la query calcola il prezzo medio di tutti i computer (SELECT AVG(Price) FROM Computers), quindi restituisce un elenco di tutti i computer con un costo inferiore al prezzo medio:
objRecordSet.Open _
  "SELECT * FROM Computers " & _
  "WHERE Price < " & _
  "(SELECT AVG(Price) FROM Computers)", _
    objConnection, adOpenStatic, _
    adLockOptimistic
Come è facile notare, nella clausola Where si è utilizzata una query SELECT. Come funziona esattamente? Questo è un argomento da affrontare in un'altra occasione. Tuttavia, rappresenta il primo passo per il recupero di ogni sorta di informazione mediante l'uso di query SQL.

Morale della favola
Come evidenziato all'inizio dell'articolo di questo mese, gli Scripting Guy erano un po' riluttanti a scrivere un altro articolo sugli script di database. Tuttavia, ora sono soddisfatti di averlo scritto, in parte perché contiene alcune query di grande utilità, ma anche per il seguente motivo: se non l'avessero scritto ora, l'avrebbero scritto lo stesso prima o poi. Dopotutto, persino Sir Arthur Conan Doyle fu costretto a "resuscitare" Sherlock Holmes. I primi tentativi di Sir Arthur in tal senso si hanno con la pubblicazione di nuovi racconti su Sherlock Holmes che narravano episodi precedenti alla morte del detective. Dopo tutto, l'autore aveva semplicemente ceduto alla pressione dei suoi lettori, architettando una storia poco credibile in cui spiegava che Sherlock Holmes aveva simulato la propria morte. Così, tutti erano contenti e ogni cosa era assolutamente perfetta.
L'aspetto interessante è che, quando furono pubblicate le avventure più recenti di Sherlock Holmes, 30.000 nuovi lettori sottoscrissero un abbonamento alla rivista The Strand Magazine. Gli editori di Sir Arthur in Gran Bretagna e negli Stati Uniti risposero rendendolo l'autore più pagato al mondo.
Hmmm, Sir Arthur Conan Doyle ha fatto resuscitare un personaggio amatissimo ed è diventato lo scrittore più pagato al mondo; allo stesso modo, gli Scripting Guy hanno fatto "resuscitare" un argomento molto amato, ma senza simulare alcuna morte. I bravi ragazzi di TechNet Magazine lo avranno notato?

Il rompicapo di script del Dottor Scripto
La sfida mensile che verifica non solo le tue capacità di risoluzione dei puzzle, ma anche le tue competenze di scripting.

Aprile 2008: scelta di una lettera
Nel puzzle di questo mese, è necessario inserire le lettere da A a O negli spazi blu per ottenere il nome di una funzione VBScript. Ogni lettera (da A a O) deve essere utilizzata una sola volta e le lettere non sono visualizzate in ordine alfabetico. La lettera può essere inserita all'inizio del nome della funzione, alla fine del nome della funzione o in una posizione qualsiasi all'interno del nome di una funzione. Ad esempio, nella riga seguente la lettera D viene inserita per completare il nome della funzione IsDate:
Ora, prova a inserire le lettere da A a O per ottenere i nomi delle funzioni VBScript in questa griglia:

Il rompicapo di script del Dottor Scripto
Risposta: scelta di una Lettera, aprile 2008

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


 Controllo della protezione: Dove sono le mie informazioni personali?
Controllo della protezione
Dove sono le mie informazioni personali?
Frank Simorjay

È opinione comune ormai che le informazioni personali rappresentino i dati più importanti da proteggere. Tuttavia, per poter garantire un'adeguata protezione delle informazioni personali, è necessario prima essere in grado di determinare quali dati personali sono archiviati nel PC. È facile dire che tutto ciò che è archiviato nel computer è riservato, ma che cosa si intende con "tutto"?
Per far luce su questo argomento, è opportuno esaminare il problema in maggiore dettaglio, suddividendo i tipi di dati che potrebbero essere riservati e determinando la posizione nel computer in cui archiviare tali dati. Innanzitutto, tenere presente che la misura del grado di riservatezza di specifiche informazioni è in genere basata su un giudizio personale. Ad esempio, alcune persone si sentono minacciate se il relativo nome viene visualizzato nei risultati di una ricerca. Ovviamente, a meno che non si sia vissuti sotto una roccia, esiste ormai un'alta probabilità di trovare il proprio nome pubblicato su Internet. Per scoprire se il proprio nome sia pubblicato su Internet, è possibile eseguire una ricerca utilizzando il motore di ricerca preferito. Tenere presente che quanto più il nome è diffuso, tanto più difficile sarà riuscire a trovare istanze che facciano specificamente riferimento al proprio nome. Questo rappresenta senz'altro un vantaggio.
Se si intende eseguire una ricerca del proprio nome su Internet, è opportuno controllare alcuni dei noti siti di networking sociale, come LinkedIn, Facebook e YouTube. È davvero sorprendente la capacità di Internet di archiviare e diffondere informazioni private la cui identificazione richiedeva in precedenza accurate attività di ricerca.
La determinazione del tipo di informazioni che è necessario proteggere richiede l'adozione di un approccio più scientifico rispetto al passato. Un metodo utile e interessante potrebbe essere quello di verificare se il proprio computer contiene informazioni potenzialmente riservate di cui si potrebbe non essere a conoscenza e che sarebbe opportuno proteggere. Anche se si può obiettare che tutte le informazioni personali che possono essere utilizzate per rubare la propria identità sono riservate, in effetti è possibile suddividere le informazioni in due livelli di dettaglio. Esistono informazioni che sono immediatamente disponibili e informazioni più private e considerate generalmente critiche per l'identità personale.
Le informazioni immediatamente disponibili non vengono in genere considerate informazioni personali. Queste informazioni includono il nome, il numero di telefono, l'indirizzo, l'indirizzo di posta elettronica, il sesso e, in molti casi, il posto di lavoro e alcuni dati sul proprio percorso didattico e formativo. Questi elementi sono immediatamente disponibili su Internet e negli elenchi pubblici, come le rubriche telefoniche. La divulgazione di tali informazioni, ad esempio nel caso in cui si consenta accidentalmente a uno spammer di accedere al proprio indirizzo di posta elettronica, può essere fastidiosa, ma da sola non può condurre al furto di identità.
Le informazioni riservate includono dati più privati che forniscono un collegamento alla propria identità personale. I dati che non si desidera vengano divulgati pubblicamente includono il numero di previdenza sociale (o altro identificativo univoco simile rilasciato da un'autorità statale), il numero di conto bancario, i numeri di carte di credito, in particolare quando accompagnati dalla data di scadenza e dall'ID membro della carta, i codici relativi a documenti di identità e le impronte digitali (o altre informazioni biometriche). Se cadono nelle mani sbagliate, queste informazioni possono essere utilizzate per causare gravi danni. È importante controllare dove e come tali informazioni vengono registrate e archiviate sia in Internet che sul proprio PC. A tal fine, in questo articolo verranno illustrati due metodi semplici per individuare tutte le informazioni personali che potrebbero essere archiviate nell'unità disco del proprio sistema.

Individuazione delle informazioni personali sul computer
Le informazioni personali sono sparse un po' ovunque. Non è un'esagerazione ritenere che, a un'attenta ricerca, si potrebbero reperire facilmente informazioni personali anche nel cestino dei rifiuti. La protezione di queste informazioni richiede diligenza e un po' di attenzione. È consigliabile acquistare un buon distruttore di documenti per distruggere qualsiasi documento che contenga informazioni personali.
Ma per quanto riguarda le informazioni personali che si annidano nel PC? L'individuazione di questi dati è un'attività tanto impegnativa quanto la relativa archiviazione in un luogo sicuro. Windows Vista® e diversi altri strumenti di ricerca desktop consentono di semplificare la ricerca di informazioni nel sistema. Tuttavia, è necessario prima stabilire quali informazioni cercare.
Per illustrare il problema, verranno utilizzati due semplici strumenti che consentiranno di fornire rapidamente esempi pratici di ciò che è in gioco. In particolare, si utilizzeranno script con Windows PowerShell®. Windows PowerShell fornisce, tra le numerose caratteristiche di cui dispone, anche funzionalità di corrispondenza delle stringhe. Ai fini di questo articolo, l'attenzione verrà focalizzata sul supporto di questo strumento per la corrispondenza di espressioni regolari. Windows PowerShell (disponibile all'indirizzo microsoft.com/powershell) è un potente strumento che è diventato rapidamente uno standard per le attività amministrative.
Inoltre, nel presente articolo verrà utilizzato findstr.exe per fornire un metodo per gestire i falsi positivi, ovvero per ignorare i file che potrebbero contenere stringhe apparentemente interessanti (a causa della casualità delle stringhe di dati nei file binari) ma che in realtà non sono di alcun interesse. In altre parole, i file non di testo possono essere ignorati per questo esercizio.
Sono stati selezionati due tipi di dati personali: i numeri di previdenza sociale e le informazioni della carta di credito. Questi dati, se archiviati sull'unità disco in testo non crittografato, possono essere individuati facilmente. La struttura e il modello di entrambi i tipi di dati sono sufficientemente univoci per consentire a un semplice script di individuare le informazioni. Tuttavia, questi dati sono anche riservati e, pertanto, sarebbe opportuno evitare di archiviarli nel PC. Per coloro, tuttavia, che sono abituati ad archiviare questo tipo di informazioni, è opportuno assicurarsi che siano protette. Tra breve verranno illustrati alcuni metodi per proteggere le informazioni personali. Questa argomentazione sulle informazioni personali è caratterizzata da alcune limitazioni, poiché esistono altri importanti tipi di informazioni personali che non sono trattati in questo articolo, come i nomi utente e le password.

Ricerca di un numero di previdenza sociale
Di seguito viene riportata una semplice stringa che consente di cercare all'interno di file qualsiasi informazione che sia costituita da un numero di previdenza sociale nel formato XXX XX XXXX o XXX-XX-XXXX. Utilizzando Windows PowerShell, è possibile immettere le seguenti righe:
Get-ChildItem  -rec -exclude *.exe,*.dll |
select-string " [0-9]{3}[-| ][0-9]{2}[-| ]
[0-9]{4}"
In alternativa, è possibile utilizzare findstr.exe per assicurarsi che i file binari non vengano letti per la ricerca mediante il seguente codice:
Get-ChildItem  -rec | ?{ findstr.exe
/mprc:. $_.FullName } | select-string
" [0-9]{3}[-| ][0-9]{2}[-| ][0-9]{4}"
Nell'esempio Get-ChildItem –rec esegue una ricerca ricorsiva nella directory di file, iniziando dalla directory in cui è stato eseguito il comando. Findstr.exe ricerca stringhe nei file, mentre Select-string è la funzione di ricerca di stringhe di Windows PowerShell. Findstr.exe fornisce una funzionalità simile che tuttavia non verrà illustrata nel presente articolo. Inoltre, lo spazio iniziale nell'espressione regolare è stato inserito intenzionalmente. Questo consente di ridurre i falsi positivi eliminando le informazioni non necessarie, ad esempio stringhe del Registro di sistema come HKLM\SOFTWARE\tool\XXX-XX-XXXX.
Nel mio esempio, il criterio di ricerca ha restituito un file di esempio di test che è stato inserito in una sottodirectory e alcuni esempi situati in un file XML che descrivono i modelli di file per i numeri di carta di credito e di previdenza sociale (vedere la Figura 1).
Figura 1 Risultati della ricerca di un formato di numero
Figura 1 Risultati della ricerca di un formato di numero
Nel primo esempio viene utilizzata la funzionalità exclude per eliminare tutti i file .exe e .dll, poiché questi file non forniscono informazioni significative. È possibile che si individuino altri tipi di file che causano falsi positivi. In tal caso, è possibile utilizzare la funzionalità exclude per ottimizzare il processo di ricerca .
Se si desidera cercare solo uno specifico numero di previdenza sociale, è possibile seguire la procedura riportata di seguito sostituendo "123 45 6789" con il proprio numero di previdenza sociale):
Get-ChildItem  -rec | ?{ findstr.exe
/mprc:. $_.FullName } | select-string
"123 45 6789","123-45-6789"
I risultati di questa ricerca sono illustrati nella Figura 2.
Figura 2 Ricerca di uno specifico numero
Figura 2 Ricerca di uno specifico numero

Ricerca delle informazioni della carta di credito
La ricerca delle informazioni della carta di credito è un po' più difficoltosa sia perché i formati possono variare sia perché si desidera limitare i falsi positivi, ovvero i risultati che sono simili a un numero di carta di credito solo per pura casualità. Tuttavia, la ricerca restituirà probabilmente alcune sequenze casuali che hanno solo una mera somiglianza con i numeri di carta di credito.
Le informazioni utilizzate in questo articolo sono state estratte dal saggio "Anatomia dei numeri di carte di credito" di Michael Gilleland in cui vengono fornite come riferimento per la creazione di queste stringhe (visitare il sito all'indirizzo merriampark.com/anatomycc.htm). Ad esempio, la stringa di ricerca di esempio specifica che il primo numero deve essere 4, 5 o 6, dal momento che il numero viene definito come codice MII (Major Industry Identifier) della carta di credito.
Ho creato delle semplici stringhe che consentono di eseguire la ricerca delle carte di credito Discover, MasterCard e Visa. In Windows PowerShell la mia stringa di ricerca è simile all'esempio riportato di seguito:
Get-CchildItem  -rec | ?{ findstr.exe
/mprc:. $_.FullName } | select-string
 "[456][0-9]{15}","[456][0-9]{3}[-| ][0-9]{4}
[-| ][0-9]{4}[-| ][0-9]{4}"
Nell'esempio illustrato nella Figura 3, è stata utilizzata la funzione exclude per eliminare le parole non significative dai tipi di file .rtf, .rbl e .h. Inoltre, il codice di esempio consente di cercare le stringhe relative alle carte di credito che non contengono spazi o trattini. Questo, purtroppo, potrebbe causare un sovraccarico dei dati visualizzati. Di seguito è riportato un comando alternativo per la stessa funzione, ma che non rileva i numeri delle carte che non contengono spazi o trattini:
Figura 3 Utilizzo di exclude per eliminare le parole non significative dai risultati
Figura 3 Utilizzo di exclude per eliminare le parole non significative dai risultati
Get-ChildItem  -rec | ?{ findstr.exe
/mprc:. $_.FullName } | select-string
"[456][0-9]{3}[-| ][0-9]{4}[-| ][0-9]{4}
[-| ][0-9]{4}"
Poiché le carte American Express sono notevolmente differenti, è stata creata una stringa di ricerca modificata per individuare il modello di tale carta. In Windows PowerShell, la stringa di ricerca è simile all'esempio riportato di seguito:
Get-ChildItem -rec | ?{ findstr.exe
/mprc:. $_.FullName } | select-string
"3[47][0-9]{13}","3[47][0-9]{2}[-| ][0-9]{6}
[-| ][0-9]{5}"
Il sovraccarico di dati potrebbe influire anche su questo risultato. Il comando alternativo svolge la stessa funzione ma non rileva i numeri di carte che non contengono spazi o trattini:
Get-childitem -rec | ?{ findstr.exe
/mprc:. $_.FullName } | select-string
"3[47][0-9]{2}[-| ][0-9]{6}[-| ][0-9]{5}"
Durante la redazione dell'articolo, ho eseguito queste ricerche sul mio sistema e sono rimasto sorpreso nello scoprire che diverse istanze del mio numero di previdenza sociale erano state salvate in posizioni in cui non dovevano essere archiviate. Ho scoperto poi che le informazioni si trovavano in una annotazione che avevo scritto un po' di tempo fa e che avevo dimenticato. È il caso di riflettere su ciò che si deve e non si deve annotare.
Se si desidera archiviare questo tipo di informazioni in modo sicuro, provare a utilizzare uno strumento come Password Safe (disponibile all'indirizzo passwordsafe.sourceforge.net). In alternativa, crittografare l'unità disco con uno strumento come Crittografia unità BitLockerTM. Infine, il Data Encryption Toolkit for Mobile PC offre indicazioni e strumenti testati per la protezione dei dati archiviati in un computer portatile. Queste soluzioni saranno almeno utili per rendere un po' più difficile la vita a chi si "intrufola" in un PC alla ricerca di informazioni personali.

Conclusioni
La ricerca delle informazioni personali è piuttosto semplice. Più difficile è essere consapevoli della presenza di tali informazioni. Tuttavia, un malware o un utente malintenzionato che riesce ad accedere al sistema può utilizzare tecniche di individuazione simili per rilevare, con altrettanta facilità, le informazioni utili nel sistema. Prestare particolare attenzione a quando e dove si inseriscono le informazioni personali e, se si è abituati ad archiviare le informazioni, accertarsi di sottoporle a crittografia.
Vorrei ringraziare Matt Hainje per il suo contributo alla risoluzione dei problemi correlati agli script di Windows PowerShell.

Frank Simorjay è Technical Program Manager per il gruppo Microsoft Solution Accelerator - Security and Compliance. È responsabile della progettazione di soluzioni di sicurezza per i clienti Microsoft, partecipa in qualità di relatore a eventi, come Secure World Exposition, di cui è fondatore, tiene corsi di formazione sulla sicurezza e ha partecipato alla stesura di un'ampia gamma di articoli e libri sulla sicurezza. La sua creazione più recente è "Starter Kit Rimozione malware".


 File desktop: Distribuzione di Windows XP con WAIK
File desktop
Distribuzione di Windows XP con WAIK
Wes Miller

È sorprendente quanto possano essere diversi i clienti. In un mondo ideale, tutti i clienti sono sempre nella stessa fase di distribuzione della stessa versione di Windows. In un mondo del genere i test sarebbero davvero semplici da eseguire, ma è evidente che le cose non stanno così. Mentre alcuni sono già alle prese (o magari hanno già finito di distribuire)
con Windows Vista® o si stanno preparando a distribuire con entusiasmo il primo Controller di dominio di sola lettura (RODC) di Windows Server® 2008 di produzione, altri sono ancora nel pieno di un processo di distribuzione a largo raggio di Windows® XP e/o Windows Server 2003 R2.
Qualche giorno fa ho ricevuto un messaggio di posta elettronica da un lettore che chiede: "È possibile utilizzare Windows Automated Installation Kit (WAIK) con Windows XP? In che modo?". Questo articolo è una risposta alla domanda del lettore.

Un altro punto di vista su WAIK
Appena un anno fa, ho scritto un articolo su WAIK, il potente set di strumenti progettato per semplificare la distribuzione di Windows Vista (technetmagazine.com/issues/2007/01/DesktopFiles). WAIK consente ora di distribuire anche Windows Server 2008 e i due sistemi operativi sono caratterizzati da una nuova infrastruttura di installazione, che gli strumenti di WAIK sono in grado di sfruttare al meglio. Per le versioni di Windows precedenti a Windows Vista che prevedono l'installazione automatica o l'impiego di Sysprep, è necessario utilizzare strumenti progettati in modo specifico per tali versioni. Ma è utile proporre WAIK in una nuova prospettiva che ne faccia risaltare gli strumenti da utilizzare per semplificare la distribuzione di Windows XP.
Windows PE 2.0 Per introdurre l'argomento, si può leggere il mio articolo del febbraio 2008 (technetmagazine.com/issues/2008/02/DesktopFiles) sull'avvio doppio con Windows XP e Windows PE 2.0. Essenzialmente, se funziona in quello scenario, Windows PE 2.0 funzionerà anche in questo. La domanda da porsi è: "Ho intenzione di distribuire Windows XP su tutti i sistemi con meno di 512MB di RAM oppure che non supportano l'interfaccia di alimentazione e configurazione avanzata (ACPI) con Windows Vista?". Se la risposta a una delle due parti della domanda è sì, sarà necessario utilizzare Windows PE 1.6 e verificare di potervi accedere come parte di Software Assurance. Solo Windows PE 2.0 e 2.1 oggi sono disponibili gratuitamente e senza limitazioni; per le versioni 1.6 e precedenti invece è richiesto un contratto Software Assurance.
ImageX/WIM ImageX e il Formato Windows Imaging (WIM) sono stati entrambi completamente progettati per l'utilizzo con tutte le versioni di Windows, a partire da Windows 2000, sia su volumi NTFS che FAT, quindi è certamente possibile applicarli per distribuire Windows XP (o Windows Server 2003).
Servizi di distribuzione Windows Servizi di distribuzione Windows (WDS), che sostituisce Servizi di installazione remota (RIS), veniva in origine fornito come versione fuori banda (OOB) in WAIK 1.0 ed è stato aggiornato e integrato in Windows Server 2003 SP2. Ora prevede funzionalità potenziate in Windows Server 2008, ma resta compatibile e applicabile alla distribuzione di Windows XP.
Se si dispone già di un server RIS o di un server WDS in esecuzione in modalità legacy, questa parte della descrizione non è di grande interesse. Ma se si è avviata la transizione a WDS in modalità mista o nativa, è invece il caso di considerare WDS come potenziale parte dello scenario di distribuzione di Windows XP.
Windows System Image Manager (WSIM) WSIM è utilizzabile solo per la distribuzione di Windows Vista e Windows Server 2008. In scenari di distribuzione di Windows Server 2003 o versioni precedenti, WSIM non è di grande aiuto.

Strumenti di distribuzione di Windows XP
Windows XP (come tutte le versioni di Windows da Windows NT® 4.0 fino a Windows Server 2003) può essere distribuito sia mediante un file unattend.txt che tramite una "immagine". Ai fini dell'articolo, l'installazione automatica verrà trascurata, poiché oggi appartiene davvero al passato. Chi desidera sfruttare le potenzialità di WAIK, e in particolare di ImageX, deve prendere in considerazione la distribuzione basata sull'immagine. Quindi, invece di un file unattend.txt, è necessario un file Sysprep.inf, il formato dei file di risposte per Sysprep.
Quando nell'articolo si utilizza il termine immagine, si fa riferimento in senso lato alla modalità di acquisizione dell'immagine del sistema operativo. In passato si sarebbero utilizzati Ghost, PQDI o altri strumenti per la creazione di immagini. Prima di ImageX, Microsoft non aveva mai prodotto strumenti per la gestione di sistema operativo e applicazioni trattati con Sysprep e la relativa copia in uno o più computer di destinazione.
È importante ricordare due punti quando si crea un'immagine di Windows:
  • Non è possibile modificare l'Hardware Abstraction Layer (HAL), fatta eccezione per gli spostamenti da sistemi a processore singolo a sistemi multiprocessore. Come già illustrato negli articoli pubblicati in precedenza, non si può modificare in modo sicuro un'immagine quando si passa da architetture ACPI ad architetture non ACPI.
  • È possibile modificare i controller di archiviazione di massa, anche se molti ritengono erroneamente che ciò non sia possibile. A tal fine, però, è necessario utilizzare Sysprep per installare gli eventuali controller di archiviazione di massa necessari per i computer di destinazione; dopo la distribuzione, si utilizza quindi di nuovo Sysprep per rimuovere tutti i driver inutili rimasti sul sistema di destinazione. Per ora basta questo.
Con questi due problemi in mente, è già possibile preparare un'immagine su un sistema e ottenere che questa funzioni su qualsiasi sistema di destinazione che utilizzi lo stesso HAL o uno compatibile.

Strumenti comuni
Quando si lavora con Windows XP in uno scenario di distribuzione basato sulle immagini, è utile tenere tre strumenti a portata di mano:
Ref.chm Il file di testo di riferimento per l'installazione automatica. È opportuno ricordare che il momento migliore per la configurazione dei componenti facoltativi nelle versioni di Windows precedenti a Windows Vista è prima della creazione delle immagini. Tuttavia, quando è necessario installare componenti facoltativi dopo l'installazione, è sempre possibile eseguire sysocmgr.exe, come illustrato alla pagina support.microsoft.com/kb/222444. Per distribuire Windows XP Tablet PC Edition, seguire la procedura alla pagina go.microsoft.com/fwlink/?LinkId=108589 in modo da creare una sola immagine con cui installare i componenti per Tablet PC sui sistemi applicabili.
Sysprep È il metodo supportato da Microsoft per la creazione di sistemi duplicati. Talvolta si vedono alcuni consigli relativi a strumenti per la modifica dell'identificatore di sicurezza (SID) di terze parti; come sempre, è consigliabile utilizzare solo Sysprep, poiché gli altri strumenti tendono a mancare posizioni SID Windows critiche (specie quelle che non sono scoperte).
Gestione guidata installazione Il metodo più veloce e semplice per creare un file sysprep.inf. Come sempre, accertarsi di disporre della versione corretta, che in genere corrisponde alla versione di Windows che si distribuisce (ad esempio, Windows XP SP2 con gli strumenti di distribuzione di Windows XP SP2).
Questi tre elementi sono tutti disponibili nel CD di Windows XP. Le versioni aggiornate sono disponibili all'indirizzo go.microsoft.com/fwlink/?LinkId=107541.
Può rivelarsi utile anche tap.exe. L'utilità è inclusa tra gli strumenti Windows XP Embedded (go.microsoft.com/fwlink/?LinkId=108590), anche nella versione di valutazione gratuita. Sotto Windows PE, tap.exe restituirà informazioni su tutti i dispositivi Plug and Play (PnP) rilevati da Windows PE e, ciò che più interessa, l'HAL che Windows PE ha scelto per il dispositivo (vedere la Figura 1). Si tratta di un risultato importante, soprattutto perché la logica che Windows PE utilizza per scegliere l'HAL è la stessa logica che verrebbe utilizzata da un'installazione completa di Windows per determinare l'HAL da utilizzare. Tap.exe sotto Windows PE è un metodo utile per scoprire qual è l'HAL consigliato da Windows per un sistema specifico.
Figura 1 L'utilità tap.exe può raccogliere informazioni sull'HAL scelto da Windows PE per un sistema specifico
Figura 1 L'utilità tap.exe può raccogliere informazioni sull'HAL scelto da Windows PE per un sistema specifico

Creazione dell'immagine
Per avviare il processo di distribuzione di un'immagine Windows XP con ImageX (sì, si può utilizzare un altro strumento di creazione di immagini, ma si scoprirà presto perché ImageX è lo strumento ideale per questo particolare processo), è possibile seguire la procedura riportata di seguito.
La prima operazione prevede il recupero di tutti gli strumenti e componenti necessari, tra cui Sysprep, Gestione guidata installazione, ImageX e Windows PE (la versione 2.0 o 1.6, in base alle proprie esigenze e alle possibilità di accesso; se si adotta la versione 2.0 con ImageX, è bene ricordare che si deve utilizzare bootsect.exe con l'opzione /nt52 quando si crea la partizione per garantire che il codice di avvio sia compatibile con Windows XP).
Ovviamente, è necessario anche un computer con Windows XP (qualsiasi SKU) installato, oltre a tutti gli aggiornamenti più recenti per Windows e per gli altri eventuali software installati. Teoricamente, il sistema non ha mai fatto parte del dominio, riducendo così la probabilità di problemi correlati a dominio o rete. Sul sistema devono essere installate solo applicazioni che non provocano problemi durante la creazione delle immagini; niente quindi che memorizzi privatamente nome del computer, SID, dominio o informazioni specifiche dell'utente che Sysprep non sia in grado di sostituire al momento della modifica del SID. Inoltre, è opportuno utilizzare l'HAL che si prevede di distribuire più spesso. Su hardware più recente, questo sarà in genere l'HAL del multiprocessore (MP) ACPI, data la prevalenza di ACPI e multicore (e in precedenza dell'hyperthreading, che pure utilizzava un HAL MP).
A questo punto, è possibile configurare il sistema Windows XP come si desidera che venga utilizzato dagli utenti finali. Installare tutte le applicazioni che la maggioranza degli utenti dovrà utilizzare (e le applicazioni che non si possono installare automaticamente). Installare o rimuovere i componenti facoltativi di Windows, in modo che il sistema sia adatto all'impiego previsto da parte degli utenti finali. Configurare quindi il desktop. Accedere come amministratore e apportare tutte le modifiche necessarie al profilo, compreso lo sfondo del desktop, lo screensaver, il menu Start e così via. Per impostazione predefinita (a partire da Windows XP SP2), Sysprep copia le impostazioni dall'account Administrator nell'account dell'utente predefinito.
Eseguire quindi Gestione guidata installazione (vedere la Figura 2), specificando che si intende creare un nuovo file unattend di Sysprep e automatizzare completamente l'installazione. Si noti come, nei passaggi eseguiti in Gestione guidata installazione, sia necessario immettere un codice "Product Key". Se non è immediatamente disponibile un codice oppure si prevede di immetterlo in un secondo momento (e non si dispone di una chiave per i contratti multilicenza), è possibile specificare la chiave fornita nel file unattend.txt predefinito sul CD di Windows XP o Windows Server 2003 (che consente di portare a termine l'installazione, ma non l'attivazione).
Figura 2 Utilizzo di Gestione guidata installazione per la creazione di un file di risposte di Sysprep
Figura 2 Utilizzo di Gestione guidata installazione per la creazione di un file di risposte di Sysprep
È inoltre necessario fornire un nome del computer. In seguito è anche possibile automatizzare questa operazione utilizzando SQL o un altro meccanismo, ma per ora immettere un valore e utilizzare uno script per sostituire il nome del computer prima di eseguire Sysprep, dopo la distribuzione di WIM sul computer.
È necessario ricordare che, se si fornisce una password per l'account Administrator, questa verrà applicata solo se l'account Administrator esistente nell'immagine non ne dispone già. Nella sezione di aggiunta al dominio non è possibile crittografare le credenziali di aggiunta al dominio. Si deve utilizzare l'account con privilegio minimo per impostare l'account del computer. Infine, è preferibile utilizzare l'opzione Stringa versione in Gestione guidata installazione per tenere traccia della "versione" dell'immagine appena creata.
A questo punto, posizionare il file Sysprep.inf nella directory C:\Sysprep con sysprep.exe e setupcl.exe e aggiungere il seguente file .inf:
[Sysprep]
BuildMassStorageSection = Yes

[SysprepMassStorage]
Eseguire quindi Sysprep –bmsd. In questo modo si modifica il file sysprep.inf e si aggiungono tutti gli ID di archiviazione di massa noti all'installazione di Windows, come illustrato nella Figura 3. È possibile aggiungere altri dispositivi, che possono altrimenti essere aggiunti all'installazione di Windows rieseguendo sysprep –bmsd.
Figura 3 Aggiunta degli ID di archiviazione di massa a sysprep.inf
Figura 3 Aggiunta degli ID di archiviazione di massa a sysprep.inf
Copiare quindi il file sysprep.inf su una condivisione, eseguire sysprep.exe –factory e arrestare il sistema. Riavviare in Windows PE e connettersi a una condivisione UNC (consigliata) utilizzando questo comando:
NET USE Y: \\myserver\myshare
/USER:DOMAIN\USER password
Catturare l'immagine in questo modo:
ImageX /capture C: Y:\NewImage.wim
"Factory Mode capture from 4/1/2008"
Arrestare quindi il sistema.
A questo punto si dispone di un'immagine pronta a essere aggiornata in modalità produttore computer. Non è necessario approfondire qui l'argomento ma, detto in breve, la modalità produttore computer è la modalità più sicura per conservare le immagini fino a quando queste non sono pronte per essere acquisite per la distribuzione. Per ulteriori informazioni, consultare la documentazione su deploy.cab di Windows XP menzionata in precedenza.
Non appena si è pronti per preparare le immagini per la distribuzione, vale a dire, una volta pronti all'implementazione, avviare il sistema in Windows PE e utilizzare Diskpart per creare le partizioni desiderate. Formattare le partizioni con il comando format e utilizzare bootsect.exe come necessario per applicare il codice di avvio precedente a Windows Vista (/nt52). A questo punto, connettersi a una condivisione UNC (o passare alla directory che contiene le immagini) come segue:
NET USE Y: \\myserver\myshare
/USER:DOMAIN\USER password
Applicare quindi l'immagine in questo modo:
ImageX /apply Y:\NewImage.wim C: 1
Infine, riavviare in modalità produttore computer ed eseguire gli aggiornamenti necessari all'immagine (si deve utilizzare un file winbom.ini; per informazioni vedere ref.chm nel deploy.cab). Winbom.ini deve sempre contenere le righe seguenti, che consentono di sigillare l'immagine in modo che sia pronta a eseguire l'installazione minima al riavvio successivo:
[FACTORY]
ResealMode = Mini
Al termine, arrestare il sistema. Ripetere le operazioni precedenti eseguite per acquisire l'immagine, ma ora modificare il comando di acquisizione come segue:
ImageX /append C: Y:\NewImage.wim "Resealed
and ready for deployment – captured 4/4/2008"
Quando si utilizza /append, si risparmia una quantità considerevole di spazio. Così si combinano la modalità produttore computer e le immagini risigillate, in modo che sia possibile passare agevolmente da una all'altra. È possibile anche utilizzare /delete per eliminare le immagini che nel corso del processo si è deciso di non utilizzare più. Questa operazione però non consente di risparmiare spazio, poiché prevede solo l'eliminazione del riferimento all'immagine di volume specificata. Per cancellare lo spazio non utilizzato, è necessario esportare tutte le immagini di volume che si desidera conservare.
Ora è chiaro in che modo WAIK, sebbene sia stato progettato e supportato principalmente per Windows Vista e Windows Server 2008, possa aiutare chi intende distribuire le versioni più recenti o le versioni precedenti di Windows. Anche se è necessario utilizzare una combinazione di strumenti per Windows XP e strumenti di WAIK (di certo ImageX e, probabilmente, Windows PE 2.0), Microsoft ora fornisce tutto il necessario per iniziare a distribuire qualsiasi versione di Windows.

Wes Miller è un Senior Technical Product Manager di CoreTrace (www.CoreTrace.com) di Austin, Texas. In passato ha lavorato per Winternals Software e per Microsoft in qualità di Program Manager. È possibile contattarlo all'indirizzo technet@getwired.com.


 Taccuino: Un'iniziativa meravigliosa
Taccuino
Un'iniziativa meravigliosa
Neil Fawcett

Si immagini di avere 5.000 computer in magazzino appena rigenerati e che alcuni clienti siano già pronti ad acquistarli. L'hardware rinascerà a nuova vita, ma il sistema operativo? Questo è un problema completamente diverso. La copia è legale? Tutti i computer dispongono anche di un sistema operativo? È possibile rivenderli?
Il nuovo programma commerciale Microsoft Authorized Refurbisher (MAR) è una soluzione per tutti i problemi. In apparenza, questo nuovo progetto deriva da un concetto molto semplice: aiutare le aziende commerciali a rigenerare i vecchi computer, installare un sistema operativo legale e vendere i prodotti così aggiornati.
Ma gli scopi del programma MAR sono più profondi. Da un punto di vista pragmatico, è un'opportunità commerciale sia per Microsoft che per gli operatori del settore della rigenerazione di computer. Da un punto di vista legale, aiuta a evitare la pirateria informatica (sia accidentale che intenzionale). In una prospettiva ambientalistica, consente di tenere l'hardware ancora sul mercato e lontano dalle discariche. Infine, consente di creare una condotta tramite cui le aziende possono meglio comprendere come funziona l'autorizzazione all'interno di Microsoft, soprattutto quando si tratta di computer che sono più volte passati di mano.
Il programma non è solo vantaggioso per Microsoft e per gli operatori nella rigenerazione dei computer, ma offre molti vantaggi significativi anche ai clienti: questi ottengono computer su cui si sono professionalmente cancellati i dati e preinstallate versioni originali di Windows® XP Home Edition o Windows XP Professional; possono accedere a download, aggiornamenti e funzionalità migliorate; possono accedere infine alle versioni future di Windows. Tutto questo accade con computer che avrebbero potuto facilmente finire in discarica e nelle statistiche che si utilizzano nella lotta contro i rifiuti tossici.
MAR è stato pensato per le aziende in grado di fornire una media di 5.000 computer rigenerati al mese e che, prima di essere ammesse al programma, devono dimostrare di avere già gestito in passato questi volumi di computer. Il programma MAR è stato lanciato in tutto il mondo, aperto ai principali OEM del settore, oltre che ad altri operatori in possesso dei requisiti con sede negli Stati Uniti o in Canada. Tre delle aziende partecipanti sono Redemtech, Techturn e Apto Solutions.
La concessione in licenza di prodotti software nuovi può a volte risultare problematica per venditori e acquirenti, ma il mercato dei computer rigenerati aggiunge un ulteriore livello di complessità alle operazioni consentite con le copie meno recenti di Windows. Con MAR si tenta di ridurre questa complessità per i fornitori di computer rigenerati. Il programma prevede l'utilizzo di una serie di strumenti di installazione, tra cui Refurbisher Preinstallation Kit (RPK), che semplificano le operazioni di preinstallazione di Windows XP su una base diversa di computer rigenerati. Ciascuna licenza viene fornita con un Certificato di autenticità (COA, Certificate of Authenticity) di Microsoft. Un computer rigenerato è sempre dotato del COA corrispondente e l'azienda dispone dei supporti di ripristino originali o dell'immagine di ripristino basata su disco rigido, quindi una nuova licenza di Windows non è necessaria. Tuttavia, MAR è progettato in modo da semplificare il processo per le aziende di rigenerazione dei computer nei casi in cui non esistono supporti o immagini di ripristino.
Il riutilizzo dei computer (dopo una donazione, una rigenerazione o una vendita) offre in dote la grande promessa di aumentare l'accesso alle tecnologie, soprattutto da parte delle persone meno abbienti con scarse possibilità di accesso alle nuove tecnologie. Può risultare d'aiuto anche nel ridurre l'impatto dell'industria tecnologica sull'ecosistema. Infatti, il mercato dei computer usati (definito "mercato secondario dei computer) si è già dimostrato efficace nell'espandere la tecnologia in molte economie in fase di sviluppo.
Il mercato dei computer rigenerati cresce e le previsioni indicano che, se le aziende cercano delle alternative, milioni di unità potranno evitare le discariche. MAR assume un ruolo non solo strategico all'interno di Microsoft, ma aiuta in modo decisivo le grandi aziende a distribuire una soluzione hardware a basso costo in grado di garantire grandi vantaggi agli altri. Alla luce delle questioni ambientali sempre più in primo piano sul pianeta, il corretto smaltimento dei computer non è mai stato più importante. Le iniziative come il programma MAR aiutano a rivitalizzare i computer meno recenti, facilitando l'individuazione di soluzioni tecnologiche a basso costo e alleggerendo la situazione dei rifiuti tossici. La semplice riduzione della complessità nelle concessioni in licenza del software, consente al programma di rendere molto più interessante la soluzione rappresentata da un computer rigenerato. Ulteriori informazioni su programma MAR sono disponibili all'indirizzo microsoft.com/oem/mar.

Neil Fawcett scrive e pubblica da oltre 20 anni per molte pubblicazioni del settore IT. Ha anche partecipato da relatore a numerosi eventi e pubblicato 13 libri su argomenti correlati all'IT. Prima della sua carriera da redattore e scrittore, Neil ha lavorato in Silicon Valley come sviluppatore di software e progettista hardware.


 Windows Confidential: Condivisioni e simili
Windows Confidential
Condivisioni e simili
Raymond Chen

Ti sei mai chiesto perché durante la disinstallazione di un programma, in Windows® viene visualizzato un messaggio in cui si chiede conferma dell'eliminazione di un file che potrebbe impedire la corretta esecuzione di altre applicazioni? Innanzitutto, il messaggio non viene visualizzato dal sistema operativo Windows ma dal programma di disinstallazione. La domanda corretta, pertanto, è: "Perché nel programma di disinstallazione viene visualizzata questa finestra di dialogo"? Si tratta di un esempio eccellente di domanda a cui nessun utente sa rispondere. Cosa ha condotto a una situazione di questo tipo?
Per gestire i conteggi dei riferimenti ai file utilizzati da più applicazioni, come le librerie di runtime MFC, che vengono utilizzate da più programmi non correlati, nel programma di installazione viene creata una voce sotto la chiave del Registro di sistema SharedDLLs. In questa voce vengono elencati il file e il relativo conteggio dei riferimenti. Se è già presente una voce per il file, il conteggio dei riferimenti verrà incrementato. Se non è ancora presente una voce, il conteggio dei riferimenti verrà impostato su uno. Viceversa, quando il programma viene disinstallato, il conteggio dei riferimenti viene decrementato e, quando risulta pari a 0, il file viene eliminato, poiché non è più utilizzato da alcun programma. Questa è almeno la teoria.
Il file si deve eliminare?
Il file si deve eliminare?
Un problema serio di questo modello è che presuppone che tutti accettino di giocare secondo le regole. Ma la tentazione di "barare" è enorme, dal momento che le conseguenze non penalizzano, in genere, l'autore dell'inganno.
Si supponga, ad esempio, che le librerie di runtime MFC utilizzate da un programma vengano copiate dal programma di installazione nella directory di sistema senza aggiornare il conteggio dei riferimenti. In seguito, quando il programma viene disinstallato, le librerie vengono semplicemente eliminate. Ora si consideri la situazione che si verifica quando il suddetto programma tenta di coesistere con un programma che segue le regole. Di seguito viene riportata una serie di eventi di base:
  1. Installazione del programma buono: le librerie vengono installate e il conteggio dei riferimenti viene impostato su 1.
  2. Installazione del programma cattivo: le librerie vengono installate, ma il conteggio dei riferimenti non viene modificato.
  3. Disinstallazione del programma cattivo: le librerie vengono eliminate.
Il risultato di questi eventi è che, a causa dell'eliminazione delle librerie, il programma buono smette di funzionare.
Ecco un altro scenario:
  1. Installazione del programma buono: le librerie vengono installate e il conteggio dei riferimenti viene impostato su 1.
  2. Installazione del programma cattivo: le librerie vengono installate, ma il conteggio dei riferimenti non viene modificato.
  3. Disinstallazione del programma cattivo: il conteggio dei riferimenti è pari a zero e le librerie vengono eliminate.
Il risultato di questo scenario è che il programma cattivo smette di funzionare.
Gli autori del programma buono hanno pensato: "Non riusciamo a impedire al programma cattivo di interferire con le nostre attività, ma possiamo almeno tentare di evitare di interferire noi con il programma cattivo". Quindi, quando è necessario eliminare un file, viene visualizzato un messaggio con cui si richiede all'utente di confermare l'eliminazione del file. Se esiste un programma cattivo che utilizza il file, questo smetterà di funzionare. Dunque, se esiste un programma cattivo, è opportuno specificare di non eliminare il file. Tutti gli utenti sanno qual è la finestra di dialogo a cui mi riferisco. Persino il leggendario Jeffrey Richter ha consigliato questo approccio in un articolo del Microsoft Systems Journal nel 1996.
Purtroppo, l'esecuzione di questa operazione comporta la visualizzazione di un messaggio con una domanda a cui nessun utente saprà dare una risposta corretta
Naturalmente, tutti i "fanatici del controllo" che richiedono che Windows consenta di ignorare l'ultima operazione eseguita dovrebbero accogliere con entusiasmo questa finestra di dialogo. I programmi di disinstallazione offrono un controllo file per file sull'intero processo di disinstallazione. Attenzione quindi a ciò che si chiede... perché si potrebbe anche ottenerlo.

Raymond Chen, The Old New Thing, così come nell'omonimo libro, vengono illustrate la storia di Windows e la programmazione in Win32. Raymond si domanda se la fusione nucleare diventerà realizzabile nel corso della sua vita.