---

Hallo Mitleidende,

seit dem 13.09. sind wir jetzt dabei, auf die 9.1 (M050) zu migrieren. Aufgrund einiger Probleme in unseren Daten, welche zum Teil sogar noch aus Intralink (zuletzt 3.3) stammen sind wir immer noch dabei ...
Die Migration von Intralink zu PDMLink 8.0.40 lief damals absolut problemlos.

Wie sind eure Erfahrungen? Hat überhaupt schon mal jemand erfolgreich migriert?

------------------
 
MfG
Falko

[Diese Nachricht wurde von Falko am 22. Nov. 2010 editiert.]

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

---

Zitat:

---

Original erstellt von Falko:
... Hat überhaupt schon mal jemand erfolgreich migriert? ...

---

Wir haben migrieren lassen. Von 8.0 M020 auf 9.1 M030 (und in der Zwischenzeit auf M050). Allerdings war vorher keine Datenverwaltung vorhanden. System läuft schon fast ein Jahr unter 9.1

------------------
Gruß
Udo                 Keine Panik, Du arbeitest mit Pro/E! Und Du hast cad.de gefunden! 

Neu hier?     Verwundert über die Antworten?    Dann schnell nachfolgende Links durchlesen. 
• Richtig Fragen • Nettiquette • Suchfunktion • System-Info • Pro/E-Konfig • 7er-Regel      • Unities

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

---

Wie lange habt ihr denn mit der 8.0 gearbeitet?

------------------

MfG
Falko

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

---

Zitat:

---

Original erstellt von Falko:
Wie lange habt ihr denn mit der 8.0 gearbeitet? ...

---

... seit Ende 2006

------------------
Gruß
Udo                 Keine Panik, Du arbeitest mit Pro/E! Und Du hast cad.de gefunden! 

Neu hier?     Verwundert über die Antworten?    Dann schnell nachfolgende Links durchlesen. 
• Richtig Fragen • Nettiquette • Suchfunktion • System-Info • Pro/E-Konfig • 7er-Regel      • Unities

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

---

Ui, dann wart ihr aber früh dran.
Ich dachte schon (im Nachhinein), dass wir zu früh dran waren und wir haben "erst" 2007 umgestellt.

Gab es bei euch auch so viele Windu-Fehler? Arbeitet ihr auch so viel mit Familientabellen?

------------------
 
MfG
Falko

[Diese Nachricht wurde von Falko am 22. Nov. 2010 editiert.]

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

---

Zitat:

---

Original erstellt von Falko:
Ui, dann wart ihr aber früh dran.

---

Ja. Aber da keine Datenverwaltung vorhanden war und die Daten sich rege vermehrt haben, musste etwas unternommen werden.

Zitat:

---

Gab es bei euch auch so viele Windu-Fehler?

---

Was konkret für Fehler?

Zitat:

---

Arbeitet ihr auch so viel mit Familientabellen?

---

Fast ausschließlich bei Blechteilen. Die Normteile sind ohne Familientabelle erzeugt.

------------------
Gruß
Udo                 Keine Panik, Du arbeitest mit Pro/E! Und Du hast cad.de gefunden! 

Neu hier?     Verwundert über die Antworten?    Dann schnell nachfolgende Links durchlesen. 
• Richtig Fragen • Nettiquette • Suchfunktion • System-Info • Pro/E-Konfig • 7er-Regel      • Unities

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

---

Was für Fehler?
Der Windu meldet im Bereich Familientabellen folgende Fehler (jetzt immer noch):

20310  ?
20290  ?
20330  ?

und per Healingscript bereinigt haben wir:
20320  Cell with definedFlag set to 1 are not associated to generic
20450  ?
20330  ?
20190  FT.name not equal to its top generic's CADName
20270  No parameter definition in family table master with the same name as parameter value

Dem aufmerksamen Leser fällt auf, dass totz erfolgreicher Bereinigung noch immer der Fehler 20330 (wenn auch seltener) auftritt.
Im Detail kann ich leider nicht sagen, um welche Fehler es sich hier noch handelt.
Bei uns werden Familientabellen (da überwiegend Blech und alle Normteile auch in Familientabellen) excessiv eingesetzt, da wir von den meisten Teilen mehrere Größenvarianten haben. Auch gibt es aus der Vergangenheit - und heute noch - verschachtelte Familientabellen. Das hat Inneo (Leipzig) vor vielen Jahren mal so eingeführt und das ist schwer aus den Köpfen zu kriegen.

------------------

MfG
Falko

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

---

Zitat:

---

Original erstellt von Falko:
Was für Fehler? Der Windu meldet im Bereich Familientabellen ...

---

Nein, leider haben wir die nicht. Es scheint so, als ob die nicht vorhandene Datenverwaltung vor der Einführung nicht nur schlechte Aspekte hatte.

