---

Hallo SmarTeamgemeinde,

Systeminfos:
SMARTEAM® - Editor V5R18 Service Pack 4
Oracle DB10G
Windows Server 2003
und das ganze läuft auf einem VMware ESX Server

Und nun zum Problem:
Wir haben eine Systemupdate von R16 auf R18 durchgeführt und dabei auch die Datenbank von Microsoft SQL2005 auf Qracle DB10G migriert. Das System läuft gerade im Test unter der Version V5R18. Die Menge der User hält sich in Grenzen (1-5 im Testbetrieb). Das System läuft, allerdings kommt es mehrmals am Tag vor, dass sich der Dienst "SmarTeam Vault Service" --> "VaultServer.exe" nahezu 100% der CPU des Servers krallt und diese auch behält bis man diese manuell restartet. In den Eventlogs sind keine nützlichen Informtionen zufinden.
Virenscanner ist deaktiviert.

Hat jemand schon ähnliche Erfahrungen gemacht? Evtl. Lösungsmöglichkeiten?

Danke und Grüße

Mc Daniel

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo,
wo liegen denn die Vault-Ordner bzw. sind diese Lokal oder im Netzwerk (per "normale" Freigabe oder I-SCSI)? Hier könnten Netzwerkprobleme oder DNS-Probleme zu dem Fehler führen. Im Falle des I-SCSI könntet ihr euch sogar damit die Datenbank zerreisen. Greifen mehrere Vault-Server auf die gleichen Ordner zu? Hier könnten gleichzeitige Zugriffe das Problem verursachen, da der eine Vault-Service nicht mit dem anderen kommuniziert. Habt ihr beide Versionen auf dem selben Server laufen? Sprich hat vielleicht die VMware ein Problem?

------------------
MFG
Rick Schulz

Konfuzius sprach: "Wer sich das Alte noch einmal vor Augen führt, um das Neue zu verstehen, der kann anderen ein Lehrer sein."

[Diese Nachricht wurde von RSchulz am 29. Sep. 2008 editiert.]

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo,

danke für die schnelle Antwort.
Die Vault-Ordner liegen Lokal auf der Maschine (physikalisch im SAN). Die Systeme Produktiv und Test sind komplett unabhänig voneinander, getrennte Datenbanken und getrennte Vaults. Es greift auch nur ein Dienst auf den Vault zu.
Das einzige was die Systeme verbindet, ist der gleiche ESX Server.

Grüße

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hmm das klingt soweit eigentlich i.O.. Es ist natürlich schwierig aus der ferne soetwas heikles beurteilen zu können. Passiert das denn sporadisch oder bei einer bestimmten Aktion? (Datenproblem) Ist vll. immer der gleich "User" der Auslöser? (Rechteproblem) Was bedeutet Physikalisch im SAN? iSCSI ist auch physikalisch im SAN... Genau dann würde es für ein Netzwerkproblem sprechen. Dabei kann es sein, dass nur bei einem Bruchteil einer Sekunde Netzwerkausfall der Vault-Server-Service abstürzt. Im normalen Betrieb fällt das nicht auf und die anderen Services laufen auch weiter. Des weiteren ist es laut DS entscheidend, dass die Oracle DB und die SmarTeam-Services auf unterschiedlichen Servern laufen.

------------------
MFG
Rick Schulz

Konfuzius sprach: "Wer sich das Alte noch einmal vor Augen führt, um das Neue zu verstehen, der kann anderen ein Lehrer sein."

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Danke für die Tipps,

Ja, ich habe auch schon versucht Gemeinsamkeiten zwischen dem Auftreten des Fehlers und bestimmten Aktionen von Usern festzustellen. Allerdings ohne Erfolg. Das Ganze passiert auch ohne dass ein User im SmarTeam arbeitet.
Wir verwenden kein iSCSI, am ESX Server hängt über FC an einer NetApp System.

Wir werden die Migration jetzt noch einmal durchführen, bin gespannt ob es was bringt.

Kann mir jemand sagen was der Dienst "SmarTeam Vault Service" genau macht?

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo,
im Endeffekt verwaltet dieser Dienst die Rechte und stellt die Ablageordner zur Verfügung. Sprich er Prüft, ob bestimmte Verzeichnisse wie SmTemp, Config zur Verfügung stehen und stellt die Ablageordner/Vaults zur Verfügung.

------------------
MFG
Rick Schulz

Konfuzius sprach: "Wer sich das Alte noch einmal vor Augen führt, um das Neue zu verstehen, der kann anderen ein Lehrer sein."

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo,
auch wenn es nicht direkt zur Lösung beiträgt: Auf unserem Testsystem mit ST R18SP5 (WinXP SP2, SQL Express, Vaults auf der Testmaschine angelegt) tritt dieses Problem auch regelmäßig auf. Wir haben noch keinen Ansatzpunkt gefunden, warum das so ist, bleiben aber dran.

------------------
mfg, hugin66

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo,

danke für die Info. Wir sind bei dem Thema auch noch nicht viel weiter und stochern ein wenig im Dunkeln. Mittlerweile läuft das 3 Testsystem. Auf allen 3 Sytemen tritt der Fehler ca 24h nach Serverstart auf. Wir haben einen entsprechenden Call bei Dassault aufgemacht.

Falls wir zur Lösung des Problems kommen, werde ich Sie informieren.

Grüße

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo zusammen,

so wie es ausschaut haben wir die Lösung auf das Problem gefunden.
Es sieht ganz danach aus, als das der Virenscanner der Schuldige ist. Nicht der lokal installiert Client, sondern ein zentrales Tool McAffee RSD Sensor was nichts anderes macht als ein bestimmtes Netzsegment nach neuen Systeme zu scannen. Bei diesem Scan hängt sich höchst wahrscheinlich der VaultServer auf.

Wir haben den McAffee RSD Sensor deaktiviert und danach trat der Fehler nicht mehr auf.

Vielleicht ist es uns jetzt möglich auf R18 umzustellen 

Grüße

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo,

danke für die Info!
Werde das morgen gleich mal bei uns prüfen.

------------------
mfg, hugin66

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP