---

Hallo Intralinkgemeinde 
Hab jetzt also nach 3 Anläufen und Hilfe von PTC (Danke H.Husemann) meine Intralink Datenbank am laufen. Alle Patche drüber laufen lassen, Tabellenbereiche vergrößert, Dump importiert, ein paar kleine Vaults zum testen rüberkopiert und den Client gestartet. Alles klappt.
Aus dem Client das neue Wildfire 2.0 M140 gestartet. Klappt auch (juhuu). Suche im CS gestartet (1 Zeichnung mit 1 Teil) WARTEN ???
Diese Suche dauert in meinem Prod- System 2 Sek.
Im TEST- System braucht er 3 Minuten und die ORACLE.EXE frisst die CPU auf.
Was habe ich falsch gemacht ??? 
mfG
Roland

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

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

---

Vielleicht einmal die Wert der Datei initilnk.ora vergleichen?

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

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

---

... vielleicht TAN128919 ...

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

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

---

ich bin für jeden Tipp dankbar ...
hab die Einträge mal verglichen ...

ALTER EINTRAG --- Produktiv System
SPFILE='D:\oracle\product\9204\admin\ilnk\pfile\spfile.ora'

NEUER EINTRAG --- Test System
SPFILE='C:\ptc\osa\oraprod\admin\ilnk\pfile\spfile.ora'

nur, was sagt mir das ??
da hab ich doch keinen Einfluss drauf, weil der OSA das vorgibt

mfG
Roland

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

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

---

DANKE DANKE DANKE 

ich kann nicht mehr als 10 UŽs verteilen.
Aber dein TIPP hat voll ins Schwarze getroffen !!
Hier noch mal für alle die es eilig haben ..
. Run the following command:

SQL> alter system set cursor_sharing=EXACT scope=both;
3. Exit from sqlplus:
SQL> exit

DISCLAIMER NOTE: Setting cursor_sharing=EXACT has proven to improve the locate performance for individual users BUT performance could degrade if multiple concurrent users are competing for database resources. Also, use this setting cautiously since it may degrade performance in other areas.

To change this setting back to the original value follow the same steps above and run the command:
SQL>alter system set cursor_sharing=similar scope=both;
=======================================================
schon erstaunlich, das man bei der nagelneuen Intralink 3.4 M020 schon so vorgehen muß !!
vielleicht hilft dein Tipp auch anderen.
nochmals Danke

Roland

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

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

---

Hallo,

