Compress for oltp oracle что это
Обновлено: 06.07.2024
Размеры баз данных постоянно растут. Как следствие, в последние годы сжатие (компрессия) данных нашло широкое применение. Часто возникает необходимость оценить реальный размер данных, хранимых в базе, а также степень их сжатия после компрессирования. В то же время, измерения объёма информации, основанные на использовании представлений DBA_SEGMENTS (и подобных) не позволяют получить точные результаты.
Предлагаемая читателю заметка рассказывает об использовании пакета DBMS_SPACE, выдающего точную информацию о реальном объёме данных в сегментах до и после сжатия.
Прежде чем мы продолжим, я хотел бы привести строки из Евангелия:
. == Книга Екклезиаста == .
=== Глава 12, Стих 13 ===
13 Выслушаем сущность всего: бойся Бога и заповеди Его соблюдай, потому что
в этом все для человека;
14 ибо всякое дело Бог приведет на суд, и все тайное, хорошо ли оно, или
худо.
Лично для вас благая весть - Единородный Сын Божий Иисус Христос любит вас, Он взошёл на крест за ваши грехи, был распят и на третий день воскрес, сел одесную Бога и открыл нам дорогу в Царствие Небесное.
Но сможем ли мы пройти по этой дороге? Ведь каждый из нас грешен, даже если мы и не знаем о Божьем законе и Его слове. Даже если кто-то специально отгораживается от имени Иисуса мирскими заботами, властью, деньгами и нарочно не даёт себе возможности открыть Библию и обратиться к слову Божию - но сказано "всякое дело Бог приведет на суд". И будет суд этот страшен, и не сможешь "договориться", "решить вопрос", "спустить на тормозах" - всё то, что узнал и приобрёл в жизни своей - станет в один момент бесполезным.
И одна будет у нас зашита - Иисус Христос, одно оправдание - соблюдение заповедей Божиих, и одно упование - на милость Господню, которую надо заслужить покаянием, верой и делами добрыми в угоду Отцу нашему небесному.
Покайтесь, примите Иисуса как вашего Спасителя, ибо наступают последние времена и время близко - стоит Судья у ворот.
Пожалуйста, в своих каждодневных трудах, какими бы занятыми вы себе ни казались - находите время для Бога, Его заповедей и Библии.
На главной странице этого сайта вы найдете программу для чтения Библии в командной строке - буду очень рад если программа окажется полезной. Пожалуйста, читайте Библию, на экране или в печатном виде - вы будете искренне удивлены как много там сказано лично про вас и ваши обстоятельства.
Вернёмся к нашим техническим деталям.
Мы рассмотрим простой пример - изначально маленькая таблица с большим размером экстента. Такой подход применяется в хранилищах данных, где используются большие размеры блока и экстента, для облегчения администрирования и более эффективного и рационального хранения данных. Наша таблица будет иметь экстент размером 16 Мб.
Создание тестовой таблицы
Создадим таблицу в соответствии с заданными выше требованиями:
Таблица имеет всего две с половиной тысячи строк, занимает два экстента данных по 8Мб (или 1024 блока данных) каждый. Очевидно, что наша база использует блок данных с размером 8Кб. Наверняка в единственном сегменте нашей таблицы имеется огромное количество пустого места - проверим это. Сначала соберём статистику.
Уже сразу заметны расхождения. Таблица содержит в себе всего лишь 2673 строки, по 122 байта каждая - это 326106 байт, почему же мы видим 68 использованных блоков (то есть 557056 байт)? Не говоря уже о том, что на самом деле для таблицы T1 Ораклом выделено два экстента - целых 16 Мб (правда, по нашему требованию).
Какому же результату нам доверять? Запрос к DBA_SEGMENTS показывает размер таблицы T1 равным 16 Мб, представление DBA_TABLES утверждает, что таблица содержится в 68 блоках данных размером 544 Кб, а статистика говорит о 318 Кб (2673 строки по 122 байта):
Ответ прост - все значения верны, но эти представления показывают результаты разных вычислений для разных целей. DBA_SEGMENTS даёт нам возможность оценить сколько дискового пространства понадобится для всей таблицы / схемы / базы с учётом выбранных параметров хранения (storage). DBA_TABLES даёт нам число занятых блоков с данными таблицы T1, а статистика - правильное число записей (и приблизительный размер собственно данных в таблице). Эти цифры используются оптимизатором запросов Оракл и могут быть полезны администраторам для быстрой оценки размера дисковой памяти и тенденций её изменения.
Но ни один из этих результатов не подходит для точного вычисления объёма собственно данных пользователя в таблице T1.
Измерение действительного обьёма данных, до сжатия
Учитывая необходимость вычисления как можно более точного коэффициента сжатия данных, мы используем пакет DBMS_SPACE:
Вот это новость - таблица T1 содержит ровно 400 Кб пользовательских данных - не 16 Мб, не 544 Кб и не 318 Кб. Естественно, использование любого метода, не основанного на DBMS_SPACE, выдало бы нам значительно заниженные или завышенные значения степени сжатия нашей таблицы.
Пакет DBMS_SPACE выдаёт точные данные, поскольку он в состоянии учитывать текущую позицию High Water Mark для таблицы T1. В нашем примере таблица T1 не содержит частично заполненных блоков, таким образом значения fs1_bytes . fs4_bytes равны нулю и не учитываются. В реальной ситуации все эти значения надо суммировать.
Сжатие данных
Мы будем использовать одну из платных опций Oracle Enterprise Edition - OLTP Compression. Такое сжатие подходит для динамически изменяемых объектов. Бесплатная BASIC Compression эффективно работает только с данными "для чтения". Естественно, я предполагаю что вопросы лицензирования Оракл решены и у вас имеются все необходимые лицензии.
Прежде чем сжимать таблицу T1, убедимся что она имеет значение PCT_FREE равное 10% (по умолчанию) - именно это значение будет использовано для OLTP сжатия.
Как видно, таблица была перемещена в два новых экстента, начинающихся с других блоков. Насколько же уменьшились в объёме данные пользователя в нашей таблице?
Измерение действительного обьёма данных, после сжатия
Используем тот же самый скрипт с пакетом DBMS_SPACE:
Уменьшение обьёма данных пользователя значительно - 3.84 раза. Но это именно данные. Что же произошло с самой таблицей и какой коэффициент сжатия мы бы получили без использования пакета DBMS_SPACE? Мы уже знаем, что таблица по-прежнему расположена в двух экстентах. Проверим что покажут запросы к DBA_SEGMENTS и статистика.
Что же мы видим? Факт уменьшения данных зафиксирован только в одном месте - колонка BLOCKS представления DBA_TABLES уменьшила свое значение с 68 до 31. Но даже в этом случае мы получили в два раза заниженное значение степени сжатия данных. Это обьясняется тем, что представление DBA_TABLES не отслеживает значения High Water Mark для нашего сегмента T1. Таким образом, для оценки степени сжатия данных единственно верное средство - пакет DBMS_SPACE.
Измерение действительного обьёма данных для всех таблиц схемы
Используемый нами скрипт работает для одной таблицы. Что же делать, если нам необходимо определить степень сжатия для всей схемы целиком, включающей сотни таблиц, секций и подсекций (partitions и subpartitions)?
Приведенный ниже скрипт позволит вам произвести такие вычисления. Обратите внимание - пакет DBMS_SPACE надо использовать только в периоды минимальной нагрузки на вашу базу данных! Подразумевается что сегменты используют Automatic Segment Space Management.
Использовать скрипт просто - предположим, я хочу оценить реальный размер данных в схеме SOE, используемой программой Swingbench:
Проверим для сравнения, какой результат администратор базы данных получит "обычным" способом:
Разница составила 35 процентов и продемонстрировала нам, что широко используемые сегодня способы измерения размера базы значительно завышают реальный объём данных. Это вполне приемлемо при планировании закупок дополнительных дисков, но не подходит для анализа и реорганизации данных в больших хранилищах, где каждый гигабайт имеет реальную достаточно высокую цену.
Посмотрим глазами Enterprise Manager'а
Пакет DBMS_SPACE имеет недокументированную процедуру "OBJECT_SPACE_USAGE", позволяющую выполнить те же действия и используемую Enterprise Manager'ом. Создадим таблицу заново и проверим, сколько байт найдёт в ней эта функция:
В этом случае наша таблица выглядит ещё меньшей, что можно попытаться обьяснить "таинственным происхождением" и недокументированностью процедуры "OBJECT_SPACE_USAGE". Кроме того, эта процедура может серьёзно мешать работе базы данных - значительно больше, чем просто "DBMS_SPACE.SPACE_USAGE".
И тем не менее, недокументированная функция может нам очень помочь. Что случится если мы удалим строки из таблицы и проверим её размер вновь?
Из этого примера явно видно, что недокументированная процедура, используемая EM, сразу же обнаруживает удаление строк, а "SPACE_USAGE" - только после перемещения (или "shrink space") таблицы. Исходя из практических соображений, ниже я привожу версию скрипта, использующую процедуру "OBJECT_SPACE_USAGE".
Исторические данные за несколько лет. Они используются только для селекта. Таблица разбита на партиции по месяцам.
В таблице полей не более 20. numeric, datetime, char
Одно из полей типа varchar с максимальной длиной 4000 байт, но заполнятся не более 200 байт.
Не могу ответить на этот вопрос. Я не админ. Буду уточнять.
А на что это влияет?
Необходимо обновить varchar строку из 150 байт сократить до 20 байт с помощью update.
Вопрос когда делать компрессию таблицы, до обновления или после?
Необходимо обновить varchar строку из 150 байт сократить до 20 байт с помощью update.
Вопрос когда делать компрессию таблицы, до обновления или после?
Провожу эксперименты с компрессией данных, но пока результат неудовлетворительный. Подскажите, что я делаю не так?
База 11.1.0.7.0. Есть архивная таблица, партиции по месяцам. Партиции лежат по табличным пространствам, 1 год = 1 tablespace.
Я нарезал 3 новых tablespace (на три прошедших года).
Далее для каждой партиции делаю:
alter table XXX move partition YYY tablespace ZZZ compress for all operations;
База 11.1.0.7.0. Есть архивная таблица, партиции по месяцам.
Партиции лежат по табличным пространствам, 1 год = 1 tablespace.
Я нарезал 3 новых tablespace (на три прошедших года).
Далее для каждой партиции делаю:
Да это OLTP, БД для платежной системы. Основная таблица - Платежи + 8 ее сателлитов. Остальное справочники.
Я, конечно, понимал, что Платежи содержат достаточно уникальные данные и сильного чуда от компрессии не ждал. Но полученный результат вообще ни в какие рамки не лезет.
Для каждой своей партицированной таблицы я выполнил эксперимент на одной из партиций со следующей последовательностью команд:
В среднем выигрыш для OLTP - 10-15%, для Basic - 20%;
Худший результат - 2 таблицы после OLTP стали занимать больше места.
Т.е. получается следующая стратегия:
1. Собираем статистику
2. Выбираем из USER_TAB_COLUMNS столбцы с NULLABLE=N
3. Оцениваем значение NUM_DISTINCT. В соответствии с результатом получаем нужный ORDER BY для CTAS
4. Создаем временную таблицу для партиции через CTAS c PCTFREE 0 в NOPARALLEL
5. Делаем EXCHANGE PARTITIONS
Т.е. получается следующая стратегия:
1. Собираем статистику
2. Выбираем из USER_TAB_COLUMNS столбцы с NULLABLE=N
3. Оцениваем значение NUM_DISTINCT. В соответствии с результатом получаем нужный ORDER BY для CTAS
4. Создаем временную таблицу для партиции через CTAS c PCTFREE 0 в NOPARALLEL
5. Делаем EXCHANGE PARTITIONS
спасибо большое.
ORDER BY я не забыл, см. пп. 3
Эксперимент уже провел. Результат на основной таблице улучшился с 15% до 46%. Т.е. сжал партицию почти в 2 раза.
Забавно, что в документации ORACLE обещает 3-4 кратное сжатие на любых данных.
ибо не стоит жать хорошо-спроектированную OLTP систему.
ей и так тяжело!
В плане сжатия данных в Oracle Database нет ничего нового, но в релизе 11g эта функциональность принимается на новый уровень в связи с появлением возможностей усовершенствованного (Advanced) сжатия и гибридного сжатия столбцов (Hybrid Columnar Compression)
Усовершенствованное сжатие (Advanced Compression)
Сжатие не является чем-то новым для Oracle; эта функциональность появилась в Oracle9i Database в формате COMPRESS BASIC (обычная компрессия).
Сжатие всегда интенсивно использовало CPU и занимало определенное время. Обычно сжатые данные должны быть распакованы перед применением. И если эта необходимость была приемлемой при использовании хранилищ данных, где SQL-запросы обычно обрабатывают большие количества строк и потому большое время отклика обычно терпимо, то в средах OLTP это, возможно, не приемлемо.
Теперь в Oracle Database 11g (но только, если имеется лицензия на опцию Advanced Compression), можно сделать следующее:
Фраза "compress for all operations" ("сжатие для всех операций") включает сжатие при всех DML-операциях, как то: INSERT, UPDATE, etc. Сжатие выполняется при всех DML-действиях, а не только на прямом пути вставки записи, как это было в предыдущих версиях.
Это замедлит DML-операцию? Не обязательно. Это то место, где новая функция работает лучше всего. Сжатие не происходит, когда строка вставляется в таблицу. Напротив, строки вставляются стандартным способом в несжатом виде. Когда же вставлено (или обновлено) несжатым способом определенное число строк, взбрыкивает (kick) алгоритм сжатия и сжимает все несжатые строки в блоке. Другими словами, сжимается блок, а не строка. Порог, при котором совершается сжатие, определен во внутреннем коде RDBMS.
Механизм сжатия
Рассмотрим таблицу ACCOUNTS, записи которой показаны ниже:
Предположим, что в базе данных в каком-то блоке есть все показанные выше строки.
Это — нечто, на что похож несжатый блок: с записями и всеми данными во всех полях (столбцах). Когда этот блок сжимается, база данных сначала вычисляет повторяющиеся значения, найденные во всех строках, вырезает их из строк и помещает их около заголовка блока. Эти повторяющиеся в строках значения заменяются неким символом, который представляет каждое из них. Концептуально это показано на рисунке ниже, где изображен блок до и после сжатия.
Отметим, что значения были вырезаны из строк и вставлены в специальную область наверху "Symbol Table" ("Таблица символов"). Каждому значению в столбцах присваивается символ, который замещает фактические значения в строках. Поскольку такие символы занимают меньше места, чем фактические значения, размеры записей также значительно уменьшаются по сравнению с оригиналом. Чем больше повторяющихся данных имеется в строке, тем более эффективна таблица символов и, следовательно, блок.
Поскольку сжатие — инициируемое событие (но не при вставке строк), то во время обычного DML-процесса воздействие сжатия на производительность — нуль. Когда же сжатие инициировано, конечно, потребность в CPU становится высокой, но в остальное время — нуль, что делает сжатие приемлемой функциональностью для OLTP-приложений. Прямо-таки лакомство (sweetspot), предоставленное сжатием в Oracle Database 11g.
Кроме уменьшения занимаемого пространства, сжатые данные требуют меньше времени для прохождения по сети, используют меньше места при резервном копировании и делают возможной поддержку полных копий производственной базы данных при тестировании и в QA (quality assurance — обеспечение качества).
Гибридное столбцовое сжатие (Hybrid Columnar Compression)
Только Release 2 в Oracle Exadata
В Oracle Database 11g Release 2 (но только, если она предварительно установлена на Oracle Exadata v2) технология сжатия была доведена до уровня Hybrid Columnar Compression (HCC Гибридного Столбцового Сжатия).
Прежде всего, почему потребовалось расширить функциональность сжатия? Причина проста: не для всех данных в базе может быть эффективно применен один и тот же способ поиска. Например, некоторые данные (например, электронная почта компании) должны находиться в базе данных просто по юридическим причинам; они должны быть доступны все время, даже если фактически используются очень редко. Эти данные должны храниться, а хранение стоит денег – диски, питание дисков, охлаждение, занимаемые площади. Поэтому зачем использовать дорогие устройства хранения для данных, которые редко, если вообще когда-либо используются?
Это именно те данные, для которых подходит HCC. Обычно сжатие работает, заменяя повторяющиеся значения символами меньшего объема, тем самым уменьшая потребление пространства. Например, предположим, что строки несжатых данных выглядят так (столбцы разделяются “|”):
Общий размер этих трех записей 264 байта. Заметим, что фактически имеется только шесть различных значений, которые присутствуют несколько раз, в этих трех строках.
Когда этот блок сжимается, каждому индивидуальному значению присваивается специальное обозначение, далее повторяющие его значения заменяются его специальное обозначение. Например, вот присвоенные специальные обозначения:
| Оригинальное значение | Заменяющие символы |
| Quite_a_large_value1 | A1 |
| Quite_a_large_value2 | A2 |
| Quite_a_long_value1 | B1 |
| Quite_a_long_value2 | B2 |
| Another_quite_long_value1 | C1 |
| Another_quite_long_value2 | C2 |
Теперь записи выглядят так:
Общая длина: 32 байта, существенное сокращение по сравнению с прежними 264 байтами, приблизительно на 88%. (Конечно, процент сокращения зависит от данных, в особенности, от наличия различных значений, но принцип — тот же самый.) Отношение между уникальными кодами (A1, A2 и т.д.) и значениями, которые они представляют (“Quite_a_large_value1” и т.д.) сохранено в Symbol Directory (Директория Символов), а также в заголовке блока. Каждый заголовок блока хранит коды, используемые в этом блоке. Естественно, будут повторения, так как одни те же значения повторяются в блоках.
Если посмотреть на реальные данные, то можно заметить, что значения обычно чаще повторяются в столбцах, а не в строках. Например, в столбце FIRST_NAME присутствуют значения John, Jack и т.д., тогда как в другом столбце CITY_NAME находятся New York и Los Angeles. Естественно, что значение New York не ожидается в столбце first_name. Поскольку повторения значений более часто встречаются в столбцах, а не в строках, может быть всего лишь одна директория символов на столбец. И поскольку директории символов также занимают место, значительное сокращение их числа уменьшит общее требуемое пространство по сравнению с традиционным сжатием, где у каждого блока должна быть директория символов.
Hybrid Columnar Compression использует этот метод. Этот метод осуществляет существенное сжатие, но влияет на производительность DML-предложений. Поэтому его лучше всего использовать для табличных запросов, которые не являются DML.
Вот пример создания таблицы:
Фраза “compress” вызывает сжатие (компрессию) таблицы. Фраза “for query” указывает на применение механизма гибридного столбцового сжатия. Фраза “low” задает наиболее мягкое сжатие. При этом занимается больше места, но при сжатии и распаковке используется меньше CPU. Более агрессивное сжатие может быть задано при замене значения "low" на "high". Этот тип HCC известен как сжатие хранилищ данных ( warehouse compression), так как оно полезно в хранилищах данных, где хранится много данных, но они не часто запрашиваются.
Если доступ к таблице очень редкий, то её можно сжать ещё сильнее, используя фразу “for archive”:
Это ещё больше уменьшит использование пространства , но за счет CPU. Так же как в фразе “for query” (“для запроса”), здесь имеется два значения: high (высоко) и low (низко). Это известно как сжатие архива, где к данным нечасто получают доступ. Вот пример коэффициентоов сжатия на наборе презентативных данных. Конечно, коэффициенты будут значительно различаться в зависимости от данных..
Гибридное Столбцовое Сжатие (Hybrid Columnar Compression) позволяет сжимать таблицы, которые не слишком активны в плане DML-обращений к ним, но чьи данные не могут быть отброшены по юридическим или другим причинам. Теперь можно сохранять такие таблицы, используя гораздо меньше места для их хранения, и, возможно, также меньше используя CPU. Отметим еще раз, что эта функциональность доступна только на Oracle Exadata Storage Server v2. Для получения дополнительной информации обратитесь к этому отчету.
Исследование сжатой таблицы Oracle и сжатого табличного пространства
Исследование сжатой таблицы Oracle и сжатого табличного пространства
Иногда мы хотим сохранить данные производственной системы OLTP в исторической базе данных или в хранилище данных для анализа данных (демонстрационные операции происходят редко). В этом случае таблица хранится в исторической базе данных или хранилище данных в сжатом виде. Это хороший выбор, не только может сэкономить место, но и ускорить запрос.
В этой статье рассказывается только о том, как выполнить указанные выше требования, и о том, какие знания охватываются.Если вы хотите узнать больше о сжатых таблицах Oracle и сжатых табличных пространствах, обратитесь к другой информации.
Сжатое табличное пространство, то есть таблицы, созданные в табличном пространстве, по умолчанию являются сжатыми таблицами; есть также несколько типов сжатых табличных пространств, которые реализуются различными предложениями в Create table (Oracle 12.2):
1 TABLE COMPRESS FOR OLTP
Этот режим имеет немного меньшую степень сжатия и должен иметь возможность сжимать любые операции dml, сгенерированные любым способом (требуется подтверждение), и больше подходит для систем OLTP.2 TABLE COMPRESS FOR QUERY < LOW | HIGH >
Этот режим имеет большую степень сжатия и подходит для систем OLAP. Понятно, что операции dml, сгенерированные любым способом, могут быть сжаты.3 СЖАТИЕ ТАБЛИЦЫ ДЛЯ АРХИВА Этот режим аналогичен COLUMN STORE
СЖАТЬ ДЛЯ ЗАПРОСА, но степень сжатия выше, подходит для хранения данных.
(2 и 3 режимы применимы только к EXADATA)
Теперь необходимо провести тест по передаче данных OLTP в сжатую форму.Общий план состоит в том, чтобы создать сжатое табличное пространство в режиме TABLE COMPRESS FOR OLTP в целевой базе данных, а затем перенести данные через насос данных и добавить TRANSFORM = SEGMENT_ATTRIBUTES при импорте: n: table, это предложение игнорирует некоторые метаданные таблицы во время процесса импорта. Без этого предложения таблица не может быть импортирована в сжатой форме, даже если табличное пространство является сжатым табличным пространством.
контрольная работа:
Создайте сжатые и несжатые табличные пространства соответственно:
Создайте пользователей и назначьте их различным табличным пространствам по умолчанию:
Проверьте объем данных после импорта:
22.7g --smc
28.2g --smnc
Вы можете видеть, что данные действительно сжаты, но степень сжатия невысока.
Сравните с конкретными таблицами:
table1
3.8g --smnc
3.0g --smc
table2
2.8g --smnc
1.8g --smc
Видно, что степень сжатия в разных таблицах разная, в основном это зависит от количества повторяющихся данных в таблице.
Давайте сравним эффективность сжатия способа создания сжатой таблицы с оператором build table:
SMNC table1 2,8 г - без сжатия
SMNC table3 1.5g - сжатие в режиме сжатия, указанном в предложении
SMNC table4 1.6g - укажите сжатие ROW STORE COMPRESS ADVANCED с помощью оператора
SMC table1 1.8g - сжато сжатым табличным пространством
Видно, что степень сжатия у разных методов разная.
Среди них в официальном документе говорится, что метод сжатия, указанный в операторе, будет сжимать только оператор, вставленный прямым путем. Давайте проверим, так ли это:
Объем обнаруженных данных составляет 3,8 г, а размер стремится к (2Сжатие) и (1Сжатие + 1 * без сжатия).
Читайте также: