чистка и архивация таблиц в РБО
На страницу 1, 2 След.
|
Предыдущая тема :: Следующая тема |
Автор |
Сообщение |
dimka8 Участник
Вступление в Клуб: 30.01.2019
|
Чт Янв 31, 2019 03:29  чистка и архивация таблиц в РБО |
|
Полезность: Нет оценки
|
Приветствую,
коллеги, может кто написать список табличек данные в которых вы регулярно чистите? Ну или переносите частично в архив по принципу "не надо, но пусть на всякий случай будет" )
Если поделитесь инструкциями от ЦФТ на этот счет буду тоже благодарен.
PS
вот список самых больших таблиц для затравки:
Код: | Z#CARD_REE_FIELDS
Z#DOC_IN_FOLD
Z#CL_CHECK_RESULT
Z#JOURNAL_SALDO
Z#PLAN_OPER
Z#VEX_F135
Z#FOLDER_PAY
Z#REPS_CR_IN_PORT
Z#VEX_OVERDUE_DEBT
Z#STRING_CALC_PRC
Z#VEX_SMS_INF_TAGS
Z#PLAN_OPER_HIST
Z#APP_ERROR
Z#VAL_TUNING
Z#KB_HISTORY_REQ
Z#CALL_OPER_PARAM
Z#VZ_REQUEST
Z#PC_RESP
Z#VZ_RESPONSE
Z#CARD_REE_RECORDS
XML_DOCUMENT
Z#PROPERTY
Z#VEX_SMS_INF_MSG
Z#VEX_INFO_REQ
Z#VZ_PAYMENTS
Z#CIT_IN_REQUEST
Z#IP_CHANGE_LA
Z#VZ_PAYM_RESP
Z#CARD_REE_LINE
Z#REPS_DEPN_DATA
Z#F_CREDS_ACC_DEBT
Z#REPS_ACC_TYPE
Z#HOZ_OP_ACC
Z#KB_RECORD
Z#IP_TRANSACTION
Z#OWS_TRANSACTION
Z#JOUR_RATE_QUOTA
Z#HISTORY_STATES
Z#CL_HIST
Z#CONTACTS
Z#CIT_OUT_REQUEST
Z#VZ_ISS_APPL
Z#KB_EVENTS_2ARCH
Z#IP_CONTAINER
Z#F_133_DATA
Z#VZ_ISS_APPL_RES
Z#VEX_REESTR_PROV
Z#DOC_RICHES
Z#GR_TUNINGS
Z#CERT_INVALID
Z#ACCOUNT
Z#BC_MAP_DOC
Z#SUM_SYMKS
Z#CERT_RICHES
Z#F_133_DOP_DATA
Z#VEX_OVERDUE_CRED
Z#AC_FIN
Z#REPS_STORAGE
Z#VEX_OVERDUE_CL
Z#F_CREDS_DATA
Z#DOC_QUEUE
Z#VEX_CRED_CARD
Z#CASH_IN_REQ
Z#CASH_IN_REPLY
Z#VEX_IK_REQ_CONT
Z#DOC_OPER
Z#VZ_BALANCE |
|
|
 |
ykrasutskiy Участник
Вступление в Клуб: 05.10.2018
|
Чт Янв 31, 2019 07:59   |
|
Полезность: Нет оценки
|
Для документов карточной подсистемы есть встроенные инструменты очистки, остальным пока не занимался, но тоже придется озадачиваться рано или поздно... |
|
 |
dimka8 Участник
Вступление в Клуб: 30.01.2019
|
Чт Янв 31, 2019 09:51   |
|
Полезность: Нет оценки
|
ykrasutskiy пишет: | Для документов карточной подсистемы есть встроенные инструменты очистки |
не подскажите у их таблиц какой-то префикс есть конкретный? |
|
 |
Эмиралька Эксперт
Вступление в Клуб: 09.11.2015
|
Чт Янв 31, 2019 12:47   |
|
Полезность: Нет оценки
|
dimka8 пишет: | ykrasutskiy пишет: | Для документов карточной подсистемы есть встроенные инструменты очистки |
не подскажите у их таблиц какой-то префикс есть конкретный? |
Про партификацию от ЦФТ знаете? Не подходит? |
|
 |
dimka8 Участник
Вступление в Клуб: 30.01.2019
|
Пт Фев 01, 2019 02:40   |
|
Полезность: Нет оценки
|
знаю.
Но давайте вместе подумаем. Вот например таблица Z#APP_ERROR - в ней десятки миллионов записей за 8 лет. Мне ее партиционировать или удалить все что старше года и сжать?
Маленькая таблица и маленькие индексы на ней гарантировано дадут уменьшение логических чтений по сравнению с большой. А партиционирование далеко не всегда даст выигрыш в производительности, а может даже ухудшить ситуацию. |
|
 |
