Оптимизация работы утилиты RUNSTATS в среде DB2 for Linux, UNIX, and Windows: устранение проблем, обуславливаемых фрагментацией индекса

Точные статистические сведения о базы данных позволяют оптимизатору запросов DB2® (query optimizer) формировать эффективные планы доступа. Вне зависимости от того, управляете ли вы сбором статистики лично или используете для сбора статистики автоматические средства DB2, медленная работа утилиты RUNSTATS способна осложнить эту деятельность. В этой статье показано, как выяснить, не является ли именно фрагментация индекса первопричиной медленной работы RUNSTATS.

Квай Вон, разработчик программного обеспечения, IBM

Kwai WongКвай Вон (Kwai Wong) — разработчик программного обеспечения; более 20 лет она является членом группы по разработке DB2 в лаборатории IBM Canada Lab. К. Вон специализируется на таких компонентах DB2, как среда исполнения, оптимизатор запросов и статистика базы данных. Кроме того, К. Вон имеет опыт работы в таких областях, как анализ производительности, настройка и устранение неполадок.



31.01.2014

Введение

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

Эта статья ориентирована на среды, в которых исполняется версия DB2 9.7 или ниже. В версии DB2 10.1 была реализована функция Readahead prefetching (предварительная выборка с опережающим чтением), вследствие чего фрагментация индекса уже не оказывает столь же сильного влияния на производительность RUNSTATS.

Как производительность сканирования индекса способна повлиять на производительность RUNSTATS

DB2 собирает статистические сведения для таблицы и всех ее индексов после инициирования пользователем администратором следующей команды:

RUNSTATS ON TABLE MY.TABLE1 AND INDEXES ALL

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

Для больших таблиц с несколькими индексами производительность сканирования индекса оказывает значительное влияние на производительность утилиты RUNSTATS. Если соответствующие страницы индекса будут заранее выбраны в буферный пул (до того, как потребитель результатов сканирования запросит эти страницы), то сканирование индекса будет осуществляться быстрее. Однако если потребителю сканирования придется ждать, пока дисковые операции ввода/вывода перенесут эти страницы в буферный пул, то сканирование индекса не будет работать оптимальным образом. Другие операции базы данных, такие как обработка запросов, также используют сканирование индекса. Следует, однако, отметить, что утилита RUNSTATS полностью сканирует все индексы таблицы один за другим, а запросы могут ограничиваться сканированием лишь фрагмента одного индекса таблицы. Если производительность сканирования индекса находится на низком уровне, то это наиболее заметно при работе утилиты RUNSTATS.

В версии DB2 9.7 и ниже для определения необходимости выполнения предварительной выборки индекса используется функция последовательного обнаружения (sequential detection). Поскольку RUNSTATS обрабатывает страницы индекса в соответствии с порядком ключей индекса, предварительная выборка запускается в том случае, если менеджер базы данных обнаруживает последовательный доступ к страницам индекса. Предварительная выборка выгодна в том случае, если индекс не является фрагментированным, т.е. находится на смежных физических страницах. Однако если страницы индекса рассеяны по всему табличному пространству, предварительная выборка страниц может оказаться расточительной операцией в тех случаях, когда большинство заранее выбранных страниц не будет использовано.

Фрагментация индекса обуславливается несколькими факторами. Одним из этих факторов является наличие у таблицы нескольких индексов. Индексы для таблицы хранятся в одном индексном объекте (за исключением неразделенных индексов таблицы, разбитой на разделы), поэтому страницы одного индекса могут оказаться перемешанными со страницами другого индекса. Другим фактором является секционирование страницы индекса, которое может произойти в результате выполнения операций INSERT и UPDATE.

Реорганизация индекса заново компонует данные индекса в виде нефрагментированных, физически смежных страниц. Это позволяет функции sequential detection заранее выбирать страницы в буферный пул таким образом, чтобы следующая страница была доступна к тому моменту, когда она потребуется утилите RUNSTATS. В результате RUNSTATS работает быстрее.

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

Пример с фрагментированными и с нефрагментированными индексами

