vCenter: VIM_VCDB voll

Vor kurzem habe ich geschrieben, was zu tun ist wenn die Transaktionslogs der vCenter Datenbank voll sind (VIM_VCDB transactionlog voll). Heute hatte ich den anderen Fall: Die Datenbank (SQL-Express 2005) war voll bis zum Rand (bei SQL Express ist das Größenlimit 4GB). Alle üblichen Tricks mit Verkleinern der DB halfen nicht. Es war gerade mal 1 MB oder weniger frei. Das führt dazu, daß der vCenter Dienst nur kurz startet und sich nach einigen Sekunden wieder verabschiedet.

Was tun?

Zielführend war ein Artikel aus der vmware Knowledge Base (KB1025914).

Das Prinzip beruht darauf, daß man die Haltezeiten für Ereignisse und Metriken stark reduziert und danach den Bereinigungsmechanismus triggert. Ein Zugriff auf vCenter via vSphere-Client ist dazu nicht notwendig. Dort kann man diese Einstellungen zwar auch tätigen (vgl. weiter unten), aber nur solange vCenter funktional ist.

Ablauf

• alle vCenter Dienste beenden
• Microsoft Management Studio öffnen. Das kann der vCenter Host selbst, oder ein anderer Server im LAN sein. Ggf. ist es notwendig die Firewall des vCenter Hosts zu deaktivieren, da Management Studio öfter Verbindungsprobleme hat.
• Neuen Host verbinden. <vCenter>/VIM_VCDB

• [Optional, aber empfohlen] Datenbank Sicherung. Datenbanken erweitern bis zur VIM_VCDB. Kontextmenü (Rechtsklick) > Tasks > Sichern. Für den Fall das etwas dazwischen kommt und die Dinge noch schlechter werden. 😉

• Im Management Studio unter Tabellen die Tabelle VPX_PARAMETER suchen und öffnen. Dabei die Werte der unten aufgeführten Parameter anpassen. Diese Werte können normalerweise im vSphereclient unter vCenter-Settings verändert werden… wenn vCenter verfügbar wäre.
  • event.maxAge [Wert: Haltezeit in Tagen]
  • event.maxAgeEnabled [True]
  • task.maxAge [Wert: Haltezeit in Tagen]
  • task.maxAgeEnabled [True]
• Die Größe des Transaktionsprotokolls sollte nicht limitiert sein, damit der nun folgende Schritt nicht daran scheitert. Wie das funktioniert habe ich im Beitrag “vCenter: VIM_VCDB transactionlog voll” geschrieben.
• Die eigentliche Bereinigung erfolgt mit der Gespeicherten Prozedur cleanup_events_tasks_proc welche man unter VIM_VCDB > Programmierbarkeit > Gespeicherte Prozeduren findet (vgl. Bild). Rechtsklick und “ausführen”.

Der Vorgang dauert einige Minuten, je nach Datenbankgröße. Nach erfolgreicher Bereinigung kann die Größe der Datenbank im Management Studio überprüfen.

Ganz harte Fälle

Es gibt Situationen, da helfen die oben geschilderten Methonden auch nicht mehr. Die Stored-Procedure kann nicht laufen, da das Transactionlog gewaltig anwächst und dafür beispielsweise kein Platz mehr ist. In solchen Fällen muss man in die Rolle von Gordon Freeman schlüpfen und das Brecheisen verwendet werden. 😉

Der Ablauf ist fast identisch mit dem oben geschilderten. Mit dem Unterschied, daß nicht die Stored-Procedure cleanup_events_tasks_proc ausgeführt wird, sondern direkt Tabellen manipuliert werden. [BACKUP FIRST !]

In Management Studio Express führt man nacheinander folgende Befehle aus.

truncate table vpx_event_arg;
truncate table vpx_event;

Es ist hier wichtig, den SQL Befehl TRUNCATE und nicht DELETE zu verwenden. Delete erzeugt einen Eintrag im Transactionlog für jedes gelöschte Element. Truncate ist hier viel sparsamer. Truncate hat jedoch einige Einschränkungen. Der Befehl ‘DELETE FROM’ würde funktionieren, führt aber wiederum zu einem Anschwellen des Transactionlog. Das Problem sind die Foreign-Keys der Tabelle. Eine elegante Lösung entwickelte vFrank. Er modifiziert zunächst die Tabelle, führt danach TRUNCATE aus und fügt schliesslich die Foreign-Keys wieder hinzu. Very clever! 😎

alter table VPX_EVENT_ARG drop constraint FK_VPX_EVENT_ARG_REF_EVENT, FK_VPX_EVENT_ARG_REF_ENTITY 
alter table VPX_ENTITY_LAST_EVENT drop constraint FK_VPX_LAST_EVENT_EVENT

truncate table VPX_TASK
truncate table VPX_ENTITY_LAST_EVENT
truncate table VPX_EVENT
truncate table VPX_EVENT_ARG

alter table VPX_EVENT_ARG add constraint FK_VPX_EVENT_ARG_REF_EVENT foreign key(EVENT_ID) references VPX_EVENT (EVENT_ID) on delete cascade, constraint FK_VPX_EVENT_ARG_REF_ENTITY foreign key (OBJ_TYPE) references VPX_OBJECT_TYPE (ID)
alter table VPX_ENTITY_LAST_EVENT add constraint FK_VPX_LAST_EVENT_EVENT foreign key(LAST_EVENT_ID) references VPX_EVENT (EVENT_ID) on delete cascade

Vorbeugung

Man beachte, daß die integrierte SQL-Express installation nur bis zu einer begrenzen Anzahl Hosts und VMs unterstützt wird.

Note: SQL Express 2005/2008 (vCenter Server 5.0 has SQL Express 2008 as the bundled edition) supports a maximum of 5 hosts and 50 virtual machines. If your environment exceeds this threshold, you must upgrade your database to SQL Standard.

Bevor es zur Datenbankschmelze kommt sollte man bei der SQL Express Edition einige Vorsichtsmaßnahmen treffen:

Im vSphere-Client lassen sich die maximalen Haltezeiten konfigurieren. Im Prinzip macht man damit eine Manipulation der Tabelle VPX_PARAMETER wie oben beschrieben – nur über die GUI des vSphere-Clients. Das Problem war aber, daß der vSphere-Client nicht zugänglich war.

Im dortigen Menü unter Datenbankaufbewahrungsrichtlinie läßt sich die Haltezeit konfigurieren. Die Checkmarks müssen gesetzt sein, sonst ist der eingestellte Wert wirkungslos.

Zudem sollte man immer wieder einen Blick auf das Datenbankfile werfen. Im Management Studio die Datenbank auswählen, Rechtsklick > Eigenschaften.

 

Weitere Info zum Thema:

KB1009857 Purge Skript aktualisieren nach DB Upgrade.