wenn dass noch nicht reicht, dann kann laut TAN 128919 der Optimizer-Mode im ORACLE geändert werden (alter system set optimizer_mode=RULE scope=spfile .
Hat bei mir in einer großen Datenbank die Suche mit xxx*.* und rev=latest und version=latest von 5 Minuten auf 5 Sekunden runter gebracht.

Grüsse, Thomas

siehe http://www.ptc.com/appserver/cs/view/solution.jsp?n=128919

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

---

Danke ! Super Tipp 

Beschleunigt das auch die Suche nach eigenen Attributen ?
Denn das dauert bei mir lange. Die Suche nach Name* geht eigendlich recht zügig.

mfG
Roland

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

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

---

hi,

für die (schnelle) suche nach attributen musst du in der verwaltung ein häkchen bei "indizieren" (bei dem jeweiligen attribut) machen!

------------------
cu
fossy
          baumrasen.de

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

---

Danke für den Hinweis,
jetzt ist mir auch wieder eingefallen, das ich zu einem Attribut (Benennung) den Haken bereits gesetzt habe.
Hey ich bin 49 da darf man schon mal was vergessen.

Roland

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

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

---

Shönes Thema, das mich auch 'ne Weile beschäftigt hat:

Nun, wer in seinen Table Displays für den Locate-Browser unter Sort Order irgendwas drinstehen hat und nicht nach "Type Name" sortiert, kommt auch mit "cursor_sharing=EXACT" aus und kann weiterhin den Cost-Based-Optimizer benutzen.

Kommt jemand aber auf die Idee im Tab "Sort Order" den "Type Name" aufzunehmen oder gar nichts einzutragen (!?!) hat man im nu wieder die 40-fache Suchdauer.

Lustigerweise ist mir aufgefallen, dass Locate zunächst immer die default table display ausführt, welche in den Preferences für den Locate-Browser eingestellt ist, auch wenn man im Locate Fenster gerade eine andere gewählt hat. Sichtbar ist natürlich die gewählte.

Dann hilft nur zusätzlich der Rulebased Optimizer.
Ich wollte Ihn eigentlich vermeiden da ORACLE selbst seit 9i den CBO empfiehlt. Aber der Unterschied ist so überzeugend, dass ich schon fast geneigt bin für ILINK 3.4 generell Rulebased zu empfehlen.

Es wird aber IMHO immer auf den Einzelfall und einen Test ankommen.

Wir werden doch das letzte "echte" INTRALINK noch hinkriegen, oder?

------------------
CU, Uli

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

---

WOW 

Hallo Uli,
das ist ne Menge Info die ich erst mal verstehen muß.
Du bist mir einiges vorraus. Ich hab erst 5 eigene DataServer Installationen hinter mir. Wobei die letzte besonderst gemein war.
Intralink 3.4 M020 auf Windows 2003 Server. Das heißt erst M011 ohne Datenbank, dann den TCLTK Patch,fehlende Variablen ergänzen, Install fortsetzen,Update nach M020. Wir habe eine Intralink SAP Ankopplung über ISAPconnect. Daher muß Wildfire 2.0 auch auf den Server. Ist aber doof, weil PTC Wildfire auf Win2003 Server nicht unterstütz.
Aber da muß ich durch
mfG
Roland

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

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

---

Jo, ein par habe ich schon installiert, aber ich kann mich danach nicht mehr erinnern, wie gut sie liefen :-)

Ich kann mich allerdings auch nicht daran erinnern, dass ich für ilink 3.4 einen Tcl/Tk-Patch gebraucht hätte. Braucht man den für Windows 2003 Server? Bei mir war's nur W2k. Fehlende Variablen sind meist nach einem Reboot da. War das eine Migration oder Dump-raus/Dump-rein?

So schlimm ist es auch wieder nicht, ich habe mich eigentlich nur auf das Problem mit den ungewöhnlich langen Suchzeiten bei ILINK 3.4 bezogen bzw. auf die im TAN 128919 vorgeschlagenen ORACLE-Einstellungen.

Ich hatte just letzte Woche das selbe Problem und dabei etwas geforscht. Nun vielleicht der Reihe nach, dann versteht man es vielleicht besser:

Ich habe eine 3.2 auf 3.4/M011 migriert. Dabei ist aufgefallen, dass die Suche nach Name=xxx* in Verbindung Revision=Last und Version=Last (also eine durchaus übliche Suche) ca. 40 mal länger (ca. 2:20)dauerte als bei 3.2

Also nach TANs gesucht und 128919 gefunden. Der beschriebt genau das Problem. Abhilfe: der ORACLE Parameter cursor_sharing auf EXACT setzen. Ich habe auch keine Ahnung was der macht. Standard ist SIMILAR. Weiterhin steht da noch dass der Parameter optimizer_mode=RULE auch was bringen kann.

Na gut, ich habe erstmal cursor_sharing=EXACT probiert und siehe da die Suche war wieder schnell (ca. 4 sec). Problem gelöst, dachte ich.

Denkste, bei den Tests habe ich eine nagelneue ilsysprefts.txt (Preferences, Voreinstellungen) verwendet. Als ich die produktive ilsysprefts.txt von der 3.2 Datenbank verwendet habe, dauerte die Suche wieder 2:20.