------------------
Gruß
Udo                 Keine Panik, Du arbeitest mit Pro/E! Und Du hast cad.de gefunden! 

Neu hier?     Verwundert über die Antworten?    Dann schnell nachfolgende Links durchlesen. 
• Richtig Fragen • Nettiquette • Suchfunktion • System-Info • Pro/E-Konfig • 7er-Regel      • Unities

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

---

Zitat:

---

Original erstellt von Falko:
Wie sind eure Erfahrungen? Hat überhaupt schon mal jemand erfolgreich migriert?

---

In Kurzform:

Pro/E und Intralink seit 1999 im Einsatz

August 2008: Erste Testinstallation PDMLink 9.0 M030

September 2008 bis Dezember 2008
Schulungs- und Testphase PDMLink 9.0 M030
Enorme Probleme mit diversen Grundfunktionalitäten, die in PDMLink nicht so funktionieren wie in Intralink, Projekt steht zwei mal auf der Kippe

Januar 2009 bis April 2009
Mehrere Testmigrationen, intensive Testphase mit den eigenen Daten aus Intralink sowie einigen Anpassungsprogrammierungen

Mai 2009
Scharfschaltung PDMLink 9.0 M030
User sind insbesondere über die Performance der Tabellenanzeigen (verglichen mit Intralink 3.4) entsetzt. Man verspricht uns, mit PDMLink 9.1 werde alles besser.

März 2010
Umstellung von PDMLink 9.0 M030 auf PDMLink 9.1 M050
Die Performance der Tabellenanzeigen wird mitnichten besser, sondern wesentlich schlechter. Mehrere Krisentermine mit  PTC-Dienstleister erbringen keine signifikante Verbesserung. Für zusätzliche Frustration sorgen regelmäßige Abstürze des Methodenservers, Probleme mit den Trigger-Programmierungen und beim Einchecken. Die Anwender fügen sich entnervt und desillusioniert ins Unvermeidliche.

Fazit:

Die Einführung von PDMLink erfolgte in erster Linie, weil das bisherige Intralink von PTC aufgegeben wurde und um die Windchill-Fähigkeiten bei der Ankopplung unserer ausländischen Tochterwerke nutzen zu können. Ein Produkktivitätsgewinn für die eigene Konstruktion ist bis heute nicht erkennbar. Im Gegenteil haben sich die Konstruktionszeiten erheblich verschlechtert und der Aufwand für die Administration insbesondere durch das Trouble Shooting um ein Vielfaches erhöht.

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

---

@Callahan: Da hatte ihr ja einen klaren Vorteil, ihr habt euch den Umweg über die 8.0 gespart.
Sonst liest sich das alles nicht so prickelnd. Die Erfahrungen kenne ich auch gut aus der 8. Unsere Nachforschungen haben ergeben, dass dier der Methodenserver maßgeblich ist. Der verlangt einiges an Hardware und die Performance lässt sich auch über einige Einstellungen noch pimpen. Nicht ganz unbeteiligt ist auch der IE mit einer langsamen Tabellendarstellung, hier soll der Feuerfuchs schneller sein. Da ich ja (hoffentlich) demnächst 2 Systeme mit ähnlicher Datenbasis habe, will ich die Unterschiede auch mal messen.
Momentan rödelt mein (neuer) Server mit 6-7% Prozessorauslastung, d.h. Oracle nutzt auch in der 9.1 nur einen Core....

------------------

MfG
Falko

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

---

Die Testmigration lief in der letzten Woche durch. Ursache des letzten Fehlers war die nicht nachvollziehbare Versionierung eines "nicht sichbaren Objektes" (PTC!) bis an die Grenze unseres Versionsschemas. Nach Erweiterung des Schemas hat es dann auch funktioniert.

In der nächsten Woche kommt jetzt die Produktivmigration. Dafür haben wir uns zwei Tage Zeit genommen. In dieser Zeit erhalten die Anwendender eine Updateschulung für die Wildfire 5.

Die Geschwindigkeit der 9.1 ist gegenüber der 8.0 besser, was aber auch daran liegen kann, dass die Maschine deutlich stärker ist und wir die Arbeit auf 4 Methodenserverprozesse verteilt haben. Somit nutzen wir jetzt schon mal 4 Kerne (von 16) der CPU.
Was mir immer noch nicht gefällt, ist Oracle, da die DB nur auf einem Kern läuft. Bei datenbankintensiven Prozessen läuft dann eben ein Kern mit 1000% Auslastung und man kann warten. Weiß jemand von euch, ob und wie man dass ändern kann?

------------------
 
MfG
Falko

[Diese Nachricht wurde von Falko am 03. Dez. 2010 editiert.]

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

---

Hi Falko,