Чтобы продемонстрировать влияние фрагментированных индексов на производительность RUNSTATS воспользуемся "предельным" сценарием фрагментации индекса. В Листинге 1 показаны команды для создания таблицы с 10 миллионами строк. Сначала создается пять индексов, а затем в них вставляются данные. При таком методе вставки страницы с различными индексами перемешиваются, а каждый индекс имеет высокую степень фрагментированности.

Листинг 1. Скрипт для создания фрагментированных индексов
 -- run this CLP file with autocommit off (db2 +c -tvf FILE)

connect to db97;

-- create not logged initially table
drop table demo.t1;
CREATE TABLE demo.t1 (i1 int not null,
                      i2 int not null,
                      i3 int not null,
                      i4 int not null,
                      i5 int not null,
                      i6 int not null,
                      i7 int not null)
       not logged initially;

-- create indexes BEFORE inserting data 
create index demo.t1i1    on demo.t1 (i1);
create index demo.t1i2    on demo.t1 (i2);
create index demo.t1i3    on demo.t1 (i3);
create index demo.t1i62   on demo.t1 (i6,i2);
create index demo.t1i765  on demo.t1 (i7,i6,i5);

-- insert 10M rows 
-- note: the pages for the five indexes will be intermixed in the table space 
-- and each index will be fragmented
insert into demo.t1 with q(a) as (values 1 union all select a+1 from q where a<10000000)
  select -a,mod(a,1237),mod(-a,251),mod(a,353),mod(-a,100),mod(a,257),mod(-a,511) from q;
commit;

connect reset;

Теперь посмотрим, сколько времени работает утилита RUNSTATS. Как показано в Листинге 2, в случае фрагментированных индексов типичное время работы RUNSTATS превышает шесть минут.

Листинг 2. Время работы утилиты RUNSTATS в случае фрагментированных индексов
 values (current timestamp, 'TEST1: start')
1                          2
-------------------------- -------------
2013-06-16-13.59.16.093219 TEST1: start
  1 record(s) selected.

runstats on table DEMO.T1 with distribution and sampled detailed indexes all
DB20000I  The RUNSTATS command completed successfully.

values (current timestamp, 'TEST1: stop')
1                          2
-------------------------- ------------
2013-06-16-14.05.25.235269 TEST1: stop
  1 record(s) selected.

Теперь реорганизуем индексы с помощью команды REORG и снова запустим RUNSTATS. В Листинге 3 показано, что реорганизация индекса была выполнена за 1 минуту.

Листинг 3. Команда REORG INDEXES и время ее выполнения
 reorg indexes all for table demo.t1
DB20000I  The REORG command completed successfully.

real    0m58.54s
user    0m0.01s
sys     0m0.01s

Как показано в Листинге 4, после реорганизации нефрагментированных индексов время работы утилиты RUNSTATS не превышает 30 секунд. По сравнению с исходными 6 минутами имеет место 12-кратное улучшение.

Листинг 4. Время выполнения утилиты RUNSTATS после реорганизации индекса
 values (current timestamp, 'TEST2: start')
1                          2
-------------------------- -------------
2013-06-17-23.00.35.432198 TEST2: start
  1 record(s) selected.

runstats on table DEMO.T1 with distribution and sampled detailed indexes all
DB20000I  The RUNSTATS command completed successfully.

values (current timestamp, 'TEST2: stop')
1                          2
-------------------------- ------------
2013-06-17-23.01.03.483116 TEST2: stop
  1 record(s) selected.

Это искусственный пример, однако потенциальный выигрыш является вполне реальным. По сведениям администраторов баз данных, в DB2-средах большого размера время исполнения утилиты RUNSTATS может быть сокращено с 18 часов до 40 минут.


Использование журналов статистики для нахождения таблиц с большим временем исполнения утилиты RUNSTATS

