|
|
|
Горю, выручайте или уволят
|
|||
|---|---|---|---|
|
#18+
win 2000 конечна ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2003, 14:25 |
|
||
|
Горю, выручайте или уволят
|
|||
|---|---|---|---|
|
#18+
Да двухтысячная ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2003, 14:26 |
|
||
|
Горю, выручайте или уволят
|
|||
|---|---|---|---|
|
#18+
Вот это поправь: db_block_size=6144 Не бывает такого размера блока. Есть 2к, 4к, 8к, 16к, 32к ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2003, 14:36 |
|
||
|
Горю, выручайте или уволят
|
|||
|---|---|---|---|
|
#18+
pre_page_sga = TRUE убрал этот параметр и вроде заработало но премию снимут ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2003, 14:36 |
|
||
|
Горю, выручайте или уволят
|
|||
|---|---|---|---|
|
#18+
Esli W2K - problema deistvitelno v memory manager. Obychno, v takom sluchae, service startuet vruchnyu, ( no ne cherez services! ). A dal'she nado razbirat'sya s gelezom.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2003, 14:37 |
|
||
|
Горю, выручайте или уволят
|
|||
|---|---|---|---|
|
#18+
Oracle 9i Release 2 ot etogo nedostatka svoboden. Nashi recomeduyt pol'zovat'sya tol'ko 9.2. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2003, 14:38 |
|
||
|
Горю, выручайте или уволят
|
|||
|---|---|---|---|
|
#18+
Sorry.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2003, 14:40 |
|
||
|
Горю, выручайте или уволят
|
|||
|---|---|---|---|
|
#18+
как у нас народ все-таки любит умозрительно решать сложные проблемы. Вместо того чтоб разобраться что, где, как и почему не работает найти простое решение вроде взмаха волшебной палочки. 2Сергей $ Разложите проблему на составляющие - что именно стало медленнее работать, какие запросы, почему индексы не используются - проверьте планы выполнения, протрассируйте сессии, проверьте события ожидания и статистику. Когда будут конкретные данные, тогда и обращайтесь на форум за помощью. Если не знаете как их собрать - тоже спрашивай - народ поможет. Но не пытайтесь решить все одним махом. Кроме того мысли о потерянной премии тоже не помогают (ну и как я понял администрирование Оракла это не ваша основная работа). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2003, 14:55 |
|
||
|
Горю, выручайте или уволят
|
|||
|---|---|---|---|
|
#18+
Да я не админ, я разработчик а валят все на меня, потому что не работает нефига хотя я даже и дамп не ставил туда контора у нас такая (админ, просто приблатненный) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2003, 15:12 |
|
||
|
Горю, выручайте или уволят
|
|||
|---|---|---|---|
|
#18+
2 Oracle X-pert а можно поинтересоваться насчет рекомендаций таких ОГРОМНЫХ pool size-ов , sort area, processes и относительно маленького optimizer_index_caching в контексте "половина индексов не подхватывается" ? Или просто знакома данная БД ? 2 Sergey $ Такая огромная БД - десятки мегабайт кода ? Java используется со страшной силой? Если крутили pool size-ы в надежде сказочного убыстрения - верните из размер назад - лучше db_cache_size за их счет увеличить. И добавьте к первоначальному варианту init-а optimizer_index_caching=95 optimizer_index_cost_adj=5 Каков вопрос - таков ответ. Кроме того что "половина индексов не подхватывается" ничего не хотите нам сообщить (о БД) - получите лекарство только от индексов :-) Если расскажете как получили db_block_size=6144 , будет или хохма или сенсация :-)))) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2003, 18:03 |
|
||
|
Горю, выручайте или уволят
|
|||
|---|---|---|---|
|
#18+
Kakoi smysl dergat' v cash { optimizer_index_caching } 95%? Razve obnovleniya dannyh ne proishodit? Po xarakteristikam HARD dannaya konf pozvolaet dergat' pool ukazannogo razmera. Dal'she DBA ostaetsya proverit' vse HIT ratio. Uvelichenie db_cache_size na 9i release 1 W2K problematichno iz-za exp yvelicheniya swap. optimizer_index_cost_adj=5 dynamic/default value....... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2003, 18:11 |
|
||
|
Горю, выручайте или уволят
|
|||
|---|---|---|---|
|
#18+
>optimizer_index_cost_adj=5 dynamic/default value....... Вот это интересно. А я всегда думал, что default value 100. Кстате, увеличение sort_area_size до 40Mb никакого эффекта не даст, а вот свопинг вызовет, т.к. PGA процесса сможет раздуться до 120M (sort_area_size + hash_area_size, который по умолчанию равен 2 х sort_area_size). А если таких процессов будет много, то сами понимаете, что может произойти. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2003, 18:36 |
|
||
|
Горю, выручайте или уволят
|
|||
|---|---|---|---|
|
#18+
>Kakoi smysl dergat' v cash { optimizer_index_caching } 95%? Razve obnovleniya >dannyh ne proishodit? Этот параметр кеш не дергает, а только влияет на решения оптимизатора использовать или нет индексное сканирование. Но пока мы не увидим конкретных запросов и планов их выполнения все эти рассуждения - просто сотрясание воздуха. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2003, 18:39 |
|
||
|
Горю, выручайте или уволят
|
|||
|---|---|---|---|
|
#18+
optimizer_index_caching=95 - это подсказка CBO что он найдет с вероятностью 95% найдет индекс в кеше и поэтому можно юзать nested loops ? Тогда hit ratio здесь ни при чем. > optimizer_index_cost_adj=5 dynamic/default value....... optimizer_index_cost_adj=100 было по дефолту было всегда. В 9.2 изменилось ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2003, 18:47 |
|
||
|
Горю, выручайте или уволят
|
|||
|---|---|---|---|
|
#18+
2 dba Ну вот стоит только на 5 минут отойти :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2003, 18:50 |
|
||
|
Горю, выручайте или уволят
|
|||
|---|---|---|---|
|
#18+
>2 dba >Ну вот стоит только на 5 минут отойти :-) Работать меньше надо :-)) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2003, 18:52 |
|
||
|
Горю, выручайте или уволят
|
|||
|---|---|---|---|
|
#18+
Это по дефолту в 9.2: NAME TYPE VALUE ------------------------------------ ----------- -------- optimizer_dynamic_sampling integer 1 optimizer_features_enable string 9.2.0 optimizer_index_caching integer 0 optimizer_index_cost_adj integer 100 optimizer_max_permutations integer 2000 optimizer_mode string CHOOSE ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2003, 18:55 |
|
||
|
Горю, выручайте или уволят
|
|||
|---|---|---|---|
|
#18+
обратите внимание permutations уменьшили :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2003, 18:56 |
|
||
|
Горю, выручайте или уволят
|
|||
|---|---|---|---|
|
#18+
>permutations уменьшили :-) А эти пермутации до 80000 никогда и не доходили - это просто условное число. Вот что металинк пишет: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2003, 19:13 |
|
||
|
Горю, выручайте или уволят
|
|||
|---|---|---|---|
|
#18+
Знакомая лажа :) Неприятно, когда индексы в ж..е и проги работают на порядок медленее. Первое что надо сделать - запусить Estimate/Compute statistics для индексов. Для начала это попробуй. Если не получиться - буду дальше вспоминать ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.03.2003, 15:14 |
|
||
|
Горю, выручайте или уволят
|
|||
|---|---|---|---|
|
#18+
Насчет параметра optimizer_max_permutations. У нас был случай когда изменение именно этого параметра значительно увеличивало скорость обработки запроса. Ситуация рассматривалась на 5 cерверах: 1. Linux Slackware 7.1, 2xXEON 400MHz, RAM 512Mb, SCSI RAID 5, OraDB 8.1.7.0.1 Enterprise 2. Linux Slackware 7.1, 2xPIII 800MHz, RAM 768Mb, SCSI RAID 5, OraDB 8.1.7.0.1 Enterprise 3. Linux SuSE 8.1, 1xP4 2,4GHz, RAM 512Mb, IDE, OraDB 8.1.7.0.1 Enterprise 4. Linux SuSE 8.1, 1xP4 2,4GHz, RAM 512Mb, IDE, OraDB 9.2.0.1 Enterprise 5. Linux SuSE 8.1, 2xXEON 1GHz, RAM 1Gb, SCSI RAID 10, OraDB OraDB 9.2.0.1 Enterprise (с патчем p2761332_9203) Запрос приводить не буду (если кого интересует вышлю по почте): состоит из 21 таблицы, включает внешние внутренние объединения, in, exists и многое другое (запрос строится автоматически). На 9-ке этот параметр имел значение 2000 на 8-ке - 80000. Запрос работал в 5-10 раз быстрее на 9-ке. После установки значения 2000 на 8-ках запросы обрабатывались также быстро как и на девятках (с учетом аппаратных возможностей машин и, соответственно параметров SGA и PGA). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.04.2003, 12:51 |
|
||
|
Горю, выручайте или уволят
|
|||
|---|---|---|---|
|
#18+
"запросы обрабатывались также быстро " Ты хотел сказать также медленно? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.04.2003, 13:16 |
|
||
|
Горю, выручайте или уволят
|
|||
|---|---|---|---|
|
#18+
ИМХО то, что значение optimizer_max_permutations сказалось именно на тяжелых запросах весьма показательно, т.е. там, где количество возможных перестановок (читай планов выполнения) весьма велико. Уменьшение значения этого параметра заставило Оракл прервать поиск оптимального плана (а именно построение плана занимала львиную долю времени) и выдать то, что получилось. У меня вопрос: если подобный запрос периодически выполняется, то не стоило ли однажды, дождавшись выполнения при максимальном значении optimizer_max_permutations, закрепить план выполнения памяти, и в дальнейшем использовать его, не строив сызнова? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.04.2003, 13:27 |
|
||
|
Горю, выручайте или уволят
|
|||
|---|---|---|---|
|
#18+
>На 9-ке этот параметр имел значение 2000 на 8-ке - 80000. Запрос работал в >5-10 раз быстрее на 9-ке. После установки значения 2000 на 8-ках запросы >обрабатывались также быстро как и на девятках (с учетом аппаратных >возможностей машин и, соответственно параметров SGA и PGA). Вериться с трудом что парсинг может занять столько времени при дефолтных значениях параметров. Сколько ж времени тогда занимает весь запрос? Даже если 1 сек на 9-ке, то это значит, что парсинг на 8-ке занимал как минимум 10 сек.? Это-то на Гигагерцовых пентиумах? Чтож там за запрос такой? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.04.2003, 13:31 |
|
||
|
|

start [/forum/topic.php?fid=52&msg=32115967&tid=1991023]: |
0ms |
get settings: |
8ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
168ms |
get topic data: |
7ms |
get forum data: |
2ms |
get page messages: |
40ms |
get tp. blocked users: |
1ms |
| others: | 207ms |
| total: | 454ms |

| 0 / 0 |
