CftClub.ru
Клуб специалистов ЦФТ-Банк

чистка и архивация таблиц в РБО
На страницу 1, 2  След.
 
Ответить на тему    Клуб специалистов ЦФТ-Банк (IBSO) -> Oracle DBA
Предыдущая тема :: Следующая тема  
Автор Сообщение
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    Ответить с цитатой
Полезность: Нет оценки
kai пишет:
...

Спасибо, что подключились к теме!
dimka8
Участник


Вступление в Клуб: 30.01.2019
СообщениеСр Фев 13, 2019 01:37    Ответить с цитатой
Полезность: Нет оценки
Эмиралька пишет:
kai пишет:
...

Спасибо, что подключились к теме!

но очень жаль что не смогли внести никакой конкретики: ни вырезки из документации, ни списка таблиц из личного опыта/практики

Crying or Very sad
kai
Профи


Вступление в Клуб: 16.08.2012
СообщениеПт Фев 15, 2019 14:10    Ответить с цитатой
Полезность: 1
dimka8 пишет:
но очень жаль что не смогли внести никакой конкретики: ни вырезки из документации, ни списка таблиц из личного опыта/практики

Crying or Very sad


список таблиц ? Так я уже внёс её в приложение МЖЦД 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 лет работал).

Что ещё-то, дальше рекламировать приложение? Ну, посмотрите, пожалуйста Idea

Цитата:
ни вырезки из документации

к приложению есть документация со всеми идеями.
Но без ознакомления 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
СообщениеСр Фев 27, 2019 14:51    Ответить с цитатой
Полезность: Нет оценки
Обновили архив приложения МЖЦД https://support.cft.ru/api/v1/ru/systems/cft_orm_adm/files/dist?filePath=arc_2_0.zip

Внутрь добавлен архив size_of_objects.7z с запросами по вычислению размеров табличных пространств, таблиц и пр. (size_of_objects.sql).
Показать сообщения:   
Ответить на тему    Клуб специалистов ЦФТ-Банк (IBSO) -> Oracle DBA Часовой пояс: GMT + 3
На страницу 1, 2  След.
Страница 1 из 2

 
Перейти:  
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Рейтинг@Mail.ru