20
Crash Datenbankserver (Oracle)
Liebes Forumsteam,
in unserem Unternehmen setzen wir folgende Konfiguration ein:
VMware ESXi 5.5.0 (free) Host Server (HP ProLiant DL380p Gen8 mit 12CPU x 2,094GHz) mit 5 installierten Gastservern:
*) Server 1: Windows Server 2012; Übernimmt Active Directory, DNS, Fileserver, Printserver
*) Server 2: Windows Server 2012; Datenbankserver für Oracle 12c
*) Server 3: Windows Server 2012 R2; Terminalserver
*) Server 4: Windows Server 2012; Übernimmt die Kommunikation zu Fremdsystemen (Webservices etc.)
*) Server 5: Windows 8.1; Kleine MSSQL Datenbank
Das Problem ist, dass unser Datenbankserver anscheinend sporadisch den Geist aufgibt, was sich wie folgt darstellt:
*) Die Clients zeigen plötzlich die Fehlermeldung, dass keine Datenbankverbindung mehr möglich ist.
*) Versucht man in dem Moment, in dem diese Fehlermeldung kommt auf den AD zuzugreifen (Dateizugriff), erhält man eine Fehlermeldung, dass dieser nicht erreichbar ist
*) Nach einigen Sekunden kann man die Verbindung zum AD wiederherstellen, allerdings ist die Datenbankverbindung immer noch nicht möglich
*) Über TNSPing ist die Datenbank noch erreichbar. Baut man eine RDP-Verbindung zum DB-Server auf, so wird nur der Desktophintergrund und eine leere Taskleiste angezeigt (keine Symbole am Desktop und in der Taskleiste). Bei Login als Administrator wird noch die Server Management Konsole geöffnet, beim Aufrufen des Ereignisprotokolls über diese gibt es allerdings einen Fehler wegen anscheinend fehlenden Berechtigungen.
*) Die Datenbank funktioniert erst nach einem Neustart des Datenbankservers und Neustarten der zugreifenden Anwendungen wieder
Datenbankzugriffe erfolgen bei uns über ODP.net Komponenten (Zusatzprogrammierungen), sowie über den Oracle Client (Hauptanwendung).
Folgende Logs finde ich auf den Servern kurz bevor der Fehler auftritt:
AD:
*) ID105, 326, 327, 103: ESENT Meldungen, dass das Datenbankmodul eine neue Instanz gestartet hat, sowie eine neue Datenbank angefügt hat, und dann eine Datenbank getrennt hat
*) ID 7036: Service Control Manager "Dienst Remoteregistrierung befindet sich im Status Beendet / Ausgeführt"
Keine Info über den Verbindungsabbruch
Datenbank:
*) ID 1000:
Name der fehlerhaften Anwendung: Explorer.EXE, Version: 6.2.9200.16384, Zeitstempel: 0x50107dbc
Name des fehlerhaften Moduls: windows.immersiveshell.serviceprovider.dll, Version: 6.2.9200.16384, Zeitstempel: 0x50108240
Ausnahmecode: 0x80270233
Fehleroffset: 0x000000000000854f
ID des fehlerhaften Prozesses: 0x269c
Startzeit der fehlerhaften Anwendung: 0x01cfe19a88591f6b
Pfad der fehlerhaften Anwendung: C:\Windows\Explorer.EXE
Pfad des fehlerhaften Moduls: C:\Windows\System32\windows.immersiveshell.serviceprovider.dll
Berichtskennung: c6438e34-4d8d-11e4-93fa-000c29e432e5
Vollständiger Name des fehlerhaften Pakets:
Anwendungs-ID, die relativ zum fehlerhaften Paket ist:
*) ID 1001:
Fehlerbucket , Typ 0
Ereignisname: APPCRASH
Antwort: Nicht verfügbar
CAB-Datei-ID: 0
Problemsignatur:
P1: Explorer.EXE
P2: 6.2.9200.16384
P3: 50107dbc
P4: windows.immersiveshell.serviceprovider.dll
P5: 6.2.9200.16384
P6: 50108240
P7: 80270233
P8: 000000000000854f
P9:
P10:
Meine Vermutung:
Es sieht für mich so aus, als würde die komplette Rechteverwaltung durch einen kurzen Ausfall des AD (warum auch immer!?) zusammenbrechen. Mein nächster Schritt wird sein, den DB-Server aus der Domäne zu nehmen und zu analysieren, ob die Probleme weiterhin auftreten.
Gibt es von Eurer Seite eventuell Ideen zu meinem Problem? Warum friert der Explorer einfach so ein?
Vielen Dank!
-Robert
in unserem Unternehmen setzen wir folgende Konfiguration ein:
VMware ESXi 5.5.0 (free) Host Server (HP ProLiant DL380p Gen8 mit 12CPU x 2,094GHz) mit 5 installierten Gastservern:
*) Server 1: Windows Server 2012; Übernimmt Active Directory, DNS, Fileserver, Printserver
*) Server 2: Windows Server 2012; Datenbankserver für Oracle 12c
*) Server 3: Windows Server 2012 R2; Terminalserver
*) Server 4: Windows Server 2012; Übernimmt die Kommunikation zu Fremdsystemen (Webservices etc.)
*) Server 5: Windows 8.1; Kleine MSSQL Datenbank
Das Problem ist, dass unser Datenbankserver anscheinend sporadisch den Geist aufgibt, was sich wie folgt darstellt:
*) Die Clients zeigen plötzlich die Fehlermeldung, dass keine Datenbankverbindung mehr möglich ist.
*) Versucht man in dem Moment, in dem diese Fehlermeldung kommt auf den AD zuzugreifen (Dateizugriff), erhält man eine Fehlermeldung, dass dieser nicht erreichbar ist
*) Nach einigen Sekunden kann man die Verbindung zum AD wiederherstellen, allerdings ist die Datenbankverbindung immer noch nicht möglich
*) Über TNSPing ist die Datenbank noch erreichbar. Baut man eine RDP-Verbindung zum DB-Server auf, so wird nur der Desktophintergrund und eine leere Taskleiste angezeigt (keine Symbole am Desktop und in der Taskleiste). Bei Login als Administrator wird noch die Server Management Konsole geöffnet, beim Aufrufen des Ereignisprotokolls über diese gibt es allerdings einen Fehler wegen anscheinend fehlenden Berechtigungen.
*) Die Datenbank funktioniert erst nach einem Neustart des Datenbankservers und Neustarten der zugreifenden Anwendungen wieder
Datenbankzugriffe erfolgen bei uns über ODP.net Komponenten (Zusatzprogrammierungen), sowie über den Oracle Client (Hauptanwendung).
Folgende Logs finde ich auf den Servern kurz bevor der Fehler auftritt:
AD:
*) ID105, 326, 327, 103: ESENT Meldungen, dass das Datenbankmodul eine neue Instanz gestartet hat, sowie eine neue Datenbank angefügt hat, und dann eine Datenbank getrennt hat
*) ID 7036: Service Control Manager "Dienst Remoteregistrierung befindet sich im Status Beendet / Ausgeführt"
Keine Info über den Verbindungsabbruch
Datenbank:
*) ID 1000:
Name der fehlerhaften Anwendung: Explorer.EXE, Version: 6.2.9200.16384, Zeitstempel: 0x50107dbc
Name des fehlerhaften Moduls: windows.immersiveshell.serviceprovider.dll, Version: 6.2.9200.16384, Zeitstempel: 0x50108240
Ausnahmecode: 0x80270233
Fehleroffset: 0x000000000000854f
ID des fehlerhaften Prozesses: 0x269c
Startzeit der fehlerhaften Anwendung: 0x01cfe19a88591f6b
Pfad der fehlerhaften Anwendung: C:\Windows\Explorer.EXE
Pfad des fehlerhaften Moduls: C:\Windows\System32\windows.immersiveshell.serviceprovider.dll
Berichtskennung: c6438e34-4d8d-11e4-93fa-000c29e432e5
Vollständiger Name des fehlerhaften Pakets:
Anwendungs-ID, die relativ zum fehlerhaften Paket ist:
*) ID 1001:
Fehlerbucket , Typ 0
Ereignisname: APPCRASH
Antwort: Nicht verfügbar
CAB-Datei-ID: 0
Problemsignatur:
P1: Explorer.EXE
P2: 6.2.9200.16384
P3: 50107dbc
P4: windows.immersiveshell.serviceprovider.dll
P5: 6.2.9200.16384
P6: 50108240
P7: 80270233
P8: 000000000000854f
P9:
P10:
Meine Vermutung:
Es sieht für mich so aus, als würde die komplette Rechteverwaltung durch einen kurzen Ausfall des AD (warum auch immer!?) zusammenbrechen. Mein nächster Schritt wird sein, den DB-Server aus der Domäne zu nehmen und zu analysieren, ob die Probleme weiterhin auftreten.
Gibt es von Eurer Seite eventuell Ideen zu meinem Problem? Warum friert der Explorer einfach so ein?
Vielen Dank!
-Robert
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 251083
Url: https://administrator.de/contentid/251083
Printed on: April 25, 2024 at 12:04 o'clock
20 Comments
Latest comment
Hi.
Wie ich selber erfahren habe, gibt es auf ESXI 5.5 Probleme mit Server 2012 R2 und Win8.1.
Sétzt Du auf 8.1 die virtuelle Intel-Netzwerkkarte ein? Wenn ja, ändere dies mal auf vmxnet3.
Wie ich selber erfahren habe, gibt es auf ESXI 5.5 Probleme mit Server 2012 R2 und Win8.1.
Sétzt Du auf 8.1 die virtuelle Intel-Netzwerkkarte ein? Wenn ja, ändere dies mal auf vmxnet3.
Moin,
Gruß,
Dani
Setzt Du auf 8.1 die virtuelle Intel-Netzwerkkarte ein? Wenn ja, ändere dies mal auf vmxnet3.
Das gilt auch für die Server. Die VMs bzw. Vorlagen nach Vorgaben von VMWare installiert/konfiguriert?Gruß,
Dani
Hallo,
vielen Dank für die Antworten.
Ja, das Problem mit den Netzwerkkartendrivern haben wir auch gehabt und danach auf vmxnet3 umgestellt. Die alten Netzwerkkarten sind aber immer noch am Server konfiguriert, allerdings deaktiviert. Könnte das ein Problem darstellen?
Bezüglich Vorgaben von VMWare: Das muss ich checken, leider habe ich die Server nicht selbst aufgesetzt, sondern unser externer IT-Betreuer. Werde mich morgen erkundigen!
Danke auf jeden Fall einstweilen!
vielen Dank für die Antworten.
Ja, das Problem mit den Netzwerkkartendrivern haben wir auch gehabt und danach auf vmxnet3 umgestellt. Die alten Netzwerkkarten sind aber immer noch am Server konfiguriert, allerdings deaktiviert. Könnte das ein Problem darstellen?
Bezüglich Vorgaben von VMWare: Das muss ich checken, leider habe ich die Server nicht selbst aufgesetzt, sondern unser externer IT-Betreuer. Werde mich morgen erkundigen!
Danke auf jeden Fall einstweilen!
Moin,
wichtig wäre auch das der ESXi auf aktuellen Patchstand ist. Gerade in Punkte 2012R2/8.1 wurde viel von VMWare nachgebessert.
lg,
Slainte
wichtig wäre auch das der ESXi auf aktuellen Patchstand ist. Gerade in Punkte 2012R2/8.1 wurde viel von VMWare nachgebessert.
lg,
Slainte
Hallo,
habe gerade die Installation nach Anleitung von VMWare gecheckt.
Host- sowie Gastserver wurden nach Instruktionen von VMWare installiert (http://partnerweb.vmware.com/GOSIG/Windows_Server_2012.html#installatio ..).
Bezüglich des aktuellen Patchstandes:
Wir haben im Moment ESXi, 5.5.0, 1623387 (also Update 1) installiert. Werde heute organisieren, dass wir das neueste "Update 2" installieren.
lg,
Robert
habe gerade die Installation nach Anleitung von VMWare gecheckt.
Host- sowie Gastserver wurden nach Instruktionen von VMWare installiert (http://partnerweb.vmware.com/GOSIG/Windows_Server_2012.html#installatio ..).
Bezüglich des aktuellen Patchstandes:
Wir haben im Moment ESXi, 5.5.0, 1623387 (also Update 1) installiert. Werde heute organisieren, dass wir das neueste "Update 2" installieren.
lg,
Robert
Moin,
Gruß,
Dani
Könnte das ein Problem darstellen?
Könnte.... genaues weis man nicht. Einfach deinstallieren und den Server neu starten.Gruß,
Dani
Hallo,
Ok, werden die Netzwerkkarten entfernen.
Bezüglich des Updates auf "Update 2" habe ich soeben erfahren, dass wir eine "HP custom Version" (inklusive HP Treiber) installiert haben. Bei Installation des Update 2auf einer Testumgebung (auch von HP) kam es bei unserem IT-Betreuer zu Fehlern. Allerdings gibt es in der Testumgebung nicht die geforderten 8GB Memory. Werden die Memorys ergänzen, dann nochmals testen und dann in die Produktivumgebung gehen.
Vielen Dank nochmals für Eure Hilfe!
-Robert
Könnte.... genaues weis man nicht. Einfach deinstallieren und den Server neu starten.
Ok, werden die Netzwerkkarten entfernen.
Bezüglich des Updates auf "Update 2" habe ich soeben erfahren, dass wir eine "HP custom Version" (inklusive HP Treiber) installiert haben. Bei Installation des Update 2auf einer Testumgebung (auch von HP) kam es bei unserem IT-Betreuer zu Fehlern. Allerdings gibt es in der Testumgebung nicht die geforderten 8GB Memory. Werden die Memorys ergänzen, dann nochmals testen und dann in die Produktivumgebung gehen.
Vielen Dank nochmals für Eure Hilfe!
-Robert
Liebes Forumsteam,
Netzwerkkarten wurden entfernt, Update 2 wurde installiert, und es gibt eine neue Erkenntnis:
In der Oracle-DB gibt es ein Trace-File, welches mir folgenden Fehler liefert:
Habe den Fehler dann gegoogelt und bin auf eine Einstellung im Oracle System gekommen, die eine Authentifizierung auf der Datenbank über Windows-User komplett deaktiviert und nur mehr database-user zulässt (wir verwenden nur Datenbank-user).
Die Einstellung ist in der "sqlnet.ora" zu finden.
Jetzt funktionieren alle unsere Dienste ständig, auch wenn der Datenbankserver wieder einmal keinen Desktop und keine Taskleiste anzeigt! Ein weiterer interessanter Fakt ist, dass dieses Phänomen nur auftritt, wenn man sich mit einem Domänen-Benutzer (bzw. Domänen-Admin) anmeldet. Erfolgt die Anmeldung über einen lokalen User, so funktioniert das OS ganz normal!
Habe nach diesem Problem im Internet gesucht, aber leider nichts passendes gefunden.
LG
Robert
Netzwerkkarten wurden entfernt, Update 2 wurde installiert, und es gibt eine neue Erkenntnis:
In der Oracle-DB gibt es ein Trace-File, welches mir folgenden Fehler liefert:
TNS-12638: Credential retrieval failed
opiodr aborting process unknown ospid (9856) as a result of ORA-609
opiodr aborting process unknown ospid (9856) as a result of ORA-609
Habe den Fehler dann gegoogelt und bin auf eine Einstellung im Oracle System gekommen, die eine Authentifizierung auf der Datenbank über Windows-User komplett deaktiviert und nur mehr database-user zulässt (wir verwenden nur Datenbank-user).
Die Einstellung ist in der "sqlnet.ora" zu finden.
Jetzt funktionieren alle unsere Dienste ständig, auch wenn der Datenbankserver wieder einmal keinen Desktop und keine Taskleiste anzeigt! Ein weiterer interessanter Fakt ist, dass dieses Phänomen nur auftritt, wenn man sich mit einem Domänen-Benutzer (bzw. Domänen-Admin) anmeldet. Erfolgt die Anmeldung über einen lokalen User, so funktioniert das OS ganz normal!
Habe nach diesem Problem im Internet gesucht, aber leider nichts passendes gefunden.
LG
Robert
Kein Desktop:
Drücke STRG-ALT-ENTF, Taskmanager starten, da dann auf Datei -> Neuer Task -> explorer.exe eingeben
Dann sollten sich Desktop usw wieder aufbauen (ohne Verluste)
Gruss RS
Drücke STRG-ALT-ENTF, Taskmanager starten, da dann auf Datei -> Neuer Task -> explorer.exe eingeben
Dann sollten sich Desktop usw wieder aufbauen (ohne Verluste)
Gruss RS
Hallo,
Habe ich bereits versucht, Ergebnis: Es öffnet sich der ganz normale Windows-(Datei-)Explorer.
Die Taskleiste und der Desktop bleiben weg.
Grüße,
Robert
Drücke STRG-ALT-ENTF, Taskmanager starten, da dann auf Datei -> Neuer Task -> explorer.exe eingeben
> Dann sollten sich Desktop usw wieder aufbauen (ohne Verluste)Habe ich bereits versucht, Ergebnis: Es öffnet sich der ganz normale Windows-(Datei-)Explorer.
Die Taskleiste und der Desktop bleiben weg.
Grüße,
Robert
Hi,
hmmm, dann könntest Du evtl. vorher noch mit dem TaskManager alle existenten explorer.exe-Tasks
abschiessen, und DANN über Datei->bla die explorer.exe neu aufrufen...
Vielleicht geht das.
Gruss RS
hmmm, dann könntest Du evtl. vorher noch mit dem TaskManager alle existenten explorer.exe-Tasks
abschiessen, und DANN über Datei->bla die explorer.exe neu aufrufen...
Vielleicht geht das.
Gruss RS
Hallo,
existierenden Explorer beenden und neu starten bringt nur wieder einen leeren Desktop und eine leere (nur blaue) Taskleiste.
Wollte jetzt einen Systemcheck mit sfc /scannow ausführen, allerdings erhalte ich den Fehler "Der Windows-Ressourcenschutz konnte den angeforderten Vorgang nicht ausführen".
LG
Robert
existierenden Explorer beenden und neu starten bringt nur wieder einen leeren Desktop und eine leere (nur blaue) Taskleiste.
Wollte jetzt einen Systemcheck mit sfc /scannow ausführen, allerdings erhalte ich den Fehler "Der Windows-Ressourcenschutz konnte den angeforderten Vorgang nicht ausführen".
LG
Robert
Hi,
falls noch aktuell, starte einfach einen weiteren exporer.exe-Task, irgendwann müsste der Desktop kommen
Gruss RS
falls noch aktuell, starte einfach einen weiteren exporer.exe-Task, irgendwann müsste der Desktop kommen
Gruss RS
Hallo,
ich kann das Problem von RFoerster auf mehreren Systemen nachvollziehen. Der Oracle Workaround sorgt lediglich dafür, das die DBs weiterhin erreichbar bleiben. Der Server selber ist bis zu einem Neustart praktisch nicht administrierbar.
Da das Thema ja bereits 3 Monate zurückliegt: Meine Frage hat jemand inzwischen eine Lösung gefunden?
Danke
Uwe
ich kann das Problem von RFoerster auf mehreren Systemen nachvollziehen. Der Oracle Workaround sorgt lediglich dafür, das die DBs weiterhin erreichbar bleiben. Der Server selber ist bis zu einem Neustart praktisch nicht administrierbar.
Da das Thema ja bereits 3 Monate zurückliegt: Meine Frage hat jemand inzwischen eine Lösung gefunden?
Danke
Uwe
Hallo Uwe,
ich wollte Dir gerade schreiben, dass wir jetzt seit einigen Wochen keine Probleme mehr haben ==> mache zur Sicherheit eine Remoteverbindung zum Server auf und er ist wieder mal ohne GUI.......
Was wir in der Zwischenzeit versucht haben:
*) Der Oracle-Server ist bei uns auf einem falschen Storage gelegen (war auf einem Raid 5 gemeinsam mit anderen Servern, liegt jetzt alleine auf einem Raid 1), wurde verschoben.
*) Es waren zwar die VMWare-Tools am Oracle Server installiert (und damit auch der richtige Netzwerkdriver VMNEXT3, jedoch nicht auf einigen anderen VMs, diese wurden nachinstalliert.
*) Das Gastbetriebssystem wurde in den Energieeinstellungen auf "Höchstleistung" gesetzt
Tut mir leid, dass ich Dir nicht weiterhelfen kann, habe mich selbst eigentlich schon fast damit abgefunden, dass der Server in naher Zukunft neu aufgesetzt werden muss...
-Robert
ich wollte Dir gerade schreiben, dass wir jetzt seit einigen Wochen keine Probleme mehr haben ==> mache zur Sicherheit eine Remoteverbindung zum Server auf und er ist wieder mal ohne GUI.......
Was wir in der Zwischenzeit versucht haben:
*) Der Oracle-Server ist bei uns auf einem falschen Storage gelegen (war auf einem Raid 5 gemeinsam mit anderen Servern, liegt jetzt alleine auf einem Raid 1), wurde verschoben.
*) Es waren zwar die VMWare-Tools am Oracle Server installiert (und damit auch der richtige Netzwerkdriver VMNEXT3, jedoch nicht auf einigen anderen VMs, diese wurden nachinstalliert.
*) Das Gastbetriebssystem wurde in den Energieeinstellungen auf "Höchstleistung" gesetzt
Tut mir leid, dass ich Dir nicht weiterhelfen kann, habe mich selbst eigentlich schon fast damit abgefunden, dass der Server in naher Zukunft neu aufgesetzt werden muss...
-Robert
Hallo zusammen,
wir haben hier exakt dasselbe Problem mit der Kombination HP Proliant DL380p Gen8 Server, VMware vSphere 5.5 mit allen Host-Patches, Windows Server 2012 R2 und Oracle 12c (R1).
Alle 12 bis 14 Tage ist der Server in einem merkwürdigen Zustand. Der Start-Button funktioniert nicht mehr und die in der Aufgabenplanung hinterlegten Oracle-Export-Tasks laufen auch nicht mehr. Außerdem lassen sich auf der Maschine solange keine Windows-Updates installieren, bis ich den Server neugestartet habe. Nach dem Neustart läuft für einige Tage alles wunderbar, als wäre nie was gewesen. Im Windows-EventLog finde ich lediglich einen roten Eintrag, der hier auch schon beschrieben wurde:
Allerdings sehe ich hier nicht die Ursache, sondern eher eine weitere Folge aus einem anderen Problem, dass sich jedoch nicht auffinden lässt.
Die Windows VM hat den VMXNET3-Adapter, alle Host-Patches, HP-Firmware-Updates sowohl Windows-Updates sind installiert. Die Verwendung von "sfc /scannow" hat keine Fehler gefunden.
So meine Frage: Da der Thread schon etwas länger ruht, wie habt Ihr das Problem mit eueren Servern gelöst? Hat die Neuinstallation von Windows Abhilfe gebracht? Habt ihr vielleicht auf VMware 6 aktualisiert? Oder bestehen die Probleme bei euch nach wie vor?
Eine Idee wäre noch, per Task den Server einmal pro Woche neuzustarten. Das halte ich jedoch zu sehr für improvisiert - zumal ich nicht weiß, ob durch den Fehler noch Langzeitfolgen hinsichtlich der DB-Konsistenz auftreten können.
Viele Grüße
Christian
wir haben hier exakt dasselbe Problem mit der Kombination HP Proliant DL380p Gen8 Server, VMware vSphere 5.5 mit allen Host-Patches, Windows Server 2012 R2 und Oracle 12c (R1).
Alle 12 bis 14 Tage ist der Server in einem merkwürdigen Zustand. Der Start-Button funktioniert nicht mehr und die in der Aufgabenplanung hinterlegten Oracle-Export-Tasks laufen auch nicht mehr. Außerdem lassen sich auf der Maschine solange keine Windows-Updates installieren, bis ich den Server neugestartet habe. Nach dem Neustart läuft für einige Tage alles wunderbar, als wäre nie was gewesen. Im Windows-EventLog finde ich lediglich einen roten Eintrag, der hier auch schon beschrieben wurde:
Application Error
Name der fehlerhaften Anwendung: Explorer.EXE, Version: 6.3.9600.18231, Zeitstempel: 0x56b8c9f1
Name des fehlerhaften Moduls: twinui.appcore.dll, Version: 6.3.9600.18423, Zeitstempel: 0x5793b4e5
Ausnahmecode: 0x80270233
Fehleroffset: 0x000000000008c5fb
ID des fehlerhaften Prozesses: 0x9a0
Startzeit der fehlerhaften Anwendung: 0x01d24aec64bf9b82
Pfad der fehlerhaften Anwendung: C:\Windows\Explorer.EXE
Pfad des fehlerhaften Moduls: C:\Windows\System32\twinui.appcore.dll
Berichtskennung: a2924d16-b6df-11e6-8101-0050569f4266
Vollständiger Name des fehlerhaften Pakets:
Anwendungs-ID, die relativ zum fehlerhaften Paket ist: Allerdings sehe ich hier nicht die Ursache, sondern eher eine weitere Folge aus einem anderen Problem, dass sich jedoch nicht auffinden lässt.
Die Windows VM hat den VMXNET3-Adapter, alle Host-Patches, HP-Firmware-Updates sowohl Windows-Updates sind installiert. Die Verwendung von "sfc /scannow" hat keine Fehler gefunden.
So meine Frage: Da der Thread schon etwas länger ruht, wie habt Ihr das Problem mit eueren Servern gelöst? Hat die Neuinstallation von Windows Abhilfe gebracht? Habt ihr vielleicht auf VMware 6 aktualisiert? Oder bestehen die Probleme bei euch nach wie vor?
Eine Idee wäre noch, per Task den Server einmal pro Woche neuzustarten. Das halte ich jedoch zu sehr für improvisiert - zumal ich nicht weiß, ob durch den Fehler noch Langzeitfolgen hinsichtlich der DB-Konsistenz auftreten können.
Viele Grüße
Christian
Hallo Christian,
das Problem besteht bei uns leider immer noch. Im Unterschied zu euch funktioniert bei uns allerdings die Aufgabenplanung und alle Tasks, deswegen ist es nicht ganz so tragisch, wenn auch extrem ärgerlich (und unprofessionell...). Wir stellen innerhalb der nächsten 2 Monate auf eine Cloud-Lösung um, muss mich dann nicht mehr mit dem (Oracle-)Server herumschlagen.
Tut mir leid, dass ich dir nicht weiterhelfen konnte.
-Robert
das Problem besteht bei uns leider immer noch. Im Unterschied zu euch funktioniert bei uns allerdings die Aufgabenplanung und alle Tasks, deswegen ist es nicht ganz so tragisch, wenn auch extrem ärgerlich (und unprofessionell...). Wir stellen innerhalb der nächsten 2 Monate auf eine Cloud-Lösung um, muss mich dann nicht mehr mit dem (Oracle-)Server herumschlagen.
Tut mir leid, dass ich dir nicht weiterhelfen konnte.
-Robert
Hallo Robert,
danke für deine Antwort. Möglicherweise bekommen wir wenigstens die geplanten Tasks zum Laufen, indem wir die Authentifizierung auf der Datenbank über Windows-User auch deaktivieren - so wie es weiter oben schon einmal beschrieben wurde.
Ich würde nur gerne wissen, ob sich die Neu-Installation des Servers lohnt - oder ob ich mir das sparen kann, da der Effekt vielleicht wieder auftritt. Hattest du deinen Oracle-Server zwischenzeit neu installiert?
Christian
danke für deine Antwort. Möglicherweise bekommen wir wenigstens die geplanten Tasks zum Laufen, indem wir die Authentifizierung auf der Datenbank über Windows-User auch deaktivieren - so wie es weiter oben schon einmal beschrieben wurde.
Ich würde nur gerne wissen, ob sich die Neu-Installation des Servers lohnt - oder ob ich mir das sparen kann, da der Effekt vielleicht wieder auftritt. Hattest du deinen Oracle-Server zwischenzeit neu installiert?
Christian
Hallo Christian,
Oracle-Server wurde nicht neu aufgesetzt.
Wenn du das machst würde ich mich auch über ein Ergebnis freuen!
-Robert
Oracle-Server wurde nicht neu aufgesetzt.
Wenn du das machst würde ich mich auch über ein Ergebnis freuen!
-Robert
Hallo Robert,
ich habe den Oracle-Server bisher auch nicht neu aufgesetzt. Stattdessen habe ich das Problem umgangen, indem ich einen Task definiert habe, der den Server einmal pro Woche neustartet. Einfach per Batch mit folgendem Inhalt:
shutdown /r /t 5
Seither haben wir das Problem nicht mehr. Sollte der Zyklus von einer Woche irgendwann nicht mehr reichen, werde ich um eine Neuinstallation nicht drumrum kommen. Wenn ich die VMware-Umgebung mal wieder patche, werde ich den Task deaktivieren, um zu prüfen, ob die Patches irgendwelche Auswirkungen haben. Die letzte Aktualisierung habe ich zwischen den Jahren gemacht, trotzdem bestand das Problem weiter. Daher jetzt der Workaround mit dem reboot.
Viele Grüße,
Christian
ich habe den Oracle-Server bisher auch nicht neu aufgesetzt. Stattdessen habe ich das Problem umgangen, indem ich einen Task definiert habe, der den Server einmal pro Woche neustartet. Einfach per Batch mit folgendem Inhalt:
shutdown /r /t 5
Seither haben wir das Problem nicht mehr. Sollte der Zyklus von einer Woche irgendwann nicht mehr reichen, werde ich um eine Neuinstallation nicht drumrum kommen. Wenn ich die VMware-Umgebung mal wieder patche, werde ich den Task deaktivieren, um zu prüfen, ob die Patches irgendwelche Auswirkungen haben. Die letzte Aktualisierung habe ich zwischen den Jahren gemacht, trotzdem bestand das Problem weiter. Daher jetzt der Workaround mit dem reboot.
Viele Grüße,
Christian
