---

Vorgeschichte:
------------------------------
Wir haben momentan 3 Standorte (Österreich, Slowakei und China).
Auf allen 3 Standorten ist Teamcenter im Einsatz (SingleSiteLösung).

Österreich:        lauter 2TierRichClients, die direkt in die Volumes arbeiten.
Slowakei:          lauter 4TierRichClients, die alle über einen CacheServer arbeiten > kein “Store & Forward“.
China:              lauter 4TierRichClients, die auch alle über einen CacheServer arbeiten > “Store & Forward“.

Vielleicht noch zu erwähnen, wir haben WAN-Accelerators im Einsatz.

Problem:
------------------------------
Wir haben des öfteren das Problem, dass ein Dataset (zB:CATPart,...) in China oder in der Slowakei nicht mehr geladen werden kann:
„Unable to Open Document“.

In Österreich ist das Laden kein Problem, das Dataset (CATPart) wird ganz normal geöffnet.

>> Ich schließe daraus, dass das Problem nur der CacheServer sein kann.

Es dürfte irgendein Problem bei der Übertragung gegeben haben, jetzt haben wir eben die Situation,
dass das fehlerhafte File im CacheServer liegt und es als aktuell gehalten wird.

Unser work-around war bis jetzt immer folgender:
-------------------------------------------------------------------------------
x) CATPart in Österreich laden und speichern, dadurch ist es im CacheServer nicht mehr aktuell und muss neu übertragen werden.
Bei dem aktuellen Fall haben wir aber das Problem, dass dieser Stand schon freigegeben ist und wir diesen auf keinen Fall mehr ändern (laden und speichern) dürfen. > Problem mit Laderegeln
oftmals ist es nicht mehr möglich erneut zu speichern (binäre Results aus Berechnungen, etc)

x) Was noch funktionieren würde: Den ServerCache zu löschen, dies wollen wir aber auf jeden Fall vermeiden, da wir dadurch enorme Performanceprobleme verursachen würden.

x) Das einzelne File GUID vom Server- bzw. ClientCache löschen > enormer Aufwand.

Fragen:
------------------------------
x) Hat jemand so ähnliche Probleme? Wenn ja, was macht ihr dann?
x) Kann man dies im Vorhinein irgendwie verhindern?

Laut Professional Service ist das Problem bekannt und dürfte auch bei mehreren Kunden auftreten,
aber es gibt keine Lösung das Problem im Vorhinein zu verhindern.
Bei den meisten Kunden wird der work-around des erneuten abspeicherns akzeptiert.

Für uns ist dies ein sehr großes Problem, da wir die Datenkonsistenz in den CacheServern nicht sicherstellen können.

Vielleicht könnt ihr mir helfen,
ich danke euch im Voraus.

------------------
--------------
MfG Michael

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

---

Hilft dir zwar nicht unbedingt:
Ich werd mich am Do mit ähnlichen Sachen befassen ( ähnliche Konstellation wie bei dir, nur _mit_ StoreAndForward ). Wahrscheinlich eh mit demselben SISW MA wie du ....

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

---

Hi, da wir meist komplette Projekte übertragen machen wir viel über Prepopulate von Daten (mit Store & Forward). Also erst plmxml_export danach Load_fsccache. Dies funktioniert.

------------------
Gruß

Michael

have you tried turning it off and on again

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

---

Danke erstmals für eure Antworten,

@little_ug:
also hattest du in deinen CacheServern noch nie dieses Problem? Bei uns ist es schwer ganze Projekte zu übertragen, wir arbeiten sehr viel mit Übernahmeteilen. Werde es aber einmal versuchen, danke.

------------------
MfG Michael

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

---

Zitat:

---

Original erstellt von pmwi:
...@little_ug:
also hattest du in deinen CacheServern noch nie dieses Problem? Bei uns ist es schwer ganze Projekte zu übertragen, wir arbeiten sehr viel mit Übernahmeteilen. Werde es aber einmal versuchen, danke.

---

Wir machens ein wenig anders:
Über SQL erstellen wir täglich eine Liste der Files die seit dem gestrigen Zeitpunkt geändert wurden, und die werden via load_fsccache dann an die aussenstehenden FSCs übertragen ("prepopulate").

