---

Hallo Intralinkgemeinde 

Worums gehts ist aus dem Betreff zu sehen.
PTC empfiehlt den TAN 129653
=============================
On a PowerEdgeTM  2850 Dual Xeon 2U Server  with WINDOWS 2003 SERVER Servicepack 1
the Dataserver installation hangs intermittent while "Running Oracle Data Base Configuration Assistant(DBCA)...".
This has also been seen with other systems using Windows 2003 servicepack 1.
Alternate Technique
-----------------
Get the patch TclTkUpdate.zip attached to SPR 1146449 .
This patch could be applied only for Pro/INTRALINK 3.4F001 and 3.4M011
installations on MS Windows 2003 Server machines.
Please follow this procedure to apply the patch.
0. Shutdown data server, if it is running.
1. Under directory %PROI_HOME%\tools create a new folder "Old Tcl-Tk"
2. Make a copy of existing folders "%PROI_HOME%\tools\bin" and
"%PROI_HOME%\tools\lib" into the created directory.
3. In the folder "%PROI_HOME%\tools\bin" remove everything exept the
file "proipwd.exe".
4. In folder "%PROI_HOME%\tools\lib" remove all files.
5. Extract all files from provided TclTk849UpdateForWindows2003Server.zip
archive into "%PROI_HOME%" directory.
6. Create new data server with "install_ilink" command or upgrade already
existing with "ilink_patches" command.
Please see resolution.
Resolution
-----------------
This will be resolved in a future release of Intralink 3.4
============================================================
Jetzt kommt das gemeine 
Anschließend funktioniert der ..\intralink\bin\proimgr nich mehr !!
wish.exe kann tk82.dll nicht finden !! Klar..sollte ich ja löschen !!!
Aber auch hier hat PTC eine Lösung !!
Description
-----------
Launching the DSMU returns error "The dynamic link library tk82.dll could not be found".
This issue occurs on a Windows 2003 Server Service pack 1 machine on which the patch TclTkUpdate.zip from SPR 1146449
has been applied before upgrading to Pro/INTRALINK 3.4 M020.
Alternate Technique
-----------------
1) Rename the file “wish.exe” located in the folder <dataserver_loadpoint>\intralink\tools\bin to “wish82.exe”
2) Rename the file “wish84.exe” located in the folder <dataserver_loadpoint>\intralink\tools\bin to “wish.exe”
Resolution
-----------------
This issue will be resolved in a future release of Pro/INTRALINK.
=================================================================
Womit klar wäre, das ich DEpp mal wieder die falsche Reihenfolge gewählt habe.
Vielleicht hilft das ja dem einen oder anderen ..
Bis dann
Roland

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

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

---

und falls dann auf einer Multiprozessormaschine der proimgr immer noch hängt, muss man im Taskmanager dem Prozess wish.exe genau eine CPU zuweisen, per dafeult sind alle CPU's für die Prozesse aktiviert.

Task-Manager->Prozesse->wish.exe auswählen->rechte Maustaste->Zugehörigkeit festlegen...

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

---

... fast richtig ... ganz richtig ist, nicht mehr als 2 CPU's zuzuweisen, falls ich mich noch recht daran erinnere ...

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

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

---

Hallo mnoeth,
wenn ich 4 virtuelle CPUs habe (CPU 0 - CPU 3) welchen beiden weise ich dann am besten die oracle.exe zu ??

mfG
Roland

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

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

---

Hallo Herr Gründer,

der Trick reicht aber nur so lange bis der Prozesse beendet und wieder neu gestartet wird. Leider behält Windoof nicht was ich will.
Da ISAPconnect die xtop.exe dauernd startet und beendet, hab ich da ein Problem. Ich werde wohl nicht daran vorbei kommen einen Win2003 Server für INTRALINK und einen Win2000 Server für ISAP und WILDFIRE parallel laufen zu lassen bis PTC die Probleme mit Win2003 Servern in den Griff bekommen hat. Siehe E-Mail meines australischen Kollegens ..

Hello Roland,

