© Copyright Microsoft Corporation, 2002. Tutti i diritti riservati.
Il team responsabile della documentazione di SQL Server non è in condizione di rispondere a domande di supporto tecnico, tuttavia eventuali commenti e suggerimenti degli utenti relativi a questo documento rappresentano una risorsa molto importante e preziosa per il team. È possibile inviare commenti tramite posta elettronica in modo semplice e rapido utilizzando il collegamento disponibile di seguito. I commenti dovranno essere redatti in lingua inglese.
Per inviare commenti e suggerimenti su questo documento fare clic qui: Invia commenti.
1.0 Introduzione
1.1 Panoramica dell'installazione di Componenti database SP3
1.2 Rimozione di SP3
1.3 Identificazione della versione corrente di SQL Server o Analysis Services
1.4 Informazioni aggiuntive su SP3
1.5 Disponibilità della versione aggiornata della Documentazione in linea
1.6 Disponibilità di esempi aggiornati per SQL Server e Analysis Services
2.0 Download ed estrazione di SP3
3.0 Installazione del service pack
3.1 Backup dei database di SQL Server
3.2 Backup del repository e dei database di Analysis Services
3.3 Verifica dello spazio libero per i database di sistema
3.4 Chiusura di applicazioni e servizi prima dell'esecuzione del programma di installazione di SP3
3.5 Installazione di Componenti database SP3
3.6 Installazione di Analysis Services SP3
3.7 Installazione di Desktop Engine SP3
3.9 Riavvio delle applicazioni
3.10 Installazione in un cluster di failover
3.11 Installazione su server replicati
3.12 Applicazione di SP3 a database o filegroup di sola lettura
4.0 Considerazioni aggiuntive sull'installazione
4.2 Ridistribuzione di Data Access Components SP3
5.1 Miglioramenti relativi a Componenti database e Desktop Engine
5.1.1 Utilizzo di caratteri cinesi, giapponesi o coreani con Componenti database SP3
5.1.2 Rimozione dei gruppi di hash
5.1.3 Aggiunta di opzioni per affinity mask
5.1.4 Viste indicizzate filtrate
5.1.5 Ricostruzione dei cataloghi full-text dopo l'installazione
5.1.6 Modifica della sintassi del comando sp_change_users_login
5.1.7 Accesso ad hoc ai provider OLE DB disattivato per impostazione predefinita
5.1.8 Nuova opzione SqlServerLike per il provider
5.1.9 Messaggi di errore aggiuntivi per le query distribuite
5.1.10 Nuova funzione fn_get_sql che restituisce l'istruzione SQL
5.1.11 Concatenamento della proprietà tra database
5.1.12 Miglioramento relativo al flag di traccia 1204
5.1.13 Modifiche relative alle autorizzazioni per sp_changedbowner
5.1.14 Modifiche relative alla funzionalità di debug
5.2 Miglioramenti relativi ad Analysis Services
5.2.1 Partizioni remote
5.2.2 Installazione client ridistribuibile aggiornata di Analysis Services
5.2.3 Supporto per i provider degli algoritmi di data mining di terze parti
5.2.4 Installazione di Analysis Services in un computer con file client aggiornati
5.2.5 Aumento del numero massimo di cubi OLAP a cui può fare riferimento un cubo virtuale
5.2.6 Nuova parola chiave DESCRIPTION
5.2.7 Nuova proprietà Restricted Client per Servizio PivotTable
5.2.8 Modifiche relative alla proprietà Safety Options
5.2.9 Migrazione del repository a Meta Data Services disattivata per impostazione predefinita
5.2.10 Modifica delle autorizzazioni per la cartella Data remota
5.3 Miglioramenti relativi alla funzione di replica
5.3.1 Stored procedure personalizzata di aggiornamento per la replica transazionale
5.3.2 Istruzioni UPDATE della replica transazionale su colonne univoche
5.3.3 Restrizioni rimosse dall'elaborazione di snapshot concorrenti
5.3.4 Stored procedure personalizzate per la creazione di script per la replica transazionale
5.3.5 Riorganizzazione dei metadati basata sul periodo di memorizzazione e sulla replica di tipo merge
5.3.6 Problemi relativi al backup e al ripristino per la replica di tipo merge
5.3.7 Ripristino di database replicati da versioni diverse di SQL Server
5.3.8 Nuovo parametro -MaxCmdsInTran per Agente lettura log
5.3.9 Limitazione relativa agli indici cluster non univoci
5.3.10 Nuovo argomento della riga di comando –MaxNetworkOptimization per l'agente snapshot
5.3.11 Nuovo ruolo nella replica di tipo merge
5.3.12 Nuovi requisiti per le sottoscrizioni create da utenti senza diritti di sysadmin
5.3.13 Modifiche relative alle autorizzazioni per le stored procedure
5.3.14 Nuovo parametro per sp_addmergearticle e sp_changemergearticle
5.3.15 Nuova schermata della Configurazione guidata pubblicazione e distribuzione
5.3.16 Modifiche relative al supporto per Gestione sincronizzazione Microsoft Windows
5.3.17 Modifica dei requisiti necessari per il collegamento o il ripristino di un database di replica
5.4 Miglioramenti relativi ad Agente SQL Server
5.4.1 Informazioni sugli account dei log di Agente SQL Server
5.4.2 Modifiche relative alle configurazioni server master/target
5.4.3 Nuova stored procedure estesa di Agente SQL Server
5.4.4 Controllo delle autorizzazioni in Agente SQL Server
5.5 Miglioramenti relativi ai componenti di connettività di SQL Server
5.5.1 Aggiornamenti relativi a Microsoft Data Access Components
5.6 Miglioramenti relativi a Meta Data Services
5.6.1 Visualizzatore metadati ed esportazioni in Unicode
5.6.2 Supporto per l'esecuzione di script disattivato
5.6.3 Nuovo ruolo RepositoryUser per l'accesso alle informazioni del repository
5.7 Miglioramenti relativi a Data Transformation Services
5.7.1 Dimensioni massime delle colonne String non più limitate a 255 caratteri in Creazione guidata DTS
5.7.2 Registrazione del contesto di protezione per pacchetti DTS eseguiti da Agente SQL Server
5.7.3 Miglioramenti relativi all'account delegato di Agente SQL Server
5.7.4 Salvataggio in Meta Data Services disattivato per impostazione predefinita
5.8 Miglioramenti relativi a XML
5.8.1 Convalida migliorata delle espressioni XPath
5.9 Miglioramenti relativi all'API Virtual Backup Device
5.9.1 Acquisizione di più database in un singolo snapshot
5.10 Segnalazione.degli errori
5.11 Miglioramenti relativi a English Query
5.12 DB-Library ed Embedded SQL per C
Questa versione del Service Pack 3 (SP3) di Microsoft® SQL Server™ 2000 è suddivisa in tre parti:
Le tre parti di SP3 possono essere implementate individualmente nel modo di seguito descritto:
Nota Se nello stesso computer sono installate istanze distinte di Desktop Engine e di altre edizioni di SQL Server 2000, è necessario applicare Desktop Engine SP3 alle istanze di Desktop Engine e Componenti database SP3 alle altre istanze di SQL Server 2000.
Per ulteriori informazioni sull'installazione di Desktop Engine, vedere la sezione 3.7 Installazione di Desktop Engine SP3.
Nota Desktop Engine SP3 è l'unico componente del service pack disponibile in portoghese (Brasile), svedese e olandese. SQL Server 2000 Desktop Engine è infatti l'unica versione di SQL Server 2000 disponibile in queste lingue. I componenti di SQL Server 2000 aggiornati tramite Componenti database SP3 o Analysis Services SP3 non sono disponibili in queste lingue. Gli utenti portoghesi, svedesi o olandesi che desiderano applicare SP3 a una versione di SQL Server diversa da Desktop Engine devono scaricare i file di SP3 corrispondenti alla lingua dell'edizione da aggiornare, ad esempio i file in inglese se utilizzano la versione in lingua inglese di SQL Server 2000. Per informazioni su come scaricare il service pack, vedere la sezione 2.0 Download ed estrazione di SP3.
Il programma di installazione di Componenti database SP3 rileva automaticamente la versione di SQL Server 2000 installata nell'istanza di SQL Server 2000 in fase di aggiornamento e quindi aggiorna esclusivamente i componenti installati per tale istanza. Ad esempio, quando viene installato in un computer in cui è in esecuzione SQL Server 2000 Standard Edition, il service pack non cercherà di aggiornare i componenti forniti solo con SQL Server 2000 Enterprise Edition.
Componenti database SP3 può essere installato in un'unica istanza predefinita oppure in un'istanza denominata di SQL Server. Se si desidera aggiornare a SP3 più istanze di SQL Server 2000, è necessario applicare SP3 a ogni istanza. Quando un'istanza in un computer con una o più istanze di SQL Server 2000 viene aggiornata a SP3, verranno aggiornati anche tutti gli strumenti corrispondenti. Non esisteranno copie distinte degli strumenti per ogni istanza.
Il metodo utilizzato per la rimozione di SQL Server SP3 dipende dai componenti di SQL Server 2000 SP3 che si desidera rimuovere.
Quando si installa Componenti database SP3 di SQL Server, per motivi di manutenzione vengono apportate modifiche alle tabelle di sistema e vengono aggiornati i database utente e di distribuzione appartenenti a una topologia di replica. A causa di queste modifiche, la rimozione di SP3 non è un'operazione semplice. Per ripristinare la versione in esecuzione prima dell'installazione di SP3, è innanzitutto necessario disinstallare l'istanza di SQL Server 2000 e quindi installarla nuovamente. Se era in esecuzione un service pack precedente di SQL Server 2000 o erano stati applicati QFE (Quick Fix Engineering), è necessario installare nuovamente tale service pack e riapplicare all'istanza gli eventuali QFE.
Nota Per rimuovere SP3 è necessario avere una copia di backup dei database master, model e msdb creata immediatamente prima dell'installazione di SP3. Per maggiori informazioni, vedere la sezione 3.1 Backup dei database di SQL Server e la sezione 3.2 Backup del repository e dei database di Analysis Services.
Per ulteriori informazioni, vedere Disinstallazione dei componenti di SQL Server 2000 e di Desktop Engine SP3.
Per poter ripristinare la versione di SQL Server Analysis Services precedente all'installazione di SP3, è necessario eseguire il backup della chiave del Registro di sistema HK_LOCAL_MACHINE\Software\Microsoft\OLAP Server e delle relative sottochiavi prima di installare SP3. Quando si disinstalla SP3, è necessario eliminare questa chiave dal Registro di sistema e ripristinare la copia di backup eseguita prima dell'installazione di SP3.
Nota Non è possibile disinstallare gli aggiornamenti a MDAC 2.7 SP1 eseguiti durante l'installazione di SP3.
Per ulteriori informazioni, vedere Disinstallazione di SQL Server 2000 Analysis Services SP3.
Per individuare la versione installata di SQL Server o Analysis Services, utilizzare i metodi illustrati nelle sezioni seguenti.
Per conoscere la versione installata di SQL Server 2000, digitare SELECT @@VERSION o SERVERPROPERTY('ProductVersion') al prompt dei comandi quando si utilizza l'utilità osql o isql oppure nella finestra Query di SQL Query Analyzer.
In modo analogo, è possibile verificare il livello del prodotto di una determinata versione di SQL Server 2000 eseguendo l'istruzione SELECT SERVERPROPERTY('ProductLevel').
Nella tabella seguente sono illustrati la relazione tra il livello e la versione di SQL Server 2000 e il numero di versione restituito da @@VERSION nonché il livello del prodotto restituito da SERVERPROPERTY('ProductLevel').
| Livello e versione di SQL Server 2000 | @@VERSION | ProductLevel |
| SQL Server 2000 RTM | 8.00.194 | RTM |
| Componenti database SP1 | 8.00.384 | SP1 |
| Componenti database SP2 | 8.00.534 | SP2 |
| Componenti database SP3 | 8.00.760 | SP3 |
Se non si è sicuri della versione di SQL Server 2000 in uso, controllare l'ultima riga dell'output restituito dall'istruzione SELECT @@VERSION. Tale riga dovrebbe corrispondere a una delle seguenti:
Desktop Engine on Windows NT 5.0 (Build 2195: Service Pack 2)
Enterprise Evaluation Edition on Windows NT 5.0 (Build 2195: Service Pack 2)
Developer Edition on Windows NT 5.0 (Build 2195: Service Pack 2)
Personal Edition on Windows NT 5.0 (Build 2195: Service Pack 2)
Standard Edition on Windows NT 5.0 (Build 2195: Service Pack 2)
Enterprise Edition on Windows NT 5.0 (Build 2195: Service Pack 2)Nota All'inizio della riga è indicata l'edizione di SQL Server in uso, seguita dal sistema operativo.
È inoltre possibile determinare l'edizione in uso digitando SELECT SERVERPROPERTY('Edition') al prompt dei comandi quando si utilizza l'utilità osql o isql oppure nella finestra Query di SQL Query Analyzer.
Per identificare la versione installata di Analysis Services, procedere nel modo seguente:
| Versione di Analysis Services | Numero di build in Informazioni su |
| SQL Server 2000 Analysis Services RTM | 8.0.194 |
| Analysis Services SP1 | 8.0.382 |
| Analysis Services SP2 | 8.0.534 |
| Analysis Services SP3 | 8.0.760 |
L'elenco delle correzioni contenute in questo service pack si trova nell'articolo 306908 della Microsoft Knowledge Base. Ogni correzione riportata è associata a un articolo specifico della Knowledge Base in cui viene descritto il problema oggetto della correzione. Per ulteriori informazioni relative a una correzione specifica, utilizzare i collegamenti ai relativi articoli della Knowledge Base. Gli articoli (in lingua inglese) sono disponibili nella Knowledge Base del Servizio Supporto Tecnico Clienti Microsoft.
Per cercare un articolo nella Knowledge Base
Eventuali informazioni aggiuntive relative a SQL Server 2000 Service Pack 3 che saranno disponibili successivamente alla redazione di questo documento verranno pubblicate nell'articolo 330022 della Knowledge Base del Servizio Supporto Tecnico Clienti Microsoft (informazioni in lingua inglese).
In questo service pack sono contenuti gli aggiornamenti relativi a Microsoft Data Access Components (MDAC), inclusi gli aggiornamenti per MSXML.
Per ulteriori informazioni, vedere la sezione 5.5.1 Aggiornamenti relativi a Microsoft Data Access Components.
Tutti i problemi relativi alla protezione di SQL Server 2000 SP2 e resi noti pubblicamente sono stati risolti in SP3.
Eventuali QFE per SQL Server 2000 ricevuti dopo il 14 ottobre 2002 quasi sicuramente non sono inclusi in SP3. Rivolgersi al fornitore di fiducia per ottenere gli stessi QFE per SQL Server 2000 SP3.
Gli utenti di Microsoft SQL Server 2000 Windows® CE Edition (SQL Server CE) che hanno aggiornato o intendono aggiornare a SP3 i server di database e di pubblicazione di SQL Server 2000 devono aggiornare i componenti di replica del server nei server Microsoft Internet Information Services (IIS). Il programma di installazione aggiornato degli strumenti per SQL Server CE è disponibile nel sito Web Microsoft (informazioni in lingua inglese).
È disponibile la documentazione aggiornata di SP3. La Documentazione in linea di SQL Server 2000 (aggiornata per SP3) contiene alcune revisioni nonché informazioni sulle novità introdotte in SP3.
È possibile scaricare la Documentazione in linea di SQL Server 2000 (aggiornamento per SP3) dal sito Web Microsoft (informazioni in lingua inglese).
Sono disponibili gli esempi aggiornati di SP3 per SQL Server 2000 e Analysis Services. È possibile scaricare questi esempi dal sito Web Microsoft (informazioni in lingua inglese).
SP3 viene distribuito nei formati seguenti:
Nota I moduli di merge e i file msi necessari per l'installazione di una nuova istanza di Desktop Engine sono inclusi sia nel CD di SQL Server 2000 Service Pack 3 sia nel file ITA_Sql2kdesksp3.exe.
Per il download e l'estrazione dei file di installazione di Componenti database e Analysis Services SP3, seguire le indicazioni seguenti:
Nota Quando si estraggono i file del service pack in una condivisione di rete, il percorso della cartella specificata corrisponde alla cartella in cui è stato eseguito il programma di estrazione automatica.
Nota Alcuni file dei service pack sono file di sistema. Per visualizzarli, in Esplora risorse scegliere Opzioni cartella dal menu Strumenti, quindi nella scheda Visualizzazione selezionare la casella di controllo Visualizza cartelle e file nascosti.
I file di installazione di Componenti database e Analysis Services includono la versione aggiornata della documentazione relativa all'installazione a cui è possibile accedere facendo clic su ? durante l'installazione di SP3. Questa documentazione non aggiorna tuttavia la versione della Documentazione in linea di SQL Server 2000 già installata nel computer. Per informazioni su come ottenere la versione aggiornata della Documentazione in linea di SQL Server, vedere la sezione 1.5 Disponibilità della versione aggiornata della Documentazione in linea. Per accedere alla documentazione aggiornata relativa all'installazione di SQL Server 2000 SP3 senza aggiornare la Documentazione in linea di SQL Server, eseguire il file Setupsql.chm contenuto nella sottocartella \Books della directory sul CD di SP3, della directory locale o della condivisione di rete in cui si trovano i file estratti del service pack.
Per informazioni sul download e sull'estrazione di Desktop Engine SP3, vedere la sezione 3.7 Installazione di Desktop Engine SP3.
Per installare SP3, seguire le istruzioni riportate nelle sezioni seguenti. Alcuni passaggi della procedura non devono essere eseguiti. Ciò dipende da quali tra i componenti e le configurazioni di SQL Server 2000 indicati di seguito si applica il service pack:
Per ogni passaggio della procedura di installazione, sono indicati i componenti per i quali il passaggio deve essere eseguito.
Nota Il service pack è disponibile in lingue diverse. È necessario implementare la versione nella lingua corrispondente a quella del componente di SQL Server da aggiornare.
L'installazione di SP3 avrà esito negativo se uno dei due criteri di protezione seguenti è impostato su Non consentire installazione (Windows XP) o Non consentire l'installazione (Windows 2000):
Se è stata selezionata l'impostazione Non consentire installazione (Windows XP) o Non consentire l'installazione (Windows 2000), è necessario modificarla su Installa senza avvisare (Windows XP) o Installazione invisibile all'utente riuscita (Windows 2000) prima di installare SP3. Se necessario, è possibile ripristinare l'impostazione originale del criterio dopo l'installazione.
Nota Non consentire installazione (Windows XP) o Non consentire l'installazione (Windows 2000) non è l'impostazione predefinita per questi criteri di protezione.
Se si installa il service pack in una versione non finale di Microsoft Windows .NET Server build 3683 o successiva, verrà visualizzato il messaggio di errore seguente:
Il software che si sta installando non ha superato il testing del programma Windows Logo che consente di verificarne la compatibilità con Windows. Il software non verrà installato. Contattare l'amministratore di sistema.È possibile ignorare il messaggio e continuare l'installazione facendo clic su OK.
Nota Questo messaggio blocca un'eventuale installazione automatica.
Prima di installare SP3 nella versione francese di Windows NT 4.0, seguire le istruzioni riportate nell'articolo 259484 della Knowledge Base del Servizio Supporto Tecnico Clienti Microsoft (informazioni in lingua inglese). Per istruzioni su come eseguire ricerche nella Knowledge Base, vedere la sezione 1.4 Informazioni aggiuntive su SP3.
Se si applica Componenti database SP3 a un'istanza di SQL Server in un computer in cui è installato Analysis Services, l'installazione potrebbe avere esito negativo quando si esegue lo script Sp3_serv_uni.sql. In questo caso, riavviare il computer ed eseguire nuovamente il programma di installazione.
Con l'installazione di SP3 non vengono aggiornati i database utente, ad eccezione di quelli coinvolti attivamente nelle topologie di replica. Gli altri database utente non vengono modificati in seguito all'installazione di SP3. Ad esempio:
Con l'installazione di SP3 vengono aggiornati i database utente appartenenti a una topologia di replica. Prima di installare SP3, assicurarsi che i database e i filegroup di replica supportino operazioni di scrittura e che all'account utente in base a cui viene eseguito il programma di installazione siano associate le autorizzazioni necessarie per l'accesso ai database. Per ulteriori informazioni sull'applicazione di SP3 ai database appartenenti a topologie di replica, vedere la sezione 3.11 Installazione su server replicati.
Se durante l'installazione di SP3 vengono rilevati database utente o filegroup che non supportano operazioni di scrittura:
Sono stati rilevati uno o più database e filegroup non modificabili.Tale messaggio può essere ignorato, a meno che alcuni database elencati nel log di installazione non appartengano a una topologia di replica. In tal caso, è necessario modificare gli attributi dei database in modo che supportino operazioni di scrittura e rieseguire l'installazione di SP3 per l'istanza di SQL Server 2000 corrispondente.
Nota Questo messaggio non riguarda le installazioni automatiche. Per ulteriori informazioni sulle installazioni automatiche, vedere la sezione 4.1 Installazioni automatiche.
Per ulteriori informazioni su come configurare un database in modo che supporti operazioni di scrittura, vedere la sezione 3.12 Applicazione di SP3 a database o filegroup di sola lettura. Per ulteriori informazioni sulla reinstallazione di SP3, vedere la sezione 3.14 Reinstallazione di SP3.
Nota Durante l'installazione non viene fatta alcuna distinzione tra database di sola lettura e database non in linea o sospetti. Se durante l'installazione un database o filegroup di replica si trova in una di queste modalità ed è coinvolto in una topologia di replica, è necessario configurare il database in modo che supporti operazioni di scrittura e applicare nuovamente il service pack.
Nota Poiché la presenza di database che non supportano operazioni di scrittura non è più la causa di problemi di installazione, non è necessario annullare la distribuzione dei log prima di eseguire l'aggiornamento a SP3.
Non è possibile installare SQL Server 2000 Service Pack 3 in modalità remota. È tuttavia possibile installare SP3 in modo automatico in più computer Windows NT Server 4.0 tramite Microsoft Systems Management Server. A tale scopo, utilizzare il file di definizione del pacchetto (Smssql2ksp3.pdf) per automatizzare la procedura di creazione di un pacchetto SQL Server in Systems Management Server. Il pacchetto di SQL Server può quindi essere distribuito e installato nei computer in cui viene eseguito Systems Management Server. L'installazione automatica mediante Systems Management Server viene avviata dal file batch Sms2kdef.bat. In questo tipo di installazione, tutte le informazioni sul sistema necessarie vengono rilevate automaticamente, senza nessun intervento da parte dell'utente.
Nota Non è possibile installare Desktop Engine SP3 mediante Systems Management Server.
Le informazioni seguenti sono valide per tutti i componenti, ad eccezione dei componenti client del database.
Prima di installare Componenti database SP3 o Desktop Engine SP3, eseguire una copia di backup dei database master, msdb e model. Durante l'installazione di SP3 vengono infatti apportate modifiche a questi database, che risulteranno pertanto non compatibili con le versioni di SQL Server precedenti a SP3. Le copie di backup saranno necessarie se si decide di reinstallare SQL Server 2000 senza SP3.
È inoltre consigliabile eseguire il backup dei database utente, anche se con SP3 vengono eseguiti aggiornamenti solo nei database utente appartenenti a topologie di replica.
Le informazioni seguenti sono relative solo ad Analysis Services.
Prima di installare Analysis Services SP3, eseguire una copia di backup dei database di Analysis Services eseguendo il backup della cartella Microsoft Analysis Services\Data, installata per impostazione predefinita nella cartella C:\Programmi. Se non è stata eseguita la migrazione del repository di Analysis Services a SQL Server, eseguire una copia di backup del file Msmdrep.mdb, che si trova nella cartella Microsoft Analysis Services\Bin. È inoltre consigliabile salvare le voci del Registro di sistema di Analysis Server eseguendo Regedit.exe e quindi scegliendo Esporta file del Registro di sistema dal menu Registro di sistema per esportare la chiave HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\OLAP Server in un file di backup. Se invece è stata eseguita la migrazione del repository di Analysis Services a SQL Server, prima di installare SP3 eseguire una copia di backup del database contenente il repository. Per ulteriori informazioni, vedere Disinstallazione di SQL Server 2000 Analysis Services SP3.
Le informazioni seguenti sono valide per tutti i componenti, ad eccezione dei componenti client del database e di Analysis Services.
Se per i database master e msdb non è stata selezionata l'opzione Aumento automatico, i database devono disporre di almeno 500 kilobyte (KB) di spazio libero. Per verificare la disponibilità di questo spazio, eseguire la stored procedure di sistema sp_spaceused per il database master o msdb. Se lo spazio non allocato per uno dei database è minore di 500 KB, aumentare le dimensioni del database. Per ulteriori informazioni, vedere "Espansione di un database" nella Documentazione in linea di SQL Server.
Se l'opzione Aumento automatico è stata selezionata per i database master e msdb e nelle unità è disponibile spazio sufficiente, è possibile ignorare questo passaggio.
Per verificare se l'opzione è stata selezionata in SQL Server 2000, aprire SQL Server Enterprise Manager, fare clic con il pulsante destro del mouse sull'icona relativa al database desiderato e quindi scegliere Proprietà. Verificare che la casella di controllo Aumento automatico dimensioni del file sia selezionata.
Per verificare se questa opzione è stata selezionata in Desktop Engine, eseguire le istruzioni SQL seguenti:
Nell'output di queste istruzioni verificare che la colonna growth non includa il valore 0.
Le informazioni seguenti sono valide per tutti i componenti.
Per installare SP3, non è necessario chiudere i servizi. In tal caso, tuttavia, al termine dell'installazione verrà richiesto di riavviare il computer. Se non si riavvia il computer, non sarà possibile avviare i servizi seguenti:
È possibile avviare il programma di installazione senza riavviare il computer chiudendo i servizi e le applicazioni prima di procedere all'installazione di SP3.
Non è possibile chiudere i servizi in un ambiente di cluster. Per ulteriori informazioni, vedere la sezione 3.10 Installazione in un cluster di failover.
Le informazioni seguenti sono valide per tutti i componenti, ad eccezione di Desktop Engine e Analysis Services.
Eseguire lo script Setup.bat da una delle posizioni seguenti:
Nota Per installare Componenti database da una condivisione di rete, è necessario eseguire una delle operazioni seguenti:
Durante l'installazione viene visualizzata una finestra di dialogo in cui viene richiesto di specificare se, ad esempio, si desidera utilizzare l'autenticazione di SQL Server oppure quella di Windows. Se si sceglie di utilizzare l'autenticazione di SQL Server, è necessario specificare la password per l'amministratore di sistema (sa login). Se invece si sceglie di utilizzare l'autenticazione di Windows, è necessario che sia in esecuzione il programma di installazione mentre si accede a Windows utilizzando un account di accesso di Windows. Questo account di accesso deve appartenere al ruolo predefinito del server sysadmin per l'istanza di SQL Server 2000 in fase di aggiornamento.
Durante l'esecuzione del programma di installazione verranno eseguite le operazioni seguenti:
Nota La modifica della password viene eseguita immediatamente, anche nel caso in cui l'installazione abbia esito negativo.
Nota I passaggi precedenti devono essere eseguiti solo quando si applica SP3 a database o filegroup che non supportano operazioni di scrittura e che appartengono a una topologia di replica. Per ulteriori informazioni, vedere la sezione 3.12 Applicazione di SP3 a database o filegroup di sola lettura.
Nella finestra di dialogo Modalità di autenticazione non vengono inseriti i valori predefiniti delle impostazioni correnti per l'installazione. Le impostazioni predefinite di questa finestra sono:
Nota Prima di modificare la modalità di autenticazione o la password per l'amministratore di sistema, assicurarsi che l'eventuale modifica non abbia un impatto negativo sulle applicazioni esistenti. Ad esempio, se per un'istanza di SQL Server si sostituisce la modalità di autenticazione mista con la modalità di autenticazione di Windows, le applicazioni esistenti che eseguono tentativi di connessione con l'autenticazione di SQL Server potranno stabilire la connessione solo dopo l'impostazione dell'autenticazione di Windows. Inoltre, se la password per l'amministratore di sistema viene modificata, le applicazioni o i servizi di amministrazione che utilizzano la vecchia password potranno connettersi solo dopo averli configurati per l'utilizzo della nuova password.
Importante Per ragioni di sicurezza, è consigliabile non utilizzare una password vuota per l'amministratore di sistema.
Per ogni operazione eseguita viene inserito un record nel file Sqlsp.log, che si trova nella directory Windows del computer in cui viene eseguito il programma di installazione. Se si esegue l'aggiornamento di più istanze, nel log viene registrato solo l'aggiornamento più recente.
Nella finestra di dialogo Elenco di controllo compatibilità con versioni precedenti sono elencati i problemi di compatibilità con versioni precedenti che si potrebbero verificare durante l'installazione del service pack. I problemi visualizzati nell'elenco di controllo variano in base alla configurazione dell'istanza di SQL Server 2000 in fase di aggiornamento.
Possono verificarsi i problemi di compatibilità seguenti:
Nota Non è consigliabile attivare questa funzionalità per tutti i database.
Nota Se il concatenamento della proprietà tra database è stato attivato in una versione non finale di SP3 (precedente alla build 8.00.760), sarà necessario attivarlo nuovamente quando si installa la versione finale di SP3.
Le informazioni seguenti sono relative solo ad Analysis Services.
Per installare Analysis Services SP3, eseguire Setup.exe da una delle posizioni seguenti:
Durante l'esecuzione del programma di installazione verranno eseguite le operazioni seguenti:
Dopo aver installato Analysis Services SP3 è necessario aggiornare a SP3 tutti i computer utilizzati per l'amministrazione remota. In caso contrario, verrà visualizzato il messaggio di errore seguente quando si tenta di connettersi in remoto mediante Analysis Manager:
Impossibile connettersi al Registro di sistema nel server (nome_server), oppure l'utente non fa parte del gruppo OLAP Administrators in questo server.In Meta Data Services è stato aggiunto un nuovo ruolo dedicato RepositoryUser, che consente di accedere e aggiornare le informazioni del repository nel database msdb. Il ruolo RepositoryUser dispone delle autorizzazioni necessarie per la creazione, la lettura, l'aggiornamento, l'eliminazione e l'esecuzione nel repository del database msdb. Il ruolo public è stato sostituito dal nuovo ruolo e non dispone più delle autorizzazioni necessarie per questo repository. Se sono soddisfatte le condizioni seguenti, è necessario aggiungere il gruppo OLAP Administrators al ruolo RepositoryUser in modo tale che i membri del gruppo possano accedere al repository dopo l'installazione del service pack:
Nota Poiché questa modifica interessa i server remoti che accedono al repository di Meta Data Services in un server che è stato aggiornato a SP3, è necessario aggiungere al ruolo RepositoryUser anche gli account di accesso remoto a tali server.
Nota È necessario aggiungere il gruppo OLAP Administrators al ruolo RepositoryUser prima di ripristinare un repository di Meta Data Services di cui era stato eseguito il backup prima dell'aggiornamento a SP3. In caso contrario, l'operazione di ripristino avrà esito negativo.
Per ulteriori informazioni sul ruolo RepositoryUser, vedere la sezione 5.6.3 Nuovo ruolo RepositoryUser per l'accesso alle informazioni del repository.
Se la cartella Data di Analysis Services si trova in un computer diverso da quello in cui è in esecuzione Analysis Server, è necessario modificare le autorizzazioni per la cartella dopo aver eseguito il programma di installazione di SP3. Per ulteriori informazioni, vedere la sezione 5.2.10 Modifica delle autorizzazioni per la cartella Data remota.
Le informazioni seguenti sono relative solo a Desktop Engine.
Il service pack per SQL Server 2000 Desktop Engine (MSDE) è destinato agli sviluppatori che creano applicazioni ridistribuibili basate su Desktop Engine. Tutte le istanze di Desktop Engine installate tramite un'applicazione di terze parti devono essere aggiornate con il service pack distribuito dal fornitore dell'applicazione. Se si eseguono applicazioni che utilizzano Desktop Engine, rivolgersi al fornitore del software per informazioni sull'aggiornamento delle istanze di Desktop Engine installate tramite queste applicazioni. Per ulteriori informazioni, vedere "Distributing the SQL Server 2000 Desktop Engine" nella Documentazione in linea di SQL Server (informazioni in lingua inglese). Per informazioni sull'utilizzo appropriato di Desktop Engine, visitare il sito Web Microsoft SQL Server dedicato a Desktop Engine. Per ulteriori informazioni sull'installazione di Desktop Engine SP3, vedere l'articolo 810826 della Knowledge Base.
Il service pack per Desktop Engine viene distribuito nei formati seguenti:
Entrambe le soluzioni includono i file necessari per installare una nuova istanza di Desktop Engine (file msi), aggiornare tutte le istanze esistenti di Desktop Engine (file msp), nonché per utilizzare i moduli di merge (file msm) nelle applicazioni. Per ulteriori informazioni, vedere "Distributing SQL Server Applications" nella Documentazione in linea di SQL Server (informazioni in lingua inglese) o l'articolo 810826 della Knowledge Base del Servizio Supporto Tecnico Clienti Microsoft.
In questa sezione è illustrata la posizione dei file relativi a Desktop Engine SP3.
Nota Se si installa Desktop Engine come componente di un'altra applicazione, contattare il fornitore del software per ottenere ulteriori informazioni sull'aggiornamento di Desktop Engine.
Tutti i file di installazione di Desktop Engine sono inclusi nella directory \MSDE o in una delle relative sottodirectory, che si trova in una delle posizioni seguenti:
Il file Setup.exe è incluso nella directory \MSDE.
I pacchetti di installazione (file msi) sono inclusi nella sottodirectory \Setup della cartella \MSDE contenente il file Setup.exe.
Windows Installer 2.0 (InstMsi20.exe) è contenuto nella sottodirectory \MSI.
I moduli di merge e i relativi file di installazione sono inclusi nella sottodirectory \MSM della cartella \MSDE contenente il file Setup.exe. Per un elenco completo dei moduli di merge di Desktop Engine disponibili, vedere l'argomento "Using SQL Server Desktop Engine Merge Modules" nella Documentazione in linea di SQL Server (informazioni in lingua inglese).
I requisiti seguenti sono relativi solo alle installazioni di Desktop Engine:
Nota Sono supportate fino a 16 istanze di Desktop Engine.
Se si desidera aggiornare Windows Installer, SP3 include i file necessari per l'aggiornamento.
Per aggiornare Windows Installer:
Il programma di installazione di Desktop Engine supporta i parametri di installazione seguenti in SP3.
| Nome parametro | Descrizione |
|---|---|
| ALLOWXDBCHAINING=1 | Attiva il concatenamento della proprietà tra database. Per ulteriori informazioni, vedere la sezione 5.1.11 Concatenamento della proprietà tra database. |
| BLANKSAPWD=1 | Ignora il funzionamento predefinito del programma di installazione, che consiste nell'interrompere la procedura se viene rilevata una password vuota per l'amministratore di sistema. Se si imposta BLANKSAPWD=1, il programma consente l'installazione con una password vuota per l'amministratore di sistema.
Avviso Non è consigliabile utilizzare password vuote. |
| INSTANCENAME=
nome_istanza |
Indica il nome dell'istanza. Se non viene specificato alcun nome per l'istanza, viene utilizzato il nome predefinito MSSQLSERVER. |
| SAPWD=password_sa | Indica la password sa. È possibile usare questa opzione nel caso di nuove installazioni. A differenza delle altre proprietà, la proprietà SAPWD è nascosta e il valore corrispondente non è registrato nel file di log. |
| SECURITYMODE=SQL | Indica che l'istanza utilizza l'autenticazione di SQL Server. In Windows NT 4.0, Windows 2000 o Windows XP, se non si specifica il parametro SECURITYMODE=SQL, viene utilizzata l'autenticazione di Windows e il gruppo degli amministratori locali di Windows viene aggiunto al ruolo predefinito del server sysadmin di SQL Server.
Importante Se possibile, utilizzare l'autenticazione di Windows. |
| UPGRADEUSER=sa | Indica l'account di accesso da utilizzare quando si esegue l'aggiornamento di Desktop Engine con l'autenticazione di SQL Server. Tale account deve appartenere al ruolo predefinito del server sysadmin. |
| UPGRADEPWD=
sa_password |
Indica la password per l'account di accesso utilizzata quando si esegue l'aggiornamento di Desktop Engine con l'autenticazione di SQL Server. |
| UPGRADE=1 | Utilizzato quando si aggiorna un'istanza di Microsoft Desktop Engine versione 1.0 a SQL Server 2000 Desktop Engine SP3. 1 è l'unico valore supportato. |
I parametri di installazione possono essere specificati nella riga di comando o in un file ini. Per informazioni, vedere "Customizing Desktop Engine Setup.exe" nella Documentazione in linea di SQL Server (informazioni in lingua inglese).
Nota Se si utilizzano i moduli di merge di SQL Server 2000 Desktop Engine come parte integrante di un'installazione personalizzata, potrebbe non essere possibile personalizzare l'installazione di Desktop Engine mediante questi parametri della riga di comando. Per ulteriori informazioni, vedere l'articolo 810826 (informazioni in lingua inglese) della Knowledge Base.
Importante Evitare l'archiviazione delle credenziali in un file ini.
Le opzioni di installazione seguenti vengono utilizzate durante l'aggiornamento, l'installazione o la disinstallazione di Desktop Engine.
| Nome opzione | Descrizione |
|---|---|
| /upgradesp <percorso_installazione>\SqlRunXX.msi | SQLRUN | In SP3 e versioni successive questa opzione sostituisce l'opzione /p utilizzata quando si specifica la posizione dei pacchetti. Quando si esegue l'aggiornamento a SP3, se si conosce il numero dei file msi originali utilizzati per installare Desktop Engine, specificarlo insieme al percorso completo del file msi di SP3 che ha lo stesso nome. In alternativa, è possibile utilizzare SQLRUN se si specifica il nome dell'istanza con il parametro INSTANCENAME. Nella sezione seguente sono riportati alcuni esempi su come utilizzare questa nuova opzione. |
| /l*v [nomefile] | Questa opzione standard si rivela utile nella risoluzione dei problemi relativi all'installazione. Indica la creazione di un log dettagliato. Se si specifica un valore per filename, il log viene memorizzato nel file indicato. |
| /x nome_pacchetto | Questa opzione standard è utilizzata durante la disinstallazione di Desktop Engine. È necessario specificare il nome del file (msi) del pacchetto di Windows Installer utilizzato per l'installazione dell'istanza di Desktop Engine. |
Per informazioni su altri argomenti del programma di installazione, vedere l'argomento "Customizing Desktop Engine Setup.exe" nella Documentazione in linea di SQL Server (informazioni in lingua inglese).
In SP3 è stata introdotta la nuova opzione /upgradesp per l'aggiornamento di Desktop Engine, che sostituisce l'opzione /p. A seconda delle informazioni disponibili sull'istanza di Desktop Engine da aggiornare, è possibile utilizzare la nuova opzione in due modi diversi. È necessario conoscere il nome dell'istanza (MSSQLSERVER è il nome predefinito) o il file msi utilizzato per installare l'istanza originale di Desktop Engine.
Se si conosce il nome dell'istanza, utilizzare l'opzione /upgradesp come illustrato nell'esempio seguente:
Setup.exe /upgradesp SQLRUN INSTANCENAME=nome_istanza SECURITYMODE=SQL
UPGRADEUSER=<nomeutente> UPGRADEPWD=<password>Importante Se durante l'installazione si utilizza un file ini, evitare l'archiviazione delle credenziali in tale file.
In questo caso, il nome dell'istanza consente di determinare quale file msi è stato utilizzato per l'installazione originale dell'istanza di Desktop Engine.
Nota Se si aggiorna l'istanza predefinita, non è necessario specificare INSTANCENAME.
Desktop Engine può essere installato con uno dei 16 file msi disponibili (da SqlRun01.msi a SqlRun16.msi). Se invece si conosce il nome del file msi originale utilizzato per l'installazione di Desktop Engine, è possibile specificarlo insieme al percorso completo del file msi di SP3 con lo stesso nome come illustrato nell'esempio seguente:
Setup.exe /upgradesp c:\SQL2KSP3\MSDE\Setup\SqlRun03.msi SECURITYMODE=SQL
UPGRADEUSER=<nomeutente> UPGRADEPWD=<password>Importante Se durante l'installazione si utilizza un file ini, evitare l'archiviazione delle credenziali in tale file.
In questo esempio C:\SQL2KSP3\MSDE\Setup è il percorso dei file msi di SP3 e SqlRun03.msi è il file utilizzato per l'installazione originale.
Se non si conosce né il nome dell'istanza né il nome del file msi originale, vedere l'articolo 311762, che illustra come determinare il nome del file msi originale ed è disponibile nella Knowledge Base del Servizio Supporto Tecnico Clienti Microsoft (informazioni in lingua inglese).
Per aggiornare SQL Server 2000 Desktop Engine
/upgradesp SQLRUN INSTANCENAME=nome_istanza
-oppure-
Se si conosce il nome del file msi originale, utilizzare /upgradesp e specificare il nome del file msi insieme al percorso completo del file msi di SP3 con lo stesso nome.
Importante Se durante l'installazione si utilizza un file ini, evitare l'archiviazione delle credenziali in tale file.
Nota Se si utilizza BLANKSAPWD=1, non è necessario specificare SECURITYMODE=SQL o UPGRADEUSER e UPGRADEPWD.
Avviso Non è consigliabile utilizzare password vuote.
Nota Se si esegue l'aggiornamento di Desktop Engine in un computer con Windows 98 o Windows Millennium Edition, prima di avviare il programma di installazione è necessario chiudere l'istanza di Desktop Engine che si desidera aggiornare.
Per eseguire l'aggiornamento da Desktop Engine versione 1.0
Questo service pack consente di aggiornare un'istanza di Desktop Engine versione 1.0 direttamente a SQL Server 2000 Desktop Engine SP3. Per aggiornare Desktop Engine:
Se si utilizza l'autenticazione di SQL Server, è inoltre necessario eseguire le operazioni seguenti:
Nota Se si utilizza BLANKSAPWD=1, non è necessario specificare SECURITYMODE=SQL o UPGRADEUSER e UPGRADEPWD.
Avviso Non è consigliabile utilizzare password vuote.
Importante Se durante l'installazione si utilizza un file ini, evitare l'archiviazione delle credenziali in tale file.
Con SP3 è possibile installare una nuova istanza di Desktop Engine.
Per installare una nuova istanza di Desktop Engine
Nota Se si specificano entrambi i parametri SAPWD e BLANKSAPWD, SAPWD avrà la priorità e BLANKSAPWD verrà ignorato.
Importante Se durante l'installazione si utilizza un file ini, evitare l'archiviazione delle credenziali in tale file.
Avviso Non è consigliabile utilizzare password vuote.
Per ulteriori informazioni, vedere l'argomento "Installing Desktop Engine" nella Documentazione in linea di SQL Server (informazioni in lingua inglese). Per informazioni sull'utilizzo appropriato di Desktop Engine, visitare il sito Web Microsoft SQL Server dedicato a Desktop Engine.
Per ridistribuire il service pack, è consigliabile che i fornitori di software indipendenti (ISV) seguano una delle procedure seguenti:
Per ulteriori informazioni sulla creazione di file di correzione, vedere l'articolo 810826 della Knowledge Base o la documentazione inclusa in Windows Installer Software Development Kit (SDK), che è possibile scaricare dal sito Web di Microsoft Platform SDK (informazioni in lingua inglese).
Nota È possibile ridistribuire una copia completa di SP3.
Le informazioni seguenti sono valide per tutti i componenti.
Al termine dell'esecuzione del programma di installazione potrebbe venire richiesto di riavviare il sistema. Dopo avere riavviato il sistema o al termine dell'installazione se non è stato richiesto il riavvio del sistema, tramite l'applicazione Servizi del Pannello di controllo verificare che MS DTC e i servizi Microsoft Search, MSSQLServer, MSSQLServerOLAPService e SQLServerAgent, o i servizi equivalenti specifici per un'istanza, siano in esecuzione. Eseguire una copia di backup dei database master e msdb aggiornati.
Le informazioni seguenti sono valide per tutti i componenti.
Riavviare le applicazioni che sono state chiuse prima di eseguire il programma di installazione del service pack.
Le informazioni seguenti sono relative solo ai componenti di SQL Server 2000 inclusi in un cluster di failover.
Per installare il service pack in un cluster di failover
Nota Dopo l'installazione potrebbe venire richiesto di riavviare i nodi del cluster di failover. In tal modo i file in uso durante l'installazione vengono sostituiti con i file aggiornati.
Se si esegue l'aggiornamento di un'istanza di SQL Server predefinita (non inclusa in un cluster) in un server virtuale, è necessario innanzitutto aggiornare l'istanza predefinita in istanza virtuale e quindi applicare SP3. Per ulteriori informazioni sulla procedura di aggiornamento, vedere "How to upgrade from a default instance to a default clustered instance of SQL Server 2000 (Setup)" nella Documentazione in linea di SQL Server (informazioni in lingua inglese).
Per ulteriori informazioni sull'installazione di SP3 in un cluster di failover, vedere l'articolo 811168 della Knowledge Base.
Per ricreare un nodo del cluster di failover, eseguire le operazioni seguenti
Quando si installa Analysis Services SP3 in un cluster, è necessario aggiornare ogni istanza individualmente.
Per installare SP3 in un cluster Analysis Services
Le informazioni seguenti sono relative solo ai componenti di SQL Server 2000 inclusi in una topologia di replica:
Nota In molti casi, soprattutto nella replica di tipo merge, il server di distribuzione e quello di pubblicazione coincidono e vengono aggiornati contemporaneamente.
Nelle topologie di replica basate sulla replica di tipo merge o transazionale che consentono l'aggiornamento dei server di sottoscrizione e che includono uno o più server che fungono sia da server di sottoscrizione sia da server di pubblicazione (o di distribuzione), potrebbe essere necessario interrompere tutte le procedure di aggiornamento ed eseguire l'aggiornamento di tutti i server contemporaneamente.
Nella tabella seguente sono indicati i server che eseguono la pubblicazione e sottoscrivono le pubblicazioni che consentono di aggiornare il server di sottoscrizione. Come indicato in precedenza, è necessario seguire l'ordine di aggiornamento server di distribuzione, server di pubblicazione e server di sottoscrizione per le topologie che consentono l'aggiornamento del server di sottoscrizione. In base a questo ordine è necessario aggiornare il server A per primo per la pubblicazione di tipo merge e il server B per primo per la pubblicazione transazionale con aggiornamento dei server di sottoscrizione. In questo caso è necessario interrompere tutti gli aggiornamenti e aggiornare i server simultaneamente.
| Server A | Server B |
|---|---|
| Server di pubblicazione/distribuzione per la replica di tipo merge | Server di sottoscrizione per la replica di tipo merge |
| Server di sottoscrizione per la replica transazionale con aggiornamento | Server di pubblicazione/distribuzione per la replica transazionale con aggiornamento |
In questo esempio è possibile aggiornare il server A per primo perché la pubblicazione transazionale di sola lettura consente l'aggiornamento del server di sottoscrizione prima di aggiornare il server di pubblicazione/distribuzione.
| Server A | Server B |
|---|---|
| Server di pubblicazione/distribuzione per la replica di tipo merge | Server di sottoscrizione per la replica di tipo merge |
| Server di sottoscrizione per la replica transazionale di sola lettura | Server di pubblicazione/distribuzione per la replica transazionale di sola lettura |
Importante Prima di eseguire l'aggiornamento a SP3, verificare che l'account di Windows in cui viene eseguito il servizio SQL Server appartenga al ruolo predefinito del server sysadmin. Questa verifica è necessaria perché i database di distribuzione di una topologia di replica vengono aggiornati nel contesto dell'account di servizio di SQL Server. Dopo aver eseguito l'aggiornamento a SP3, è necessario rimuovere l'account di Windows dal ruolo sysadmin.
Se si utilizza la replica di tipo merge e il server di distribuzione si trova in un computer o un'istanza di database diversa (un server di distribuzione remoto), dopo aver applicato SP3 è necessario generare un nuovo snapshot.
In SP3 è stata introdotta una modifica dei requisiti necessari per il collegamento o il ripristino di database di replica. Per ulteriori informazioni, vedere la sezione 5.3.17 Modifica dei requisiti necessari per il collegamento o il ripristino di un database di replica.
Con l'installazione di SP3 vengono aggiornati i database utente appartenenti a una topologia di replica. Per applicare SP3 ai database appartenenti a una topologia di replica che non supportano operazioni di scrittura, è necessario configurare i database in modo che supportino operazioni di scrittura e quindi reinstallare SP3. Per ulteriori informazioni su come configurare un database in modo che supporti operazioni di scrittura, vedere la sezione 3.12 Applicazione di SP3 a database o filegroup di sola lettura. Per informazioni sulla reinstallazione di SP3, vedere la sezione 3.14 Reinstallazione di SP3.
Uno schema di backup esistente che prevede la replica consente il ripristino di un database fino a un punto noto dopo l'aggiornamento di SP3 in caso di problemi. Dopo l'applicazione di SP3, è consigliabile eseguire il backup completo del database o del log per i database utente inclusi in una topologia di replica. In questo modo, se un database di replica è danneggiato, non è necessario reinstallare SP3 dopo aver ripristinato il database.
Le informazioni seguenti sono relative solo ai componenti di SQL Server 2000 inclusi in una topologia di replica.
Se durante l'installazione vengono rilevati database o filegroup che non supportano operazioni di scrittura, viene visualizzato il messaggio seguente:
Sono stati rilevati uno o più database e filegroup non modificabili.In generale è possibile ignorare questo avviso e continuare l'installazione. Se tuttavia uno o più d'uno dei database che non supportano operazioni di scrittura elencati nel log di installazione appartengono a una topologia di replica, è necessario modificare gli attributi dei database in modo che supportino operazioni di scrittura e rieseguire l'installazione di SP3 per l'istanza di SQL Server 2000 corrispondente.
Nota Questo messaggio non riguarda le installazioni automatiche. Per ulteriori informazioni sulle installazioni automatiche, vedere la sezione 4.1 Installazioni automatiche.
Nota Durante l'installazione non viene fatta alcuna distinzione tra database che non supportano operazioni di scrittura e database non in linea o sospetti. Se durante l'installazione viene rilevato un database o un filegroup in una di queste modalità, è necessario applicare nuovamente il service pack. Per ulteriori informazioni su come portare un database in linea, vedere l'argomento "Attaching and Detaching a Database" nella Documentazione in linea di SQL Server (informazioni in lingua inglese). Per ulteriori informazioni sulla diagnostica di database sospetti, vedere l'argomento "Server and Database Troubleshooting" nella Documentazione in linea di SQL Server (informazioni in lingua inglese).
Per applicare SP3 a un database di sola lettura
ALTER DATABASE database SET READ_WRITEALTER DATABASE database SET READ_ONLYPer applicare SP3 a un filegroup di sola lettura
ALTER DATABASE Database
MODIFY FILEGROUP nome_filegroup READWRITE ALTER DATABASE Database
MODIFY FILEGROUP nome_filegroup READONLYPer ulteriori informazioni sull'istruzione ALTER DATABASE, vedere l'argomento "ALTER DATABASE" nella Documentazione in linea di SQL Server. Per ulteriori informazioni sulla reinstallazione di SP3, vedere la sezione 3.14 Reinstallazione di SP3.
Il metodo da utilizzare per la rimozione di SQL Server SP3 dipende dai componenti di SQL Server 2000 SP3 che si desidera rimuovere.
Nota Gli aggiornamenti di MDAC non vengono disinstallati. Per ulteriori informazioni, vedere la sezione 5.5.1 Aggiornamenti relativi a Microsoft Data Access Components.
Per ripristinare la versione dei componenti di SQL Server 2000 precedente all'installazione di SP3, è necessario disporre di una copia di backup dei database master, msdb e model creata prima dell'installazione del service pack. Per ulteriori informazioni, vedere la sezione 3.1 Backup dei database di SQL Server
Nota Se uno o più database sono interessati dalla replica, è necessario disattivare la funzione di pubblicazione. Per disattivare la funzione di pubblicazione:
Per ripristinare la versione di SQL Server precedente all'installazione di SP3
Avviso Se si ripristina la versione di SQL Server precedente all'installazione di SP3, tutte le modifiche apportate ai database master, msdb e model successivamente all'installazione del service pack andranno perse.
Per poter ripristinare la versione di Analysis Services precedente all'installazione di SP3, è necessario eseguire il backup della chiave del Registro di sistema HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\OLAP Server prima di installare SP3. Per ulteriori informazioni, vedere la sezione 3.2 Backup del repository e dei database di Analysis Services.
Nota Se non è stato eseguito il backup della chiave del Registro di sistema, è necessario seguire la procedura illustrata nell'articolo 330244 (informazioni in lingua inglese) della Microsoft Knowledge Base.
Per ripristinare la versione di SQL Server precedente all'installazione di SP3
Le informazioni seguenti sono valide per tutti i componenti.
È necessario reinstallare SP3 nei casi seguenti:
Per reinstallare SP3, eseguire la procedura descritta nella sezione 3.0 Installazione del service pack
In questa sezione vengono esposte considerazioni aggiuntive sull'installazione del service pack, che sono tuttavia valide solo in casi specifici.
È possibile implementare in modalità automatica Componenti database SP3 in un'istanza di SQL Server. Il CD di Componenti database SP3 contiene file iss utilizzabili per l'installazione automatica di SP3 e per altri tipi di installazione. I file seguenti si trovano nella directory principale del CD:
Per ulteriori informazioni sull'installazione automatica di SQL Server 2000, vedere l'argomento "Esecuzione di un'installazione automatica" nella Documentazione in linea di SQL Server.
Di seguito sono riportate alcune considerazioni relative alle installazioni automatiche:
start /wait setupsql.exe -s -sms -f1 C:\sql2knm.iss -sapwd password | Opzione di installazione automatica | Descrizione |
|---|---|
| UpgradeMSSearch | Consente di risolvere il problema relativo alla ricostruzione dei cataloghi full-text. Se la funzione Ricerca full-text è attivata, è necessario impostare questa opzione su 1. Per ulteriori informazioni, vedere la sezione 5.1.5 Ricostruzione dei cataloghi full-text dopo l'installazione. |
| MSXTSXUpgraded | Consente di risolvere il problema relativo all'aggiornamento delle configurazioni server master/target. Se si installa SP3 in un server master o target, è necessario impostare questa opzione su 1. Per ulteriori informazioni, vedere la sezione 5.4.2 Modifiche relative alle configurazioni server master/target. |
| EnableCrossDBChaining | (Facoltativa) Consente di abilitare il concatenamento della proprietà tra database. Per abilitare il concatenamento della proprietà tra database, impostare questa opzione su 1. Per ulteriori informazioni, vedere la sezione 5.1.11 Concatenamento della proprietà tra database. |
Componenti database SP3 include il file autoestraente Sqlredis.exe. Quando si esegue questo file:
È possibile ridistribuire il file Sqlredis.exe in base alle condizioni riportate nel file Redist.txt allegato a SP3.
In questa sezione vengono trattati i possibili problemi di installazione e le nuove caratteristiche implementate tramite SP3. Tali problematiche fanno riferimento all'esecuzione del service pack per eseguire l'aggiornamento da SQL Server 2000, SQL Server 2000 SP1 o SQL Server 2000 SP2. Tuttavia, in questa sezione non viene fornita una descrizione esaustiva di tutte le correzioni disponibili in SP3. Per un elenco completo delle correzioni, vedere l'articolo 306908 (informazioni in lingua inglese) della Microsoft Knowledge Base.
Le informazioni di questa sezione relative ad Analysis Services e Meta Data Services non sono valide per le installazioni che includono solo Desktop Engine.
Eventuali informazioni aggiuntive relative a SQL Server 2000 Service Pack 3 che saranno disponibili successivamente alla redazione di questo documento verranno pubblicate nell'articolo 330022 (informazioni in lingua inglese) della Knowledge Base del Servizio Supporto Tecnico Clienti Microsoft.
I miglioramenti seguenti sono validi per le istanze di SQL Server 2000 in cui è installato Componenti database SP3, nonché per le istanze di Desktop Engine in cui è installato Desktop Engine SP3.
Implementato in SP1
Se si installa Componenti database SP3 in un server che esegue Windows NT 4.0 o Windows 98 e in una fase successiva si procede all'aggiornamento del sistema a Windows 2000, durante l'aggiornamento a Windows 2000 alcuni file di sistema vengono sostituiti. Tali file di sistema sono necessari per l'ordinamento dei caratteri cinesi, giapponesi e coreani. Se nei database in uso di SQL Server si utilizzano caratteri cinesi, giapponesi o coreani, dopo l'aggiornamento a Windows 2000 rieseguire la versione di Sqlredis.exe fornita con SP3. Per ulteriori informazioni sull'esecuzione di Sqlredis.exe, vedere la sezione 4.2 Ridistribuzione di Data Access Components SP3.
Nota Non è necessario implementare nuovamente Sqlredis.exe nei computer client oppure nei server in cui non sono presenti database contenenti caratteri cinesi, giapponesi o coreani.
Implementato in SP1
I gruppi di hash sono stati rimossi. In seguito ad alcuni miglioramenti apportati a SQL Server 2000, i gruppi di hash non offrono più i vantaggi a livello di prestazioni che caratterizzavano SQL Server 7.0. Inoltre la rimozione dei gruppi di hash rende SQL Server 2000 più stabile.
Pertanto Query Optimizer non genera più piani di query utilizzando i gruppi di hash.
In casi rari la rimozione dei gruppi di hash potrebbe causare un rallentamento dell'elaborazione delle query. Analizzare le query per vedere se la creazione di indici più adatti potrebbe ripristinare i livelli di prestazioni originari delle query.
Implementato in SP1
In questo service pack sono state aggiunte due opzioni per affinity mask.
In questo service pack è possibile specificare le CPU utilizzate per eseguire i thread per le operazioni di I/O del disco. Questa opzione deve essere utilizzata in combinazione con l'opzione affinity mask. Per ulteriori informazioni, vedere l'articolo 298402 (informazioni in lingua inglese) nella Knowledge Base del Servizio Supporto Tecnico Clienti Microsoft. Per istruzioni su come eseguire ricerche nella Knowledge Base, vedere la sezione 1.3 Informazioni aggiuntive su SP3.
Grazie a questo service pack è possibile configurare i sistemi in modo da abilitarli per l'architettura VIA (Virtual Interface Architecture, architettura a interfaccia virtuale) e pertanto rendere possibile l'associazione tra le connessioni di SQL Server da schede di rete specifiche e uno o più processori. Questa opzione deve essere utilizzata in combinazione con l'opzione affinity mask. Per ulteriori informazioni, vedere l'articolo 299641 (informazioni in lingua inglese) nella Knowledge Base del Servizio Supporto Tecnico Clienti Microsoft.
Implementato in SP2
Se in SQL Server 2000 è stato riscontrato il problema 355069 descritto nell'articolo 306467 (informazioni in lingua inglese) della Microsoft Knowledge Base, questo service pack impedisce soltanto la generazione di risultati imprevisti in seguito a modifiche dei dati. Pertanto, oltre ad applicare questa correzione, è necessario ricreare tutti gli indici basati sulle viste con filtri. Per ulteriori informazioni, vedere la Knowledge Base del Servizio Supporto Tecnico Clienti Microsoft.
Implementato in SP3
Durante l'installazione di SP3 vengono ricostruiti tutti i catologhi full-text. La ricostruzione viene eseguita automaticamente e richiede un numero elevato di risorse. Le query eseguite sui cataloghi full-text potrebbero restituire risultati parziali o nessun risultato fino a quando non è stata completata la ricostruzione. Dopo l'installazione di SP3, nel registro eventi di sistema sono riportati i messaggi indicanti che i cataloghi risultavano danneggiati, che la relativa versione era obsoleta e che pertanto sono stati ricostruiti.
Per informazioni, vedere l'articolo 327217 (informazioni in lingua inglese) della Knowledge Base, che illustra le soluzioni possibili per garantire la disponibilità della funzione di ricerca full-text durante la ricostruzione e per evitare la ricostruzione automatica.
Implementato in SP3
Quando si esegue sp_change_users_login con l'argomento @Action=Auto_Fix, è ora necessario specificare una password. sp_change_users_login assegna la password a tutti i nuovi account di accesso creati per l'utente. Nell'esempio seguente è illustrato il nuovo argomento @Password:
sp_change_users_login [ @Action = ] 'action'
[ , [ @UserNamePattern = ] 'user' ]
[ , [ @LoginName = ] 'login' ]
[ , [ @Password = ] 'password' ]Utilizzare l'argomento @Password solo con @Action=Auto_Fix. Nell'esempio seguente è illustrata la nuova sintassi del comando sp_change_users_login quando si utilizza Auto_Fix. Tutti gli altri esempi contenuti nella Documentazione in linea di SQL Server rimangono invariati.
USE pubs
go
EXEC sp_change_users_login 'Auto_Fix', 'Mary', NULL, 'B3r12-36'
goImplementato in SP3
Se l'opzione del Registro di sistema DisallowAdhocAccess non è impostata in modo esplicito, per impostazione predefinita l'accesso ad hoc ai provider OLE DB non è consentito. In questo caso la sintassi della query ad hoc, ad esempio OPENDATASOURCE e OPENROWSET, non funzionerà sui server remoti. Per consentire l'accesso ad hoc, è necessario impostare in modo esplicito l'opzione DisallowAdhocAccess su 0.
Implementato in SP3
Per consentire un'elaborazione più efficace delle query remote che includono predicati LIKE, è stata aggiunta l'opzione SqlServerLike in SP3. Se questa opzione è impostata su 1, SQL Server è in grado di sottoporre query con predicati LIKE al provider. In passato, se il provider in uso non era il provider OLE DB per SQL Server, le query distribuite che contenevano predicati LIKE venivano sempre valutate nell'istanza locale di SQL Server.
Implementato in SP3
Per le query distribuite, oltre alle informazioni sugli errori a livello di server, vengono visualizzate informazioni sugli errori a livello di provider. Quando si verifica un errore durante l'esecuzione di una query tra server collegati, SQL Server controlla che il provider supporti l'interfaccia OLE DB IErrorRecords. Se l'interfaccia è supportata, viene richiamata la funzione GetErrorInfo per ottenere informazioni supplementari sull'errore dal provider e includerle nel messaggio di errore. Se invece l'interfaccia non è supportata, non si verifica alcuna modifica nel funzionamento di SQL Server e viene visualizzato un errore generico.
Eseguire ad esempio la query seguente su un server che utilizza MSDASQL, che non supporta sql_variant:
SELECT * FROM remote2k.dqtable.dbo.sqlvariantnotnull --Remote2k is a loopback server.Nelle versioni di SQL Server precedenti a SP3 veniva visualizzato il messaggio di errore seguente:
Server: messaggio 7356, livello 16, stato 1, riga 1
I metadati forniti dal provider OLE DB 'msdasql' per una colonna sono inconsistenti.
I metadati sono stati modificati in fase di esecuzione.Dopo aver installato SP3 viene visualizzato il messaggio seguente:
Server: messaggio 7356, livello 16, stato 1, riga 1
I metadati forniti dal provider OLE DB 'msdasql' per una colonna sono inconsistenti.
I metadati sono stati modificati in fase di esecuzione.
Traccia di errore OLE DB [errore non di interfaccia: la colonna 'sql_variant'
(numero ordinale 3 in fase di compilazione) dell'oggetto
'"dqtable"."dbo"."sqlvariantnotnull"' ha riportato un DBCOLUMNFLAGS_ISFIXEDLENGTH
pari a 16 in fase di compiazione e pari a 0 in fase di esecuzione].Implementato in SP3
SP3 include la nuova funzione fn_get_sql che restituisce il testo dell'istruzione SQL per l'handle SQL specificato. Inoltre, per garantire il supporto di questa funzione sono state aggiunte tre nuove colonne alla tabella di sistema sysprocesses, che sono illustrate nella tabella seguente.
| Nome colonna | Tipo di dati | Descrizione |
|---|---|---|
| sql_handle | binary(20) | Rappresenta il batch o l'oggetto in esecuzione. |
| stmt_start | int | Offset iniziale dell'istruzione SQL corrente per il valore di sql_handle specificato. |
| stmt_end | int | Offset finale dell'istruzione SQL corrente per il valore di sql_handle specificato.
Un valore pari a -1 indica che l'istruzione corrente viene eseguita fino alla fine dei risultati restituiti dalla funzione fn_get_sql per il valore di sql_handle specificato. |
fn_get_sql ([ @SqlHandle = ] SqlHandle )
[ @SqlHandle = ] SqlHandle
Valore dell'handle. SqlHandle è di tipo binary(20).
| Nome colonna | Tipo di dati | Descrizione |
|---|---|---|
| dbid | smallint | ID del database. Questo valore è NULL per le istruzioni SQL ad hoc. |
| objectid | Int | ID dell'oggetto di database. Questo valore è NULL per le istruzioni SQL ad hoc. |
| number | smallint | Numero del gruppo, se le procedure sono raggruppate. Questo valore è 0 per le voci che non sono procedure e NULL per le istruzioni SQL ad hoc. |
| encrypted | Bit | Indica se l'oggetto è crittografato. Il valore è 0 se l'oggetto non è crittografato e 1 se invece è crittografato. |
| text | Text | Testo dell'istruzione SQL. Questo valore è NULL per gli oggetti crittografati. |
È possibile ottenere un handle SQL valido dalla colonna sql_handle della tabella di sistema sysprocesses.
Se si passa un handle che non è più contenuto nella cache, fn_get_sql restituisce un set di risultati vuoto. Se si passa un handle non valido, il batch viene interrotto e viene visualizzato il messaggio di errore seguente:
Server: messaggio 569, livello 16, stato 1, procedura fn_get_sql, riga 12 L'handle passato a fn_get_sql non è valido.
SQL Server 2000 non è in grado di inserire nella cache alcune istruzioni Transact-SQL, ad esempio istruzioni di copia in massa e istruzioni che includono stringhe letterali superiori a 8 KB. Non è possibile recuperare gli handle relativi a tali istruzioni mediante la funzione fn_get_sql.
Nella colonna text del set di risultati viene applicato un filtro per visualizzare testo che potrebbe includere password.
Le informazioni restituite dalla funzione fn_get_sql sono simili a quelle ottenute mediante il comando DBCC INPUTBUFFER. Utilizzare la funzione fn_get_sql quando non è possibile utilizzare il comando DBCC INPUTBUFFER, ad esempio nei casi seguenti:
Solo i membri del ruolo predefinito del server sysadmin possono eseguire la funzione fn_get_sql.
Gli amministratori del database possono utilizzare la funzione fn_get_sql per eseguire la diagnosi dei processi che causano problemi. Dopo aver identificato l'ID del processo server (SPID, Server Process ID), l'amministratore può recuperare l'handle SQL dell'ID, richiamare la funzione fn_get_sql con tale handle e utilizzare l'offset iniziale e finale per determinare il testo SQL dell'ID del processo server che causa problemi. Ad esempio:
DECLARE @Handle binary(20)
SELECT @Handle = sql_handle FROM sysprocesses WHERE spid = 52
SELECT * FROM ::fn_get_sql(@Handle) Implementato in SP3
In questo service pack sono incluse nuove opzioni per l'attivazione e la disattivazione del concatenamento della proprietà tra database. Durante l'installazione di SP3 nella finestra di dialogo Elenco di controllo compatibilità con versioni precedenti è visualizzata un'opzione per la configurazione di questa funzionalità. Per impostazione predefinita il concatenamento della proprietà è disattivato per tutti i database utente, ma se lo si desidera è possibile attivarlo per tutti i database. Per ulteriori informazioni, vedere Finestra di dialogo Elenco di controllo compatibilità con versioni precedenti
Nota Non è consigliabile attivare questa funzionalità per tutti i database.
Dopo l'installazione è possibile attivare o disattivare il concatenamento della proprietà tra database per tutti i database dell'istanza utilizzando una delle opzioni seguenti:
Se il concatenamento della proprietà tra database è disattivato per l'istanza, è possibile configurarlo per singoli database. Attivare o disattivare il concatenamento della proprietà per un database utilizzando una delle opzioni seguenti:
Nota Se il concatenamento della proprietà tra database è stato attivato in una versione non finale di SP3 (precedente alla build 8.00.760), sarà necessario attivarlo nuovamente quando si installa la versione finale di SP3.
Per ulteriori informazioni, fare clic su ? nella schermata Elenco di controllo compatibilità con versioni precedenti del programma di installazione, scaricare la versione aggiornata della Documentazione in linea di SQL Server 2000 oppure vedere l'articolo 810474 della Knowledge Base (informazioni in lingua inglese).
Implementato in SP3
Il flag di traccia 1204 restituisce il tipo di blocchi coinvolti nel blocco critico (deadlock) e il comando corrente interessato. In SP3 e versioni successive, se questo flag di traccia è attivato, le informazioni sul blocco critico vengono automaticamente registrate nel log degli errori.
Implementato in SP3
Solo i membri del ruolo predefinito del server sysadmin possono eseguire la stored procedure di sistema sp_changedbowner.
Implementato in SP3
Per impostazione predefinita la funzionalità di debug delle stored procedure con Microsoft Visual Studio® 6.0 e versioni precedenti o con una versione di SQL Server Query Analyzer precedente a SP3 è disattivata. Per impostazione predefinita è inoltre disattivata la funzionalità di debug delle applicazioni (arresto a un punto di interruzione di SQL Server Transact-SQL durante il debug di un'applicazione client). Per attivare la funzionalità di debug, eseguire la stored procedure sp_sdidebug passando il parametro legacy_on. Per disattivare il debug, passare il parametro legacy_off alla stored procedure.
Nota Non è consigliabile eseguire la stored procedure sp_sdidebug in server di produzione.
Per ulteriori informazioni, vedere l'articolo 328151 (informazioni in lingua inglese) della Knowledge Base del Servizio Supporto Tecnico Clienti Microsoft.
In questa sezione vengono illustrati i miglioramenti relativi a SQL Server 2000 Analysis Services inclusi in SP3.
Implementato in SP1
Quando viene creata una partizione remota in un server locale in cui è stato installato SP1 o versione successiva, nel server remoto è necessario utilizzare un account utente di dominio con autorizzazioni di accesso complete al cubo padre nel server locale. A qualsiasi account utente appartenente al gruppo OLAP Administrators nel server locale sono associate autorizzazioni di accesso complete.
Inoltre, se nel server locale è stato installato SP1 o versione successiva, per poter creare o amministrare le partizioni remote è necessario che il service pack sia installato anche nel server remoto.
Implementato in SP1
Analysis Services SP1 e versioni successive includono le versioni client aggiornate dei seguenti programmi di installazione client ridistribuibili:
Questi file sono disponibili in \Msolap\Install\PTS nella directory di installazione di SP3.
Nota PTSFull.exe include MDAC, non disponibile invece in PTSLite.exe.
Utilizzare questi programmi di installazione client aggiornati nelle applicazioni in uso per evitare o risolvere eventuali problemi di installazione che si possono verificare quando si utilizza Analysis Services in Microsoft Office XP.
Nota Se si utilizza Analysis Services in Office XP, è consigliabile eseguire l'aggiornamento del client.
Implementato in SP1
Analysis Services SP1 e versioni successive includono il supporto per l'aggiunta di provider degli algoritmi di data mining di terze parti. Per ulteriori informazioni sullo sviluppo di provider di algoritmi di data mining, vedere il white paper "Third Party Data Mining Providers" e OLE DB for Data Mining Resource Kit, contenente il codice di esempio di un provider degli algoritmi di data mining (informazioni in lingua inglese).
Implementato in SP1
Se si installa SQL Server 2000 Analysis Services in un computer in cui sono disponibili file client aggiornati, ad esempio SQL Server 2000 SP1 o Office XP, è necessario applicare Analysis Services SP1 o versione successiva in modo da garantire il corretto funzionamento del client e la possibilità di esplorazione dei cubi.
Implementato in SP3
I cubi virtuali possono ora fare riferimento a un massimo di 255 cubi. Tuttavia, se un cubo virtuale fa riferimento a più di 64 cubi, non è visibile per le versioni di Servizio Microsoft PivotTable® precedenti a SP3.
Implementato in SP3
Nei cubi locali è ora previsto il supporto per la proprietà del membro intrinseca DESCRIPTION per misure e dimensioni. La parola chiave DESCRIPTION, aggiunta all'istruzione MDX (MultiDimensional Expression) CREATE CUBE, consente di utilizzare la proprietà del membro intrinseca DESCRIPTION. Nelle clausole BNF seguenti sono illustrate le modifiche apportate all'istruzione CREATE CUBE:
<dimensions def> :: = DIMENSION <dimension name> [<time def>]
[DIMENSION_STRUCTURE <sub_type>] [<hidden def>] [DESCRIPTION <description expression>]
<options def> <comma> <hierarchy def list>
<measures def> :: = MEASURE <measure name> <measure function def>
[<measure format def>] [<measure type def>] [<hidden def>] [DESCRIPTION <description expression>]
[<comma> <measures def>]Implementato in SP3
In SP3 è stata implementata la nuova proprietà della stringa di connessione Restricted Client di Servizio PivotTable. Questa proprietà consente di evitare che Servizio PivotTable utilizzi la funzionalità di cubo locale. Se si cerca di utilizzare un'istruzione che prevede la creazione o l'utilizzo di un cubo locale, ad esempio CREATE CUBE, CREATE GLOBAL CUBE o CREATE SESSION CUBE, si verifica un errore. Inoltre, per le istruzioni che prevedono una ricorsione dettagliata, ad esempio una serie di istruzioni DRILLDOWN nidificate, si verifica un errore se l'istruzione può causare l'overflow dello stack gestito da Servizio PivotTable.
Questa proprietà contiene un valore stringa. Se il valore è impostato su un valore stringa che inizia per "Y", "y", "T" o "t", o che può essere convertito in un valore numerico diverso da 0, Servizio PivotTable non può utilizzare la funzionalità cubo locale. Se invece il valore è impostato su un qualsiasi altro valore stringa, inclusa una stringa vuota (""), o su un valore stringa che può essere convertito in un valore numerico pari a 0, Servizio PivotTable può utilizzare la funzionalità cubo locale. Il valore predefinito di questa proprietà è "0".
Nota Questa proprietà non impedisce l'utilizzo di modelli di data mining locali.
Implementato in SP3
L'impostazione della proprietà Safety Options su DBPROP_MSMD_SAFETY_OPTIONS_ALLOW_SAFE impedisce l'utilizzo della parola chiave PASSTHROUGH nei cubi locali.
Implementato in SP3
In SP3 è stata disattivata l'opzione della Migrazione guidata repository che prevede l'utilizzo del formato del repository Meta Data Services. Non è infatti consigliabile utilizzare questo formato. Tuttavia, se per motivi aziendali è necessario utilizzare questo formato, è possibile attivare l'opzione attraverso la chiave del Registro di sistema EnableMigrationToMetaDataServicesFormat.
Per impostazione predefinita questa chiave non esiste. È pertanto necessario crearla in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\OLAP Server\Server Connection Info e impostarla per consentire la migrazione del repository al formato Meta Data Services. Questa chiave include un valore stringa che fa distinzione tra maiuscole e minuscole. Se il valore è impostato su 1 o True, la migrazione del repository al formato Meta Data Services è attivata. Se il valore è impostato su un qualsiasi altro valore stringa, oppure se la chiave del Registro di sistema non esiste, la migrazione del repository al formato Meta Data Services è disattivata.
Nota La modifica di questa chiave del Registro di sistema è immediatamente operativa.
Implementato in SP3
Se la cartella Data di Analysis Services si trova in un computer diverso da quello in cui è in esecuzione Analysis Server, è necessario modificare le autorizzazioni per la cartella dopo aver eseguito il programma di installazione di SP3. Impostare le autorizzazioni in modo che tutti i membri del gruppo OLAP Administrators nel computer in cui è in esecuzione Analysis Server abbiano l'accesso Controllo completo alla cartella. Quando si aggiungono o si rimuovono utenti dal gruppo OLAP Administrators, assicurarsi di modificare le autorizzazioni per la cartella Data remota in modo che corrispondano allo stato corrente del gruppo OLAP Administrators. In questo modo, la funzionalità di backup e ripristino verrà eseguita in modo corretto.
Inoltre, dopo aver eseguito l'installazione di SP3, è necessario assegnare all'account in base a cui viene eseguito Analysis Server l'accesso Controllo completo alla cartella Data remota.
Se si applica SP3 a un'istanza di Analysis Services in esecuzione in una configurazione cluster, è necessario consentire al gruppo OLAP Administrators a livello di dominio l'accesso Controllo completo alla cartella Data remota. Per ulteriori informazioni sulla creazione e sull'utilizzo del gruppo OLAP Administrators a livello di dominio, vedere l'articolo 308023 (informazioni in lingua inglese) della Knowledge Base del Servizio Supporto Tecnico Clienti Microsoft.
In questa sezione vengono illustrati i miglioramenti relativi alla funzione di replica di SQL Server 2000 inclusi in SP3.
Implementato in SP1
Durante l'installazione della replica transazionale vengono create stored procedure personalizzate per operazioni di inserimento, eliminazione e aggiornamento nel database di sottoscrizione. Indipendentemente dal numero di colonne interessate da un'istruzione UPDATE, tramite la stored procedure di aggiornamento verranno aggiornate tutte le colonne della tabella di sottoscrizione. Nelle colonne che non sono state modificate vengono ripristinati i valori precedenti all'aggiornamento. In genere questa operazione non ha alcuna ripercussione. Se tuttavia una di queste colonne è indicizzata, l'operazione potrebbe risultare costosa in termini di risorse.
Nel caso della replica transazionale, se la tabella di sottoscrizione include numerosi indici e solo i valori di alcune colonne variano in seguito agli aggiornamenti, l'overhead per la manutenzione degli indici potrebbe risultare un fattore critico quando vengono apportate modifiche a livello di server di sottoscrizione. Ad esempio, un database di sottoscrizione utilizzato per la generazione di report potrebbe essere caratterizzato da un numero di indici di gran lunga superiore a quello del database di pubblicazione. Per migliorare le prestazioni, è possibile generare in modo dinamico l'istruzione UPDATE in fase di runtime. L'aggiornamento interesserà esclusivamente le colonne modificate e pertanto verrà creata una stringa UPDATE ottimale.
In questo service pack è disponibile la nuova stored procedure sp_scriptdynamicupdproc, che consente di generare una stored procedure personalizzata utilizzabile a livello di server di sottoscrizione per la generazione dinamica dell'istruzione UPDATE in fase di runtime. Per quest'ultima operazione sono tuttavia necessari processi di elaborazione aggiuntivi in fase di runtime.
La stored procedure sp_scriptdynamicupdproc consente di generare l'istruzione CREATE PROCEDURE, che crea una stored procedure di aggiornamento in modo dinamico. L'istruzione UPDATE all'interno della stored procedure personalizzata viene generata in modo dinamico in base alla sintassi MCALL, che indica quali colonne modificare. Utilizzare questa stored procedure se il numero di indici nella tabella di sottoscrizione è in aumento mentre il numero di colonne in fase di modifica è ridotto. La stored procedure viene eseguita a livello di server di pubblicazione nel database di pubblicazione.
sp_scriptdynamicupdproc [ @artid =] artid
[@artid =] artid
ID dell'articolo. artid è un valore int (nessuna impostazione predefinita).
Restituisce un set di risultati composto da un'unica colonna nvarchar(4000). Tale set di risultati forma l'istruzione CREATE PROCEDURE completa utilizzata per creare la stored procedure personalizzata.
sp_scriptdynamicupdproc viene utilizzata nella replica transazionale. Nel codice di script predefinito MCALL sono incluse tutte le colonne all'interno dell'istruzione UPDATE e viene utilizzata un'immagine bitmap per contrassegnare le colonne modificate Se una colonna non è stata modificata, viene eseguita un'operazione di reimpostazione del valore originale della colonna. Questa operazione in genere non causa problemi. Se la colonna è indicizzata, saranno tuttavia necessari altri processi di elaborazione. Con questa stored procedure viene utilizzato invece un approccio dinamico che agisce esclusivamente sulle colonne modificate. Viene pertanto creata una stringa UPDATE ottimale. Per la generazione dinamica dell'istruzione UPDATE sono tuttavia necessari processi di elaborazione aggiuntivi in fase di runtime. È consigliabile eseguire una prova sia dell'approccio dinamico che dell'approccio statico predefinito e quindi scegliere la soluzione più adatta alle esigenze specifiche.
Gli utenti associati al ruolo public possono eseguire sp_scriptdynamicupdproc.
Nell'esempio seguente viene creato un articolo (con artid impostato su 1) nella tabella authors del database pubs e l'istruzione UPDATE viene impostata come stored procedure personalizzata da eseguire:
'MCALL sp_mupd_authors'
Generare le stored procedure personalizzate eseguite da Agente di distribuzione a livello di server di sottoscrizione mediante l'esecuzione della stored procedure seguente a livello di server di pubblicazione:
EXEC sp_scriptdynamicupdproc @artid = '1'
The statement returns:
create procedure [sp_mupd_authors]
@c1 varchar(11),@c2 varchar(40),@c3 varchar(20),@c4 char(12),@c5 varchar(40),@c6 varchar(20),
@c7 char(2),@c8 char(5),@c9 bit,@pkc1 varchar(11),@bitmap binary(2)
as
declare @stmt nvarchar(4000), @spacer nvarchar(1)
select @spacer =N''
select @stmt = N'update [authors] set '
if substring(@bitmap,1,1) & 2 = 2
begin
select @stmt = @stmt + @spacer + N'[au_lname]' + N'=@2'
select @spacer = N','
end
if substring(@bitmap,1,1) & 4 = 4
begin
select @stmt = @stmt + @spacer + N'[au_fname]' + N'=@3'
select @spacer = N','
end
if substring(@bitmap,1,1) & 8 = 8
begin
select @stmt = @stmt + @spacer + N'[phone]' + N'=@4'
select @spacer = N','
end
if substring(@bitmap,1,1) & 16 = 16
begin
select @stmt = @stmt + @spacer + N'[address]' + N'=@5'
select @spacer = N','
end
if substring(@bitmap,1,1) & 32 = 32
begin
select @stmt = @stmt + @spacer + N'[city]' + N'=@6'
select @spacer = N','
end
if substring(@bitmap,1,1) & 64 = 64
begin
select @stmt = @stmt + @spacer + N'[state]' + N'=@7'
select @spacer = N','
end
if substring(@bitmap,1,1) & 128 = 128
begin
select @stmt = @stmt + @spacer + N'[zip]' + N'=@8'
select @spacer = N','
end
if substring(@bitmap,2,1) & 1 = 1
begin
select @stmt = @stmt + @spacer + N'[contract]' + N'=@9'
select @spacer = N','
end
select @stmt = @stmt + N' where [au_id] = @1'
exec sp_executesql @stmt, N' @1 varchar(11),@2 varchar(40),@3 varchar(20),@4 char(12),@5 varchar(40),
@6 varchar(20),@7 char(2),@8 char(5),@9 bit',@pkc1,@c2,@c3,@c4,@c5,@c6,@c7,@c8,@c9
if @@rowcount = 0
if @@microsoftversion>0x07320000
exec sp_MSreplraiserror 20598
Dopo avere eseguito questa stored procedure, è possibile utilizzare lo script risultante per creare manualmente la stored procedure a livello di server di sottoscrizione.
Implementato in SP1
Nella replica transazionale le istruzioni UPDATE vengono in genere replicate sotto forma di aggiornamenti. Se l'aggiornamento modifica una colonna che appartiene a un indice univoco, un indice cluster o un'espressione utilizzati come vincolo univoco, l'aggiornamento verrà eseguito come un'istruzione DELETE seguita da un'istruzione INSERT a livello di server di sottoscrizione. Ciò avviene perché questo tipo di aggiornamento potrebbe interessare più righe e potrebbe pertanto verificarsi una violazione a livello di univocità se gli aggiornamenti vengono implementati riga per riga.
Se invece l'aggiornamento interessa solo una riga, non esiste alcun rischio di violazione dell'univocità. A questo service pack è stato tuttavia aggiunto il flag di traccia 8207 per consentire la replica come istruzioni UPDATE degli aggiornamenti in una colonna qualsiasi che interessano solo una riga. Questa ottimizzazione è stata implementata specificatamente per le applicazioni che installano trigger UPDATE definiti dall'utente a livello di server di sottoscrizione e che richiedono questi trigger per attivare gli aggiornamenti che interessano solo una riga in una colonna univoca.
Per utilizzare il flag di traccia 8207, attivarlo utilizzando il prompt dei comandi (sqlservr.exe -T8207) oppure, in fase di runtime, utilizzando DBCC TRACEON(8207, -1) prima di avviare Agente lettura log.
Importante In genere il flag di traccia 8207 viene utilizzato con la replica transazionale di sola lettura. Non utilizzarlo con sottoscrizioni aggiornabili se la chiave primaria UPDATE è presente nel server di sottoscrizione.
Implementato in SP1
In SQL Server 2000 l'elaborazione di snapshot concorrenti non è consigliata se la tabella di pubblicazione contiene un indice univoco che non corrisponde alla chiave primaria o alla chiave di clustering. Se durante la generazione dello snapshot concorrente sono state apportate modifiche ai dati della chiave di clustering, la replica potrebbe avere esito negativo e restituire un errore di chiave duplicata durante l'applicazione dello snapshot concorrente a un server di sottoscrizione. Questo service pack non prevede alcuna restrizione all'utilizzo dell'elaborazione degli snapshot concorrenti.
Implementato in SP1
Quando si impostano sottoscrizioni di tipo nosync, ovvero sottoscrizioni che non ricevono lo snapshot iniziale, le stored procedure personalizzate per le istruzioni INSERT, UPDATE e DELETE devono essere create manualmente. In genere, queste istruzioni vengono create nel server di sottoscrizione quando viene recapitato lo snapshot iniziale. È stata aggiunta la nuova stored procedure sp_scriptpublicationcustomprocs per generare script per stored procedure personalizzate a livello di pubblicazione. Questa nuova funzionalità potrebbe rendere maggiormente facile l'impostazione delle sottoscrizioni di tipo nosync.
La stored procedure sp_scriptpublicationcustomprocs crea gli script delle stored procedure personalizzate INSERT, UPDATE e DELETE per tutti gli articoli di tabella in una pubblicazione in cui è attivata l'opzione per la generazione automatica dello schema delle stored procedure personalizzate. sp_scriptpublicationcustomprocs risulta particolarmente utile per l'impostazione delle sottoscrizioni alle quali lo snapshot viene applicato manualmente.
sp_scriptpublicationcustomprocs [@publication]= publication_name
[@publication] = publication_name
Nome della pubblicazione. publication_name è di tipo sysname e non prevede alcun valore predefinito.
0 (esito positivo) o 1 (esito negativo)
Restituisce un set di risultati composto da un'unica colonna nvarchar(4000). Tale set di risultati forma l'istruzione CREATE PROCEDURE completa utilizzata per creare la stored procedure personalizzata.
Non viene creato lo script delle stored procedure personalizzate per gli articoli con l'opzione per la generazione automatica dello schema delle stored procedure (0x2) attivata.
Al ruolo public sono associate autorizzazioni di esecuzione. All'interno di questa stored procedure viene eseguito un controllo della protezione a livello di procedure per limitare l'accesso ai membri del ruolo predefinito del server sysadmin e del ruolo predefinito del database db_owner nel database corrente.
Nell'esempio seguente viene generato uno script delle stored procedure personalizzate in una pubblicazione denominata Northwind.
exec Northwind.dbo.sp_scriptpublicationcustomprocs
@publication = N'Northwind'
Implementato in SP1
Se le tabelle di sistema della replica di tipo merge includono una quantità elevata di metadati, è possibile ottenere un miglioramento delle prestazioni riorganizzando i metadati. Prima del rilascio di SQL Server 2000 SP1, era possibile riorganizzare metadati solo tramite la stored procedure sp_mergecleanupmetadata. In SQL Server 2000 SP1 e versioni successive è stata implementata la funzione di riorganizzazione dei metadati basata sul periodo di memorizzazione che consente di eliminare automaticamente i metadati dalle tabelle di sistema seguenti:
Nota Le tabelle con immagini pre-aggiornamento sono presenti se per la pubblicazione è stata attivata l'opzione di ottimizzazione della sincronizzazione @keep_partition_changes.
La riorganizzazione dei metadati basata sul periodo di memorizzazione si verifica nelle condizioni seguenti:
Nota Il parametro -MetadataRetentionCleanup è impostato su 1 per tutti i profili degli agenti di merge inclusi in SQL Server 2000 SP1 e versioni successive. Se si esegue l'aggiornamento di un server installando SP1 o versioni successive e si aggiunge quindi la replica di tipo merge, il profilo dell'agente di merge viene aggiornato automaticamente in modo da includervi questo parametro. Se si esegue l'aggiornamento installando SP1 o SP3 in un server in cui la replica di tipo merge è già attivata, il profilo dell'agente di merge non viene aggiornato automaticamente. Per aggiornarlo è necessario eseguire sp_add_agent_parameter (vedere Parametri di sp_add_agent_parameter aggiuntivi più avanti in questa sezione).
Importante Il periodo di memorizzazione predefinito per le pubblicazioni è 14 giorni. Se un articolo appartiene a più pubblicazioni, è possibile che esistano periodi di memorizzazione diversi. In questo caso, viene utilizzato il periodo di memorizzazione più lungo per determinare il momento in cui verrà eseguita la prima riorganizzazione. Se in un database sono disponibili più pubblicazioni di cui una utilizza un periodo di memorizzazione infinito (@retention=0), la riorganizzazione dei metadati di merge per il database non viene eseguita automaticamente. È pertanto opportuno utilizzare il periodo di memorizzazione infinito con cautela.
Per la stored procedure di sistema sp_add_agent_parameter è ora disponibile il nuovo parametro MetadataRetentionCleanup, che consente di includere o escludere dai profili degli agenti di merge la funzione di riorganizzazione dei metadati basata sul periodo di memorizzazione. Se il parametro è impostato su 1, la funzione di riorganizzazione viene inclusa nel profilo. Se invece è impostato su 0, la funzione di riorganizzazione viene esclusa. La stored procedure seguente, ad esempio, consente di includere la funzione di riorganizzazione dei metadati basata sul periodo di memorizzazione in un profilo:
EXEC sp_add_agent_parameter @profile_id=<my_profile_id>, @parameter_name='MetadataRetentionCleanup', @parameter_value=1Per consentire la riorganizzazione automatica dei metadati basata sul periodo di memorizzazione in un database coinvolto nella replica di tipo merge, è necessario che il database e l'agente di merge siano inclusi entrambi nei server in cui è in esecuzione SQL Server 2000 SP1 o versione successiva. Ad esempio:
L'esecuzione della riorganizzazione automatica soltanto in alcuni server comporta al massimo la generazione di falsi conflitti, che dovrebbero essere comunque rari. Nel caso di topologie che includono versioni di SQL Server precedenti a SQL Server 2000 SP1, è possibile ottenere un miglioramento delle prestazioni eseguendo sp_mergemetadatacleanup in tutti i server in cui la riorganizzazione dei metadati non viene eseguita in modo automatico.
La riorganizzazione dei metadati basata sul periodo di memorizzazione consente di evitare sovrascritture non convergenti e automatiche delle modifiche ad altri nodi. È tuttavia possibile che si verifichino falsi conflitti se vengono soddisfatte le condizioni seguenti:
Ad esempio, se i metadati vengono riorganizzati nel server di pubblicazione ma non in quello di sottoscrizione e quindi viene implementato un aggiornamento nel server di pubblicazione, si verificherà un conflitto anche se i metadati sembrano sincronizzati.
Per evitare questo tipo di conflitti, assicurarsi che i metadati vengano riorganizzati contemporaneamente in tutti i nodi correlati. Se il parametro -MetadataRetentionCleanup è impostato su 1, la riorganizzazione viene eseguita automaticamente nel server di pubblicazione e in quello di sottoscrizione prima dell'avvio dell'operazione di merge. In tal modo la riorganizzazione viene eseguita contemporaneamente in tutti i nodi interessati. In caso di conflitto, tramite il visualizzatore dei conflitti della replica di tipo merge esaminare il conflitto e apportare eventuali modifiche.
Se un articolo appartiene a più pubblicazioni oppure a scenari di ripubblicazione, è possibile che il periodo di memorizzazione per una riga specifica a livello del server di pubblicazione sia diverso da quelli del server di sottoscrizione. Per ridurre il rischio di riorganizzazione dei metadati in un database ma non nell'altro, è consigliabile impostare per le pubblicazioni periodi di memorizzazione diversi.
Nota Se nelle tabelle di sistema è presente una grande quantità di metadati da riorganizzare, l'esecuzione del processo di merge potrebbe richiedere molto tempo. Per evitare questo problema, è consigliabile eseguire la riorganizzazione dei metadati a intervalli regolari.
Implementato in SP1
Un database di pubblicazione ripristinato da una copia di backup dovrebbe essere innanzitutto sincronizzato con un database di sottoscrizione a cui è associato un tipo di sottoscrizione globale, ovvero una sottoscrizione con un valore di priorità assegnato, in modo da garantire il corretto funzionamento della convergenza. La sincronizzazione garantisce che le modifiche perdute nel database di pubblicazione a causa dell'operazione di ripristino vengano implementate nuovamente in modo accurato.
Non sincronizzare il database di pubblicazione con un database di sottoscrizione a cui è associata una sottoscrizione anonima. Poiché per le sottoscrizioni anonime non è disponibile una quantità di metadati sufficiente per l'implementazione delle modifiche nel database di pubblicazione, tale sincronizzazione potrebbe generare dati non convergenti.
Quando si pianificano operazioni di backup e ripristino per la replica di tipo merge, è consigliabile considerare quanto segue:
Ripristinare un database di sottoscrizione da una copia di backup solo se la copia non è più vecchia del periodo di memorizzazione più breve di tutte le pubblicazioni che il server di sottoscrizione sottoscrive. Se, ad esempio, un server di sottoscrizione sottoscrive tre pubblicazioni il cui periodo di memorizzazione è pari a 10, 20 e 30 giorni rispettivamente, la copia di backup utilizzata per il ripristino del database non deve avere più di 10 giorni.
È consigliabile sincronizzare un server di sottoscrizione con il server di pubblicazione prima di eseguire un backup. Se non si esegue la sincronizzazione, in caso di ripristino del server di sottoscrizione da questo backup è possibile che la convergenza del sistema non venga eseguita correttamente. Anche se il file di backup stesso è recente, l'ultima sincronizzazione con un server di pubblicazione potrebbe coincidere con il periodo di memorizzazione. Si supponga, ad esempio, che il periodo di memorizzazione di una pubblicazione sia pari a 10 giorni. Si supponga inoltre che l'ultima sincronizzazione sia stata eseguita 8 giorni fa e che oggi venga eseguito il backup. Se il backup venisse eseguito quattro giorni più tardi, l'ultima sincronizzazione verrebbe eseguita dodici giorni prima, ovvero il periodo di memorizzazione sarebbe già trascorso. Se il server di sottoscrizione fosse stato sincronizzato correttamente prima del backup, il database di sottoscrizione rientrerebbe nel periodo di memorizzazione.
Se è necessario modificare il periodo di memorizzazione della pubblicazione, reinizializzare manualmente il server di sottoscrizione per evitare la mancata convergenza dei dati. La funzione di riorganizzazione dei metadati basata sul periodo di memorizzazione consente di eliminare i dati obsoleti dalle tabelle di sistema per la replica di tipo merge quando viene raggiunto il periodo di memorizzazione della pubblicazione.
In base al periodo di memorizzazione della pubblicazione viene stabilita la scadenza delle sottoscrizioni non sincronizzate entro il periodo di memorizzazione. Se dopo la riorganizzazione dei metadati si incrementa il periodo di memorizzazione della pubblicazione e una sottoscrizione tenta di eseguire il merge con il server di pubblicazione (in cui i metadati sono già stati eliminati), a causa dell'incremento del periodo di memorizzazione la sottoscrizione non scadrà. Inoltre, nel server di pubblicazione non è disponibile una quantità di metadati sufficiente per scaricare le modifiche apportate al server di sottoscrizione e si avrà pertanto una situazione di non convergenza.
Implementato in SP1
Il ripristino di un backup nel server e nel database che eseguono la stessa versione del server in cui è stato creato il backup consente di mantenere le impostazioni di replica. In caso di ripristino di un database replicato in una versione di SQL Server diversa dalla versione utilizzata per eseguire il backup del database, è consigliabile considerare quanto segue:
Implementato in SP1
In SP1 è stato aggiunto il nuovo parametro del prompt dei comandi -MaxCmdsInTran per Agente lettura log. Per le transazioni che interessano un elevato numero di comandi, in genere, aggiornamenti o eliminazioni di massa, Agente di distribuzione deve attendere che Agente lettura log scriva l'intera transazione nel database di distribuzione prima di poter avviare la propagazione della transazione nel server di sottoscrizione. Questo ritardo blocca Agente di distribuzione e riduce il parallelismo tra i due agenti.
Mediante l'utilizzo di –MaxCmdsInTran Agente lettura log frammenta le transazioni in blocchi più piccoli, dove ogni blocco contiene lo stesso numero di comandi o un numero inferiore rispetto all'input -MaxCmdsInTran. Pertanto, Agente di distribuzione può avviare l'elaborazione dei primi blocchi di una transazione mentre Agente lettura log sta ancora elaborando gli ultimi blocchi della stessa transazione.
Questo miglioramento nel parallelismo tra Agente lettura log e Agente di distribuzione comporta un miglioramento del throughput complessivo della replica. È tuttavia importante sottolineare che nel server di sottoscrizione viene eseguito il commit di questi blocchi come singole transazioni e di conseguenza la proprietà di atomicità, una delle proprietà ACID (atomicità, consistenza, isolamento e durata), non viene più rispettata. Nella maggior parte dei casi ciò non comporta alcun problema, ma è consigliabile eseguire una verifica.
Impostare il parametro -MaxCmdsInTran su un valore intero positivo (maggiore o uguale a 1). Se si specifica 0, il parametro non viene utilizzato. Poiché -MaxCmdsInTran comporta un miglioramento delle prestazioni solo se la transazione è di grandi dimensioni, in genere viene impostato su un valore maggiore o uguale a 5000, Ad esempio:
logread.exe -MaxCmdsInTran 10000. Per poter utilizzare questo parametro, è necessario che nel server di pubblicazione sia in esecuzione SQL Server 2000 SP1 o versione successiva e che Agente lettura log e Agente di distribuzione siano stati aggiornati a SP3. In caso contrario, il parametro verrà ignorato.
Implementato in SP2 e relativo solo alla replica transazionale
Non è possibile creare un indice cluster non univoco in una tabella dopo la pubblicazione della tabella per la replica transazionale. Prima di creare l'indice, è necessario eliminare le pubblicazioni che includono la tabella.
Implementato in SP2
Durante la normale elaborazione della replica di tipo merge vengono inviati ai server di sottoscrizione comandi DELETE per le righe non incluse nella partizione del server di sottoscrizione. L'operazione eseguita da questo tipo di comando DELETE viene denominata eliminazione irrilevante. Tali operazioni non hanno alcun impatto sull'integrità o la convergenza dei dati, ma possono generare traffico di rete inutile.
Per ridurre il traffico di rete generato da eliminazioni irrilevanti, è possibile utilizzare il nuovo parametro -MaxNetworkOptimization dell'agente snapshot con pubblicazioni per la replica di tipo merge. Impostando il parametro su 1, l'esecuzione di possibili eliminazioni irrilevanti viene ridotta al minimo, con la conseguente ottimizzazione massima delle prestazioni di rete.
Nota L'impostazione del parametro su 1 risulta utile solo quando l'opzione per l'ottimizzazione della sincronizzazione della pubblicazione di tipo merge è impostata su true (parametro @keep_partition_changes di sp_addmergepublication).
Il valore predefinito è 0. L'impostazione del parametro su 1 infatti può comportare un incremento dell'area di memorizzazione dei metadati e una diminuzione delle prestazioni a livello del server di pubblicazione se sono presenti più livelli di filtri join e filtri complessi. È importante valutare attentamente la topologia di replica e impostare -MaxNetworkOptimization su 1 solo se il traffico di rete generato da eliminazioni irrilevanti è estremamente elevato.
È possibile aggiungere questo parametro al profilo dell'agente snapshot eseguendo la stored procedure di sistema sp_add_agent_parameter:
EXEC sp_add_agent_parameter 1, 'MaxNetworkOptimization', 1Implementato in SP3
In SP3 viene creato automaticamente un nuovo ruolo per l'utilizzo nella replica di tipo merge chiamato MSmerge-<ID pubblicazione>. Il ruolo viene creato nel server di pubblicazione per le pubblicazioni per la replica di tipo merge e funge da elenco di accesso alla pubblicazione (PAL, Publication Access List) per il controllo dell'accesso alle pubblicazioni di tipo merge nel server di pubblicazione. Se il ruolo viene eliminato, è possibile eseguire una nuova stored procedure inclusa in SP3, sp_createmergepalrole, per ricrearlo. Questa stored procedure viene eseguita nel database di pubblicazione del server di pubblicazione per ricreare il ruolo.
sp_createmergepalrole [ @publication = ] 'publication'
[@publication = ] 'publication'
Nome della pubblicazione. publication è di tipo sysname e non prevede alcun valore predefinito. Questo parametro viene utilizzato per selezionare la pubblicazione da utilizzare per ricreare un ruolo impiegato dalla replica di tipo merge.
0 (esito positivo) o 1 (esito negativo)
L'esecuzione della stored procedure sp_createmergepalrole consente di aggiungere una nuova riga alla tabella sysusers per il nuovo ruolo. Il nome di questo nuovo ruolo si basa sul valore della colonna pubid nella tabella sysmergepublications per la pubblicazione specifica. Il prefisso del nome del ruolo è 'MSMerge_' e il valore pubid viene aggiunto (senza trattini) al nome del ruolo.
Solo i membri del ruolo predefinito del server sysadmin e del ruolo predefinito del database db_owner possono eseguire sp_createmergepalrole.
Implementato in SP3
Se una sottoscrizione è stata creata da un utente che non appartiene al ruolo predefinito del server sysadmin, è necessario eseguire una delle operazioni seguenti:
Nota Per l'attivazione dell'agente remoto è necessario che il passaggio del processo sia sempre eseguito in base all'account utente appartenente al ruolo predefinito del server sysadmin.
Implementato in SP3
Sono state modificate le autorizzazioni per una serie di stored procedure utilizzate per l'implementazione, l'amministrazione e il monitoraggio di una topologia di replica. La maggior parte delle modifiche prevede la necessità di autorizzazioni specifiche per l'esecuzione delle stored procedure. Per ulteriori informazioni sulle nuove autorizzazioni, vedere la documentazione di Transact-SQL per la replica delle stored procedure nella versione aggiornata della Documentazione in linea di SQL Server. Per ulteriori informazioni sulla versione aggiornata della Documentazione in linea di SQL Server, vedere la sezione 1.5 Disponibilità della versione aggiornata della Documentazione in linea.
Implementato in SP3
È stato aggiunto il nuovo parametro @published_in_tran_pub a sp_addmergearticle e sp_changemergearticle. Questo parametro è utilizzato per indicare che un articolo di una pubblicazione di tipo merge è pubblicato anche in una pubblicazione transazionale. @published_in_tran_pub è di tipo nvarchar(5) e il valore predefinito è FALSE. Il valore TRUE indica che l'articolo è pubblicato anche in una pubblicazione transazionale.
Nota Quando si modifica questo parametro in sp_changemergearticle, è necessario invalidare lo snapshot e reinizializzare i server di sottoscrizione.
Implementato in SP3
Nella Configurazione guidata pubblicazione e distribuzione è ora disponibile la nuova schermata Password server di distribuzione. Se sono stati selezionati uno o più server di pubblicazione che utilizzano il server come server di distribuzione remoto e se uno o più server di pubblicazione richiedono una password è necessario specificare una password in questa schermata. La connessione tra un server di pubblicazione e un server di distribuzione remoto corrisponde a una combinazione di server collegato e server remoto. La connessione utilizza l'account di accesso distributor_admin. Poiché per impostazione predefinita il server di pubblicazione non è configurato come server di tipo trusted presso il server di distribuzione, è necessaria una password.
Nota Se è stata scaricata e installata la Documentazione in linea di SQL Server 2000 (aggiornamento per SP3), questa informazione è disponibile facendo clic sul pulsante ? relativo alla nuova schermata.
Implementato in SP3
SQL Server consente di abilitare le sottoscrizioni esistenti (create con SQL Server Enterprise Manager, SQL-DMO e stored procedure di replica) per l'utilizzo con Gestione sincronizzazione Microsoft Windows. Con Gestione sincronizzazione Microsoft Windows è inoltre possibile creare nuove sottoscrizioni. Dopo aver applicato il service pack, quando si esegue la sincronizzazione di una sottoscrizione verrà richiesto di specificare la password o le password necessarie per la connessione ai server coinvolti nella sincronizzazione.
Implementato in SP3
Dopo aver installato SP3, per collegare o ripristinare un database pubblicato per la replica, è necessario che l'utente che esegue l'operazione appartenga al ruolo predefinito del server sysadmin e che il concatenamento della proprietà tra database sia attivato. Se questi requisiti non sono soddisfatti, è possibile eseguire la stored procedure sp_changedbowner nel database per assegnare la proprietà del database all'account di accesso amministrativo predefinito sa. In questo modo, la replica verrà eseguita in modo corretto.
Nota Per poter eseguire sp_changedbowner è necessario appartenere al ruolo predefinito del server sysadmin.
Per ulteriori informazioni sul concatenamento della proprietà tra database, vedere la sezione 5.1.11 Concatenamento della proprietà tra database.
In questa sezione vengono illustrati i miglioramenti relativi ad Agente SQL Server inclusi in SP3.
Implementato in SP2
Tramite la cronologia dei processi di Agente SQL Server viene ora registrato l'account in base al quale viene eseguito ogni processo. Ciò consente agli amministratori di diagnosticare eventuali problemi di protezione a livello di processi pianificati, inclusi i processi pianificati definiti per la replica e le attività DTS (Data Transformation Services).
Implementato in SP3
L'amministrazione multiserver è il processo di automatizzazione dell'amministrazione in più istanze di SQL Server. Utilizzare l'amministrazione multiserver se, in caso di gestione di due o più server, si desidera centralizzare le attività di manutenzione.
In SP3 l'account di servizio di Agente SQL Server non deve essere un amministratore di Windows, a meno che non sia necessario utilizzare l'account delegato di Agente SQL Server. Per ulteriori informazioni sull'account delegato di Agente SQL Server, vedere la sezione 5.7.3 Miglioramenti relativi all'account delegato di Agente SQL Server. L'account di servizio di Agente SQL Server deve essere un membro del ruolo predefinito del server sysadmin.
Una configurazione di amministrazione multiserver è costituita da almeno un server master e almeno un server target. Il server master distribuisce processi ai server target e riceve eventi da tali server. Nel server master è archiviata la copia centrale delle definizioni di processo per i processi eseguiti nei server target. I server target stabiliscono connessioni periodiche al server master per aggiornare l'elenco dei processi da eseguire. Se è disponibile un nuovo processo, questo viene scaricato dal server target, che quindi si disconnette dal server master. Dopo il completamento del processo, il server target stabilisce una nuova connessione al server master e trasmette lo stato del processo.
Prima di installare SP3, è necessario completare alcune procedure per aggiornare la configurazione server master/target corrente di SQL Server 2000. Le modifiche introdotte con SP3 non sono compatibili con i server target di SQL Server 7.0 o con qualsiasi server in cui non venga eseguito SP3. Si tratta di una modifica rispetto alla funzionalità originale di SQL Server 2000.
Per aggiornare la configurazione server master/target corrente
--Opzione A: autenticazione di Windows
EXEC sp_grantlogin 'DOMINIO\utente'
GO
USE msdb
GO
EXEC sp_adduser 'DOMINIO\utente', 'DOMINIO\utente', 'TargetServersRole'
GO
--Opzione B: autenticazione di SQL Server – vedere la spiegazione riportata di seguito per
--ulteriori informazioni.
EXEC sp_addlogin <AccountMSX>, <PasswordAccountMSX>, 'msdb'
GO
USE msdb
GO
EXEC sp_adduser <AccountMSX>, <AccountMSX>, 'TargetServersRole'
GODove <AccountMSX> è il nome dell'account di accesso SQL scelto e <PasswordAccountMSX> è la password corrispondente.
Nota Questi valori devono essere racchiusi tra virgolette singole.
Durante la selezione di un account MSX sono disponibili le seguenti opzioni:
Non specificare un account di tipo probe di Agente SQL Server (<nome_computer>_msx_probe_login). Durante l'aggiornamento a SP3, in SQL Server vengono rimossi gli account di tipo probe obsoleti perché non vengono più utilizzati dai server TSX.
Nota Dopo l'esecuzione di xp_sqlagent_msx_account, è necessario interrompere e riavviare Agente SQL in ogni server.
Per ulteriori informazioni su xp_sqlagent_msx_account, vedere la sezione 5.4.3 Nuova stored procedure estesa di Agente SQL Server.
Implementato in SP3
In SP3 è disponibile una nuova stored procedure estesa che consente di configurare l'account utilizzato dal server TSX di Agente SQL Server per scaricare le istruzioni da un server MSX. Tale account è conosciuto anche come account MSX oppure account del server master.
La stored procedure estesa xp_sqlagent_msx_account consente di impostare o recuperare il nome utente e la password dell'account MSX di Agente SQL Server a livello di informazioni riservate dell'autorità di protezione locale (LSA, Local Security Authority) nel server TSX. Solo i membri del ruolo predefinito del server securityadmin possono eseguire questa stored procedure estesa.
Per poter eseguire la stored procedure, è necessario che Agente SQL Server sia in esecuzione. Inoltre, se l'account specificato è un account di accesso di SQL Server, Agente SQL Server deve disporre di diritti di amministratore locali di Windows. In Agente SQL Server il nome utente e la password vengono archiviati come informazioni riservate dell'autorità di protezione locale (LSA) e pertanto l'accesso è limitato agli amministratori locali di Windows.
xp_sqlagent_msx_account
{N'GET' |
N'SET' | N'DEL', N'MSX_domain_name', N'MSX_username', N'MSX_password'
}
N'GET'
Recupera l'account MSX corrente di Agente SQL Server. N'GET' è di tipo nvarchar e non prevede alcun valore predefinito. La password non viene restituita per motivi di protezione.
N'SET'
Imposta l'account da utilizzare come account MSX di Agente SQL Server. Utilizzare i parametri MSX_username e MSX_password per specificare l'account da utilizzare come account MSX di Agente SQL Server. N'SET' è di tipo nvarchar e non prevede alcun valore predefinito.
N'DEL'
Elimina l'account MSX di Agente SQL Server.
'MSX_domain_name'
Riservato per utilizzi futuri.
'MSX_username'
Nome dell'account di Windows da utilizzare come account MSX di Agente SQL Server. Specificare una stringa vuota per questo parametro e per MSX_password per impostare la protezione di Windows. In questo caso, per accedere al server MSX verranno utilizzate le credenziali dell'account di servizio di Agente SQL Server. MSX_username è di tipo nvarchar e non prevede alcun valore predefinito.
'MSX_password'
Password per l'account di SQL Server specificata nel parametro MSX_username. Specificare una stringa vuota per questo parametro e per MSX_username per impostare la protezione di Windows. In questo caso, per accedere al server MSX verranno utilizzate le credenziali dell'account di servizio di Agente SQL Server. MSX_password è di tipo nvarchar e non prevede alcun valore predefinito.
Nota I parametri di xp_sqlagent_msx_account devono essere specificati nell'ordine indicato. Non è consentito utilizzare parametri denominati.
0 (esito positivo) o 1 (esito negativo).
Quando l'esecuzione di xp_sqlagent_msx_account ha esito negativo e restituisce 1, viene generato un messaggio di errore che include informazioni sull'errore stesso.
Se è stato impostato un account MSX di Agente SQL Server, xp_sqlagent_msx_account restituisce un set di risultati che, quando si specifica N'GET', include le informazioni seguenti.
| Nome colonna | Tipo di dati | Descrizione |
|---|---|---|
| domain | sysname | N/D - riservato per utilizzi futuri |
| username | sysname | Account utilizzato come account MSX di Agente SQL Server. |
Se non è stato impostato un account MSX di Agente SQL Server, oppure si specifica N'SET', non viene restituito alcun risultato.
Le autorizzazioni di esecuzione per xp_sqlagent_msx_account vengono assegnate per impostazione predefinita ai membri del ruolo predefinito del server securityadmin.
Nell'esempio seguente viene recuperato l'account assegnato per l'utilizzo come account MSX di Agente SQL Server:
EXEC master.dbo.xp_sqlagent_msx_account N'GET'Nell'esempio seguente l'account MSX di Agente SQL Server viene impostato in modo che utilizzi l'autenticazione di Windows:
EXEC master.dbo.xp_sqlagent_msx_account N'SET',
N'', -- Riservato per utilizzi futuri
N'', -- MSX_username
N'' -- MSX_passwordNell'esempio seguente l'account MSX di Agente SQL Server viene impostato su Ralph con una password:
EXEC master.dbo.xp_sqlagent_msx_account N'SET',
N'', -- Riservato per utilizzi futuri
N'Ralph', -- MSX_username
N'RalphPwd' -- MSX_passwordNell'esempio seguente l'account MSX di Agente SQL Server viene eliminato. Ciò significa che Agente SQL Server utilizzerà per impostazione predefinita la protezione integrata di Windows a livello di autenticazione.
EXEC master.dbo.xp_sqlagent_msx_account N'DEL'Implementato in SP3
In SQL Server viene ora eseguito un controllo per verificare che il proprietario del processo di Agente SQL Server disponga delle autorizzazioni necessarie per aggiungere o sovrascrivere il file di log di output di ogni processo. Si possono verificare tre casi:
In ogni caso, i processi vengono scritti utilizzando le credenziali di Agente SQL Server anche se viene verificato che l'utente disponga delle autorizzazioni necessarie per scrivere nella posizione del file di log di output selezionata nel server. Gli errori vengono riportati nella cronologia del processo. I passaggi del processo verranno eseguiti comunque anche nel caso in cui risulti impossibile scrivere il file di log.
In questa sezione vengono illustrati i miglioramenti relativi ai componenti di connettività di SQL Server 2000 inclusi in SP3.
Implementato in SP3
SP3 include gli aggiornamenti a Microsoft Data Access Components (MDAC). Durante l'installazione di SP3 viene installato anche MDAC 2.7 Service Pack 1. MDAC 2.7 SP1 non include modifiche alle funzionalità della versione di MDAC installata con SQL Server 2000 (MDAC 2.6), bensì correzioni e miglioramenti relativi alla protezione. MDAC 2.71 include un aggiornamento a MSXML 3 SP3.
Nota Questa versione di MDAC non viene installata se viene rilevata la stessa versione o una versione più recente.
Per ulteriori informazioni su questa versione di MDAC, visitare il sito Web Microsoft Universal Data Access all'indirizzo microsoft.com. Le correzioni incluse in questa versione di MDAC saranno illustrate nell'articolo 326848 della Knowledge Base del Servizio Supporto Tecnico Clienti Microsoft (informazioni in lingua inglese).
Implementato in SP3
In SQL Server è ora previsto il supporto per le implementazioni SAN (System Area Network) con architettura VIA (Virtual Interface Architecture) QLogic. Per abilitare il supporto delle connessioni attraverso l'architettura VIA QLogic, è necessario che nei computer client e server venga eseguita la risoluzione degli indirizzi IP in un file chiamato Vihosts contenuto nell'apposita cartella system32\drivers\etc di Windows.
Il file Vihosts deve avere il formato seguente:
<Indirizzo IP VI del computer server> <NOMECOMPUTER_SERVER>
<Indirizzo IP VI del computer client> <NOMECOMPUTER_CLIENT>
Ad esempio:
139.4.130.1 SQLCOMPUTER
139.4.130.2 SQLCLIENT
Utilizzare gli indirizzi IP delle schede di rete VIA QLogic corrispondenti e i nomi effettivi dei computer. In caso contrario, non sarà possibile stabilire una connessione alle istanze denominate o con protocolli IP diversi, ad esempio TCP o Named Pipes. Il file Vihosts non è necessario per la connettività VIA Giganet.
Nota È necessario individuare il fornitore VIA corretto nei computer client mediante l'utilità Configurazione di rete client. Selezionare la voce desiderata nell'elenco a discesa Produttore. È necessario eseguire questa operazione anche nei computer server mediante l'utilità Configurazione di rete di SQL Server.
In questa sezione vengono illustrati i miglioramenti relativi a SQL Server 2000 Meta Data Services inclusi in SP3.
Implementato in SP1
In Visualizzatore metadati ora sono supportate le esportazioni dei metadati XML in Unicode. Prima di SQL Server 2000 SP1 in Visualizzatore metadati era possibile esportare codice ANSI, che non supportava i caratteri non inglesi. Questa modifica di carattere funzionale non è visibile all'utente. A partire dalla versione corrente del SP3, i dati esportati sono sempre in formato Unicode. È ancora possibile eseguire le esportazioni in codice ANSI impostando su 0 la chiave del Registro di sistema HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Repository\Engine\XMLExport. Nell'elenco seguente sono riportati i possibili valori per questa chiave del Registro di sistema:
Per ulteriori informazioni su questi flag, vedere "IExport::Export Method" nella Documentazione in linea di SQL Server (informazioni in lingua inglese).
Implementato in SP3
Nei modelli informativi è stato disattivato il supporto per l'esecuzione di script. Dopo l'installazione di SP3, verrà restituito l'errore seguente se l'applicazione in uso accede a una proprietà o a un metodo per cui è stato definito uno script:
EREP_SCRIPTS_NOTENABLEDPer attivare il supporto per l'esecuzione di script
Se è necessario eseguire script, seguire la procedura seguente per creare un'impostazione del Registro di sistema che consenta l'esecuzione di script.
Per disattivare l'esecuzione di script in un momento successivo, impostare questa nuova chiave del Registro di sistema su 0.
Importante Per impedire l'accesso non autorizzato è consigliabile proteggere i modelli informativi e il database repository.
Implementato in SP3
Nel database msdb di SQL Server sono incluse tabelle, stored procedure e viste che contengono le informazioni utilizzate dal motore del repository di Meta Data Services. In SP3 è stato aggiunto un nuovo ruolo dedicato chiamato RepositoryUser che deve essere utilizzato per accedere e aggiornare le informazioni del repository. Questo ruolo dispone delle autorizzazioni necessarie per le operazioni di creazione, lettura, aggiornamento, eliminazione ed esecuzione relative a questi oggetti. Il ruolo public non dispone più delle autorizzazioni per questi oggetti.
Questa modifica interessa gli oggetti del repository esistenti nonché tutti gli altri oggetti creati in futuro dal motore del repository. Gli utenti e le applicazioni che accedono al repository attraverso il ruolo public devono essere aggiunti al ruolo RepositoryUser.
In questa sezione vengono illustrati i miglioramenti relativi a SQL Server 2000 Data Transformation Services inclusi in SP3.
Implementato in SP2
Durante l'esportazione di dati in un file di testo tramite Importazione/Esportazione guidata DTS il pacchetto viene ora configurato in modo da supportare la scrittura di 8000 caratteri nelle colonne contenenti dati di tipo String.
Implementato in SP2
Agente SQL Server registra il contesto di protezione in cui viene eseguito ogni passaggio di un processo. A partire da SP3 il contesto di protezione è riportato nella finestra di dialogo Cronologia processo. Quando si esegue un pacchetto DTS da un passaggio di un processo, Agente SQL Server registra l'account utente in base al quale viene eseguito il pacchetto. Ciò consente agli amministratori di eseguire la diagnosi dei problemi a livello di autorizzazione e autenticazione che si verificano quando è stata pianificata l'esecuzione dei pacchetti DTS in un server.
Implementato in SP2
Prima del rilascio di SP3, non era possibile eseguire i pacchetti DTS archiviati nel server in base alle credenziali dell'account delegato di Agente SQL Server, a meno che all'account delegato non fossero associate autorizzazioni di accesso per la cartella Temp dell'utente dell'account in base a cui veniva eseguito il server nel caso di processi eseguiti da xp_cmdshell o l'agente nel caso di processi dell'agente. Di conseguenza l'utente doveva spesso modificare la variabile di ambiente TEMP in modo che l'account di avvio di SQL Server o Agente SQL Server puntasse a una directory accessibile sia tramite l'account di avvio sia tramite l'account delegato, ad esempio la directory C:\Temp. Con SP3 DTS è stato migliorato in modo che, se la cartella Temp dell'utente non è disponibile, venga utilizzata la cartella di sistema Temp, riducendo notevolmente la necessità di modificare la variabile di ambiente.
Implementato in SP3
Per impostazione predefinita, in SP3 l'opzione per l'archiviazione dei pacchetti DTS in Meta Data Services è disattivata. Ciò significa che nella finestra di dialogo Salva pacchetto DTS l'opzione Meta Data Services non è inclusa nell'elenco a discesa Posizione. L'opzione è inoltre disattivata nella schermata Salva, pianifica e replica pacchetto dell'Importazione/Esportazione guidata DTS.
Per consentire il salvataggio dei pacchetti in Meta Data Services
Nota Per modificare questa proprietà è necessario connettersi con privilegi amministrativi.
Se l'opzione per l'archiviazione dei pacchetti in Meta Data Services è disattivata, è possibile caricare i pacchetti esistenti da Meta Data Services, modificarli e quindi salvarli in Meta Data Services mediante il comando Salva. Meta Data Services non è tuttavia disponibile se si sceglie il comando Salva con nome. Ad esempio, non è possibile salvare nuovo un pacchetto in Meta Data Services utilizzando un nome diverso.
Nella sezione seguente è illustrato un miglioramento relativo a XML e SQLXML incluso in SP3.
Implementato in SP3
Prima del rilascio di SP3, nella versione di MSXML installata con SQL Server 2000 (MSXML 2.6) nei predicati delle espressioni XPath era possibile utilizzare il carattere speciale di abbreviazione, un punto (.), per identificare il nodo di contesto corrente. Ciò viola la specifica della sintassi XPath, in base a cui questo carattere deve essere seguito da un'espressione del percorso di posizione.
Durante l'installazione di SP3 viene installata una versione aggiornata di MSXML (3.0 SP3) come parte dell'aggiornamento di MDAC. Per ulteriori informazioni, vedere la sezione 5.5.1 Aggiornamenti relativi a Microsoft Data Access Components.
Nella nuova versione di MSXML non è possibile specificare un predicato immediatamente dopo il carattere speciale di abbreviazione per il nodo di contesto corrente. Dopo l'aggiornamento a SP3, le espressioni XPath nelle query SQLXML (query XPath su schemi di mapping annotati e in fogli di stile XSLT creati per trasformare i risultati delle query SQLXML) che utilizzano la vecchia sintassi avranno esito negativo.
Per evitare questi problemi, identificare e correggere le espressioni che utilizzano una sintassi errata. Ad esempio, la sintassi dell'espressione XPath che è specificata come valore dell'attributo di test nell'elemento xsl:if seguente non è valida perché il predicato [@ResourceTypeID='2'] è posto immediatamente dopo il carattere speciale di abbreviazione che identifica il nodo di contesto corrente.
Dopo l'installazione di SP3, l'istruzione seguente, che in precedenza non restituiva errori, avrà esito negativo.
<xsl:if test=".[@ResourceTypeID='2']">Per evitare questo problema, correggere l'espressione XPath come illustrato di seguito:
<xsl:if test="@ResourceTypeID='2'">Nelle sezioni seguenti vengono fornite informazioni sull'API Virtual Backup Device di SQL Server 2000.
Implementato in SP2
L'API Virtual Backup Device consente l'integrazione di SQL Server 2000 nei prodotti dei fornitori di software indipendenti (ISV). Questa API, che è stata creata allo scopo di ottenere il massimo grado di affidabilità e prestazioni ottimali, supporta la funzionalità di backup e ripristino di SQL Server 2000, con l'intera gamma di funzioni di backup "a caldo" e snapshot.
In SP1 e versioni precedenti non era possibile bloccare ed eseguire il backup di più database contemporaneamente. SP3 implementa il supporto del lato server per il blocco e l'acquisizione di più database in un singolo snapshot tramite il comando VDC_PrepareToFreeze.
La specifica dell'API Virtual Backup Device di SP3 include informazioni aggiornate su questo comando. In \Devtools\Include nella directory di installazione di SP3 è disponibile una versione aggiornata del file di intestazione dell'interfaccia Virtual Device Interface (Vdi.h).
È possibile scaricare la specifica aggiornata dal sito Web di download Microsoft SQL Server (informazioni in lingua inglese).
Implementato in SP3
In Microsoft SQL Server la segnalazione degli errori è disattivata per impostazione predefinita. È possibile abilitare questa funzione durante l'installazione di SQL Server o Analysis Services, oppure successivamente mediante la finestra di dialogo delle proprietà del server in Enterprise Manager o in Analysis Manager. Se si attiva la funzione durante l'installazione di SQL Server, verranno segnalati gli errori relativi al motore di database di SQL Server e all'Agente SQL Server. Se invece la si attiva durante l'installazione di Analysis Services, verranno segnalati gli errori relativi ad Analysis Services. Per abilitare la funzione sia per SQL Server sia per Analysis Services, è necessario abilitare la segnalazione degli errori per SQL Server durante l'installazione di SQL Server e per Analysis Services durante l'installazione di Analysis Services.
In questo caso verrà configurato l'invio automatico di un report a Microsoft se si verifica un errore irreversibile nel motore di database di SQL Server, in Agente SQL Server o in SQL Server Analysis Services. Tali report, considerati riservati, vengono utilizzati da Microsoft per migliorare le funzionalità di SQL Server.
Le informazioni relative agli errori vengono inviate mediante una connessione protetta (HTTPS) a Microsoft, dove sono archiviate con accesso limitato. In alternativa, le informazioni possono essere inviate al server aziendale che gestisce la segnalazione degli errori. Visitare il sito Web Microsoft (informazioni in lingua inglese) per ulteriori informazioni sulla configurazione di un server aziendale per la gestione della segnalazione degli errori.
Nel report degli errori sono contenute le seguenti informazioni:
Microsoft non ha lo scopo di raccogliere file, nomi, indirizzi, indirizzi di posta elettronica o qualsiasi altra informazione personale. È tuttavia possibile che il report contenga informazioni specifiche del cliente derivanti dalla memoria o dai file del processo che ha generato l'errore. Le informazioni raccolte possono contenere informazioni personali. Tuttavia, tali informazioni non saranno utilizzate da Microsoft in alcun modo se non per gli scopi sopra menzionati.
Per ulteriori informazioni sui criteri adottati da Microsoft per la raccolta dei dati relativi alla segnalazione degli errori, visitare il sito Web Microsoft (informazioni in lingua inglese).
Se dopo avere abilitato la funzione di segnalazione degli errori si verifica un errore irreversibile, è possibile che venga visualizzata una risposta da Microsoft nel log eventi di Windows che fa riferimento a un articolo della Microsoft Knowledge Base relativo all'errore specifico. Di seguito è riportato un esempio di risposta:
Origine = MSSQLServerOlapServicesDW
ID evento = 1010
dati = http://support.microsoft.com/support/misc/kblookup.asp?id=Q123456&iBucketTable=1&iBucket=39980&Cab=21474432.cab&LCID=1033&OS=5.1.2600.2.00010100.0.0Per disabilitare la funzione di segnalazione degli errori per il motore di database di SQL Server e Agente SQL Server, visualizzare la finestra di dialogo Proprietà SQL Server (scheda Generale) in Enterprise Manager e deselezionare la casella di controllo Abilita la funzionalità di segnalazione degli errori. Per disabilitare la funzione di segnalazione degli errori per Analysis Services, visualizzare la finestra di dialogo delle proprietà del server in Analysis Manager e deselezionare la casella di controllo Abilita la funzionalità di segnalazione degli errori. Se la funzione è stata abilitata sia per SQL Server (motore di database e Agente SQL Server) sia per Analysis Services, è necessario disabilitarla individualmente per ogni applicazione.
Implementato in SP1
Microsoft ha rilasciato un miglioramento della funzione di protezione per le applicazioni che supportano English Query, che non viene però installato durante l'installazione del service pack. In caso di utilizzo di English Query è tuttavia consigliabile implementarlo. Il miglioramento della funzione di protezione è incluso nella cartella \EQHotfix nel CD di SP3. Per ulteriori informazioni sui miglioramenti apportati a English Query, vedere la Knowledge Base del Servizio Supporto Tecnico Clienti Microsoft ed eseguire la ricerca dell'articolo 297105 (informazioni in lingua inglese).
Implementato in SP1
Il supporto per DB-Library e Embedded SQL per API in C è stato implementato anche in SQL Server 2000, ma nelle future versioni di SQL Server non verranno inclusi i file necessari per la programmazione di applicazioni che supportano queste API. Le connessioni tra applicazioni esistenti scritte tramite DB-Library ed Embedded SQL per C saranno supportate nella prossima versione di SQL Server, ma non nelle versioni successive. È pertanto consigliabile evitare l'utilizzo di questi componenti durante lo sviluppo di nuove applicazioni. Nel caso di modifica di applicazioni esistenti è consigliabile rimuovere le dipendenze basate su queste tecnologie. Per l'accesso ai dati archiviati in SQL Server è possibile utilizzare ADO, OLE DB o ODBC anziché DB-Library o Embedded SQL per C. Per ulteriori informazioni su queste tecnologie, vedere la Documentazione in linea di SQL Server.