powered by simpleCommunicator - 2.0.44     © 2025 Programmizd 02
Форумы / Oracle [игнор отключен] [закрыт для гостей] / большая таблица
25 сообщений из 31, страница 1 из 2
большая таблица
    #32059763
newer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Oracle 8.1.7 на FreeBSD4.4

Есть таблица на 44 млн. записей

sum(поле) по всей таблице занимает около 250с.

Причем на той же машине W2K + MS SQL2000
давал тот же результат за 210c.
(даже диск один и тот-же)

Я понимаю что у меня что-то в настройках init для базы не так, я в этом деле новичек.

Может подскажет кто-нибудь оптимальные параметры базы, где есть такая таблица.
...
Рейтинг: 0 / 0
большая таблица
    #32059775
.dba
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
а что это единственная задача, которая решается на этой базе?
...
Рейтинг: 0 / 0
большая таблица
    #32059780
newer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
нет, это просто пример, другие запросы тоже длятся дольше
...
Рейтинг: 0 / 0
большая таблица
    #32059789
Alexander Sobyanin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Привет
Для начала надо поставить Оракл на что-нибудь что сертифицированное.
И еще надо хоть примерно знать что за железки в этом сервере, параметры базы текущие, как размещены табличные пространства.
Вообще неизвестных очень много в этом уровнении
...
Рейтинг: 0 / 0
большая таблица
    #32059810
Фотография softy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Реально можно судить где быстрее, а где нет, если ты тестировал этот запрос достаточно много. Если ты один раз этот запрос выполнял, разве можно что-то говорить о достоверности.
Надо изучать план запроса, изучать как Oracle работает с буферами, redo-логами, как настроена система кэширования FreeBSD. Ньюансов очень много.
...
Рейтинг: 0 / 0
большая таблица
    #32059817
newer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Железо для теста, поэтому не очень:
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ки не отличим
...
Рейтинг: 0 / 0
большая таблица
    #32059823
Фотография softy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Слушай , чего ты хочешь от 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
...
Рейтинг: 0 / 0
большая таблица
    #32059909
newer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
за совет спасибо, сделал так , но опять те же 247,3с
...
Рейтинг: 0 / 0
большая таблица
    #32059913
.dba
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
а можно более подробнее:

запрос,
план выполнения,
статистика.
...
Рейтинг: 0 / 0
большая таблица
    #32059921
newer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
таблица это трафик по ип адресам за месяц, накапливается около 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
...
Рейтинг: 0 / 0
большая таблица
    #32059961
Alexander Sobyanin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
1. поставь db_block_multi_read_count = 32
2. создай индекс по ip_id
3. собери статистику dbms_stats.gather_table_stats(...)
4. сделай next для временного пространства побольше (1M), и вообще выложи его если есть возможность на другой винт, можно туда где система
...
Рейтинг: 0 / 0
большая таблица
    #32060185
newer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Так все таки, что же влияет на FULL SCAN , как я понял ни размер SGA, ни db_file_multiblock_read_count, ни NEXT в TEMP
...
Рейтинг: 0 / 0
большая таблица
    #32060189
Фотография softy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
На FULL SCAN влияет быстродействие дисковой системы I/O. А почему может выбираться FULL SCAN вместо скажем индекса при его налчии, это уже другой вопрос. Оптимизатор может решить что чтение таблицы данных более производитьнее чем поиск по индексу.

Но у тебя проблемы не в этом, а как раз в том что индекса то и нет, поэтому используется FULL SCAN.
Сделай индекс как тебе советовали. Я бы еще посоветовал добавить в этот индекс те поля которые ты выбираешь. Тогда данные запроса будут полностью браться из индекса.
...
Рейтинг: 0 / 0
большая таблица
    #32060194
newer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Да это понятно, при поднятии PCI шины до 41,5 скорость ответа увеличалась процентов на 20.

В том то и дело что индексов нет, но их нет и в M$, хотелось бы получить все таки, хотя бы равный результат.
...
Рейтинг: 0 / 0
большая таблица
    #32060196
