Shrink БД TSM


В этой теме 9 ответов, 4 участника, последнее обновление Картинка профиля Demetrio Demetrio 11 мес., 1 неделя назад.

Aliexpress INT
  • Автор
    Сообщения
  • #39007
    Картинка профиля pavliga
    pavliga
    Участник
    Aliexpress INT

    Приветствую.

    Версия TSM Server 7.1.1.300

    До определенного момента использовал технологию клиентской дедупликации+сжатие. Значительно вырос размер БД с 50 до 250 Гб. В ходе эксплуатации стало понятно, что сервер не вытягивает по ресурсам и начинает упираться в memory и IO disk + недостаточно дисковых емкостей в deduplication stgpool. Выполнил миграцию всех данные из deduplication stgpool на ленты и отказался от дедупликации и сжатия. Размер БД про прежнему ~250Гб.

    Вопрос: существуют ли какие-то варианты выполнить сокращение (уменьшение, сжатие) БД TSM? Возможно в DB2 похожий подход как в Oracle и размер БД после высвобождения табличных пространств не уменьшается без специальной процедуры shrink’а.

  • #39008
    Картинка профиля Oldnick
    Oldnick
    Участник
  • #39011
    Картинка профиля pavliga
    pavliga
    Участник

    Интересно получается. Может я что-то не понял в статье. Или пока не разобрался в механизме работы DB2.

    В TSM настроена Online Table and Index reorganisation, выполняется исправно.

    Tablename                      Last Reorg
    —————————— ———-
    TSMMON_STATUS                  2016-08-09
    BF_SUPER_AGGREGATES            2016-08-09
    GUIL2_ALLCLI_GRID              2016-08-07
    BACKUP_OBJECTS                 2016-08-06
    BF_AGGREGATED_BITFILES         2016-08-05
    BF_BITFILE_EXTENTS             2016-08-05
    BF_AGGREGATE_ATTRIBUTES        2016-08-05
    AS_SEGMENTS                    2016-08-05
    AF_SEGMENTS                    2016-08-03
    AF_BITFILES                    2016-08-03
    ACTIVITY_SUMMARY               2016-08-03
    ACTIVITY_LOG                   2016-08-03
    NODES                          2016-02-10
    TSMMON_ALERT_TRIGGER           2015-11-28

    Indices for Tablename Last Reorg
    —————————— ———-
    SCHEDULES 2016-08-10
    TSMMON_STATUS 2016-08-10
    TSMMON_ALERT 2016-08-10
    GUIL2_SCHCLI_GRID 2016-08-10
    GUIL2_CLIASS_GRID 2016-08-10
    GUIL2_ALLPOL_GRID 2016-08-10
    RESTART_EXPIRATION 2016-08-10
    SCHEDULE_PENDING 2016-08-10
    SCHEDULE_ASSOCATION 2016-08-10
    COLLOCATION_GROUP_MEMBER2 2016-08-10
    COLLOCATION_GROUPS 2016-08-10
    AF_BACKUP_OPTIMIZATION 2016-08-10
    BF_AGGREGATED_BITFILES 2016-08-09
    AF_VOL_CLUSTERS 2016-08-09
    AF_DAMAGED 2016-08-09
    AF_BITFILES 2016-08-09
    DEVCLASS_DIRS 2016-08-09
    POLICY_DOMAINS 2016-08-09
    POLICY_DOMAIN_MEMBERS 2016-08-09
    COPY_GROUPS 2016-08-09
    AS_SEGMENTS 2016-06-11
    BF_BITFILE_EXTENTS 2016-06-10
    BF_SUPER_AGGREGATES 2016-06-09
    AF_SEGMENTS 2016-06-07
    GUIL2_MAINTHIST 2016-06-06
    GUIL2_MAINT_GRID 2016-06-06
    BF_AGGREGATE_ATTRIBUTES 2016-06-06
    BACKUP_OBJECTS 2016-05-12
    UNRESOLVED_OBJECTS 2016-02-10
    UNRESOLVED_LEADERS 2016-02-10
    SCHEDULE_NODE_ADDRESSES 2016-02-10
    LICENSE_NODE_STORAGE 2015-12-15
    SS_VOLUME_IDS 2015-12-15
    SS_POOL_CONTENTS 2015-12-15
    SEQ_VOLUME_HISTORY 2015-12-14

    В Таблицах и индексах четко показывает, что место используется значительно меньше, чем выделено в табличных пространствах.

    TNAME ROWS_IN_TABLE TABLE_USED_MB TABLE_ALLOC_MB INDEX_USED_MB INDEX_ALLOC_MB
    ———————– ————— ————– —————- ————— —————
    BF_AGGREGATED_BITFILES 86336894 8668 24417 10204 100753
    BF_BITFILE_EXTENTS 59603050 3980 18932 12359 96688
    ACTIVITY_LOG 5714825 580 4424 108 651
    BF_DEREFERENCED_CHUNKS 0 0 4066 14 11836
    BF_QUEUED_CHUNKS 0 0 816 33 1630
    BACKUP_OBJECTS 71930 23 52 25 28
    TSMMON_STATUS 233497 19 23 12 13
    AS_SEGMENTS 11398 1 16 0 3
    AF_SEGMENTS 11398 0 3 0 8
    BF_AGGREGATE_ATTRIBUTES 4684 0 3 0 3

    При выполнении сжатия

    db2 ALTER TABLESPACE BFABFDATASPACE REDUCE MAX
    db2 ALTER TABLESPACE BFABFIDXSPACE REDUCE MAX

    Команды выполняются успешно,буквально за пару секунд. Но по факту изменений никаких не происходит.

  • #39012
    Картинка профиля Andrew White
    Andrew White
    Участник

    Пришлите, плиз, q db f=d.

    Подозреваю, что сделали REDUCE не по всем табличным пространствам. Самые большие объекты хранятся, как правило, в LARGESPACE1, LARGEIDXSPACE1. Судя по тексту сообщения не понятно сколько табличных пространств сжали. Два указанных выше? Не достаточно. Плюс ко всему, эти команды асинхронные.

    В документе все сказано, просто он длинный и сложно все сразу прочитать, понять.

  • #39013
    Картинка профиля pavliga
    pavliga
    Участник

    q db f=d

    Database Name: TSMDB1
    Total Size of File System (MB): 1,048,576
    Space Used on File System(MB): 436,257
    Space Used by Database(MB): 265,301
    Free Space Available (MB): 612,319
    Total Pages: 30,525,890
    Usable Pages: 30,525,440
    Used Pages: 30,501,600
    Free Pages: 23,640
    Buffer Pool Hit Ratio: 98.38
    Total Buffer Requests: 6,401,850,000
    Sort Overflows: 0
    Package Cache Hit Ratio: 98.332
    Last Database Reorganization: 2016-08-11, 14:20:10
    Full Device Class Name: TAPE_3592
    Number of Database Backup Streams: 1
    Incrementals Since Last Full: 0
    Last Complete Backup Date/Time: 2016-08-11, 11:51:42
    Compress Database Backups: No

    Сделал REDUCE только по этим двум указанным в комментарии выше.

    Мне показалось, что

    LARGESPACE1, LARGEIDXSPACE1 это табличные пространства для TSM v6.2 и 6.3, а для TSM 7.1 указаны другие в данном документе.

     

    Далее проверил с помощью

    <tt>table(sysproc.MON_GET_EXTENT_MOVEMENT_STATUS(‘</tt><tt>BFABFDATASPACE’,-1)) ” table(sysproc.MON_GET_EXTENT_MOVEMENT_STATUS(‘</tt><tt>BFABFIDXSPACE’,-1)) ” </tt>

    в выводе получил -1. Т.е. процесс завершен

  • #39014
    Картинка профиля Andrew White
    Andrew White
    Участник

    Из вывода q db видно по полю Free Pages , что REDUCE не поможет. Нет свободных страниц, которые можно сократить.

    Думаю два варианта.

    1. Все таки проделать offline reorg. Не знаю, оптимизирует ли онлайн реорганизация свободное пространство таблиц, индексов.

    2. Включить сжатие на таблицах, индексах. И повторить оффлайн реорганизацию и сжатия табличных пространств. В нашем случае эффект почти в два раза.

     

     

    ПС: В нашем случае ТСМ 7.1 самая большая таблица BACKUP_OBJECTS лежит в LARGESPACE1

    • Ответ изменён 11 мес., 2 нед. назад пользователем Картинка профиля Andrew White Andrew White.
  • #39016
    Картинка профиля pavliga
    pavliga
    Участник

    Спасибо. Буду планировать Offline Reorg.

  • #39027
    Картинка профиля Demetrio
    Demetrio
    Участник

    странный вопрос задам

    Под базу отдельный раздел выделен? Потому, если нет, то Space Used on File System – это фактически все отъеденное место всем подряд. Я на одном сервере сглупил в свое время и на одном разделе разместил все (  базу логи  дисковый пул) И теперь он мне показывает, что размер базы 1.5 Тб

    • Ответ изменён 11 мес., 1 неделя назад пользователем Картинка профиля Demetrio Demetrio.
    • Ответ изменён 11 мес., 1 неделя назад пользователем Картинка профиля Demetrio Demetrio.
  • #39033
    Картинка профиля pavliga
    pavliga
    Участник

    БД, логи и архивлоги действительно расположены на одной ФС.

    Total Size of File System (MB): 1,048,576
    Space Used on File System(MB): 436,257
    Space Used by Database(MB): 265,301

    Размер самой фс 1 Тб, занято на ФС 436 Гб (там живет еще другой инстанс TSM). А Размер БД получается 265 Гб.

    • Ответ изменён 11 мес., 1 неделя назад пользователем Картинка профиля pavliga pavliga.
  • #39047
    Картинка профиля Demetrio
    Demetrio
    Участник

    Space Used by Database(MB): 265,301
    На это даже не смотри в твоем случае
    Посчитай размер db space напрумую из файловой системы

    И может реально столько объектов?
    Что там у тебя показывает occupancy?

Для ответа в этой теме необходимо авторизоваться.