Gestione dei database di Planning Server

Per ogni installazione di Planning Server sono previsti un database del sistema di pianificazione (PPSPlanningSystem) e un database del servizio di pianificazione (PPSPlanningService).

Il database del sistema di pianificazione contiene i componenti seguenti:

• Dati di protezione del sistema di pianificazione

• Dati di libreria di tipi di Planning

• Dati di configurazione a livello del sistema di pianificazione

• Metadati a livello di applicazione di PerformancePoint Planning

Le dimensioni del database del sistema di pianificazione e del database del servizio di pianificazione sono ridotte e anche in seguito rimangono relativamente tali.

È possibile creare entrambi i database manualmente o durante l'esecuzione di Gestione configurazione Planning Server.

Se si sceglie di creare automaticamente i database mediante Gestione configurazione Planning Server, entrambi i database si troveranno nel gruppo di file primario e per entrambi verranno impostate le dimensioni predefinite di 50 MB con aumento automatico delle dimensioni di 50 MB alla volta. Le dimensioni predefinite del file di log saranno di 20 MB con aumento automatico di 20 MB alla volta.

Se si sceglie di creare i database manualmente, è possibile selezionare il gruppo di file e definire le impostazioni predefinite relative alle dimensioni iniziali dei database e del file di log.

SQL Server 2005 esegue il mapping di un database a un set di file del sistema operativo. Le informazioni di dati e log non vengono mai inserite nello stesso file e ogni file viene utilizzato da un unico database. Per ulteriori informazioni sui file di dati e i file di log dei database, vedere SQL Server.

Per tutti i database di Planning Server creati automaticamente dal server PerformancePoint Planning, le dimensioni iniziali predefinite vengono impostate a 50 MB con aumento automatico di 50 MB alla volta.

Per i database delle applicazioni e dell'area di gestione temporanea, è consigliabile che gli amministratori dei database di Planning Server definiscano criteri appropriati di gestione e mantenimento dei dati dell'organizzazione, per consentire una pianificazione adeguata della capacità e una determinazione attendibile delle dimensioni iniziali dei file di dati. È consigliabile, ad esempio, determinare il numero di modelli all'interno di ogni sito modelli e il numero di siti modelli che si prevede di raggiungere all'interno di ogni applicazione.

Alcune linee guida generali da seguire nella progettazione del file di dati e del file di log dei database sono le seguenti:

• Attivare l'aumento automatico delle dimensioni.

• Assegnare dimensioni iniziali appropriate.

• Impostare le dimensioni massime dei file di dati per evitare di esaurire inavvertitamente lo spazio disponibile su disco. Questo è particolarmente importante nel caso di più database.

• Impostare un valore appropriato per l'incremento delle dimensioni del file di dati. È preferibile impostare un incremento fisso minore o uguale a 1 GB, meglio se con inizializzazione immediata dei file.

• Considerare l'opportunità di attivare l'inizializzazione immediata dei file di dati.

• Considerare l'opportunità di utilizzare la tecnologia RAID per i file di dati e di log.

• Allocare un solo file di log.

• Isolare il file di log in un'unità separata. Per ottenere prestazioni migliori, è consigliabile mantenere i file di log, anziché i file di dati, in un disco fisico separato.

È inoltre importante eseguire il monitoraggio del file di log. Per controllare lo stato del file di log, eseguire la query seguente:

select * from 
sys.dm_os_performance_counters 
where counter_name like '%Log%'
and instance_name = 'Alpine_Ski_House_AppDB'

Per ulteriori informazioni, vedere SQL Server.

Per evitare un aumento eccessivo delle dimensioni del file di log quando si utilizza l'aumento automatico delle dimensioni, è consigliabile allocare anticipatamente dimensioni appropriate per questo file. Le dimensioni del file di log dipendono da due fattori: la frequenza del backup del log e l'attività del sistema Planning Server.

Le linee guida generali consigliano di definire un file di log con dimensioni iniziali pari al 10 o al 15% delle dimensioni del file di database. Le dimensioni effettive del file di log, tuttavia, dipendono dalla frequenza con cui viene effettuato il backup del file.

Se il backup del file di log viene effettuato ogni cinque minuti e l'attività di Planning è normale, è consigliabile definire le dimensioni iniziali del file di log come descritto di seguito:

• Database del sistema di pianificazione: 50 MB

• Database del servizio di pianificazione: 200 MB

