chaosmoengers 0 Geschrieben Freitag um 13:56 Melden Geschrieben Freitag um 13:56 Moin in die Runde, ich habe aktuell ein Problem bei der Erstellung meiner Wartungspläne im Kontext der Verfügbarkeitsgruppen. Zum Einsatz kommen bei uns zwei identische SQL-Server 2022 mit mehreren Instanzen und Verfügbarkeitsgruppen. Nun bin ich dabei die Wartungspläne einzurichten und frage mich, wie ich in diese eine Prüfung einbauen kann, welche den jeweiligen Knoten als aktiv (primäre Rolle) bez. inaktiv (sekundäre Rolle) identifiziert und dann entsprechend den Wartungsplan laufen lässt oder halt eben nicht laufen lässt. Die Funktion sys.fn_hadr_backup_is_preferred_replica ('DB Name')), die diese Prüfung für eine Datenbank durchführt, hatte ich schon entdeckt, nur weiss ich nicht an welcher Stelle ich diese in den Wartungsplan bzw. den Auftrag des SQL-Server Agents einbauen könnte. Da würde ich mich über ein kleine Hilfestellung freuen. Oder gibt es doch eine Möglichkeit für eine Verfügbarkeitsgruppe einen Wartungsplan zu erstellen. Ich meine gelesen zu haben, dass das für die sogenannten Enthaltenen Verfügbarkeitsgruppen nicht funktionieren würde. Ist dem so oder gibt es da Möglichkeiten? Ich danke schon mal im Voraus für eine Hilfestellung. Gruß Karsten Zitieren
t-sql 22 Geschrieben Freitag um 19:14 Melden Geschrieben Freitag um 19:14 Maintenance Pläne gehen in einer Contained AG nicht. Maintenance Pläne sind eh nicht das gelbe vom Ei. zu unflexible. Für die gängisten Wartungen sind die Scripte von Ola Hallengren die besten (ola.hallengren.com). Da haste auch keine Probleme mit den AGs. Als DBA solltest dich mit T-SQL auseinandersetzen. Da isses wichtig DMVs und System Tabellen zu kennen. Denn das meiste kannste eben nicht mit einem Maintenance Plan abdecken 1 Zitieren
vkf 0 Geschrieben Samstag um 09:44 Melden Geschrieben Samstag um 09:44 Reine PowerShell-Lösung ist übersichtlicher. Zitieren
t-sql 22 Geschrieben Samstag um 10:09 Melden Geschrieben Samstag um 10:09 vor 21 Minuten schrieb vkf: Reine PowerShell-Lösung ist übersichtlicher. Reine T-SQL Lösungen sind übersichtlicher. Powershell ist zu umständlich und dbatools (was die einzige Powershellalternative zu T-SQL wäre) darfste halt auch net auf jedem Server installieren. Außerdem viel zu umständlich mit SQL Agent auszuführen. Taskscheduler kannste in die Tonne kloppen weil faktisch keine Flexibilität. 1 Zitieren
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.