Возникает закономерный вопрос: Каким образом можно проверить таблицы на предмет наличия вышеописанных проблем с производительностью RUNSTATS? Один из подходов состоит в выявлении таблиц с большим временем выполнения утилиты RUNSTATS. Имеет смысл обратить внимание на эти таблицы, поскольку время является важным ресурсом. Если таблица страдает от фрагментации индекса, а время исполнения RUNSTATS не слишком велико (возможно, по причине относительно небольших размеров этой таблицы), то эта таблица не нуждается в вашем внимании.

Журналы статистики, введенные в версии DB2 9.5, содержат информацию об операциях по сбору статистики в экземпляре базы данных. Эти журналы хранятся в каталоге событий, находящемся в каталоге диагностических данных (db2dump/events). В Листинге 5 показаны записи журнала операции COLLECT для RUNSTATS в примере с фрагментированным индексом. С помощью таких журналов статистики можно вывлять долго выполняющиеся прогоны RUNSTATS (с помощью меток времени start и success).

Листинг 5. Записи в журнале статистики
 2013-06-16-13.59.16.101750-240 E1597A582          LEVEL: Event
PID     : 2950020              TID  : 1544        PROC : db2sysc
INSTANCE: kwaiwong             NODE : 000         DB   : DB97
APPHDL  : 0-29                 APPID: *LOCAL.kwaiwong.130616175833
AUTHID  : KWAIWONG
EDUID   : 1544                 EDUNAME: db2agent (DB97)
FUNCTION: DB2 UDB, relation data serv, sqlrLocalRunstats, probe:10
COLLECT : TABLE AND INDEX STATS : AT "2013-06-16-13.59.16.096268" : BY "User" : start
OBJECT  : Object name with schema, 11 bytes
DEMO    .T1
IMPACT  : None

2013-06-16-14.05.25.231686-240 E2180A723          LEVEL: Event
PID     : 2950020              TID  : 1544        PROC : db2sysc
INSTANCE: kwaiwong             NODE : 000         DB   : DB97
APPHDL  : 0-29                 APPID: *LOCAL.kwaiwong.130616175833
AUTHID  : KWAIWONG
EDUID   : 1544                 EDUNAME: db2agent (DB97)
FUNCTION: DB2 UDB, relation data serv, sqlrLocalRunstats, probe:220
COLLECT : TABLE AND INDEX STATS : AT "2013-06-16-14.05.25.231595" : BY "User" : success
OBJECT  : Object name with schema, 11 bytes
DEMO    .T1
IMPACT  : None
DATA #1 : String, 109 bytes
RUNSTATS ON TABLE "DEMO"."T1" ON ALL COLUMNS WITH DISTRIBUTION ON ALL COLUMNS 
 AND SAMPLED DETAILED INDEXES ALL

Более легкий способ просмотра информации в журнале статистики состоит в использовании табличной функции SYSPROC.PD_GET_DIAG_HIST. С помощью этой табличной функции можно отформатировать различные аспекты журнала статистики с целью упрощения просмотра и анализа событий в статистических сведениях. Соответствующий пример показан в Листинге 6.

Листинг 6. Использование функции SYSPROC.PD_GET_DIAG_HIST
 select timestamp(varchar(substr(first_eventqualifier,1,26),26)) as eventtime, 
substr(objname_qualifier,1,20) as objschema, substr(objname,1,10) as objname, 
substr(eventtype,1,8) as eventtype,
substr(second_eventqualifier,1,10) eventby, 
substr(eventstate,1,10) as eventstate 
from table(sysproc.PD_GET_DIAG_HIST('optstats','EX','NONE',null,cast(null as timestamp))) 
as sl order by objschema,objname,eventtime

EVENTTIME                  OBJSCHEMA            OBJNAME    EVENTTYPE EVENTBY    EVENTSTATE
-------------------------- -------------------- ---------- --------- ---------- ----------
2013-06-16-13.59.16.096268 DEMO                 T1         COLLECT   User       start
2013-06-16-14.05.25.231595 DEMO                 T1         COLLECT   User       success

  2 record(s) selected.

Следует иметь в виду, что журналы статистики относятся к категории rolling log (перезаписываемый журнал). С помощью переменной реестра DB2_OPTSTATS_LOG можно сконфигурировать, каким образом DB2 будет сохранять эти журналы.


