Shrink БД TSM

Просмотр 9 веток ответов
  • Автор
    Сообщения
    • #39007
      pavliga
      Участник

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

      Версия TSM Server 7.1.1.300

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

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

    • #39008
      Oldnick
      Участник
    • #39011
      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
      Участник

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

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

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

    • #39013
      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
      Участник

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

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

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

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

       

       

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

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

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

    • #39027
      Demetrio
      Участник

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

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

      • Ответ изменён 4 года, 2 месяца назад пользователем Demetrio.
      • Ответ изменён 4 года, 2 месяца назад пользователем Demetrio.
    • #39033
      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 Гб.

      • Ответ изменён 4 года, 2 месяца назад пользователем pavliga.
    • #39047
      Demetrio
      Участник

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

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

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