---

hallo alle zusammen,

wir wollen die performance unserer Intralink-Datenbank verbesser.
der erste schritt war, zu unseren 256 MB RAM weitere 512 MB RAM anzuschaffen. so weit so gut.
in der initlnk.ora haben wir shared_pool_size und db_block_buffer etwas angepasst db_block_buffers = 60360 und shared_pool_size = 160000000 (siehe auch http://ww3.cad.de/foren/ubb/Forum69/HTML/000052.shtml)

für einen oracle-nichts-wisser ist das mit den parametern 'n buch mit sieben siegeln - aber dafür gibt's ja euch  

wie groß ist denn so ein db_block_buffer? 60360 = 60360 bit?
ich habe iregendwo gefunden:

Zitat:

---

db_block_buffers—Use as much available memory for the db_block_buffers as your system can handle, not to exceed a total System Global Area (SGA) (buffers + shared_pool + log_buffer) of 50% of the system’s memory.

---

naja, das ist ja schön und gut, aber in welchem verhältnis? oder gibt es für intralink andere aussagen?!?

weiterhin (und das war das einzige bezüglich parameter) habe ich in der PTC-Datenbank folgenden TPI gefunden: http://www.ptc.com/cs/tpi/110929.htm  (bezüglich optimizer_index_caching = 99 und optimizer_index_cost_adj = 10)

... was bewirkt der eintrag dieser parameter genau?
was wird durch das ausführen von
SVRMGR> connect internal         -- Note: NT admins usually must connect as internal/internal
SVRMGR> execute dbms_utility.analyze_schema('PDM','COMPUTE');
"gemacht"?

könnte man durch einfaches rausnehmen der parameter wieder die ursprüngliche verhaltensweise wieder herstellen?
wofür stehen die zahlen?

hoffentlich ist hier im forum jemand, der diese "blöden" fragen beantworten kann, vielleicht sogar jemand, der das nur als hobby macht ;-)

danke schon mal.

------------------
cu
fossy
             meine kleine website

[Diese Nachricht wurde von fossy am 11. November 2003 editiert.]

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

---

hi,

"einwas" kann ich schon selber beantworten :-)

Zitat:

---

Original erstellt von fossy:

wie groß ist denn so ein db_block_buffer? 60360 = 60360 bit?

---

db_block_size * db_block_buffer = größe in byte

warum ist bei der intralinkdatenbank eigentlich der parametzer
db_files =  96  so niedrig? ich hab das gefühl, in anderen oracle-datenbanken geht die anzahl der datenbankfiles in die 1000!!!???!!!

------------------
cu
fossy
          meine kleine website

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

---

Hi fossy,

wenn ich eine Datenbank auf einem Rechner installiere, dann sehe ich mir zuerst die Speicherauslastung mit dem Standardwert an.
Danach gebe ich einen Faktor, sagen wir einmal "10" auf den Wert (kurz gesagt, einfach eine "0" dranhängen), und sehe mir nach einem Neustart das Ganze noch mal an. Nötigenfalls kann man den Wert ja noch mal ändern. Wenn dann der Server auf ca. 90% steht, warŽs gut und reicht aus.
Erstaunlich ist, was man da für eine Performanceverbesserung bekommt. Wir hatten da mal ein Daten-Rettungsprojekt, bei dem dann auch mal über den (nicht von uns installierten) Server geschaut wurde. Es waren nach einigen Tests Zeiten festzustellen, die beim CheckOut von Baugruppen mit ca. 1200 Objekten von 8-10 Minuten auf 1-2 Minuten runter waren.

Viele Grüße

Detlef

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

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

---

hi,

so wie es aussieht, gibt es nicht viele, die sich damit beschäftigen bzw. "wissen" was man mit den parametern einstellen kann.
... schade eigentlich, denn "literatur" ist entweder verdammt umfangreich oder halt speziell für irgend 'ne andere anwendung außer intralink.
naja, vielleicht kann ja irgendwann mal ein "neuer" helfen.

------------------
cu
fossy
          meine kleine website

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

---

initilnk_ora.txt

Hallo Zusammen,

im Zweifelsfall würde ich einen Dataserver-Call bei der Hotline aufmachen, da man sorgfältig an den Parametern schrauben muss.

Bei der Einstellung der Werte der initilnk.ora haben wir uns beraten lassen. Nun, wie so ist, ist unsere Datenbank immer groesser geworden.
In der Maschine sind 1 GB Memory eingebaut. Nach einem Boot benötigt der Server schon ca. 900 MB. Im Betrieb gerät die Maschine nun doch immer öfter ins Swappen. Bis jetzt hat sich noch kein Anwender beschwert. Leider ist das Purgen der Datenbank mächtig langsam geworden. Wir werden die Maschine jetzt auf 2 GB aufrüsten.

Anbei unsere initilnk.ora. Wir haben ca 30 Anwender Online, bei 260 GB Pro/E-Daten.

Grüße

    Bernhard Veckes

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

---

hallo,

und danke bernhard!

nun es gibt zu unserer config zwei wesentliche unterschiede.

bei euch wird der "control_file" nicht gespiegelt (wird in jeder dokumentation empfohlen (systemsicherheit) - ich weiß aber auch nicht genau wozu das notwendig ist, weil ja gesichert wird...)
und
es gibt einen zusätzlichen parameter "large_pool_size" wobei der mit 20MB relativ klein ist gegenüber "shared_pool_size" mit ca. 170MB.