Проверка исполняющейся утилиты RUNSTATS

Другой способ для выявления большого времени исполнения RUNSTATS состоит в проверке всех работающих утилит на предмет большого времени их исполнения. В Листинге 7 показаны выходные данные команды LIST UTILITIES SHOW DETAIL, полученные в процессе исполнения утилиты RUNSTATS. В этом примере пользователь вызвал сведения об утилите RUNSTATS, запущенной 16 июня в 13:59 для таблицы DEMO.T1.

Листинг 7. Выходные данные команды LIST UTILITIES
 list utilities show detail 

ID                               = 1
Type                             = RUNSTATS
Database Name                    = DB97
Partition Number                 = 0
Description                      = DEMO.T1
Start Time                       = 06/16/2013 13:59:16.356724
State                            = Executing
Invocation Type                  = User
Throttling:
   Priority                      = Unthrottled

Информацию о выполнении утилиты RUNSTATS также можно получить с помощью команды db2pd, которая описывается в одном из последующих разделов этой статьи.

Выявление фрагментированных индексов в статистических данных

Статистику индекса можно использовать для выявления фрагментированных индексов. Используются следующие статистические сведения: SYSCAT.INDEXES.SEQUENTIAL_PAGES и SYSCAT.INDEXES.NLEAF. Если индекс слабо фрагментирован, то значения sequential_pages очень мало отличается от значений nleaf. Если индекс является фрагментированным, то значения sequential_pages намного меньше, чем значения nleaf. Обратимся к статистическим данным, собранным в предшествующем примере.

В Листинге 8 показано, что до выполнения команды REORG у всех индексов значение sequential_pages равно нулю, а после выполнения REORG у всех индексов значение sequential_pages мало отличается от значения nleaf. Вы сможете использовать эти статистические данные индекса вместе с размером таблицы для выявления таблиц с фрагментированными индексами, к которым следует применить соответствующие меры.

Листинг 8. Статистические показатели индекса: SEQUENTIAL_PAGES и NLEAF
 select substr(indname,1,8) as idxname, stats_time, nleaf, sequential_pages
from syscat.indexes where tabschema='DEMO' and tabname='T1'

---
-- first, before REORG ...
---

IDXNAME  STATS_TIME                 NLEAF                SEQUENTIAL_PAGES
-------- -------------------------- -------------------- --------------------
T1I1     2013-06-16-14.05.25.080000                41841                    0
T1I2     2013-06-16-14.05.25.080000                25245                    0
T1I3     2013-06-16-14.05.25.080000                24894                    0
T1I62    2013-06-16-14.05.25.080000                31138                    0
T1I765   2013-06-16-14.05.25.080000                81178                    0

  5 record(s) selected.

---
-- next, after REORG ...
---

select substr(indname,1,8) as idxname, stats_time, nleaf, sequential_pages
from syscat.indexes where tabschema='DEMO' and tabname='T1'

IDXNAME  STATS_TIME                 NLEAF                SEQUENTIAL_PAGES
-------- -------------------------- -------------------- --------------------
T1I1     2013-06-17-23.01.03.320000                41667                41666
T1I2     2013-06-17-23.01.03.320000                22475                22474
T1I3     2013-06-17-23.01.03.320000                22473                22472
T1I62    2013-06-17-23.01.03.320000                22817                22816
T1I765   2013-06-17-23.01.03.320000                64103                64102

  5 record(s) selected.

Подтверждение того, что большое время исполнения RUNSTATS обусловлено сбором статистики индекса

После выявления таблиц, которые могут иметь фрагментированные индексы, у вас может возникнуть желание подтвердить, что большое время исполнения обусловлено именно сбором статистики индекса. Эта задача может быть решена с помощью опции -runstats команды db2pd monitor. Она предоставляет данные по продолжительности различных фаз выполнения RUNSTATS, включая время на сбор статистических данных таблицы и время на сбор статистических данных индексов (поддерживается до четырех индексов). Если таблица имеет более четырех индексов, то в процессе исполнения утилиты RUNSTATS команду db2pd — в случае необходимости — можно запускать повторно с целью регистрации продолжительности сбора для первых индексов. Исполнение команды db2pd после завершения утилиты RUNSTATS покажет продолжительность сбора статистики для последних четырех обработанных индексов. Снова рассмотрим данные db2pd для нашего предшествующего примера.