I am very unhappy with the level of support I have received from PTC on this issue. We have come up with more information about this issue than PTC has provided us with. They are very reluctant to provide access to their Oracle DBA’s and any requests for information I make to PTC falls on deaf ears. I first opened this call 21 days ago (on the 5th of October) and this call has been escalated to Extremely Critical but still PTC’s response has been less than acceptable.
Also do you notice when you update a large assembly to include drawings and instances that it only uses one processor?
During the update process on a large assembly a server with 4 processors the system will show 25% CPU utilisation and on a server with two processors the system will show 50% CPU utilisation for the oracle.exe process.
It will never use more than one CPU for the update process.
Over the last few weeks we have built about 5 test servers testing all possible combinations of Hardware and operating systems. After all our testing it has become apparent that the reason for the slow updates is the fact that Oracle 9i is only using one CPU to carry out the update queries for Intralink 3.4. This is not a hardware issue and it is not an operating system issue. 
Our Production & Test1 machines have 4x700MHz Xeon Processors with 2MB of Cache and 2GB of RAM.
Our other Test2 machine has a single 3.4GHz Xeon Processor with 1MB of Cache and 1GB of RAM.
From our results the Test2 machine always finishes the update or any other Oracle queries four times quicker than the Production or Test1 machines. This is because the update process (oracle.exe) ONLY ever uses one CPU in Intralink 3.4 / Oracle 9i so effectively our Production and Test1 machines run as single processor 700MHz machines! (Which is about 4 times slower than a 3.4 GHz processor)
Also from our investigation there seems to be a definite point where if the number of objects to be updated will return more than about 1750 rows the update process then starts to do a lot processing and the processor speed difference between 700MHz & 3.4GHz really becomes apparent.

Best regards,
 
Chris Culver
Manager Information Technology
DBT Australia Pty Ltd
Unit 101 29-31 Solent Circuit
Lakeside Corporate Centre
Norwest Business Park
Baulkham Hills NSW 2153
Australia
Tel.: +61 2 8887 0012
Fax: +61 2 8887 0099
E-Mail:
Chris.Culver@dbtaustralia.com www.dbt.de

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

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

---

Zitat:

---

Original erstellt von roland_s:

Hallo mnoeth,
wenn ich 4 virtuelle CPUs habe (CPU 0 - CPU 3) welchen beiden weise ich dann am besten die oracle.exe zu ??

---

Also, bei "wish.exe" nehme ich eigentlich immer CPU 0 und CPU 1 (kommt wahrscheinlich aber gar nicht so drauf an) ... und bei "oracle.exe" muss man ja nicht auf weniger CPU's beschränken ... aufgrund der Ausführungen des australischen Kollegens neige ich aber dazu - wenn überhaupt - dann die Prozessoren CPU 2 und CPU 3 zu empfehlen, da ja vielleicht andere Prozesse genauso wenig Multi-Prozessor-konform sind und dementsprechend dann womöglich auch alles auf CPU 0 laufen lassen (does this make sense ???) ... ich habe mich aber nie wirklich damit befasst (zu wenig Budget für sehr viele Prozessoren pro Maschine).

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

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

---

Hallo MNoeth,
jetzt bin ja noch ein Neuling, was das Zuweisen von CPUs zu Programmen betrifft. Wenn man diesem Link trauen kann ... http://www.admins-tipps.de/Microsoft/Windows_2000/Wie_k%F6nnen_beim_Betrieb_mehrerer_CPUs_Programme_dauerhaft_einer_bestimmten_CPU_zugeordnet_werden.htm
====================================================
Windows 2000 und Windows NT unterstützen den Systembetrieb mit mehreren CPUs. Während der Laufzeit eines Programms kann der Taskmanager dazu verwendet werden, das Programm einer bestimmten CPU zuzuordnen. Allerdings muss dies bei jedem Neustart des Programms wiederholt werden.

Mit dem Programm Imagecfg.exe, welches sich auf der Installations-CD Windows NT und Windows 2000 be­findet, kann diese Zuordnung dauerhaft eingerichtet werden.

Auf der Windows-NT-CD befindet sich das Programm im Verzeichnis \support\debug\i386, für Windows 2000 wird das Windows 2000 Server Resource Kit Supplement l benötigt. Mit der Kommandozeile Imagecfg  -a  XXX  PfadZumProgramm wird die Zuweisung vorgenommen.

Dabei ist für <XXX> ein Hexadezimal­Wert von 0 bis 31 möglich, welcher die CPU benennt. Für den Fall, dass zwei CPUs vorhanden sind, bedeutet 0X1 die erste CPU und 0X2 folglich die zweite.
===============================================================
... dann brauche ich also nur ...
D:\ProeWildfire2\i486_nt\obj\imagecfg.exe -a 0x2 0x3 D:\ptc\osa\oraprod\bin\oracle.exe  ... ausführen und alles ist gut ??

mfG
Roland

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

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

---

Eigentlich sollte ORACLE auf Grund von multi-threading auch alle CPU's nutzen können, habe da auch schon in der ORACLE Doku gesucht aber nichts gefunden.

PS: Wenn man SAP oder ein eine Warehouse-Applikation auf Microsoft mit ORACLE laufen lässt, wäre es ja bei den vielen Tausend Anfragen bischen komisch, wenn nur eine CPU beschäftigt ist...

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