Das funktioniert grundsätzlich gut.
An den Aussenstellen sind mir keine FSC Probleme in der Art von pmwi bekannt.

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

---

Zitat:

---

Original erstellt von ThomasZwatz:

Über SQL erstellen wir täglich eine Liste der Files die seit dem gestrigen Zeitpunkt geändert wurden, und die werden via load_fsccache dann an die aussenstehenden FSCs übertragen ("prepopulate").

---

Also ihr übertragt alle Dateien in den CacheServer,
d.h. der CacheServer muss so groß dimensioniert werden wie alle Volumes zusammen, sehe ich das richtig?
Ist ein genialer Ansatz zur Performanceverbesserung, aber trotzdem glaube ich nicht, dass dies mein Problem löst.
Bei der Übertragung kann es trotzdem zu irgendwelchen Problemen kommen, und dann liegt erst wieder das fehlerhafte File im Cache.

Mir ist aber überhaupt nicht klar wie so etwas passieren kann, normalerweise müssten dies Teamcenter-Mechanismen,
die prüfen ob die Files im Volume und im Cache ident sind, verhindern.
Aber die gibt es anscheinend nicht.

------------------
MfG Michael

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

---

>>An den Aussenstellen sind mir keine FSC Probleme in der Art von pmwi bekannt.

@pmwi:
Ich würde auch erst einmal prüfen, ob sich die Qualität der Übertragungsstrecke nicht verbessern läßt.
Immerhin hast Du selbst den Verdacht geäußert, daß es vielleicht kein FSC-Problem ist.
>>Es dürfte irgendein Problem bei der Übertragung gegeben haben.

------------------
R.Schulze

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

---

@schulze:
Bei Übertragungen kann es immer wieder zu Problemen kommen, auch wenn die Qualität der Übertragungsstrecke noch so gut ist.
Außerdem hat mir der Professional Service gesagt, dass dieses Problem auch andere Kunden haben, bei denen aber der work-around des nochmaligen speicherns akzeptiert wird.
Wir wollen bzw. können diesen nicht akzeptieren.
Ich denke mir, dass Teamcenter in der Pflicht ist die Datenkonsistenz zu gewährleisten.

------------------
MfG Michael

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

---

Hi Pmwi,

ist das nur bei euren Catia Files so oder auch generell mit anderen Datasets?

------------------
Gruß

Michael

have you tried turning it off and on again

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

---

Hi little_ug,

Bis jetzt ist es nur bei Catia-Files aufgetreten (CATParts, CATDrawings, DrawingSheets), man muss aber dazu sagen, dass auf den Standorten großteils nur mit Catia gearbeitet wird > sprich CAD Verwaltung.

------------------
MfG Michael

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

---

Könnt ihr mir vielleicht erklären warum am Cache-Server zwischen Read u. Write Cache unterschieden wird?
Ich nehme an, dass bei einem Lesend-Zugriff in den Read-Cache gespeichert wird und beim Speichern in den Write-Cache.

Jetzt stellt sich aber die Frage, ob die Daten vom Write-Cache auch in den Read-Cache synchronisiert werden?

Wie sieht das ganze beim Store & Forward Mechanismus aus?
Es werden die Daten in das Default-Local-Volume gespeichert, danach überträgt der Dispatcher die Daten in das Default-Volume. Bekommt bei diesem Vorgang der Cache-Server auch etwas mit?

Logisch wäre es, sonst hätte der Cache-Mechanismus keinen Sinn, aber was ist schon logisch......

Danke,

------------------
MfG Michael

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

---

Zitat:

---

Original erstellt von pmwi:
....Wie sieht das ganze beim Store & Forward Mechanismus aus?
Es werden die Daten in das Default-Local-Volume gespeichert, danach überträgt der Dispatcher die Daten in das Default-Volume. Bekommt bei diesem Vorgang der Cache-Server auch etwas mit?...

---

Zum Read/Write Cache kann ich nichts sagen, da weiss ich von nichts ...

Store&Forward:
Der FSC am Aussenstandort bekommt IMHO nicht mit, dass das File auf ein anderes Volume verschoben wurde.
( Zuerst wird das File vom LocalVolume "nach Hause" kopiert und erst zeitversetzt dann am LocalVolume gelöscht, d.h. das sind 2 separate Dispatcher Aufträge )