В Листинге 9 показаны результаты выполнения команды db2pd-runstats после завершения работы RUNSTATS.

Листинг 9. Выходная информация команды db2pd -runstats
 DB Partition 0 - Database DB97 - Active - Up 0 days 00:07:44 - Date 06/16/2013 14:05:55

Table Runstats Information:

Retrieval Time: 06/16/2013 14:05:55
TbspaceID: 2        TableID: 4
Schema: DEMO      TableName: T1
Status: Completed     Access: Allow write
Sampling: No          Sampling Rate: -
Start Time: 06/16/2013 13:59:16   End Time: 06/16/2013 13:59:25
Total Duration: 00:00:09
Cur Count: 0                      Max Count: 0

Index Runstats Information:

Retrieval Time: 06/16/2013 14:05:55
TbspaceID: 2        TableID: 4
Schema: DEMO      TableName: T1
Status: Completed     Access: Allow write
Start Time: 06/16/2013 13:59:25   End Time: 06/16/2013 14:05:25
Total Duration: 00:05:59
Prev Index Duration [1]: 00:00:20
Prev Index Duration [2]: 00:00:49
Prev Index Duration [3]: 00:00:11
Cur Index Start: 06/16/2013 14:02:31
Cur Index: 5            Max Index: 5            Index ID: 5
Cur Count: 0                      Max Count: 0

Первый раздел под названием Table Runstats Information содержит информацию о сборе статистики таблицы. Для сбора статистических данных таблицы потребовалось лишь девять секунд (с 13:59:16 по 13:59:25). Второй раздел под названием Index Runstats Information показывает, что сбор статистики для индекса iid5 занял 2 минуты 54 секунды (с 14:02:31 по 14:05:25). Раздел под названием Prev Index Duration показывает, что для индексов iid4, iid3 и iid2 потребовалось 20, 49 и 11 секунд, соответственно. В разделах для таблица и для индекса демонстрируется статус Completed (завершено).

Эта таблица имеет пять индексов. Выходная информация команды db2pd -runstats, собранная в процессе выполнения утилиты RUNSTATS, показывает продолжительность сбора статистики для первого индекса. В Листинге 10 показана информация, собранная в то время, пока утилита RUNSTATS обрабатывала индекс iid4.

Листинг 10. Выходная информация команды db2pd-runstats, собранная в процессе работы RUNSTATS
 DB Partition 0 - Database DB97 - Active - Up 0 days 00:04:14 - Date 06/16/2013 14:02:25

Table Runstats Information:

Retrieval Time: 06/16/2013 14:02:25
TbspaceID: 2        TableID: 4
Schema: DEMO      TableName: T1
Status: Completed     Access: Allow write
Sampling: No          Sampling Rate: -
Start Time: 06/16/2013 13:59:16   End Time: 06/16/2013 13:59:25
Total Duration: 00:00:09
Cur Count: 0                      Max Count: 0

Index Runstats Information:

Retrieval Time: 06/16/2013 14:02:25
TbspaceID: 2        TableID: 4
Schema: DEMO      TableName: T1
Status: In Progress   Access: Allow write
Start Time: 06/16/2013 13:59:25   End Time: 06/16/2013 14:02:11
Total Duration: 00:02:45
Prev Index Duration [1]: 00:00:49
Prev Index Duration [2]: 00:00:11
Prev Index Duration [3]: 00:01:45
Cur Index Start: 06/16/2013 14:02:11
Cur Index: 4            Max Index: 5            Index ID: 4
Cur Count: 23150                  Max Count: 47500