Фотография softy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Потом ты пытаешься решить проблему слишком просто.
44 млн. записей, как мне кажется это не очень мало.
При таких обьёмах надо использовать какие-то дополнительные средства улучшения быстродействия.
Использовать партииции, кластеры.
В конце концов, можно сделать промежуточную таблицу, которая будет содержать уже просчитанное значение для ip_id.
Вначале запрос будет искать в этой таблице, если когда-либо по данному ip_id уже был поиск, то данные будут. Время будет самое минимальое.
Конечно же необходимо производить отслеживание при добавлении новых данных, что-бы пересчитывать сумму.
Для этого можно использовать триггер, при добавлении в основную таблицу, производить также поиск во вспомогательной и производить update.
Или производить пересчёт всей таблицы скажем в то время когда меньше всего нагрузка.
Другой вариант. Пользователей наверняка как-то можно расгруппировать и разнести их вообще по разным таблицам.

Вобщем вариантов куча.
...
Рейтинг: 0 / 0
большая таблица
    #32060206
Alexander Sobyanin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
>Так все таки, что же влияет на FULL SCAN , как я понял
>ни размер SGA, ни db_file_multiblock_read_count, ни NEXT
>в TEMP
1. Размер не вообще SGA, а резмер db_block_buffers и он влияет на повторный фулскан.
2. NEXT в TEMP влияет на скорость большой сортировки.
Еще интеремны параметр PCTUSED?
3. Если это загрузка из логов то поставь что-нить около 95%, это должно помочь и поможет.
...
Рейтинг: 0 / 0
большая таблица
    #32060211
Фотография softy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
"В том то и дело что индексов нет, но их нет и в 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 минутами.
Поэтому что я могу сказать не надо искать простых решений. Надо искать оптимальные.
...
Рейтинг: 0 / 0
большая таблица
    #32060213
Фотография killed
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
>1. Размер не вообще SGA, а резмер db_block_buffers и он влияет на повторный фулскан.

Это справедливо только для маленьких таблиц. Для 44млн. записей - наврядли
...
Рейтинг: 0 / 0
большая таблица
    #32060242
newer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Ок, спасибо всем, буду рыть дальше
...
Рейтинг: 0 / 0
большая таблица
    #32060431
Alexander Sobyanin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
2Killed:
>>1. Размер не вообще SGA, а резмер db_block_buffers
>>и он влияет на повторный фулскан.

>Это справедливо только для маленьких таблиц. Для >44млн. записей - наврядли

Маленький и большой понятия согласись весьма растяжимые, и 44 млн это тоже и не мало и не много, может у него записи по 10 байт :) Хотя даже если так, на 512 метрах далеко не уедешь...
...
Рейтинг: 0 / 0
большая таблица
    #32060472
Фотография killed
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
даже с учетом 10 байтной строки (что маловероятно) - это нужно перелопатить около 400Мб данных при FULL SCAN'e. Но дело не в этом, даже если человек увеличит кэш-буффер до 2Гб, то скорость полного сканирования при повторных операциях не увеличится, поскольку блоки таблицы не будут кэшироваться.
...
Рейтинг: 0 / 0
большая таблица
    #32060538
Alexander Sobyanin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
>Но дело не в этом, даже если человек увеличит
>кэш-буффер до 2Гб, то скорость полного
>сканирования при повторных операциях не
>увеличится, поскольку блоки таблицы не
>будут кэшироваться.

Если можно здесь поподробнее.
Почему они не будут кэшироваться?
...
Рейтинг: 0 / 0
большая таблица
    #32060548
Фотография killed
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
При полном табличном сканировании используется лишь несколько буферов кэш-буфера с LRU-конца списка. Подозреваю, что их число равно db_file_mutliblock_read_count. Сделано это для того, чтобы FULL SCAN не размывал кэш, поскольку вероятность повторного использования блоков при этой операции низка.
...
Рейтинг: 0 / 0
большая таблица
    #32060617
ora600
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
alter table ... cache ? :-)
...
Рейтинг: 0 / 0
большая таблица
    #32060619
Фотография killed
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
для 44 млн. ? ;-)
...
Рейтинг: 0 / 0
25 сообщений из 31, страница 1 из 2
Форумы / Oracle [игнор отключен] [закрыт для гостей] / большая таблица
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]