Alkov Профи
Вступление в Клуб: 23.09.2010
|
Пт Фев 01, 2019 05:06   |
|
Полезность: Нет оценки
|
А какая первопричина, что заставило думать в этом направлении ?
Места нехватат или запросы тормозят ? |
|
 |
kai Профи
Вступление в Клуб: 16.08.2012
|
Чт Фев 07, 2019 18:12   |
|
Полезность: 2
|
dimka8 пишет: | Но давайте вместе подумаем. Вот например таблица Z#APP_ERROR - в ней десятки миллионов записей за 8 лет. Мне ее партиционировать или удалить все что старше года и сжать?
Маленькая таблица и маленькие индексы на ней гарантировано дадут уменьшение логических чтений по сравнению с большой. А партиционирование далеко не всегда даст выигрыш в производительности, а может даже ухудшить ситуацию. |
1. При секционировании в приложении МЖЦД предлагается неуникальные индексы сжимать. Уникальные - нет, так как ловили ORA-600. Но и сжатие данных и неуникальных индексов пока "не приживается", dba относятся к нему с опаской из-за возникавших проблем. Окончательные выводы делать рано - мало наблюдений.
2. Насчёт оптимизации запросов. Да, Том Кайт говорит (13-ая глава в его книге от 2016г.), что для OLTP-систем выигрыша в производительности SQL запросов ждать не нужно, потому как запросы выбирают одиночные записи. Но с другой стороны, немаловажную роль при выполнении запросов играет (как говорят в Oracle) "репрезентативная" статистика. А теперь представьте, большая медленнорастущая таблица. Как статистика по ней собирается? В отведенное тех / окно (не обязательно простой - просто окно, как ограниченный промежуток). И для того, чтобы успеть собрать по большой таблице статистику указывают процент данных от всего объема таблицы (по умолчанию 10%). Теперь вопрос: если вы заархивируете от 50% до 80% данных, по архивным секциям вы сможете собрать полностью статистику 1 раз и не собирать до следующей архивации - следующего добавления в секцию данных (а то и только по новой секции). А в актуальной секции у вас останется от от 20% до 50% данных. В актуальной секции меньше данных, значит больший процент может быть проанализирован. В результате статистика по таблице станет более репрезентативной. И для запросов появится предпосылка работать лучше.
Чтобы снизить риски от непредвиденного ухудшения выполнения запросов, рекомендуется собрать информацию о выполняющихся запросах до и после секционирования. |
|
 |
