|
большая таблица
|
|||
---|---|---|---|
#18+
Oracle 8.1.7 на FreeBSD4.4 Есть таблица на 44 млн. записей sum(поле) по всей таблице занимает около 250с. Причем на той же машине W2K + MS SQL2000 давал тот же результат за 210c. (даже диск один и тот-же) Я понимаю что у меня что-то в настройках init для базы не так, я в этом деле новичек. Может подскажет кто-нибудь оптимальные параметры базы, где есть такая таблица. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.10.2002, 15:26 |
|
большая таблица
|
|||
---|---|---|---|
#18+
а что это единственная задача, которая решается на этой базе? ... |
|||
:
Нравится:
Не нравится:
|
|||
18.10.2002, 15:34 |
|
большая таблица
|
|||
---|---|---|---|
#18+
нет, это просто пример, другие запросы тоже длятся дольше ... |
|||
:
Нравится:
Не нравится:
|
|||
18.10.2002, 15:36 |
|
большая таблица
|
|||
---|---|---|---|
#18+
Привет Для начала надо поставить Оракл на что-нибудь что сертифицированное. И еще надо хоть примерно знать что за железки в этом сервере, параметры базы текущие, как размещены табличные пространства. Вообще неизвестных очень много в этом уровнении ... |
|||
:
Нравится:
Не нравится:
|
|||
18.10.2002, 15:46 |
|
большая таблица
|
|||
---|---|---|---|
#18+
Реально можно судить где быстрее, а где нет, если ты тестировал этот запрос достаточно много. Если ты один раз этот запрос выполнял, разве можно что-то говорить о достоверности. Надо изучать план запроса, изучать как Oracle работает с буферами, redo-логами, как настроена система кэширования FreeBSD. Ньюансов очень много. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.10.2002, 16:02 |
|
большая таблица
|
|||
---|---|---|---|
#18+
Железо для теста, поэтому не очень: 2xpII 233 512m. диски: 20Гб. 7.2 на одном система + oracle, на другом база. init такой: db_block_size = 8192 db_files = 80 db_file_multiblock_read_count = 8 db_block_buffers = 100 shared_pool_size = 3500000 processes = 50 dml_locks = 100 parallel_max_servers = 8 датафайл для tablespace где таблица: DATAFILE '/*/table.dbf' SIZE 20M REUSE AUTOEXTEND ON NEXT 10M MAXSIZE 2000M MINIMUM EXTENT 100K DEFAULT STORAGE ( INITIAL 10K NEXT 10K MINEXTENTS 1 MAXEXTENTS 10 PCTINCREASE 0 ); На счет сертифицированного, пробовал линукс результат от freeBSD практичеcки не отличим ... |
|||
:
Нравится:
Не нравится:
|
|||
18.10.2002, 16:06 |
|
большая таблица
|
|||
---|---|---|---|
#18+
Слушай , чего ты хочешь от Oracle, когда у тебя на буфера для данных выделено всего 8192(размер блока)*100(количество блоков)=800Kb. Имея в налии 512Mb - надо 256Mb отдать Oracle для SGA. Отдай 50Mb на shared_pool_size, 10Mb на sort_area_size, остальное для db_block_buffers = (256-(50+10))*1024/8 = 25088. Округли для ровного счёта до 25000. Итого: shared_pool_size = 52428800 sort_area_size = 10240 ### 25000*8192/1024/1024 = 195Mb db_block_buffers = 25000 ... |
|||
:
Нравится:
Не нравится:
|
|||
18.10.2002, 16:18 |
|
большая таблица
|
|||
---|---|---|---|
#18+
за совет спасибо, сделал так , но опять те же 247,3с ... |
|||
:
Нравится:
Не нравится:
|
|||
18.10.2002, 19:31 |
|
большая таблица
|
|||
---|---|---|---|
#18+
а можно более подробнее: запрос, план выполнения, статистика. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.10.2002, 19:50 |
|
большая таблица
|
|||
---|---|---|---|
#18+
таблица это трафик по ип адресам за месяц, накапливается около 40 млн записей (откуда куда порт и т.д.) очень часто нужны запросы типа select sum(bytes_in), sum(bytes_in), например: select sum(bytes_in), sum(bytes_out) from X_Traffic_Flows_Work where ip_id=18058 select operation,options from SQLN_EXPLAIN_PLAN where statement_id='test' OPERATION OPTIONS ------------------------------ ---------------------------- SELECT STATEMENT SORT AGGREGATE TABLE ACCESS FULL select sum(pins) "Executions", sum(pinhits) "Execution Hits", ((sum(pinhits) / sum(pins)) * 100) "Hit Ratio", sum(reloads) "Misses",((sum(pins) / (sum(pins) + sum(reloads))) * 100) "Hit Ratio" from v$librarycache Executions Execution Hits Hit Ratio Misses Hit Ratio ---------- -------------- ---------- ---------- ---------- 2410 2014 83.5684647 12 99.5045417 select 1-(sum(decode(name, 'physical reads', value,0))/ (sum(decode(name, 'db block gets', value,0)) + (sum(decode(name, 'consistent gets', value,0))))) Read_Hit_Ratio from v$sysstat READ_HIT_RATIO -------------- .013210506 select sum(gets), sum(getmisses), (1 - (sum(getmisses) / (sum(gets) + sum(getmisses)))) *100 HitRat from v$rowcache SUM(GETS) SUM(GETMISSES) HITRAT ---------- -------------- ---------- 971 150 86.6190901 ... |
|||
:
Нравится:
Не нравится:
|
|||
18.10.2002, 20:45 |
|
большая таблица
|
|||
---|---|---|---|
#18+
1. поставь db_block_multi_read_count = 32 2. создай индекс по ip_id 3. собери статистику dbms_stats.gather_table_stats(...) 4. сделай next для временного пространства побольше (1M), и вообще выложи его если есть возможность на другой винт, можно туда где система ... |
|||
:
Нравится:
Не нравится:
|
|||
19.10.2002, 12:59 |
|
большая таблица
|
|||
---|---|---|---|
#18+
Так все таки, что же влияет на FULL SCAN , как я понял ни размер SGA, ни db_file_multiblock_read_count, ни NEXT в TEMP ... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2002, 12:27 |
|
большая таблица
|
|||
---|---|---|---|
#18+
На FULL SCAN влияет быстродействие дисковой системы I/O. А почему может выбираться FULL SCAN вместо скажем индекса при его налчии, это уже другой вопрос. Оптимизатор может решить что чтение таблицы данных более производитьнее чем поиск по индексу. Но у тебя проблемы не в этом, а как раз в том что индекса то и нет, поэтому используется FULL SCAN. Сделай индекс как тебе советовали. Я бы еще посоветовал добавить в этот индекс те поля которые ты выбираешь. Тогда данные запроса будут полностью браться из индекса. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2002, 12:37 |
|
большая таблица
|
|||
---|---|---|---|
#18+
Да это понятно, при поднятии PCI шины до 41,5 скорость ответа увеличалась процентов на 20. В том то и дело что индексов нет, но их нет и в M$, хотелось бы получить все таки, хотя бы равный результат. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2002, 12:46 |
|
большая таблица
|
|||
---|---|---|---|
#18+
Потом ты пытаешься решить проблему слишком просто. 44 млн. записей, как мне кажется это не очень мало. При таких обьёмах надо использовать какие-то дополнительные средства улучшения быстродействия. Использовать партииции, кластеры. В конце концов, можно сделать промежуточную таблицу, которая будет содержать уже просчитанное значение для ip_id. Вначале запрос будет искать в этой таблице, если когда-либо по данному ip_id уже был поиск, то данные будут. Время будет самое минимальое. Конечно же необходимо производить отслеживание при добавлении новых данных, что-бы пересчитывать сумму. Для этого можно использовать триггер, при добавлении в основную таблицу, производить также поиск во вспомогательной и производить update. Или производить пересчёт всей таблицы скажем в то время когда меньше всего нагрузка. Другой вариант. Пользователей наверняка как-то можно расгруппировать и разнести их вообще по разным таблицам. Вобщем вариантов куча. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2002, 12:50 |
|
большая таблица
|
|||
---|---|---|---|
#18+
>Так все таки, что же влияет на FULL SCAN , как я понял >ни размер SGA, ни db_file_multiblock_read_count, ни NEXT >в TEMP 1. Размер не вообще SGA, а резмер db_block_buffers и он влияет на повторный фулскан. 2. NEXT в TEMP влияет на скорость большой сортировки. Еще интеремны параметр PCTUSED? 3. Если это загрузка из логов то поставь что-нить около 95%, это должно помочь и поможет. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2002, 13:00 |
|
большая таблица
|
|||
---|---|---|---|
#18+
"В том то и дело что индексов нет, но их нет и в M$, хотелось бы получить все таки, хотя бы равный результат". Хорошо, раз на то пошло. Слушай мою историю про переход с Windows на RH Linux. Я скачал дистрибутив RH Linux 7.3, тупо через инсталлятор поставил Linux, потом поставил Oracle. Перенёс базу. Для проверки сравнительного быстродействия, после установки на RH Linux я выполнял задачу, которая ранее на Oracle под Windows выполнялась где-то 1 час. Под Linux эта задача выполнялась более 2(двух) с половиной часов. Я думаю, ты понимаешь мои ощущения на том момент? Я думаю они были куда сильнее чем в твоём случае. Так вот, для того что-бы исправить такую неприятную ситуацию, я произвёл множество манипуляций, связанных с оптимизацией ядра Linux, оптимизацией дисковой системы I/O, пересмотром параметров инициализации Oracle. В результате всех манипуляции время выполнения задачи стало 15 минут!!! Это время показала база сразу после рестарта. Реально же при долгой непрерывной работы с базой, тест показал 48минут. Так режим теста и режим обычной регулярной работы отличается использованием обьектов БД. Но если всё же говорить о 2 часах, они именно соотносятся с 15 минутами. Поэтому что я могу сказать не надо искать простых решений. Надо искать оптимальные. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2002, 13:07 |
|
большая таблица
|
|||
---|---|---|---|
#18+
>1. Размер не вообще SGA, а резмер db_block_buffers и он влияет на повторный фулскан. Это справедливо только для маленьких таблиц. Для 44млн. записей - наврядли ... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2002, 13:08 |
|
большая таблица
|
|||
---|---|---|---|
#18+
Ок, спасибо всем, буду рыть дальше ... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2002, 14:08 |
|
большая таблица
|
|||
---|---|---|---|
#18+
2Killed: >>1. Размер не вообще SGA, а резмер db_block_buffers >>и он влияет на повторный фулскан. >Это справедливо только для маленьких таблиц. Для >44млн. записей - наврядли Маленький и большой понятия согласись весьма растяжимые, и 44 млн это тоже и не мало и не много, может у него записи по 10 байт :) Хотя даже если так, на 512 метрах далеко не уедешь... ... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2002, 18:41 |
|
большая таблица
|
|||
---|---|---|---|
#18+
даже с учетом 10 байтной строки (что маловероятно) - это нужно перелопатить около 400Мб данных при FULL SCAN'e. Но дело не в этом, даже если человек увеличит кэш-буффер до 2Гб, то скорость полного сканирования при повторных операциях не увеличится, поскольку блоки таблицы не будут кэшироваться. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2002, 21:01 |
|
большая таблица
|
|||
---|---|---|---|
#18+
>Но дело не в этом, даже если человек увеличит >кэш-буффер до 2Гб, то скорость полного >сканирования при повторных операциях не >увеличится, поскольку блоки таблицы не >будут кэшироваться. Если можно здесь поподробнее. Почему они не будут кэшироваться? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.10.2002, 09:24 |
|
большая таблица
|
|||
---|---|---|---|
#18+
При полном табличном сканировании используется лишь несколько буферов кэш-буфера с LRU-конца списка. Подозреваю, что их число равно db_file_mutliblock_read_count. Сделано это для того, чтобы FULL SCAN не размывал кэш, поскольку вероятность повторного использования блоков при этой операции низка. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.10.2002, 09:49 |
|
|
start [/forum/topic.php?fid=52&msg=32059789&tid=1992880]: |
0ms |
get settings: |
10ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
27ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
55ms |
get tp. blocked users: |
1ms |
others: | 250ms |
total: | 376ms |
0 / 0 |