• Database dell'applicazione di PerformancePoint Planning: 1 GB

• Database dell'area di gestione temporanea di Planning: 1 GB

• Database in uscita di Planning: 400 MB

È possibile modificare questi valori in base alla frequenza del backup del log. Se ad esempio il backup del log viene effettuato ogni 10 minuti, è necessario impostare dimensioni iniziali maggiori per il file di log. Se il backup viene effettuato ogni due minuti, sono sufficienti dimensioni inferiori.

Oltre a dimensioni iniziali appropriate per il file di log, è consigliabile impostare un importo fisso, non una percentuale, per l'aumento automatico delle dimensioni del file stesso. Non impostare l'aumento illimitato delle dimensioni del file.

Per le prestazioni di SQL Server è inoltre importante mantenere il più possibile ridotte le dimensioni del file di log virtuale. Per ulteriori informazioni sull'esecuzione di questa attività, vedere SQL Server.

È importante eseguire regolarmente il backup del file di log. Per evitare perdite di dati, è consigliabile pianificare l'esecuzione periodica del backup del log, ad esempio ogni cinque o 10 minuti, nel computer del sistema di produzione che esegue SQL Server. Se la modalità di recupero del database impostata è Con registrazione completa e non si esegue il backup del log per un lungo periodo, le dimensioni del log aumenteranno fino a generare un errore che indica che il log è pieno.

L'overhead del sistema da parte del backup del log è minimo. Backup frequenti non influiscono quindi sulle prestazioni. Maggiore è la frammentazione del file di log, maggiormente il backup del log influirà sulle prestazioni. Per garantire le migliori prestazioni del backup del log, è quindi importante allocare dimensioni iniziali appropriate per il file di log.

Quando il file di log è pieno, l'unica soluzione è effettuare il backup del log. Con questa operazione il log inattivo viene cancellato e le dimensioni del file di log si riducono. Il backup del log non cancella i log attivi, poiché il commit delle transazioni di questi ultimi non è stato eseguito.

In un ambiente non di produzione, per il quale la perdita di dati non è un problema, è possibile cancellare il log troncandolo. Eseguire questa operazione solo per sistemi prototipi, di sviluppo o di test per i quali la perdita di dati è accettabile.

Per i sistemi di produzione o non di produzione è comunque necessario effettuare la gestione del file di log, mediante backup o troncamento. In caso contrario, le dimensioni del file di log aumenteranno rapidamente e influiranno negativamente sulle prestazioni del sistema Planning.

Script di esempio

In questa sezione vengono illustrati alcuni script di esempio per l'esecuzione del backup o del troncamento del log. È importante pianificare l'esecuzione dello script che segue nel computer che esegue SQL Server. In caso di esecuzione all'interno di un ambiente di test o prototipo, se si desidera evitare di eseguire il backup o il troncamento del log, modificare la modalità di recupero del database da Con registrazione completa a Con registrazione minima nella pagina delle proprietà del database in SQL Server Management Studio.

Importante:
Non utilizzare mai la modalità Con registrazione minima per un ambiente di produzione. Per ulteriori informazioni sui modelli di recupero del database, vedere SQL Server.

-- Truncate Log sample script
-- Use only if you are in testing environment and do not care about DB backup.
BACKUP LOG 'Alpine_Ski_House_AppDB WITH NO_LOG
GO
BACKUP LOG 'Alpine_Ski_House_AppDB WITH TRUNCATE_ONLY
GO

USE 'Alpine_Ski_House_AppDB
GO
EXEC sp_helpfile 
GO
-- get the log file name for this DB

-- now shrink the log file
USE 'Alpine_Ski_House_AppDB
GO
DBCC SHRINKFILE(Alpine_Ski_House_AppDB_log, TRUNCATEONLY)
GO

-- Backup log sample script
-- For any DB that you care about data loss, you should back up DB and the 
-- log, that is the only good way to clear the inactive logs.

-- Create dump devices first
EXEC sp_addumpdevice 'disk', 'ServiceDBData', 
'C:\work\ServiceDBData.bak';
GO

EXEC sp_addumpdevice 'disk', 'ServiceDBLog', 
'C:\work\ServiceDBLog.bak';
GO

-- Back up database and log file
USE PPSPlanningService
GO
BACKUP DATABASE PPSPlanningService TO ServiceDBLog;
GO
BACKUP LOG PPSPlanningService TO ServiceDBLog
GO
DBCC SHRINKFILE(PPSPlanningService_log, TRUNCATEONLY)
GO