kai Профи
Вступление в Клуб: 16.08.2012
|
Чт Фев 07, 2019 18:15   |
|
Полезность: 1
|
Alkov пишет: | А какая первопричина, что заставило думать в этом направлении ?
Места нехватат или запросы тормозят ? |
большая БД - это не только место для неё самой, но и для копий.
Больше времени для создания бэкапов.
Это повышает риски, когда из-за невозможности сделать копию и проверить какие-то изменения, эти изменения ставятся сразу на пром (( |
|
 |
Эмиралька Эксперт
Вступление в Клуб: 09.11.2015
|
Пт Фев 08, 2019 09:03   |
|
Полезность: Нет оценки
|
Спасибо, что подключились к теме! |
|
 |
dimka8 Участник
Вступление в Клуб: 30.01.2019
|
Ср Фев 13, 2019 01:37   |
|
Полезность: Нет оценки
|
Эмиралька пишет: |
Спасибо, что подключились к теме! |
но очень жаль что не смогли внести никакой конкретики: ни вырезки из документации, ни списка таблиц из личного опыта/практики
 |
|
 |
kai Профи
Вступление в Клуб: 16.08.2012
|
Пт Фев 15, 2019 14:10   |
|
Полезность: 1
|
dimka8 пишет: | но очень жаль что не смогли внести никакой конкретики: ни вырезки из документации, ни списка таблиц из личного опыта/практики
 |
список таблиц ? Так я уже внёс её в приложение МЖЦД https://support.cft.ru/api/v1/ru/systems/cft_orm_adm/files/dist?filePath=arc_2_0.zip там и дока есть, и запрос, взятый отсюда
http://oracle-core-dba.blogspot.com/2008/01/cool-scripts-for-daily-dba-activities.html, который формирует список таблиц с их размерами, размерами индексов. Далее составил запросы к словарю ТЯ, повзоляющие найти связанные таблицы. Все их оформил в представления для просмотра, заходите, смотрите, группируйте их по "вторичным половым". Группы могут быть объеденены в иерархию и включены именованный набор групп (типа профиль настроек в обязательной отчётности, я же там более 10 лет работал).
Что ещё-то, дальше рекламировать приложение? Ну, посмотрите, пожалуйста
Цитата: | ни вырезки из документации |
к приложению есть документация со всеми идеями.
Но без ознакомления 13-ой главы Тома Кайта не рекомендую даже близко подходить =) //шутка//
В операциях архивации, кстати, технологию проработали. Теперь знаем, как сделать, чтобы они работали в несколько потоков, и для этого не требовалось бы приобретать "менеджер параллельных процессов" (запускается либо руками, либо чем-то своим). |
|
 |
kai Профи
Вступление в Клуб: 16.08.2012
|
Вт Фев 19, 2019 06:58  Составление списка таблиц |
|
Полезность: Нет оценки
|
Прежде чем работать со списком таблиц его нужно проверить и актуализировать. И кто-то должен взять на себя ответственность за его состав. По группе дистрибутивных ТБП - ЦФТ, локальных - банк. По группе локальных, связанных с дистрибутивными - (кто ???) здесь могут быть любые варианты.
Список составлять несложно. Самая большая сложность - это организовать его согласование и обсуждение между коллегами, между разработчиками и технологами, и пр. А также чтобы предмет обсуждения всем был понятен. Как это сделать? Для этого справочники и существуют: DLC_TABLE - для общего списка таблиц (в нём выбираем кандидатов для секционирования по размерам), PART_CLASS - составляем группу взаимосвязанных ТБП.
И я бы выделил 3 уровня поиска взаимосвязей: физический и 2 логических. По констрейнтам в словаре Oracle dba может выявить физические связи. По словарю ТЯ дополнительно можно выявить связанные массивы. Но чтобы картина о целостности данных была полной, нужно учесть ещё и бизнес логику приложений. А кто её знает? Только технологи и аналитики (в банке и в продуктовой дирекции, ответственной за разработку этих ТБП в ЦФТ).
Представления для просмотра из моего предыдущем сообщения позволят сделать настройку в 1-ом приближении - найти констрейнты и массивы.
Добавляем запись в справочник в PART_CLASS и заходим в "массивы":
1. Информация о классе
2. Колонки ссылок и массивов
3. -> из составных реквизитов
4. Ссылающиеся массивы
5. Колонки дат
Информация в этих массивах хранится либо в словаре Oracle, либо в словаре ТЯ - самостоятельно её вносить не нужно.
Эту информацию и используем для поиска связанных ТБП. Очередность - это уровень в иерархии связей.
Когда архивируем данные в какой таблице, то связанные через массивы нужно тоже обязательно архивировать.
"Колонки дат" используются для определения критерия устаревания данных. |
|
 |
dimka8 Участник
Вступление в Клуб: 30.01.2019
|
Вт Фев 19, 2019 09:29   |
|
Полезность: Нет оценки
|
спасибо ,архив бы весьма познавательным.
В том, то и беда: я как ДБА могу выкатить список больших и быстрорастущих таблиц. А вот что из них удалять и по каким критериям это вопрос уже не ко мне.
Мы бы пошли по более простому варианту - удалять регулярно из "буферных" таблиц "все старое". А партиционировать это уже следующий уровень. |
|
 |
kai Профи
Вступление в Клуб: 16.08.2012
|
Чт Фев 21, 2019 07:51   |
|
Полезность: 1
|
dimka8 пишет: | Мы бы пошли по более простому варианту - удалять регулярно из "буферных" таблиц "все старое". А партиционировать это уже следующий уровень. |
При удалении из простой таблицы больше 50% - 70% эффективнее пересоздавать таблицу по create table as select (CTAS).
Внесите свою таблицу в справочник "Усечение. 1. Таблицы" TRUNCATE_TABLE, пропишите правило выбора записей, которые хотите оставить (допустимы 2 переменные :DATE и :DEGREE) и запустите соответствующую для удаления операцию.
Повторюсь, важно, что сначала вы определяетесь, где что будете делать. А результаты анализа и настроек в справочниках позволят вам управлять процессом регулярной чистки, преобразований простых таблиц в секционированные, архивации в них данных. |
|
 |
kai Профи
Вступление в Клуб: 16.08.2012
|
|
 |
|
|
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете голосовать в опросах
|
|