Also wo ist der Fehler? Kann ja eigentlich nur an den Voreinstellungen liegen, oder? Ich habe vieles ausprobiert und schließlich, als ich die Sortierung der Suchergebnisse nach "Typ Name" rausgenommen habe, war's wieder schnell. Dazu hab ich aber schon mal ewig gebraucht, denn ich habe immer anfangs die aktuelle Tabellenkonfiguration im Such-Browser verändert, ohne jemals die voreingestellte Tabellenkonfiguration anzupassen. Dabei hat sich nie was getan, was darauf schließen lässt, dass INTTRALINK zunächst immer die voreingestellte Tabellenkonfiguration ausführt und dann erst die Anzeige mit der aktuell eingestellten anpasst. Also für die weitern Tests habe ich erstmal in den Voreinstellungen KEINE Tabellenkonfiguration für den Such-Browser eingestellt. So jetzt konnte ich endlich mal vernünftig testen. Lustigerweise ist die Suche ebenso langsam, wenn man in der Sortierreihenfolge gar kein Attribut einträgt.

Sie's drum. Auf jeden Fall ist da was faul. Sortierung nach "Typ Name" will ich schon haben. Um alle Möglichkeiten getestet zu haben und auch wegen dem Beitrag von Thomas Gründer hier im thread habe ich dann doch noch den optimizer_mode auf RULE umgestellt.

Vielleicht noch das Wenige was ich dazu weiß:
Bei einer komplexen Suche (auch Abfrage genannt) müssen i.d.R. viele Tabellen nacheinander durchsucht werden, die unterschiedlich groß sind. Im allgemeinen sucht man zuerst in der Tabelle, wo man die wenigsten Treffer vermutet, damit reduziert sich die Anzahl der Datensätze nach denen dann in den anderen Tabellen gesucht werden muss (stark vereinfacht ausgedrückt). D.H. die Reihenfolge in der die Tabellen durchsucht werden kann sehr entscheidend für die Abfrageperformance sein.

Normalerweise (bis INTRALINK3.3/ORACLE 8i) wird diese Reihenfolge von den Entwicklern der Applikation (in diesem Fall ptc) bestimmt (rulebased bzw. optimizer_mode=RULE), ganz einfach durch die Schreibreihenfolge der SELECT-Anweisungen in den SQL-Scripts.

Seit ORACLE 8i bietet ORACLE des sog. Cost Based Optimizer (CBO) an. Dabei wird die Tabellenreihenfolge, welche für die Abfrage herangezogen wird automatisch von ORACLE bestimmt und zwar in Abhängigkeit von Statistiken, die im Grunde Tabellenfüllgrade ermitteln. Wie das genau funktioniert weiß ich auch nicht. Aktiviert wird er über den ORACLE-Parameter optimizer_mode=CHOOSE und das Erstellen dieser Statistiken, welches übrigens regelmäßig wiederholt werden sollte.

ptc hat mal für 3.0 empfohlen den CBO zu nutzen für große Baugruppen. Sagt aber gleich dazu man sollte ab 3.1 wieder rulebased aktivieren. Seit INTRALINK 3.4/ORACLE9i ist wieder der CBO empfohlen und als Standard eingestellt, mit dem Hinweis er wäre besser geworden und man müsste die Statistiken nicht mehr manuell erstellen.

Soweit zur Theorie bzw. den unterschiedlichen Tips von ptc in unterschiedlichen TANs.

Vielleicht versteht ihr jetzt, warum ich den zweiten Schritt aus TAN 128919 nicht so ohne weiters und unmittelbar gehen wollte.

Fakt ist aber: Meine Suche in INTRALINK 3.4 ist jetzt wieder in allen erdenklichen Kombinationen schnell, seit ich den optimzer_mode=RULE eingestellt habe.

CU, Uli

------------------
CU, Uli

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

---

Zu dem Tcl/Tk Patch auf Windows 2003 Server habe ich auch noch etwas. Ich bin ja von Natur aus sehr faul. Deswegen habe ich auf meiner C:\ Platte eine Datei mit dem namen start.cmd erstellt. Als Inhalt der Datei habe ich einfach "d:\start.exe" geschrieben. Bei W2K3 Server kann man auf den Eigenschafter einer CMD Datei einen Kompatibilitätsmodus einschalten (Windows 2000). Fertig. Hat munter lustig installiert und konfiguriert. Ok, das war nicht meine erste Idee. Eigentlich wollte ich den Patch von Roland ausprobieren, aber habe mich zu deppert angestellt.

CU Stefan

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