Importante:

Per ridurre le dimensioni del file di log, ottenere migliori prestazioni ed evitare perdite di dati, è necessario eseguire il troncamento del log (in un sistema non di produzione) o impostarne il backup periodico nel computer che esegue SQL Server. Se le dimensioni del file di log aumentano in modo eccessivo, le prestazioni di Planning Server peggioreranno significativamente. L'aumento delle dimensioni del file di log, inoltre, causa una riduzione, sempre maggiore con l'andar del tempo, dello spazio disponibile su disco.

Le dimensioni di TempDB possono influire sulle prestazioni del sistema. Se, ad esempio, le dimensioni definite per TempDB sono insufficienti, per consentire al sistema di supportare il carico di lavoro una parte del carico di elaborazione potrebbe essere svolto tramite l'aumento automatico delle dimensioni del database ogni volta che il servizio SQL Server (MSSQLSERVER) viene riavviato. Per evitare tale overhead, aumentare le dimensioni di TempDB.

Alcune indicazioni per l'impostazione della posizione fisica e delle opzioni di TempDB sono le seguenti:

• Consentire l'espansione automatica di TempDB nella misura necessaria al funzionamento del sistema.

• Impostare un valore appropriato per le dimensioni originali di TempDB, per evitare l'espansione automatica dei file nel caso in cui sia necessaria una maggiore quantità di spazio. Se TempDB si espande troppo frequentemente, le prestazioni potrebbero peggiorare.

• Impostare una percentuale di incremento appropriata per evitare un aumento insufficiente dei file di TempDB. Se l'aumento è insufficiente rispetto alla quantità di dati scritti in TempDB, potrebbe verificarsi un'espansione costante del database con un conseguente peggioramento delle prestazioni.

• Per garantire buone prestazioni, collocare TempDB in un sottosistema di input/output veloce o effettuarne lo striping su più dischi. Collocare TempDB all'interno di dischi diversi da quelli utilizzati per i database utente. Per ulteriori informazioni sullo spostamento di TempDB in una nuova posizione, vedere SQL Server.

Al riavvio di SQL Server TempDB torna alle dimensioni configurate inizialmente e aumenta in base ai requisiti. Questo può causare frammentazione di TempDB e overhead e influire sulle prestazioni del carico di lavoro. È consigliabile definire dimensioni iniziali di TempDB appropriate.

I database di Planning Server utilizzano il cosiddetto "isolamento READ COMMITTED" mediante la funzionalità di controllo delle versioni delle righe. Per ottenere prestazioni migliori di TempDB è quindi consigliabile impostarne le dimensioni su un valore adeguatamente grande, almeno 500 MB. Per prestazioni ancora migliori, impostare le dimensioni iniziali di TempDB su 1 GB.

È importante effettuare il monitoraggio dello spazio disponibile in TempDB. Per ulteriori informazioni, vedere SQL Server.

È consigliabile raggruppare gli oggetti di database in gruppi di file a scopo di allocazione e amministrazione.

È possibile creare il database del sistema di pianificazione e il database del servizio di pianificazione durante l'installazione di Planning Server oppure effettuarne il provisioning prima di installare Planning Server. Se si desidera creare i due database automaticamente mendiante Gestione configurazione Planning Server, non è possibile specificarne il gruppo di file. Le dimensioni dei database sono relativamente ridotte e la necessità di utilizzare un gruppo di file per questi è minima.

Il database di un'applicazione di PerformancePoint Planning viene creato durante il processo Crea applicazione. Per la creazione di database delle applicazioni sono disponibili due opzioni. È possibile specificare l'opzione Genera script di creazione applicazione per l'esecuzione manuale nell'interfaccia utente Crea applicazione in Planning Administration Console. In tale modo gli amministratori dei database sono in grado di personalizzare le istruzioni CREATE DATABASE e CREATE TABLE per il processo di creazione dell'applicazione, in particolare aggiungendo informazioni relative al gruppo di file al momento della creazione del database dell'applicazione. Dopo la generazione degli script di SQL Server da parte del processo Crea applicazione, gli amministratori dei database possono modificare CreateAppDB.sql e TypeLibMasterSchema.sql aggiungendo le informazioni sul gruppo di file e quindi eseguire gli script.

Per ulteriori informazioni sui gruppi di file, vedere SQL Server.