Wird am Aussenstandort ein Teil geladen, wird der FSC befragt, ists lokal im Cache am Aussenstandort ( nicht wirklich "lokal" im FCC, wenns eh im lokalen FCC ist, dann kommts von dort ), dann wirds von dort geholt, ansonsten kommts von "zu Hause".
Daher auch diese "PrePopulate" Mechanismen, damit der User nicht warten muss bis das File über die WAN Verbindung ankommt.

PS: Dass es kein Problem des lokalen FCCs ist ("Unable to open Document"), habt ihr ja schon abgeklärt, soweit ich das oben gelesen hab.

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

---

Hallo Thomas,

Danke für die Antwort.
Wie der Store & Forward Mechanismus funktioniert ist mir bekannt, es ist aber für mich nicht logisch,
dass bei diesem Mechanismus der Server-Cache nichts mitbekommt.

Mit dem PrePopulate kannst du schon Recht haben, aber bei folgendem Szenario wird es schwer:

Zwei Konstrukteure arbeiten am selben Teil (gleicher Tag), das Speichern funktioniert immer schnell (Store & Forward).
Das Lesen dagegen sehr langsam, da die Datei immer wieder vom Volume (daheim) geholt werden muss, wenn unterschiedlich gespeichert wird (einmal Konstrukteur A, einmal Konstrukteur B).
Wenn der S&F Mechanismus den Server-Cache berücksichtigen würde, dann würde es in beide Richtungen performant funktionieren.

Das Cache-Problem ist noch nicht geklärt, bin noch immer überzeugt, dass es ein Problem von Teamcenter ist.
Es kümmert sich momentan gerade der Professional Service darum, da dieses Problem mehrere Kunden haben.

------------------
MfG Michael

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

---

Michael,

versuche das CAD-Part auf dem Cache Server zu lokalisieren und zu löschen.
Danach neu laden. Sollte so gehen:
(in <>-Klammern entsprechende Werte einsetzten, Bsp. für Unix/Linux, wir stehen in $TC_ROOT/bin)

1. Ermitteln der UID des IMANFiles mit gegebener Item Revision
./plmxml_export -item=<ITEM NAME> -rev=<REV> -export_bom=no -transfermode=justDatasetsOut -xml_file=tickets.plmxml

2. Um die entsprechende GUID für den Imanfile zu erhalten, müssen wir den plmxml bemühen aus Pkt 1:
./generate_loadfsccache_tickets -plmxml_input=tickets.plmxml -tickets_output=/tmp/1.txt -verbose

GUID Details als Output im Ausgabefile:

4454b447c67e23be3cfbcf76eb8db04703555a8bb9ba5dba1fb7c67dc084a0dfv1004T00000000000064e24e9bd44a15fb4f542012%2f06%2f14+16%3a02%3a09348763648+++++++++++++++++++++++xxxxx xxxx++++++++++++++++++++++++63c84e1421a314c9b600++++++++++++%2fdba_4fd2261e%2fcat_ca_2pj0mhv4expw2._catpart

Die GUID ist der String nach 4T und bevor 2012.

3. Um festzustellen, ob die gesuchte GUID auf dem Cache Server gecacht ist, benutze den fscadmin und löschen falls ja

$ ./fscadmin.sh -s http://<SERVER_NAME>:4544 ./cachedetail |grep 00000000000064e24e9bd44a15fb4f54

Gruss,
Sixpence

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

---

Zitat:

---

Original erstellt von Sixpence:
versuche das CAD-Part auf dem Cache Server zu lokalisieren und zu löschen.
Danach neu laden. Sollte so gehen:

---

Hallo Sixpence,
Danke für deine Antwort, dies war auch der work-around von Siemens.
Für uns ist dies aber nicht akzeptabel, da wir nicht wissen welche Daten betroffen sind und wir nur auf Zuruf reagieren können (Problem mit 6 Stunden Zeitverschiebung nach China, usw.)

Wie schon mehrmals erwähnt ist unsere Meinung, dass Siemens die Datenkonsistenz sicherstellen muss und dass solche Probleme nicht auftreten dürfen.
Der Professional Service kümmert sich gerade um das Problem, da wir nicht die einzigen sind bei denen dies auftritt.

Gebe euch natürlich Bescheid sobald ich mehr weiß.

------------------
MfG Michael

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