Calcolare la durata del processo di aggiornamento e lo spazio necessario (SharePoint Foundation 2010)
Si applica a: SharePoint Foundation 2010
Ultima modifica dell'argomento: 2016-11-30
Un aspetto importante della pianificazione di un aggiornamento da Windows SharePoint Services 3.0 a Microsoft SharePoint Foundation 2010 consiste nel determinare la durata del processo di aggiornamento e lo spazio di archiviazione necessario. Ogni ambiente è unico e include capacità hardware e caratteristiche di siti diverse. La quantità di spazio e il tempo necessari per eseguire un aggiornamento pertanto variano in modo significativo a seconda dell'ambiente. Il modo migliore per valutare questi aspetti consiste nell'eseguire un aggiornamento di prova e quindi nell'esaminare lo spazio utilizzato e i tempi richiesti. Per ulteriori informazioni sull'esecuzione di un aggiornamento di prova, vedere Utilizzare un aggiornamento di prova per individuare possibili problemi (SharePoint Foundation 2010).
Contenuto dell'articolo:
Stimare lo spazio necessario per l'aggiornamento
Stimare la durata dell'aggiornamento
Stimare lo spazio necessario per l'aggiornamento
Durante un aggiornamento sul posto o basato sul collegamento di database è possibile che le dimensioni dei database aumentino. Poiché inoltre durante il processo di aggiornamento vengono eseguite molte transazioni, verificare che i file di registro dispongano di spazio sufficiente per le modifiche. È necessario pertanto pianificare un aumento delle dimensioni sia per i database che per i file di registro.
Quando si pianifica un aggiornamento, accertarsi che l'ambiente corrente sia conforme alle procedure consigliate per l'archiviazione relative a Windows SharePoint Services 3.0 in modo da usufruire di un'esperienza e di prestazioni ottimali durante l'aggiornamento. Per ulteriori informazioni, vedere Suggerimenti per l'archiviazione fisica (Office SharePoint Server). Esaminare inoltre le procedure consigliate per SharePoint Foundation 2010 e apportare le eventuali modifiche necessarie per l'ambiente aggiornato.
A causa delle modifiche apportate alle strutture delle tabelle nella nuova versione, le dimensioni dei database aumentano temporaneamente durante la riorganizzazione dei dati. Questo spazio può essere recuperato dopo l'aggiornamento, ma è consigliabile verificare che vi sia spazio sufficiente per un aumento delle dimensioni dei database fino al 50% delle dimensioni correnti durante un aggiornamento sul posto o basato sul collegamento di database. Tenere presente che dopo l'aggiornamento è possibile ridurre di nuovo le dimensioni dei database per recuperare la maggior parte di questo spazio. Verificare inoltre che vi sia spazio sufficiente nei server di database per l'aumento delle dimensioni dei database dovuto al normale utilizzo. Per determinare la dimensione corrente dei database, utilizzare Enterprise Manager in Microsoft SQL Server. Oltre allo spazio per i database, verificare di disporre di spazio sufficiente per gli elementi seguenti:
Database temporanei. Assicurarsi di disporre di spazio sufficiente nei database per consentire una rapida crescita dei database temporanei. In caso contrario, è possibile che si verifichi il timeout del processo di aggiornamento e che l'aggiornamento abbia esito negativo.
File di registro dell'aggiornamento.
File di registro delle transazioni per i database. Le dimensioni di questi file di registro devono aumentare rapidamente per adeguarsi al numero di modifiche effettuate nei database.
Nota
In ambienti di dimensioni elevate è possibile che la percentuale predefinita di aumento delle dimensioni dei file di registro delle transazioni (10%) non sia sufficiente per il processo di aggiornamento e che si verifichi pertanto un timeout. Anche in questo caso, l'esecuzione di un aggiornamento di prova è il modo migliore per stabilire se i file di registro delle transazioni sono adeguati al processo di aggiornamento. Se l'ambiente è molto esteso o se si verifica un timeout del processo durante l'aggiornamento di prova, valutare la possibilità di aumentare anticipatamente le dimensioni dei file di registro delle transazioni di SQL Server per assicurarsi che sia disponibile lo spazio sufficiente per il numero di transazioni che dovranno essere elaborate. Per ulteriori informazioni sull'aumento delle dimensioni dei registri delle transazioni di SQL Server, vedere Espansione di un database (SQL Server 2005) (https://go.microsoft.com/fwlink/?linkid=182619&clcid=0x410) oppure Espansione di un database (SQL Server 2008) (https://go.microsoft.com/fwlink/?linkid=182620&clcid=0x410).
Stimare la durata dell'aggiornamento
Avendo a disposizione le stime dello spazio su disco necessario e i risultati di alcuni test, è ora possibile calcolare una stima approssimativa della durata del processo di aggiornamento vero e proprio. La durata dell'aggiornamento varia in modo significativo da un ambiente all'altro e dipende dall'hardware utilizzato, dalla complessità dei siti e dalle caratteristiche specifiche dell'implementazione. Se ad esempio è presente un numero elevato di raccolte documenti di grandi dimensioni, sarà necessario più tempo rispetto all'aggiornamento di un sito più semplice.
Nella tabella riportata di seguito vengono descritti i fattori che hanno effetto sulle prestazioni.
| Fattori correlati al contenuto | Fattori correlati all'hardware |
|---|---|
Numero di:
Oltre alle dimensioni totali dei database stessi. |
|
Il modo in cui sono strutturati i dati può influire sul tempo necessario per l'aggiornamento. 10.000 elenchi contenenti ognuno 10 voci ad esempio richiederanno un tempo di aggiornamento superiore rispetto a 10 elenchi contenenti ognuno 10.000 voci. Poiché le azioni da eseguire per aggiornare l'infrastruttura degli elenchi devono essere eseguite per ogni elenco, indipendentemente dal numero di voci, più sono gli elenchi maggiore sarà il numero di azioni da eseguire. La stessa regola si applica per la maggior parte degli elementi della colonna "Fattori correlati al contenuto" nella tabella sopra riportata.
Anche la struttura dell'hardware può influire in modo significativo sulle prestazioni. Le prestazioni del server di database in genere sono più importanti delle prestazioni del server Web, ma un hardware inadeguato o problemi di connettività a qualsiasi livello possono influire in modo significativo sulle prestazioni di un aggiornamento.
Il metodo di aggiornamento scelto è un altro fattore importante che influisce sul tempo necessario per il processo. L'aggiornamento basato sul collegamento di database è il metodo più rapido, anche se i passaggi di pre- e post-aggiornamento previsti da questo metodo richiedono più tempo rispetto a un aggiornamento sul posto. Un aggiornamento sul posto richiede un po' più di tempo poiché non vengono aggiornati solo i siti ma anche l'ambiente, tuttavia non prevede un numero altrettanto elevato di passaggi di pre- e post-aggiornamento.
Il modo migliore per stimare il tempo globale consiste nell'eseguire un aggiornamento di prova di una parte o di tutti i dati e quindi nell'esaminare i file di registro dell'aggiornamento. Nei file di registro viene indicata la durata dell'aggiornamento nella sezione Total Elapsed Time nella parte inferiore. Utilizzare questo valore per stimare una durata per l'intero contenuto. È inoltre possibile utilizzare i file di registro per verificare lo stato del processo di aggiornamento mentre è in corso. Il file upgrade.log è disponibile in %COMMONPROGRAMFILES%\Microsoft Shared\web server extensions\14\LOGS.
La stima a cui si giunge sulla base dell'aggiornamento di prova è relativa al processo di aggiornamento effettivo dei dati e non tiene conto di tutte le operazioni che è necessario eseguire prima e dopo questo passaggio e che possono richiedere più tempo dell'aggiornamento dei dati vero e proprio. Quando si calcola la durata dell'aggiornamento, oltre al tempo richiesto per l'elaborazione dei dati, è pertanto opportuno considerare il tempo necessario per le attività da eseguire durante le fasi pre- e post-aggiornamento.
Per i passaggi di pre-aggiornamento, prendere in considerazione i fattori seguenti:
Creazione di elementi personalizzati Per aggiornare le web part o ricreare i modelli personalizzati per usufruire delle nuove caratteristiche è necessario tempo. Il processo di creazione di elementi personalizzati deve iniziare presto, durante la fase di valutazione del progetto.
Back dei database Per l'aggiornamento sul posto, è necessario eseguire un backup completo, e non differenziale, dell'intero ambiente per essere certi di poter effettuare il ripristino nella remota eventualità che l'aggiornamento abbia esito negativo e sia necessario ricreare la server farm. Per ambienti di grandi dimensioni, questa operazione può richiedere molto tempo. In particolare, se si effettua il backup in un percorso di rete, i problemi di latenza di rete possono rallentare il processo.
Per i passaggi di post-aggiornamento, prendere in considerazione i fattori seguenti:
- Verifica dei siti ed esecuzione delle modifiche Calcolare tempo sufficiente affinché gli utenti possano convalidare i rispettivi siti dopo l'aggiornamento. Questa attività può richiedere diversi giorni. Per ulteriori informazioni, vedere Verificare l'aggiornamento e controllare i siti aggiornati (SharePoint Foundation 2010).
Possono contribuire a estendere i tempi di aggiornamento anche altri fattori relativi all'ambiente, tra cui:
Raccolte documenti particolarmente estese Una raccolta documenti con oltre 250.000 documenti, tutti contenuti nella radice della raccolta anziché in cartelle, comporta tempi lunghi e il rischio di un esito negativo dell'aggiornamento. Attenendosi alle indicazioni per Windows SharePoint Services 3.0 sull'utilizzo di cartelle per suddividere raccolte documenti di grandi dimensioni, è possibile controllare la dimensione delle raccolte. Se ad esempio si interviene sulla stessa raccolta documenti dividendo i 250.000 documenti in 125 cartelle, l'aggiornamento verrà eseguito più agevolmente.
Database di grandi dimensioni Per l'aggiornamento di database di oltre 100 GB è necessario molto tempo.
Nota
Se si dispone di database del contenuto di dimensioni che superano 100 GB, è consigliabile dividerli in database più piccoli prima di eseguire l'aggiornamento. Oltre a richiedere più tempo per l'aggiornamento, i database di grandi dimensioni possono essere più difficili da ripristinare in caso di esito negativo dell'aggiornamento.
Per spostare siti da un database a un altro è possibile utilizzare le operazioni mergecontentdbs o backup e restore in Stsadm.exe. Per ulteriori informazioni, vedere Mergecontentdbs: operazione Stsadm (Windows SharePoint Services) e Backup e ripristino: operazioni di Stsadm (Windows SharePoint Services).Se si dispone di un database molto esteso (oltre 100 GB) che non può essere diviso perché gran parte del contenuto si trova in una raccolta siti, è possibile riconsiderare il metodo di aggiornamento scelto. L'aggiornamento basato sul collegamento di database è più difficile nel caso di database particolarmente estesi, poiché il backup e il ripristino di database di questo tipo sono problematici.
Avviso
Prima di tentare l'aggiornamento, seguire le indicazioni per la pianificazione della capacità della versione precedente e della nuova versione. Se si superano i valori indicati per le prestazioni ottimali, il processo di aggiornamento potrebbe durare più a lungo oppure potrebbe avere esito negativo, ad esempio potrebbe verificarsi ripetutamente il timeout per la stessa raccolta documenti di grandi dimensioni. Se la distribuzione non è conforme alle linee guida per le capacità consigliate, valutare se non sia necessario eseguire particolari attività per renderla conforme prima di procedere con l'aggiornamento. Anche in questo caso, per prendere una decisione, può essere utile eseguire un aggiornamento di prova.
Requisiti per le comunicazioni
È necessario notificare agli utenti e al proprio team la pianificazione dell'aggiornamento e concedere loro il tempo necessario per eseguire le attività richieste. Per ulteriori informazioni, vedere Creare un piano di comunicazione (SharePoint Foundation 2010).
Gestione di avvisi e allarmi del sistema
È necessario monitorare le prestazioni del sistema durante l'aggiornamento, ma non alcune caratteristiche specifiche. Sospendere eventuali allarmi e avvisi non necessari generati da Microsoft Systems Center Operations Manager o Microsoft Operations Manager e quindi riattivarli dopo l'aggiornamento.
Attivazione/disattivazione del mirroring e del log shipping di SQL
È consigliabile disattivare il mirroring e il log shipping prima dell'aggiornamento e quindi riattivarli dopo aver verificato il corretto funzionamento dell'ambiente dopo l'aggiornamento. Non eseguire il mirroring o il log shipping durante l'aggiornamento, poiché si creerebbe un ulteriore carico nei server che eseguono SQL Server e verrebbero occupate risorse per il mirroring o lo shipping di dati temporanei.
Testare il processo di aggiornamento per calcolare il tempo necessario e quindi creare una pianificazione per le operazioni di aggiornamento e testarla per definire la cronologia. Nella cronologia delle operazioni è consigliabile includere il tempo necessario per i passaggi di pre- e post-aggiornamento. Se per eseguire il backup dell'ambiente sono necessarie 5 ore prima dell'inizio dell'aggiornamento, è necessario includere questo tempo nel calcolo del periodo di inattività. Includere inoltre un buffer per eventuali attività di ripristino o recupero. È consigliabile infatti definire il tempo di inattività pianificato (caso realistico) e il tempo di inattività per le emergenze (caso peggiore).