vSphere Verbindungsproblem

[dhruser]

Hallo zusammen,

in letzter Zeit habe ich des Öfteren ein Verbindungsproblem meines lokalen vSphere Clients auf den dazugehörigen Server.

Der vSphere Client konnte keine Verbindung zu XY herstellen

Nach einem Server Neustart geht es erstmal wieder...

ich denke aber im Grunde sind die Datenbanken (VIM_UMDB + VIM_VCDB bei beiden weniger als 1 MB frei) vollgelaufen (MS SQL Server Express ist ja limitiert).

Evtl könnte folgender Link mir helfen:
http://www.petenetlive.com/KB/Article/0000479.htm

Mich stört hierbei nur, das es eine ältere Quelle ist, und sich wahrsch. noch auf die 3 oder 4 VM Versionen bezieht...

Kann ich es trotzdem in meiner Umgebung versuchen?
vSphere Client Version 5.0.0 Build 1917469
VCenter Version 5.0.0 Build 1917469

Bzw. lösche ich beim Cleanup essentielle Daten/Infos oder eher mehr so Logs, die ich nicht für den korrekten Lauf meiner VM Umgebung benötige?

Besten Dank erstmal!

[irix]

Also das die VIM_UMDB voll laeuft hab ich noch nie gesehen.... ganz anders die VIM_VCDB. Wenn es alte Umgebungen sind und noch ein MSSQLEXPR 2005 zum Einsatz kommt dann ist hier die Grenze von max. 4GB pro DB. Beim spaeterem MSSQLEXP 2008 waren es dann 10GB. Wenn die DB voll ist bzw. das auto_grow keinen Extend mehr machen kann dann beendet sich letztendlich der vCenter Dienst aka "vxpd" auf deinem Windows. In den Logs kann man eigentlich sehen das die DB das Problem ist.

Es gibt einen KB Eintrag welcher beschreibt wie man Platz schaffen kann. Der hat aehnlichkeiten bzw. evtl. basiert dein geposteter Blogeintrag auf diesem KB. Allerdings gibts auch ein paar Andere Tabellen welche anschwellen koennen. Gerade in Umgebungen wo Jahrlang Snapshot basierte Sicherungen mit Veeam/vRanger und Co. laeufen.

Gruss
Joerg

[irix]

Hier ist einer der KBs http://kb.vmware.com/kb/1025914

Ich wuerde aber auch eine Auflistung der Tabellengroesse vorher mal machen um zuschauen wo man das Problem hat.

Sollte deine Umgebung aber zu Gross fuer eine MSSQLEXPR sein so ist an ein Upgrade der MSSQL zudenken oder Umstieg auf die VCSA mit embedded vPostgreSQL.

Gruss
Joerg

[dhruser]

Hallo irix,

danke für die Tipps! Das geht schon in die richtige Richtung!

- Größe Umgebung: Nein, meine Umgebung ist relativ überschaubar (15 Server, 2 Hosts)
- nutze MS-SQL EXP 2008 R2: Hier ist die Grenze 10 GB, wie von dir schon korrekt erläutert. Status im Moment ist:

VIM_UMDB:
Size: 44,88 MB
Space avail: 0,75 MB

VIM_VCDB:
Size: 7153,38 MB
space avail: 1,08 MB (wächst ja von alleine)

dementsprechend gilt:
a) du liegst richtig, die VIM_UMDB läuft so schnell nicht voll
b) zusammen sind etwa 7,2 GB von 10 GB belegt, man kann also doch noch nicht von vollgelaufen reden.

Die Windows Logs erzählen mir abaer nun auch etwas:
The transaction log for database 'VIM_VCDB' is full. To find out why space in the log cannot be reused, see the log_reuse_wait_desc column in sys.databases

Und dementsprechend vermute ich, das ich hier richtig aufgehoben bin:
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1003980

Oder?

[irix]

Transaktionslog != DB Groesse.

1. Das Limit von 10GB gilt fuer jede DB. Somit ist UMDB und VCDB getrennt zu sehen
2. Wenn du kein Backupprodukt hast welches die Transaktionslogs abschneidet nach einer Sicherung ja dann ist das irgendwann halt mal voll bzw. erreicht die Grenze. Das hat das hat dann natuerlich nichts mit der DB Groesse zutun

Stell mal das Wiederherstellungsmodell fuer die VCDB von "Vollstaendig" auf "Einfach". Letzteres ist sowas wie eine Umlaufprotokollierung.

Dann auch mal die DB bzw. Datei shrinken und posten was nun wirklich an Platz verwendet wird. Dann sehen wir weiter.

Gruss
Joerg

[~thc]

Was vielleicht hier von Interesse ist: Im Normalfall läuft eine SQL-Datenbank im "Full" Recovery Transaction Mode - das bedeutet, dass der SQL-Server neben der wachsenden Datenbank sämtliche Transaktionen in Replay-fähigen Logs speichert, die niemals von allein gelöscht werden.

Nur mithilfe von Backupsoftware, die eine "!vollständige VSS-Sicherung" fährt, werden die Transaktions-Logs gelöscht.

Der zweite Weg, die Logs zu löschen, ist der im KB-Artikel beschriebene: Datenbank auf "Simple" setzen und den Platz der Logs komplett freigeben.

@irix: Zu spät.

[dhruser]

Hi Leute,

ja klingt alles logisch und plausibel was ihr UND die Howtos sagen.
Eine Frage noch, ich bin da immer etwas unsicher bevor ich an einer DB was umstelle.

Ich zerschiese mir nix dadurch wenn ich das gleich umstelle oder? Ich kann ja nicht mitten am Tage den Betrieb der Server gefährden etc....

Ich denke es ist ungefährlich, aber sicher ist sicher

[~thc]

Nein, du verliest nur die Replay-fähigen Transaktions-Logs, nicht die Daten der Datenbank selbst.

The downside of this model is that it does not keep a record of the transaction logs, and therefore if there is a failure of the database all changes made after the last full backup are lost. If recovery from a failure is a high priority than the full recovery model must be used.

[irix]

Vorher fragen ist immer gut....

1. Mach ein Backup der SQL DB
2. Mach einen Snapshot (wenn es eine VM ist)

Das umstellen des Wiederherstellungsmodus auf Einfach führt zu keinen Problemen. Der SQL Server schreibt halt nicht mehr in seine Logs sondern gleich in die DBs.

Das mit dem Umstellen ist aber nur um das vCenter wieder zum fliegen zu bekommen. Hinterher geht die Arbeit eigentlich erst los

Gruss
Joerg