В разделе индекса показан статус In progress (выполняется). Показатель Prev Index Duration [3] указывает, что продолжительность сбора статистики для первого индекса, iid1, составляет 1 минуту 45 секунд.

Подтверждение того, что большое время исполнения RUNSTATS обусловлено отсутствием предварительной выборки

С помощью монитора базы данных DB2 можно убедиться в том, что большое время работы утилиты RUNSTATS обусловлено отсутствием предварительной выборки. Снова обратимся к примеру, использованному ранее. В Листинге 11 показаны данные моментального снимка приложения для RUNSTATS до и после применения команды REORG.

Листинг 11. Данные моментального снимка приложения
 get snapshot for application AGENTID $runstatsAppId

*** before REORG ...
Snapshot timestamp                         = 06/16/2013 14:05:44.884178
Buffer pool index logical reads            = 409356
Buffer pool index physical reads           = 204435
Total buffer pool read time (milliseconds) = 685220

*** after REORG ...
Snapshot timestamp                         = 06/17/2013 23:01:17.519335
Buffer pool index logical reads            = 175391
Buffer pool index physical reads           = 140
Total buffer pool read time (milliseconds) = 157

В разделе *** before REORG (до REORG) демонстрируется большое количество физических чтений индекса, что указывает на отсутствие предварительной выборки. Это большое количество физических чтений дополняется большим временем чтения из буферного пула, что непосредственно влияет на увеличение времени выполнения утилиты RUNSTATS.

Данные моментального снимка после реорганизации индекса (раздел *** after REORG) свидетельствуют об улучшении показателей производительности. Малое количество логических чтений свидетельствуют об уменьшении количества страниц, подлежащих обработке, а низкое соотношение физических и логических страниц позволяет предположить, что страницы индекса были заранее выбраны в буферный пул, т. е. до того момента, когда утилита RUNSTATS обратилась к этим страницам. В результате действия этих двух факторов было достигнуто 12-кратное улучшение.


Дефрагментирование индексов с помощью команды REORG

Фрагментированные индексы способны оказать отрицательное влияние не только на производительность утилиты RUNSTATS, но и на общую производительность всей системы. Сканирование индекса может осуществляться и в процессе обработки запроса, поэтому дефрагментирование индексов способно сократить и продолжительность обработки запросов, а не только продолжительность выполнения утилиты RUNSTATS.

Для повторной компоновки индексов и избавления их от фрагментации можно воспользоваться командой REORG INDEX. В листинге 3 представлен пример этой команды.

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

Совершенствование предварительной выборки в версии DB2 10.1

В версии DB2 10.1 реализован новый тип предварительной выборки под названием Readahead prefetching (предварительная выборка с опережающим чтением). Эта функция повышает производительность операций, которые обращаются к фрагментированным объектам, и уменьшает потребность в выполнении команды REORG. Если вы повторите демонстрационные примеры из этой статьи в среде DB2 10.1 с опцией Readahead prefetching, то увидите, что продолжительность исполнения утилиты RUNSTATS до и после применения команды REORG практически одинакова и соответствует продолжительности исполнения утилиты RUNSTATS в среде DB2 9.7 после применения команды REORG.

Для получения дополнительной информации обратитесь в раздел Ресурсы, в котором содержится ссылка на раздел Информационного центра по продукту IBM DB2 Version 10.1, посвященный повышению производительности при выполнении запросов посредством более эффективной предварительной выборки данных и индексов.

Заключение

Фрагментация индексов способна оказать значительное отрицательное влияние на производительность утилиты RUNSTATS. Это особенно справедливо для крупных таблиц с большим количеством индексов и с большим количеством операций insert/update. Регулярное обслуживание с помощью команды REORG позволяет избежать этого влияния на производительность. Реализованная в версии DB2 10.1 функция Readahead prefetching эффективно устраняет эту проблему.

Ресурсы

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Information Management
ArticleID=961730
ArticleTitle=Оптимизация работы утилиты RUNSTATS в среде DB2 for Linux, UNIX, and Windows: устранение проблем, обуславливаемых фрагментацией индекса
publish-date=01312014