Warten von Planning Server-Datenbanken
Aktualisiert: 2009-04-30
In diesem Artikel:
Background of Planning Server databases
Application databases in Planning Server
Staging databases in Planning Server
Outbound databases in Planning Server
Analysis Services databases in Planning Server
Planning Server physical database storage design
Dieser Artikel richtet sich an Planning Server-Datenbankadministratoren. Er erläutert einige Bereiche der Datenbankimplementierung, die für Microsoft Office PerformancePoint Server 2007 spezifisch sind. Datenbankadministratoren sollten bei der Vorbereitung der Implementierung eines Produktionssystems dieses Dokument lesen.
Hintergrund von Planning Server-Datenbanken
Der physische Speicherentwurf der Datenbank hat direkten Einfluss auf die Datenbankleistung. Im Allgemeinen haben Planning Server-Kunden eine gewisse Flexibilität beim Entwerfen der physischen Speicherattribute der Systemdatenbanken. In diesem Dokument werden Entwurfsrichtlinien für die Wartung von Planning Server-Datenbanken im Hinblick auf eine optimale Serversystemleistung dargelegt.
Planning-Systemdatenbank und Datenbank des Planning-Diensts
Für jede Planning Server-Installation gibt es eine Planning-Systemdatenbank (PPSPlanningSystem) und eine Datenbank des Planning-Diensts (PPSPlanningService).
Die Planning-Systemdatenbank umfasst die folgenden Komponenten:
Planning-Systemsicherheitsdaten
Planning-Typbibliotheksdaten
Planning-Konfigurationsdaten auf Systemebene
Planning-Metadaten auf Anwendungsebene
Die Planning-Systemdatenbank und die Datenbank des Planning-Diensts sind und bleiben relativ klein.
Die Planning-Systemdatenbank und die Datenbank des Planning-Diensts können entweder manuell oder mit dem Konfigurations-Manager für Planning Server erstellt werden.
Wenn Sie die beiden Datenbanken vom Konfigurations-Manager für Planning Server erstellen lassen, werden beide Datenbanken mit einer Standard-Datendateigröße von 50 MB und einer automatischen Vergrößerung um 50 MB in der primären Dateigruppe gespeichert. Die standardmäßige Protokolldateigröße wird auf 20 MB festgelegt, mit einer automatischen Vergrößerung um 20 MB.
Wenn Sie diese beiden Datenbanken manuell erstellen möchten, können Sie die Dateigruppe auswählen und die Standardeinstellungen für die anfängliche Datenbank- und Protokolldateigröße ändern.
Anwendungsdatenbanken in Planning Server
Ein Planning-System kann aus mehreren Planning-Anwendungen bestehen. Für jede Planning-Anwendung gibt es eine Planning-Anwendungsdatenbank. Diese Anwendungsdatenbank enthält alle Planning-Anwendungsdaten, z. B. Planning-Anwendungsmetadaten, Verweisdaten, Faktendaten, workflowbezogene Daten und Service Broker-Daten. Diese Datenbank kann sehr umfangreich werden, je nach Datenaufbewahrungsrichtlinien und der Anzahl der Modellsites und Modelle in der Planning-Anwendung.
Die Anwendungsdatenbank wird während der Anwendungerstellung erstellt. Sie können zum Erstellen einer Anwendungsdatenbank entweder die manuelle oder die automatische Methode auswählen.
Wählen Sie in der Planning-Verwaltungskonsole im Bereich Anwendung erstellen die Option Manuelle Ausführung, damit Datenbankadministratoren die CREATE DATABASE-/CREATE TABLE-Anweisungen bei der Anwendungerstellung anpassen können. Datenbankadministratoren können beim Erstellen der Anwendungsdatenbank Dateigruppeninformationen hinzufügen und die anfängliche Daten- und Protokolldateigröße angeben. Nachdem während der Anwendungserstellung Microsoft SQL Server 2005-Skripts generiert wurden, können Datenbankadministratoren CreateAppDB.sql und TypeLibMasterSchema.sql bearbeiten und die Dateigruppeninformationen sowie die Daten- und Protokolldateigröße zu den Skripts hinzufügen, bevor sie diese manuell ausführen.
Die andere Methode besteht darin, im Bereich Anwendung erstellen die Option Automatische Ausführung auszuwählen. Die Anwendungsdatenbank wird automatisch erstellt, wobei die standardmäßige anfängliche Datendateigröße auf 50 MB festgelegt und die automatische Vergrößerung mit 50 MB angegeben wird. Die standardmäßige Protokolldateigröße wird auf 20 MB festgelegt, mit einer automatischen Vergrößerung um 20 MB.
Stagingdatenbanken in Planning Server
Für jede Planning-Anwendung gibt es eine Planning-Stagingdatenbank. Diese Stagingdatenbank wird entweder während der Anwendungserstellung oder zu einem späteren Zeitpunkt manuell erstellt. Die Stagingdatenbank muss sich auf demselben Datenbankserver wie die entsprechende Anwendungsdatenbank für Version 1 befinden.
Ausgehende Datenbanken in Planning Server
Die ausgehende Planning-Datenbank enthält Planning Server-Daten, die für andere Zwecke verfügbar sind. Sie können mit der Planning-Verwaltungskonsole Datenbanken erstellen oder als Datenziel registrieren.
Analysis Services-Datenbanken in Planning Server
Eine Modellsite für eine Planning Server-Anwendung entspricht immer einer einzelnen Microsoft SQL Server 2005 Analysis Services-Datenbank. Der Analysis Services-Datenbankname wird automatisch durch Planning Server generiert. Der Standardname lautet <Anwendungsbezeichnung>_<Modellsitebezeichnung>.
Sie können alle Modellsites für die Planning-Anwendung so konfigurieren, dass sie auf denselben Analysis Services-Server, aber jeweils auf eine andere Analysis Services-Datenbank verweisen. Sie können in der Konfiguration auch festlegen, dass eine beliebige Modellsite in der Planning-Anwendung auf eine Analysis Services-Datenbank auf einem anderen Analysis Services-Server verweist. Sie können diese Konfigurationen mit der Planning-Verwaltungskonsole im Fenster zur Modellsitewartung verwalten. Geben Sie für jede Modellsite den Wert in das Feld Name des Analysis Services-Servers ein. Alle Einzelheiten finden Sie in der Hilfe zur Planning-Verwaltungskonsole.
.gif "Hinweis") Hinweis: |
|---|
Wenn Sie eine Modellsite oder -untersite löschen, müssen Sie die Analysis Services-Cubes manuell löschen. |
Physischer Speicherentwurf der Planning Server-Datenbank
Beachten Sie beim Entwurf des physischen Speichers für Planning Server-Datenbanken die entsprechenden Themen zum Datenbankspeicherentwurf unter SQL Server. Der Speicherentwurf der physischen Datenbank ist ausschlaggebend für die Gesamtleistung des Planning Server-Systems. Eine sorgfältige Implementierung der physischen Datenbank führt zu einer besseren Leistung und einem besseren Systemzustand.
In diesem Abschnitt werden die Bereiche des Speicherentwurfs der physischen Datenbank erläutert: Speicherort der Daten- und Protokolldatei der Datenbank, anfängliche Dateigröße, leistungsoptimierte Konfiguration der Protokolldatei, Dateigruppenentwurf, optimaler TempDB-Entwurf für das Planning Server-System sowie Modelle zur Datenbankwiederherstellung. Viele dieser allgemeinen Entwurfsrichtlinien werden auch unter SQL Server behandelt.
Daten- und Protokolldateien der Datenbank
In SQL Server 2005 wird eine Datenbank einer Gruppe von Betriebssystemdateien zugeordnet. Daten- und Protokollinformationen werden niemals in derselben Datei gemischt, und die einzelnen Dateien werden immer nur von einer Datenbank verwendet. Weitere Informationen über Daten- und Protokolldateien von Datenbanken finden Sie unter SQL Server.
Für alle Planning Server-Datenbanken, die automatisch von Planning Server erstellt werden, ist die anfängliche Datendateigröße auf 50 MB mit einer automatischen Vergrößerung um 50 MB festgelegt.
Für Anwendungs- und Stagingdatenbanken wird empfohlen, dass die Planning Server-Datenbankadministratoren des Kunden eine Kapazitätsplanung durchführen und anhand der Daten und der Datenaufbewahrungsrichtlinien des Unternehmens eine angemessene Größe für die anfängliche Datendatei ermitteln. Beispielsweise ist zu berücksichtigen, wie viele Modelle pro Modellsite und wie viele Modellsites in der Anwendung zu erwarten sind.
Für den Entwurf der Daten- und Protokolldatei der Datenbank gelten u. a. die folgenden allgemeinen Richtlinien:
Aktivieren Sie die automatische Vergrößerung für die Daten- und Protokolldateien der Datenbank.
Weisen Sie den Daten- und Protokolldateien der Datenbank eine angemessene anfängliche Größe zu.
Legen Sie die maximale Größe für Datendateien fest, sodass bei fehlendem Speicherplatz keine Speicherplatzprobleme auftreten (besonders wichtig bei mehreren Datenbanken).
Legen Sie die Zuwachsschrittweite für die Datendatei auf eine angemessene Größe fest (Voreinstellungen: feste Zuwachsschrittweite von maximal 1 GB, deutliche Unterstützung durch sofortige Dateiinitialisierung).
Überlegen Sie sich, ob Sie die sofortige Initialisierung für Datendateien zulassen möchten.
Denken Sie über den Einsatz der RAID-Technologie für Daten- und Protokolldateien nach.
Weisen Sie nur eine Protokolldatei zu.
Isolieren Sie die Protokolldatei auf einem eigenen Laufwerk (im Hinblick auf die Leistung sollten Sie die Protokolldateien auf einem separaten physischen Datenträger speichern, nicht die Datendateien).
Auch die Überwachung der Protokolldatei ist wichtig. Sie können den Protokolldateistatus mit der folgenden Abfrage überwachen:
select * from
sys.dm_os_performance_counters
where counter_name like '%Log%'
and instance_name = 'Alpine_Ski_House_AppDB'
Weitere Informationen finden Sie unter SQL Server.
Vorabzuordnen der Protokolldateigröße
Zum Minimieren der automatischen Vergrößerung der Protokolldatei sollten Sie dem Protokoll vorab eine geeignete Größe zuordnen. Die Größe der Protokolldatei hängt von zwei Faktoren ab: der Häufigkeit der Protokollsicherung und der Aktivität des Planning Server-Systems.
Zwar wird allgemein empfohlen, der Protokolldatei vorab eine Größe von 10 oder 15 Prozent der Datenbankdatei zuzuordnen, doch die tatsächliche Protokolldateigröße hängt von der Häufigkeit der Protokollsicherung ab.
Wenn Sie die Protokolldatei alle fünf Minuten sichern und eine normale Planning-Aktivität vorliegt, sollten Sie die anfängliche Protokolldateigröße wie folgt zuordnen:
Planning-Systemdatenbank: 50 MB
Datenbank des Planning-Diensts: 200 MB
Planning-Anwendungsdatenbank: 1 GB
Planning-Stagingdatenbank: 1 GB
Ausgehende Planning-Datenbank: 400 MB
Sie können diese Zahlen je nach Häufigkeit der Protokollsicherung ändern. Wenn Sie das Protokoll beispielsweise alle 10 Minuten sichern, müssen Sie die anfängliche Protokolldateigröße erhöhen. Wenn Sie die Protokolldatei alle zwei Minuten sichern, können Sie eine kleinere Protokolldateigröße zuordnen.
Neben der richtigen anfänglichen Protokolldateigröße wird empfohlen, die automatische Vergrößerung der Protokolldatei fest anzugeben (nicht als Prozentsatz). Außerdem sollten Sie eine Obergrenze für die Vergrößerung der Protokolldatei definieren (keine uneingeschränkte Vergrößerung).
Auch die Minimierung der virtuellen Protokolldatei ist wichtig für die SQL Server-Leistung. Informationen zur Minimierung finden Sie unter SQL Server.
Sichern der Protokolldatei
Die Protokolldatei muss regelmäßig gesichert werden. Für das Produktionssystem wird dringend empfohlen, auf dem Computer mit SQL Server eine regelmäßige Protokollsicherung (z. B. alle 5 oder 10 Minuten) zu planen, um Datenverluste zu vermeiden. Falls Sie den vollständigen Datenbankwiederherstellungsmodus verwenden und das Protokoll länger nicht sichern, wächst es weiter, bis die Fehlermeldung angezeigt wird, dass das Protokoll voll ist.
Die Protokollsicherung bedeutet nur einen minimalen Mehraufwand für das System; häufige Sicherungen beeinträchtigen also die Systemleistung nicht. Je stärker fragmentiert die Protokolldatei ist, umso aufwändiger wird die Protokollsicherung. Darum ist es so wichtig, vorab eine angemessene Protokolldateigröße für das System zuzuordnen; dies verbessert die Leistung bei der Protokollsicherung.
Wenn eine Protokolldatei voll ist, können Sie das Protokoll nur noch sichern. Durch das Sichern des Protokolls wird das inaktive Protokoll gelöscht und die Protokolldatei verkleinert. Aktive Protokolle werden durch das Sichern des Protokolls nicht gelöscht, da die Transaktionen noch nicht übernommen wurden.
In einer Nichtproduktionsumgebung ohne Gefahr von Datenverlust können Sie das Protokoll abschneiden, um es zu löschen. Diese Vorgehensweise ist allerdings nur für Prototyp-, Entwicklungs- oder Testsysteme zu empfehlen, bei denen ein Datenverlust vertretbar ist.
Sowohl bei Produktions- als auch bei Nichtproduktionssystemen müssen Sie die Protokolldatei pflegen (durch Sichern oder Abschneiden); andernfalls wächst sie schnell und beeinträchtigt die Leistung des Planning-Systems.
Beispielskripts
Dieser Abschnitt enthält Beispielskripts für das Sichern oder Abschneiden von Protokollen. Planen Sie unbedingt auf dem Computer mit SQL Server die Ausführung des folgenden Skripts. In einer Test- oder Prototypumgebung können Sie, wenn Sie sich den Aufwand für das Sichern oder Abschneiden von Protokollen ersparen möchten, statt des standardmäßigen vollständigen Datenbankwiederherstellungsmodus den einfachen Modus auswählen. Bearbeiten Sie dazu in SQL Server Management Studio die Eigenschaftenseite der Datenbank.
.gif "Wichtig") Wichtig: |
|---|
Der einfache Modus sollte nie im Produktionssystem verwendet werden. Weitere Informationen über Datenbankwiederherstellungsmodelle finden Sie unter 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
| Wichtig: |
|---|
In einem Nichtproduktionssystem müssen Sie das Protokoll entweder abschneiden oder auf dem Computer mit SQL Server eine regelmäßige Protokollsicherung einrichten, um die Protokolldateigröße zu verringern und dadurch die Leistung zu verbessern und Datenverlust zu vermeiden. Wenn Sie die Protokolldateien zu groß werden lassen, wird die Leistung von Planning Server deutlich beeinträchtigt. Die wachsende Protokolldatei belegt im Laufe der Zeit schließlich auch eine enorme Menge des Speicherplatzes auf dem Datenträger. |
TempDB
Die TempDB-Größe kann die Leistung des Systems beeinträchtigen. Wenn beispielsweise TempDB zu klein ausgelegt wird, kann bei jedem Neustart des SQL Server-Diensts (MSSQLServer) ein Teil der Systemverarbeitungsleistung durch die automatische Vergrößerung der Datenbank beansprucht werden, bis die Größe erreicht wird, die zur Unterstützung der Arbeitsauslastung erforderlich ist. Sie können diesen Mehraufwand vermeiden, indem Sie die Größe von TempDB erhöhen.
Allgemein gelten u. a. die folgenden Empfehlungen für den physischen Speicherort und die Datenbankoptionen für TempDB:
Erlauben Sie die automatische Vergrößerung von TempDB nach Bedarf.
Legen Sie die anfängliche Größe der TempDB-Dateien auf einen angemessenen Wert fest, um eine automatische Vergrößerung der Dateien bei zunehmendem Speicherplatzbedarf zu vermeiden. Wenn TempDB zu häufig vergrößert wird, kann dies die Leistung beeinträchtigen.
Legen Sie die Zuwachsschrittweite für die Datei auf einen angemessene Prozentsatz fest, um ein zu geringes Wachstum der TempDB-Dateien zu vermeiden. Bei einem zu geringen Dateizuwachs im Vergleich zur in TempDB geschriebenen Datenmenge muss die Datenbank möglicherweise ständig vergrößert werden. Dies beeinträchtigt die Leistung.
Speichern Sie TempDB auf einem Subsystem mit schneller Eingabe/Ausgabe, um eine gute Leistung zu erzielen. Erstellen Sie ein Stripeset von TempDB auf mehreren Datenträgern, um die Leistung zu verbessern. Speichern Sie TempDB auf anderen Datenträgern als die Benutzerdatenbanken. Weitere Informationen über das Verschieben von TempDB an einen neuen Speicherort finden Sie unter SQL Server.
Beim Neustart von SQL Server wird TempDB auf die ursprünglich konfigurierte Größe zurückgesetzt und wächst entsprechend den Anforderungen. Dadurch kann es zu einer Fragmentierung von TempDB und zu einem Mehraufwand kommen. Dies kann wiederum die Leistung bei der Verarbeitung der Arbeitsauslastung beeinträchtigen. Es wird empfohlen, TempDB vorab eine geeignete Größe zuzuordnen.
Da Planning Server-Datenbanken die festgeschriebene Isolation für Lesevorgänge unter Verwendung der Zeilenversionsverwaltung verwenden, sollte für TempDB eine angemessene Größe vorgegeben werden, um eine bessere Leistung zu erzielen. Legen Sie die Anfangsgröße für TempDB daher auf mindestens 500 MB fest. Eine noch bessere Leistung erzielen Sie mit einer TempDB-Anfangsgröße von 1 GB.
Überwachen Sie den freien Speicherplatz in TempDB sorgfältig. Weitere Informationen finden Sie unter SQL Server.
Dateigruppen
Sie sollten Datenbankobjekte und Dateien für Verteilungs- und Verwaltungszwecke in Dateigruppen zusammenfassen.
Die Planning-Systemdatenbank und die Datenbank des Planning-Diensts können während der Planning Server-Installation erstellt werden, oder sie können vom Kunden manuell vor dem Installieren der Planning Server-Software bereitgestellt werden. Wenn Sie die beiden Datenbanken vom Konfigurations-Manager für Planning Server erstellen lassen, können Sie keine Dateigruppe für sie angeben. Diese beiden Datenbanken sind relativ klein; es ist daher kaum notwendig, eine Dateigruppe für sie zu verwenden.
Die Planning-Anwendungsdatenbank wird während der Anwendungserstellung erstellt. Es gibt zwei Optionen zum Erstellen von Anwendungsdatenbanken. Kunden können in der Planning-Verwaltungskonsole im Bereich Anwendung erstellen die Option Manuelle Ausführung auswählen, damit Datenbankadministratoren die CREATE DATABASE-/CREATE TABLE-Anweisungen bei der Anwendungerstellung anpassen können. Datenbankadministratoren können beim Erstellen der Anwendungsdatenbank Dateigruppeninformationen hinzufügen. Nachdem während der Anwendungserstellung SQL Server-Skripts generiert wurden, können Datenbankadministratoren CreateAppDB.sql und TypeLibMasterSchema.sql bearbeiten und die Dateigruppeninformationen zu den Skripts hinzufügen, bevor sie diese ausführen
| Hinweis: |
|---|
Sie können Dateigruppen mit CREATE DATABASE oder ALTER DATABASE erstellen. Sie können eine Dateigruppe für Tabellen mit CREATE TABLE angeben. Wenn Sie neue Dateigruppen erstellen, müssen Sie die Dateien den neuen Dateigruppen hinzufügen, bevor die neuen Dateigruppen verwendet werden. |
Weitere Informationen über Dateigruppen finden Sie unter SQL Server.