hoffe, Eure Migration zu 9.1 war erfolgreich. Deine FT- und Versions-Probleme kann ich gut nachvollziehen, da ich von 8.0 auf 9.1 damit (und mit PTC) auch monatelang in vielen Calls und SPR's kämpfen musste, bis alles lief.

Was mir ein bischen spanisch vorkommt, ist deine Aussage über Oracle. Bei uns läuft das auf einem 64-bittigem dediziertem Windows-Server und skaliert gut über mehrere Kerne ohne spezielle Settings und Eingriffe.

------------------
Genius is 99 percent perspiration and 1 percent inspiration! ... Thomas Edison

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

---

Das klingt ja gut, wie macht ihr das?
Bei uns läuft die 10.2.0 unter Windows Server 2008 Standard und das Verhalten ist, wie beschrieben.
Siehst du mehrere Oracle-Prozesse oder kann der eine Prozess auf mehrere Kerne zugreifen?
Wer hat denn bei euch installiert?
Kann es auch an der Hardware liegen ? (2x XEON E5540@2.53 GHz)

------------------

MfG
Falko

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

---

Ich denke nicht, dass es an der Hardware liegen kann, habe unser Oracle selbst installiert und ich sehe nur einen oracle.exe Prozess im TaskManager.

Weiterhin ist es sehr schwierig, herauszufinden, wieviele CPU Cores ein Windows Prozess wirklich benutzt (falls hier jemand ein zuverlässiges Tool kennt, dann bitte Bescheid. Danke!), die Anzeige im TaskManager ist auch nicht gerade die reine Wahrheit und speziell in Oracle kommt es auch noch auf die Programmierung der einzelnen Abfragen an (Stichwort "parallel" keyword, etc.) bzw. wieviele Abfragen gleichzeitig laufen, wieviele Verbindungen hergestellt sind, usw.

Ich denke, das Einfachste und Erste ist, zuerst mal in SQLPLUS den Befehl "show parameter cpu_count;" auszuführen, um herauszufinden, wieviele Cores deine Oracle Installation überhaupt sieht. Du solltest bei 2 x Quadcore CPU hier vermutlich eine 8 sehen ...

------------------
Genius is 99 percent perspiration and 1 percent inspiration! ... Thomas Edison

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

---

cpu_count=16
parallel_threads_per_cpu=2

steht bei uns (die 16 Kerne zeigt mir auch der Taksmanager).
Bei voller Oracle-Last zeigt mir mein Taskmanager ca. 6% Gesamtauslastung und das entspricht etwa 100%/16...

------------------

MfG
Falko

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

---

Der nächste Schritt wäre dann womöglich, ein Oracle-Stress-Test-Tool herunterzuladen (habe darüber gelesen, aber selbst noch nie gemacht) und damit zu prüfen, ob man die Oracle-Last erhöhen kann.

Woher weisst du denn so genau, dass du volle Oracle-Last hast und Oracle nur auf einem Core läuft? Nur Task Manager und sonst nichts?

------------------
Genius is 99 percent perspiration and 1 percent inspiration! ... Thomas Edison

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

---

Genau, was anderes habe ich leider auch nicht. Ich sehe mir dann die lfd. Prozesse an und sehe bei Oracle eben nur die 6%.
Ganz gut kann mann das bei fiesen Suchen (z.B: über mehrere Paramter) beobachten, wenn dann das ganze System steht, d.h. keine parallelen Datenbankzugriffe mehr machbar sind, weil Oracle m.E. nach keinen weiteren Kern benutzen kann.

------------------

MfG
Falko

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

---

Könnte natürlich auch sein, dass in diesen Momenten Memory knapp wird, die nötigen Festplattenzugriffe der eigentliche Flaschenhals sind, die Windchill Methodenserver in Wirklichkeit nichts anderes mehr abarbeiten, etc. etc. etc.

Deswegen würde ich erst mal versuchen, Oracle selbst - ohne Windchill - zu stressen ...

------------------
Genius is 99 percent perspiration and 1 percent inspiration! ... Thomas Edison

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

---

Methodenserver, Speicher und Co. möchte ich fast ausschließen. Wir haben 4 Methodenserverprozesse und einen Backgroundmethodenserver. Die Machine hat 24 GB RAM und Windchill ist auch dementsprechend konfiguriert. Die Platten sind per Fiberchannel angebunden und somit rasend schnell.
Vielleicht liegts aber doch daran? Ich werde mich mal schlau machen, wie ich Oracle alleine testen kann.

Danke erstmal.

------------------

MfG
Falko

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

---

Noch ein Tip für "Oracle alleine" monitoren: http://<deinOracle>:1158/em  unter "Performance". Da gibt es auch CPU Auslastung, etc.

------------------
Genius is 99 percent perspiration and 1 percent inspiration! ... Thomas Edison

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