Treffen mit Datenbankadministratoren bezüglich eines Server-Upgrade-Projekts - Häufige Bedenken

Ich bin eher ein Netzwerk- / Windows-Administrator und wurde mit der Überwachung eines SQL Server-Upgrade-Projekts beauftragt. Ich muss mich mit den Datenbankadministratoren treffen und ihre Bedürfnisse / Wünsche bezüglich des Upgrades besprechen. Ich möchte nicht völlig blind werden, also dachte ich, ich würde euch zuerst fragen. Wir wechseln von SQL Server 2008 zu SQL Server 2008 R2 und wahrscheinlich nach Möglichkeit zu Windows Server 2008 R2. Was würden Sie als DBA mit einem solchen Upgrade befürchten? Was möchten Sie gleichzeitig sehen?

Ohne Informationen über die Art des Systems (siehe meinen Kommentar zur Frage) oder warum Sie ein Upgrade durchführen, ist es schwierig, spezifische und / oder präzise Ratschläge zu geben.

Als Ausgangspunkt gibt es viele ausgezeichnete Checklisten für den Aufbau eines neuen Servers. Brent Ozar und Jonathan Kehayias sind zwei gute Beispiele. Aus den vielen Empfehlungen in diesen Handbüchern sind einige Punkte hervorzuheben. Dies sind diejenigen, auf die ich am häufigsten falsch konfiguriert stoße.

• Speicher - Überprüfen Sie die Partitionsausrichtung, obwohl dies für W2K8 + weniger problematisch ist, da normalerweise keine manuelle Partitionsausrichtung erforderlich ist (nicht standardmäßiges / exotisches SAN beiseite). Format mit einer Blockgröße von 64 KB, nicht standardmäßig 4 KB, für Datenlaufwerke. Führen Sie eine Reihe grundlegender SQLIO- Tests durch, damit Sie a) einen Maßstab für den Vergleich von Server X mit Server Y haben und b) ein gewisses Maß an Vertrauen in diese Serverfähigkeit haben.

• Antivirus - Stellen Sie sicher, dass MDF-, NDF- und LDF-Dateien von Ihrem Antivirenscanner ausgeschlossen sind. Diese können auf einem ausgelasteten System zu Chaos führen. Beheben Sie das Problem, bevor dies der Fall ist.

• Modelldatenbank - Alle an der Modelldatenbank vorgenommenen Änderungen werden in jeder von Ihnen erstellten Benutzerdatenbank berücksichtigt. Stellen Sie die Modellgröße und die Wachstumsraten auf sinnvolle Werte für Ihre Umgebung / Ihr System ein. Anstelle eines anderen Handbuchs: EINFACHE Wiederherstellung (falls jemand vergisst, Protokollsicherungen zu konfigurieren), 2048 MB Datendatei mit 1024 MB Wachstum, 1024 MB Protokolldatei mit 512 MB Wachstum (gemäß JK-Checkliste).

Planen Sie für einen Server / ein System / eine Anwendung, der / die als geschäftskritisch eingestuft wird und einem strengen SLA unterliegt, das Schlechte. Mit diesen müssen Sie so nah wie möglich an 100% sicher sein, dass sich das Upgrade für das Unternehmen oder die Benutzer nicht als Downgrade herausstellt. Für dieses Maß an Vertrauen müssen Sie noch mehr testen, testen und testen.

In jedem großen System gibt es ein oder zwei Abfragen, für deren Optimierung ein Hack / Workaround / Hinweis erforderlich ist. Einige sind absichtlich und basieren auf den besten Ratschlägen der Zeit, andere sind Notfallkorrekturen, die vergessen wurden. Dies sind die Abfragen, die das Verhalten beim Upgrade aufgrund von Optimierungen und Verbesserungen am Abfrageoptimierer unerwartet ändern. Nur eine Möglichkeit, sie zu erkennen, führen Sie sie auf Ihrem neuen Kit aus.

Mein bevorzugter Ansatz ist die Erfassung und Wiedergabe der Workload mit den RML-Tools . Es gibt eine hervorragende Anleitung von SQL CAT zur Verwendung von RML für genau diesen Zweck: Präzisionsleistung für Microsoft SQL Server mit RML Utilities 9.0 .

SQL 2008 zu SQL 2008 R2 ist kein großer Wechsel, aber wenn Sie von Windows 2003 zu Windows 2008 wechseln, müssen Sie die hostbasierte Firewall ansprechen. Weitere wichtige Punkte sind Agentenjobs, Berechtigungen in master / msdb / model, das Migrieren von Anmeldungen von einem Server auf einen anderen, die Durchführung einer Sicherungswiederherstellung auf einem neuen Server oder ein direktes Upgrade, der Kompatibilitätsmodus usw.