#oracle #datatable
#Oracle #datatable
Вопрос:
Я пытаюсь сделать прогноз роста для некоторых имеющихся у меня таблиц, и для этого мне нужно выполнить некоторые вычисления для моих размеров строк, сколько строк я генерирую за день и хорошо.. математика.
Я вычисляю средний размер каждой строки в моей таблице как сумму среднего размера каждого поля. Итак, в основном:
SELECT 'COL1' , avg(vsize(COL1)) FROM TABLE union
SELECT 'COL2' , avg(vsize(COL2)) FROM TABLE
Суммируйте это, умножьте на количество записей за день и обрабатывайте прогнозы, исходя из этого.
Оказывается, что для одной из таблиц, которые я просмотрел, результирующий размер намного меньше, чем я думал, и заставил меня задуматься, был ли мой метод правильным.
Кроме того, я не учитывал размеры индексов для своих прогнозов — и, конечно, я должен.
Мои вопросы:
-
Надежен ли этот метод, который я использую?
-
Советы о том, как я мог бы обработать прогнозы для индексов?
Я поискал в Google, но все методы, которые я нахожу, касаются сегментов и расширений, или же вычислений, основанных на всей таблице. Для выполнения прогнозов мне понадобится шаг с фактической строкой моей таблицы (я должен проанализировать данные в таблице, чтобы подсчитать, сколько записей в день).
И, наконец, это приблизительное значение. Я знаю, что мне не хватает некоторых байтов здесь и там из-за накладных расходов и прочего. Я просто хочу убедиться, что мне не хватает только байтов, а не гигабайт 🙂
Комментарии:
1. Смотрите также dba.stackexchange.com/questions/23147/estimate-a-database-size
Ответ №1:
1) Ваш метод хорош для вычисления среднего размера строки. (Хотя имейте в виду, что если ваш столбец содержит null, вам следует использовать avg(nvl(vsize(col1), 0))
вместо avg(vsize(COL1))
). Однако это не учитывает физическое расположение строк.
Прежде всего, это не учитывает информацию заголовка (как из блоков, так и из строк): вы не можете поместить 8k данных в 8k блоков. Смотрите документацию по формату блока данных для получения дополнительной информации.
Затем строки не всегда хранятся аккуратно упакованными. Oracle оставляет некоторое пространство в каждом блоке, чтобы строки могли увеличиваться при их обновлении (регулируется pctfree
параметром). Также, когда строки удаляются, пустое пространство не освобождается сразу (если вы не используете ASSM с локально управляемыми табличными пространствами, количество свободного места, необходимое для возврата блока в список доступных блоков, зависит от pctused
).
Если у вас уже есть некоторые репрезентативные данные в вашей таблице, вы можете оценить объем дополнительного пространства, который вам понадобится, путем сравнения физически используемого пространства ( all_tables.blocks*block_size
после сбора статистики) со средней длиной строки.
Кстати, Oracle может легко дать вам хорошую оценку средней длины строки: соберите статистику по таблице и запросите all_tables.avg_row_len
.
2) В большинстве случаев (читай: если нет ошибки или вы не прибегаете к нетипичному использованию индекса) индекс будет расти пропорционально количеству строк.
Если у вас есть репрезентативные данные, вы можете получить хорошую оценку их будущего размера, умножив их фактический размер на относительный рост числа строк.
Ответ №2:
В последний раз Oracle публиковала свои формулы для оценки размера объектов схемы в Oracle 8.0, что означает, что связанный документ устарел на десять лет. Однако я не ожидаю, что в том, как Oracle резервирует информацию заголовка сегмента, блока или строки, изменилось не так уж много.
Комментарии:
1. Рекомендации по оценке использования пространства доступны и для более новых версий, например, в Руководстве администратора для версии 11.2 предлагается использовать DBMS_SPACE. CREATE_TABLE_COST , который освобождает вас от некоторых вычислений вручную.