bei gelegenheit werde ich mal ausprobieren, ob sich die performance verbessert, wenn dieser parameter fest gesetzt wird.

------------------
cu
fossy
          meine kleine website

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

---

Hallo Fossy,

das beste ist es, aus einer ORACLE-CD das Oracle-Tuning zu installieren. Damit hat man dann von ORACLE automatisch die Vorschläge, was zu verbessern ist. Geht ganz gut....

Grüsse, Thomas

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

---

hallo thomas,

... ein neuer "mitdencer" in der runde  herzlich willkommen.
ist die installations-cd für intralink auch eine "oracle-cd"? oder sind da wirklich nur die zur installation notwendigen sachen drauf?
wenn nein, wo bekomme ich eine "oracle-cd"? bzw. wo krieg ich das oracle-tuning her???

... fragen über fragen 

------------------
cu
fossy
              meine kleine website

[Diese Nachricht wurde von fossy am 07. Jan. 2004 editiert.]

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

---

Hallo Fossy,

noch mal kurz zum mitdenken (ich habe jetzt nicht alles gelesen, da ich dazu keine lust hatte)

was wollt Ihr den noch verbessern?

Ein paar infos zu db_files

Size of a PGA
A PGA’s initial size is fixed and operating-system specific. When the client and
server are on different machines, the PGA is allocated on the database server at
connect time; if sufficient memory is not available to connect, an Oracle error occurs
with an error number in the range for that operating system. Once connected, a user
can never run out of PGA space; there is either enough or not enough memory to
connect in the first place.
The initialization parameters OPEN_LINKS and DB_FILES affect the sizes of PGAs.
The size of the stack space in each PGA created on behalf of Oracle background
processes (such as DBW0 and LGWR) is affected by some additional parameters.

noch was:

DB_FILES specifies the maximum number of database files that can be opened for
this database. The maximum valid value for DB_FILES is the maximum number of
files, subject to operating system constraint, that will ever be specified for the
database, including files to be added by ADD DATAFILE statement.
If you increase the value of DB_FILES, you must shut down and restart all instances
accessing the database before the new value can take effect.
Note: The checkpoint process is enabled by default if the system configuration is
such that moving checkpoint processing from the logwriter to a separate process is
deemed to improve performance. Currently, the criteria are DB_FILES >= 50 or
DB_BLOCK_BUFFERS >= 10000.
Parameter type: integer
Parameter class: static
Default value: operating system-dependent; 200 on Solaris
Range of values:
minimum value: either the value that was specified in the
MAXDATAFILES clause the last time CREATE
DATABASE or CREATE CONTROLFILE was executed,
or the current actual number of datafiles in the data
maximum value: operating system-dependent
Multiple instances: must have the same value

also über all mal ebend eine 0 anhängen ist nicht immer so gut

Gruß von eurem Freizeit CadDEler
Andreas

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

---

Hi noch mal,

ich habe grade festgestellt, das ich seit geraumer Zeit nicht mehr auf diesen Seiten unterwegs gewesen bin!

Noch was zum Thema!

OPTIMIZER_INDEX_CACHING
OPTIMIZER_INDEX_CACHING lets the user adjust the behavior of the cost-based
optimizer to select nested loops joins more often. The cost of executing a nested
loops join where an index is used to access the inner table is highly dependent on
the caching of that index in the buffer cache. The amount of caching depends on
factors, such as the load on the system and the block access patterns of different
users, that the optimizer cannot predict. The user can modify the optimizer's
assumptions about index caching for nested loops joins by setting this parameter to
a value between 0 and 100 percent and thereby indicate what percentage of the
index blocks should be assumed to be in the cache. Setting this parameter to a
higher value makes nested loops join look less expensive to the optimizer and it will
be more likely to pick nested loops joins over hash or sort-merge joins. The default
for this parameter is 0, which gives the old optimizer behavior.
Parameter type: integer
Parameter class: dynamic, scope = ALTER SESSION
Default value: 0
Range of values: 0-100

geht also nur bei costen optimierten Optimizer!
also 99% heißt also to select nested loops joins more often!

OPTIMIZER_INDEX_COST_ADJ
OPTIMIZER_INDEX_COST_ADJ lets the user tune the optimizer behavior for
access path selection to be more or less index-friendly. Some users are using the
first_rows optimizer mode to get plans that use more index access paths and that
are more similar to those generated by the rule-based optimizer. However, the first_
rows mode was never intended as a pure mechanism to force the use of indexes.
The OPTIMIZER_INDEX_COST_ADJ parameter lets the user adjust the costing of
index access paths in the cost-based optimizer and thereby make the optimizer
more or less prone to selecting an index access path over a full table scan. The
default for this parameter is 100 percent, which makes the optimizer cost index
access paths a the regular cost. Any other value will make the optimizer cost the
access path at that percentage of the regular cost, e.g., setting it to 50 percent, will
make the index access path look half as expensive as normal. The legal range of
values for this parameter is 1 to 10000 percent. This parameter can be used to tune
the performance of a system where it is felt that the optimizer chooses too few or
too many index access paths. The adjustment does not apply to user-defined cost
functions for domain indexes.
Parameter type: integer
Parameter class: dynamic, scope = ALTER SESSION
Default value: 100
Range of values: 1-10000

10 scheint hier doch eher etwas klein!
eine 0 anhängen könnte da schon was bringen

Gruß
Andreas

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