|
|
|
Горю, выручайте или уволят
|
|||
|---|---|---|---|
|
#18+
Проблема следующая, работали на 8i оракле и все нормально было, но тут босс решил перейти на 9 и все тут. Короче меня вчера не было, сегодня прихожу половина индексов не подхватывается в LOV списках не работает из-за этого сортировка и т.д. Что делать ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2003, 09:21 |
|
||
|
Горю, выручайте или уволят
|
|||
|---|---|---|---|
|
#18+
Prover analyze ( esli ispol'zuete choose..) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2003, 09:29 |
|
||
|
Горю, выручайте или уволят
|
|||
|---|---|---|---|
|
#18+
Все проанализировал сегодня. и нефига не подхватывает только при FIRST_ROWS что то там хватает но это же лажа ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2003, 09:36 |
|
||
|
Горю, выручайте или уволят
|
|||
|---|---|---|---|
|
#18+
A chto gonit: HASH ili prosto Full scan? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2003, 09:44 |
|
||
|
Горю, выручайте или уволят
|
|||
|---|---|---|---|
|
#18+
Bros' mne na mail table i query.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2003, 09:45 |
|
||
|
Горю, выручайте или уволят
|
|||
|---|---|---|---|
|
#18+
FULL SCAN гонит ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2003, 09:47 |
|
||
|
Горю, выручайте или уволят
|
|||
|---|---|---|---|
|
#18+
Как переводил? Я экспортом троекратным все перевел без проблем (почти) Т.е. по крайней мере у меня все данные перелились на 100% ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2003, 09:59 |
|
||
|
Горю, выручайте или уволят
|
|||
|---|---|---|---|
|
#18+
Експортнули базу и поехало, блина может какие настройки надо (я просто не спец по таким делам, начальник решил что надо на 9 и все тут, на 8 все нормальна валило) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2003, 10:02 |
|
||
|
Горю, выручайте или уволят
|
|||
|---|---|---|---|
|
#18+
Спокойно! Тогда по иде все просто... Для начала напиши полностью скрипт экспорта и импорта... Перед импортом нужно было создать копию старой (8и) БД. Теже табл пр-ва (желательно как я понял с теми же параметрми если ты не спец и гемороя дальнейшего не хотишь) Потом скачать со старой машины TNSNAMES.ORA и залить его для новой БД. Настроить NLS_LANG как в старой. Кажись все.... Потом делай тройной импорт 2 Раз с параметром IGNORY=Y rows=N 3 Раз тоже с параметром IGNORY=Y rows=N! Все все должно залиться! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2003, 10:10 |
|
||
|
Горю, выручайте или уволят
|
|||
|---|---|---|---|
|
#18+
Блина да оно все как бы и залилось, все данные есть только вот индексы не подхватывает >>>> откуда и берутся большие тормоза и отсутствие сортировки ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2003, 10:12 |
|
||
|
Горю, выручайте или уволят
|
|||
|---|---|---|---|
|
#18+
ny, gde ini? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2003, 10:16 |
|
||
|
Горю, выручайте или уволят
|
|||
|---|---|---|---|
|
#18+
Стоп! Что значит не подхватывает? Как это понять? Они у тебя экспортиорвались? И столько же импортировалось? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2003, 10:43 |
|
||
|
Горю, выручайте или уволят
|
|||
|---|---|---|---|
|
#18+
Только я не знаю тот ли это файл ############################################################################## # Copyright (c) 1991, 2001 by Oracle Corporation ############################################################################## ########################################### # Cache and I/O ########################################### db_block_size=6144 db_cache_size=168848384 ########################################### # Cursors and Library Cache ########################################### open_cursors=300 ########################################### # Diagnostics and Statistics ########################################### background_dump_dest=D:\oracle\admin\oracle9\bdump core_dump_dest=D:\oracle\admin\oracle9\cdump timed_statistics=TRUE user_dump_dest=D:\oracle\admin\oracle9\udump ########################################### # Distributed, Replication and Snapshot ########################################### db_domain=minks.minsk.energo.net remote_login_passwordfile=EXCLUSIVE ########################################### # File Configuration ########################################### control_files=("D:\oracle\oradata\oracle9\control01.ctl", "D:\oracle\oradata\oracle9\control02.ctl", "D:\oracle\oradata\oracle9\control03.ctl") ########################################### # MTS ########################################### # Uncomment the following line when your listener is configured for SSL # (listener.ora and sqlnet.ora) # dispatchers = "(PROTOCOL=TCPS)(SER=MODOSE)", "(PROTOCOL=TCPS)(PRE=oracle.aurora.server.GiopServer)", "(PROTOCOL=TCPS)(PRE=oracle.aurora.server.SGiopServer)" dispatchers="(PROTOCOL=TCP)(SER=MODOSE)", "(PROTOCOL=TCP)(PRE=oracle.aurora.server.GiopServer)", "(PROTOCOL=TCP)(PRE=oracle.aurora.server.SGiopServer)" ########################################### # Miscellaneous ########################################### compatible=9.0.0 db_name=oracle9 ########################################### # Network Registration ########################################### instance_name=oracle9 ########################################### # Pools ########################################### java_pool_size=52428800 large_pool_size=10485760 shared_pool_size=291235328 ########################################### # Processes and Sessions ########################################### processes=150 ########################################### # Redo Log and Recovery ########################################### fast_start_mttr_target=300 ########################################### # Sort, Hash Joins, Bitmap Indexes ########################################### sort_area_size=2524288 ########################################### # System Managed Undo and Rollback Segments ########################################### undo_management=AUTO undo_tablespace=UNDOTBS ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2003, 10:45 |
|
||
|
Горю, выручайте или уволят
|
|||
|---|---|---|---|
|
#18+
########################################### db_block_size=6144 db_cache_size=168848384 ########################################### # Cursors and Library Cache ########################################### open_cursors=2000 ########################################### # Diagnostics and Statistics ########################################### background_dump_dest=D:\oracle\admin\oracle9\bdump core_dump_dest=D:\oracle\admin\oracle9\cdump timed_statistics=TRUE user_dump_dest=D:\oracle\admin\oracle9\udump ########################################### # Distributed, Replication and Snapshot ########################################### db_domain=minks.minsk.energo.net remote_login_passwordfile=EXCLUSIVE ########################################### # File Configuration ########################################### control_files=("D:\oracle\oradata\oracle9\control01.ctl", "D:\oracle\oradata\oracle9\control02.ctl", "D:\oracle\oradata\oracle9\control03.ctl") ########################################### # MTS ########################################### # Uncomment the following line when your listener is configured for SSL # (listener.ora and sqlnet.ora) # dispatchers = "(PROTOCOL=TCPS)(SER=MODOSE)", "(PROTOCOL=TCPS)(PRE=oracle.aurora.server.GiopServer)", "(PROTOCOL=TCPS)(PRE=oracle.aurora.server.SGiopServer)" dispatchers="(PROTOCOL=TCP)(SER=MODOSE)", "(PROTOCOL=TCP)(PRE=oracle.aurora.server.GiopServer)", "(PROTOCOL=TCP)(PRE=oracle.aurora.server.SGiopServer)" ########################################### # Miscellaneous ########################################### compatible=9.0.0 db_name=oracle9 ########################################### # Network Registration ########################################### instance_name=oracle9 ########################################### # Pools ########################################### java_pool_size=52428800 #large_pool_size=10485760 shared_pool_size=291235328 hash_area_size = 8192000 job_queue_processes = 15 large_pool_size = 83886080 ########################################### # Processes and Sessions ########################################### processes=1500 ########################################### # Redo Log and Recovery ########################################### fast_start_mttr_target=300 ########################################### # Sort, Hash Joins, Bitmap Indexes ########################################### #sort_area_size=2524288 sort_area_retained_size = 40960000 sort_area_size = 40960000 ########################################### # System Managed Undo and Rollback Segments ########################################### undo_management=AUTO undo_tablespace=UNDOTBS ########################################### # Added ########################################### optimizer_mode = CHOOSE db_writer_processes = 5 dml_locks = 1000 enqueue_resources = 7000 db_file_multiblock_read_count = 128 optimizer_features_enable=9.2.0 optimizer_index_caching=25 plsql_v2_compatibility = TRUE pre_page_sga = TRUE ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2003, 11:23 |
|
||
|
Горю, выручайте или уволят
|
|||
|---|---|---|---|
|
#18+
Счас попробую спасибо заранее, чувствую получится ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2003, 12:21 |
|
||
|
Горю, выручайте или уволят
|
|||
|---|---|---|---|
|
#18+
Короче все, лег сервак и не запускается.... (наверно уволят все же) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2003, 13:28 |
|
||
|
Горю, выручайте или уволят
|
|||
|---|---|---|---|
|
#18+
Minyty, chto on tebe soobshaet? moget byt' ' sintacs ignore /? Ubit' Oracle dovol'no taki trudno.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2003, 13:33 |
|
||
|
Горю, выручайте или уволят
|
|||
|---|---|---|---|
|
#18+
A so starym ini podnimaetsya? Ty delal copy-paste from HTML into ini? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2003, 13:37 |
|
||
|
Горю, выручайте или уволят
|
|||
|---|---|---|---|
|
#18+
а может быть попробовать compatible=8.1.7 в старом ини ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2003, 13:40 |
|
||
|
Горю, выручайте или уволят
|
|||
|---|---|---|---|
|
#18+
Ni v koem sluchae! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2003, 13:43 |
|
||
|
Горю, выручайте или уволят
|
|||
|---|---|---|---|
|
#18+
А в чем дело? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2003, 13:44 |
|
||
|
Горю, выручайте или уволят
|
|||
|---|---|---|---|
|
#18+
V 9i mnogie parametry dynamics, a v 8i - net. voznoknet conflict. V dannoi sityazii, skoree vsego , konflict Oracle c Memory manager. ------ 1. Postepenno ymen'shat' kol-vo sessions. ( ne hvataet semaforov v OS) 2. Comment on str::pre_page_sga = TRUE 3. Libo est' oshibki v sintacsise parameters ( copy-paste mog prinesti kakoi-libo symbol... ( Win2Unix )... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2003, 13:50 |
|
||
|
Горю, выручайте или уволят
|
|||
|---|---|---|---|
|
#18+
Решили вернуться пока к 8 обратно тут просто может версия глючная девятого 9.0.1.1.1 говорят вообще пишет что Ora-01034: Oracle not available Ora-27101: shared mampry realm doesnt exists ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2003, 14:22 |
|
||
|
Горю, выручайте или уволят
|
|||
|---|---|---|---|
|
#18+
О вроде стартанули... но всеже лучше пока на 8 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2003, 14:23 |
|
||
|
Горю, выручайте или уволят
|
|||
|---|---|---|---|
|
#18+
Vot ono chto! {Ora-27101: shared mampry realm doesnt exists} Platforma - W2K? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2003, 14:24 |
|
||
|
Горю, выручайте или уволят
|
|||
|---|---|---|---|
|
#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 |
|
||
|
Горю, выручайте или уволят
|
|||
|---|---|---|---|
|
#18+
2 softbuilder@inbox.ru если учесть что на девятке выполнялось быстрее, то "также быстро". 2 Denis Popov: > У меня вопрос: если подобный запрос периодически выполняется, то не > стоило ли однажды, дождавшись выполнения при максимальном значении > optimizer_max_permutations, закрепить план выполнения памяти, и в > дальнейшем использовать его, не строив сызнова? к сожалению так сделать нельзя. Точнее можно, но такая возможность бывает очень редко. Поясню. Запросы генерятся автоматически на основе метаописаний при помощи рукотворного генератора. При каждом запуске генерится новый SQL с новыми ограничениями. То что этот генератор нуждается в доработке - вопросов нет. Но это пока единственное средство полностью отвечающее требованиям по функциональности (что доминирует над остальными критериями в моей ситуации). 2 DBA факт. запрос "трехэтажный". дерево планировщика состяло из 154 операций (steps). Вообще речь идет о сокращении времени с 17 минут до 3-х - при первом запуске запроса, и до 45 сек. - при втором и последующем запуске того-же запроса ("кэш в работе"). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.04.2003, 14:21 |
|
||
|
Горю, выручайте или уволят
|
|||
|---|---|---|---|
|
#18+
>факт. запрос "трехэтажный". дерево планировщика состяло из 154 операций >(steps). Вообще речь идет о сокращении времени с 17 минут до 3-х - при >первом запуске запроса, и до 45 сек. - при втором и последующем запуске >того-же запроса ("кэш в работе"). я просто хочу понять как же все-таки повлияло уменьшение optimizer_max_permutations на время выполнения. Т.е. с 17 минут до 3 минут при чтении с диска. Хорошо, но если потом до 45 сек. при чтении из кеша, то это означает, что время уходило ну совсем не на парсинг, а на чтение блоков. Или я неправ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.04.2003, 14:28 |
|
||
|
Горю, выручайте или уволят
|
|||
|---|---|---|---|
|
#18+
Скорее всего, второй запуск на выполнение уходит на простую сверку селекта и изменений кэша (+ выдача результата), что составляет ок. 45 сек. Проблема сокращения времени обработки запроса комплексная. Допускаю что влияли и прочие факторы (изменения которых мы старались избегать). Но то, что время обработки (по крайней мере львиная доля) сократилось из-за изменения обсуждаемого параметра - это бесспорно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.04.2003, 14:39 |
|
||
|
Горю, выручайте или уволят
|
|||
|---|---|---|---|
|
#18+
>Скорее всего, второй запуск на выполнение уходит на простую сверку >селекта и изменений кэша (+ выдача результата), что составляет ок. 45 сек. т.е. запрос второй раз не парсился? Я то думал вы это обеспечили. Тогда вообще ничего не понятно. Как вообще можно сравнивать, если вы не знаете на что уходило время? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.04.2003, 14:49 |
|
||
|
Горю, выручайте или уволят
|
|||
|---|---|---|---|
|
#18+
Я говорю про факт. СУБД рассматриваю как черный ящик. На входе: запрос SQL, параметры СУБД, версия СУБД, конфигурация аппаратуры. На выходе: время выполнения. Оснавная задача: сократить время выполнения. Примечание: работа кэша особо не интересует. 9-ка приводится только потому, что различия обнаружились лишь прогнав запрос на двух СУБД. Для исключения влияния аппаратных мощностей был проведен тест на одной и той же машине (видно по списку). Результат: ЗНАЧИТЕЛЬНО сокращено время выполнения запроса SQL, изменив значение параметра optimizer_max_permutations. На что уходит время мне не интересно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.04.2003, 15:05 |
|
||
|
Горю, выручайте или уволят
|
|||
|---|---|---|---|
|
#18+
>Примечание: работа кэша особо не интересует ну-ну, рассматривайте и дальше СУБД как черный ящик. Я так понимаю, что и план выполнения вас особо не интересует. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.04.2003, 15:13 |
|
||
|
Горю, выручайте или уволят
|
|||
|---|---|---|---|
|
#18+
> ну-ну, рассматривайте и дальше СУБД как черный ящик. Я так понимаю, что и план выполнения вас особо не интересует. Как раз интересует, но с точки зрения стоимости выполнения запроса. Очевидно что время выполнения запроса с меньшей стоимостью будет выполнено быстрее. Я уж не буду говорить о том что стоимость изменилась после изменения параметра оптимизатора. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.04.2003, 15:17 |
|
||
|
Горю, выручайте или уволят
|
|||
|---|---|---|---|
|
#18+
>Я уж не буду говорить о том что стоимость изменилась после изменения >параметра оптимизатора. Какого именно параметра? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.04.2003, 15:20 |
|
||
|
Горю, выручайте или уволят
|
|||
|---|---|---|---|
|
#18+
2 dba см выше ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.04.2003, 15:22 |
|
||
|
Горю, выручайте или уволят
|
|||
|---|---|---|---|
|
#18+
Хорошо, тогда вот моя интерпретация вашего сообщения: На входе: Запрос На выходе: План выполнения Основная задача: Получить лучший план выполнения Результат: План выполнения улучшился при изменении колл-ва вариаций соединения таблиц с 80000 до 2000 Примечание: Сколько вариаций использовал оптимизатор в действительности -неизвестно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.04.2003, 15:35 |
|
||
|
Горю, выручайте или уволят
|
|||
|---|---|---|---|
|
#18+
тоже неплохо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.04.2003, 15:36 |
|
||
|
Горю, выручайте или уволят
|
|||
|---|---|---|---|
|
#18+
К сожалению мое начальство незнает что такое "план выполнения". Оно знает что такое "время". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.04.2003, 15:38 |
|
||
|
Горю, выручайте или уволят
|
|||
|---|---|---|---|
|
#18+
>К сожалению мое начальство незнает что такое "план выполнения". Оно >знает что такое "время". Так и Ваше сообщение больше подходит на форум для "начальства", потому что для админа важен не столько рез-тат, сколько понимание почему так произошло. Во-первых это не логично, что при увеличении числа пермутаций ухудшается план - значит это баг, который возможно устранен (а у Вас базы не пропатчены - я так понимаю что начальство не знает что такое "патч"). Во-вторых Вы не владеете полной информацией (например, были кешированы данные, парсился ли второй раз запрос) для того чтоб утверждать, что это именно так. Например, Вы изменили параметр и время отклика уменьшилось, а на самом деле это из-за того, что Петя с Васей как раз перестали играть в Unreal по сетке. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.04.2003, 15:50 |
|
||
|
Горю, выручайте или уволят
|
|||
|---|---|---|---|
|
#18+
Понятие времени мне тоже ближе т.к. оно является основной целью (точнее его сокращение). Считаю что осознание общей цели в данной ситуации более важно, т.к. задает нужное направление как для дальнейшего обсуждения, так и в поддержку/помощь автору данного топика. Причем здесь патч (хотя о них я писал выше: тестили с ними и без них)? Ко второму замечанию: данные кэшируются - однозначно (и во всех тестах). Как запрос может не парситься? Повторяю. Тесты проводились на различных конфигурациях оборудования (кроме 2-х случаев: см тест 3 и 4) для того чтобы понять как сильно влияет на результат хардверная состаляющая. Прочие условия тестирования поддерживались одинаковыми для всех случаев. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.04.2003, 16:13 |
|
||
|
Горю, выручайте или уволят
|
|||
|---|---|---|---|
|
#18+
можно сделать трассировку чтобы опровергнуть/подтвердить предположения. С цифрами на руках было бы проще. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.04.2003, 17:40 |
|
||
|
Горю, выручайте или уволят
|
|||
|---|---|---|---|
|
#18+
трассировку чего? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.04.2003, 17:56 |
|
||
|
Горю, выручайте или уволят
|
|||
|---|---|---|---|
|
#18+
трассировку сессии, выдающей это запрос разумеется. Можно затем сравнить результаты статистики на этапе парсинга. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.04.2003, 18:07 |
|
||
|
Горю, выручайте или уволят
|
|||
|---|---|---|---|
|
#18+
Вам этот трид раздувать еще не надоело? :) Вроде у автора уже все заработало...хоть и премию снимут :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.04.2003, 18:08 |
|
||
|
|

start [/forum/topic.php?all=1&fid=52&tid=1991023]: |
0ms |
get settings: |
9ms |
get forum list: |
16ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
175ms |
get topic data: |
9ms |
get forum data: |
3ms |
get page messages: |
101ms |
get tp. blocked users: |
1ms |
| others: | 206ms |
| total: | 526ms |

| 0 / 0 |
