ПредишенСледващото

От всички варианти за нас са най-важните ...

експлоатационните параметри на база данни, посочени в INIT-файл, както знаете, в Oracle изобилстват. Техният брой варира от версия до версия. На версия 8.1.5 за NT, например, на 195:

SQL> изберете броя (*) от параметър срещу $;
COUNT (*)
---------
195
Те са тези, които (не винаги, за съжаление, е ясно) документира. Плюс това, че е възможно да се добавят още 248 без документи:

SQL> изберете броя (*) от х $ ksppi където SUBSTR върху (ksppinm, 1,1) = '_';
COUNT (*)
---------
248
На неподготвен такова изобилие от корекции на работата на системата може да действа потискащо, а в действителност трябва да се добави, че не всички от тези параметри са независими, и че много от тях са в противоречие един с друг с уважение.

За щастие, на знанията на всички 195 параметри (за лица без документи - отделен въпрос), въпреки че това е кредит на администратора (освен ако такава syschetsya), но не е задължително за типичната употреба на системата. Повечето от опциите са полезни само в специални, не твърде често има случаи, които изискват познаване на тънкостите на Oracle наистина работи.

В "нормално" като "живот", освен това, не всички параметри са равни. Някои можете да редактирате, и дори не се забелязва влиянието и дългия процес на издаване на наредби разбиране на другите може да доведе до усилване на производителността, например, само с 1%.

В същото време стойностите показват по подразбиране, Oracle (и който, между другото, може да бъде различен за различните платформи) не е непременно добра, дори и в обикновени, непретенциозни изкушения до случаи на експлоатация. Някои от тях все още трябва да редактирате.

По-долу са някои Init-параметри от сред влияние върху определянето на структури в случай паметта на Oracle, които трябва да обърнат внимание на първо място, тъй като ефектът от тяхното адекватно за таксуване на околната среда може да доведе до повишаване на производителността, надвишаващ значително споменато 1%.

Ето и параметри:

Определя максималния брой блокове данни в SGA. Ако на диска трябва прочетете повече буфери, отколкото посочените в DB_BLOCK_BUFFERS, пресечки от SGA се заустват в пространства за таблици на принципа на "първи дошъл - първи навън" (LRU). Такава процедура, обаче, може да бъде отменена индивидуално за малки масички (способни да извършват цялата SGA сами по себе си, и се оставя място за други).

Размерът на променливата част на байта данни на обща площ (общ басейн). Oracle'om възприема като препоръка, и почти винаги се коригира в зависимост от собствените си ограничения (можете да проверите това като преинсталирате SHARED_POOL_SIZE, и да видим резултата). Променливата част на общ басейн се използва като място за посрещане на динамиката, произтичащи от нуждите паметта на системата RAM. Ако размерът на общ басейн повече, отколкото е необходимо, това се дължи на нарастването на свободните списъци и голям динамичен възникващите разходи за управление може да доведе до намаляване на производителността. Плюс това, много големи по размер може да причини SGA процес на споделяне на RAM диск, общата спирачна ефективност виртуална памет.

Районът в общ басейн, запазени за динамична памет, произтичащи големи непрекъснати области на искания в SGA време SQL обработка. По подразбиране е настроен на 5% от SHARED_POOL_SIZE (в байтове), но в зависимост от условията на работа, това място може или да изчезне или да бъде в недостиг. "Преместването на" параметър SHARED_POOL_RESERVED_SIZE до по-малък или по-голям страничен (повече от 50% Oracle не излагайте позволи), не променят общия размер на общ басейн, но може да се подобри или да намали ефективността на използването на тази област.

Ако използвате NT и не използвайте "обществена" сървър (споделена), паралелно на сървъра или работа с монитор сделка, настройката по подразбиране ще бъдат изложени до 0.

Определя размера на паметта, разпределени на всеки процес, за употреба на сортиране (UGA се използва, например, при лечението или DISTINCT РЕД ОТ; може да се намира в SGA или PGA). Ако паметта не е достатъчно, тя ще бъде използвана дисково пространство - добър начин да се "растение" на системата. Увеличаването на настройката намалява броя на "диск" на видове; В същото време по-голямата част диска сортиране все още не може да се избегне. В края на сортиране паметта се връща на "букет" UGA, че е точка неприятно консумация памет на оглед, се извършва само едновременно в няколко сортировъчни процеси.

В него се посочва максималното количество памет динамично поискана от UGA във финалната фаза на процедурата за сортиране осъществява със съдействието на дисково пространство. След приключване на процедурата по сортиране, тази памет се завръща, но в последния етап на сортиране, то може да се консумира в процеса за известно време в допълнение към "ядрото" паметта, регулируем параметър SORT_AREA_SIZE. (По това време, общата памет консумира процес сортиране може да се постигне SORT_AREA_SIZE + SORT_AREA_RETAINED_SIZE)

Целта на този параметър се издава институция в специален блок данни буфер под-буфери, за които няма валидни обикновени LRU-подмяна механизъм блокове. Ако има един или повече много активно използват обекти (маси), а общият им обем е относително малък, а след това да ги осигури в паметта може да се увеличи скоростта на реакцията на системата.

Целта на този параметър е издаването институция друга специфична под-буфер, отново нарушава стандартната реда на блоковете на смяна, но в обратна посока. Ако се използва рядко голям обект (много голяма маса), то може да се дължи на суб-буфер рециклират, а след това на Оракула "пусна" на неговите единици веднага след употреба (което може да получи изпълнение, както и следното позоваване на блока не скоро ще).

Тя ви позволява да определите броя на едновременните четене блокове, когато диск база данни чете. увеличение DB_FILE_MULTIBLOCK_READ_COUNT The дава осезаем ефект за голяма маса сканиране.

Владимир Przyjalkowski, учител TCC Interface Ltd.

Свързани статии

Подкрепете проекта - споделете линка, благодаря!