Сравнение DB2 для z/OS и DB2 для Linux, UNIX и Windows

Обзор для администраторов баз данных DB2, желающих приобрести кросс-платформенный опыт

В статье представлен обзор работы DB2 на различных платформах для администраторов баз данных DB2®. Администраторы баз данных могут воспользоваться своим опытом работы с DB2 на z/OS® или на Linux®, UNIX® и Windows® (LUW) для изучения выполнения задач администрирования на других платформах.

Балачандран Чандрасекаран, ИT-специалист, IBM

Балачандран Чандрасекаран (Balachandran Chandrasekaran) – фотографияБалачандран Чандрасекаран (Balachandran Chandrasekaran) работает консультантом в группе IBM System and Technology Lab India. Занимается различными темами, связанными с DB2 для z/OS, включая программирование приложений, установку и администрирование серверов DB2. В настоящее время в сферу его интересов входит также DB2 для Linux, UNIX и Windows.



21.12.2012

Введение

Редакции DB2 для z/OS и Linux, UNIX, Windows (LUW) настолько различны, что администраторы DB2 часто должны владеть различными навыками для работы на разных платформах. Данная статья поможет вам начать работать с DB2 на другой платформе. Предполагается, что вы знаете соответствующее аппаратное обеспечение и операционные системы. Данная статья представляет различные методики администрирования базы данных на различных платформах, и ее не следует использовать для сравнения функций и возможностей двух этих продуктов.

DB2 LUW также выпускается в разных редакциях: DB2 Express-C (бесплатная), DB2 Express Edition, DB2 Personal Edition, DB2 Workgroup Server Edition, DB2 Enterprise Server Edition и DB2 Advanced Enterprise Server Edition. Наиболее подходящий для вашего бизнеса набор функциональных возможностей будет зависеть от возможностей базового продукта, размера бизнеса, количества пользователей и условий лицензирования. В данной статье DB2 z/OS – это DB2 10 для z/OS, а DB2 LUW – это DB2 9.7 для Linux, UNIX и Windows. Следует также отметить, что под Linux на серверах System z будет работать DB2 LUW, а не DB2 z/OS.

Подсистемы, экземпляры и базы данных

Существуют различия в обращении и способе доступа к серверу DB2 на этих двух платформах. Сервер DB2 называется подсистемой (subsystem) в z/OS и экземпляром (instance) в LUW. DB2 выполняет свои задания в соответствии с набором адресных пространств на системе z/OS (рассматривается в разделе Структуры памяти), как процесс в операционных системах Linux и UNIX и как сервис (если не запущен с ключом /D) в Windows. Каждый сервер DB2 z/OS идентифицируется четырехсимвольным идентификатором подсистемы (SSID), а каждый сервер DB2 LUW идентифицируется именем экземпляра, указанным в переменной окружения DB2INSTANCE.

Что означает понятие база данных в каждой платформе? База данных в DB2 LUW имеет свою собственную область памяти, процессы и журналы восстановления (recovery log), тогда как база данных в DB2 z/OS является логическим набором нескольких табличных и индексных пространств с очень небольшим количеством параметров, определенных по умолчанию для всех созданных объектов. В DB2 LUW каждая база данных имеет свои собственные таблицы каталога, тогда как в DB2 z/OS каждая подсистема DB2 имеет таблицы каталога.

Системные объекты

  • База данных DSNDB06 в подсистеме DB2 z/OS и табличное пространство SYSCATSPACE в DB2 LUW будут содержать все таблицы каталога DB2.
  • В DB2 z/OS, не использующей совместный доступ к данным, DSNDB07 является файловой базой данных. Табличные пространства, создаваемые в DSNDB07, используются как хранилище для обработки SQL-соединений и сортировок, а также для временных таблиц. В DB2 LUW для сортировок и соединений используется системное временное табличное пространство по умолчанию TEMPSPACE1. Для хранения данных временных таблиц следует создать одно или несколько временных табличных пространств USER.
  • Если при создании табличного пространства в DB2 z/OS название базы данных не указывается, пользовательской базой данных по умолчанию для созданного объекта является DSNDB04. Если при создании таблицы табличное пространство не указывается, DB2 сама создаст неявное табличное пространство. Если предположить, что вы еще не создали в DB2 LUW ни одного табличного пространства, все таблицы, создаваемые без явного указания табличного пространства, будут храниться в USERSPACE1.
  • DB2 z/OS хранит разнообразную информацию, необходимую для обычной операции, в специальной базе данных DSNDB01. Boot Strap Dataset (BSDS) – это набор данных z/OS VSAM, который содержит некоторую критичную информацию: имена наборов данных журнала восстановления, контрольные точки DB2 и подробности размещения DB2. В свою очередь, база данных DB2 LUW хранит разнообразную информацию, необходимую для обычной операции, в нескольких файлах операционной системы в локальном каталоге базы данных.

Создание первого удаленного соединения

Для доступа к удаленному серверу DB2 LUW необходимо каталогизировать узел, указав экземпляр DB2, а затем целевую базу данных под этим экземпляром в этом каталогизированном узле. В листинге 1 показано, как найти информацию о сервере DB2 на AIX-хосте. В свою очередь, необходимо каталогизировать удаленную DB2 z/OS, используя ее местоположение. Также, можно сохранить информацию о хосте DB2 в каталоге Database Connection Services (DCS) Directory посредством команды CATALOG DCS DATABASE, как показано в листинге 2. Местоположение DB2 z/OS определяется во время установки подсистемы DB2; его можно узнать, выполнив команду -DIS DDF на сервере DB2 z/OS, как показано в листинге 3.

Подсистема DB2 z/OS содержит информацию для установки соединений с удаленными подсистемами в наборе таблиц каталога, называемых Communication Database (CDB). Также для удаленного соединения с базами данных DB2, расположенными на хост-системах (в том числе z/OS) требуется дополнительная лицензия IBM DB2 Connect. Ссылки на дополнительную информацию о IBM DB2 Connect приведены в разделе Ресурсы.

Листинг 1. Команды для получения имени хоста и пары порт/сервис удаленного сервера DB2 LUW
$ db2set -all
[i] DB2COMM=TCPIP
[g] DB2SYSTEM=host.ibm.com
$ db2 get DB2INSTANCE

 The current database manager instance is:  db2inst1

$ db2 "get dbm cfg " | grep -i '(svcename)'
  TCP/IP Service name                          (SVCENAME) = DB2_db2inst1
$ cat /etc/services | grep -i DB2_db2inst1
  DB2_db2inst1    60000/tcp
Листинг 2. Команды на DB2 Client для каталогизации указанных выше серверов
$ db2 "CATALOG TCPIP NODE aixnode REMOTE host.ibm.com SERVER 60000 
> REMOTE_INSTANCE db2inst1"
$ db2 "CATALOG DATABASE sampledb AS sampledb AT NODE aixnode"
$ db2 "CONNECT TO sampledb USER userid USING passwd"

$ db2 "CATALOG TCPIP NODE zosnode REMOTE zserver.ibm.com SERVER 446"
$ db2 "CATALOG DATABASE nyc AS zosdb2 AT NODE zosnode"
$ db2 "CATALOG DCS DATABASE nyc AS newyork"
$ db2 "CONNECT TO zosdb2 USER zosuser USING passwd"
Листинг 3. Результат работы команды -DIS DDF на DB2 z/OS
-DIS DDF                                                          
DSNL080I  @ DSNLTDDF DISPLAY DDF REPORT FOLLOWS:                 
DSNL081I STATUS=STARTD                                           
DSNL082I LOCATION           LUNAME            GENERICLU          
DSNL083I NEWYORK            A.B               -NONE              
DSNL084I TCPPORT=446       SECPORT=0     RESPORT=4463  IPNAME=-NONE  
DSNL085I IPADDR=::ip-addr                                    
DSNL086I SQL    DOMAIN=zserver.ibm.com
DSNL099I DSNLTDDF DISPLAY DDF REPORT COMPLETE

Запросить информацию о каталогизированных базах данных и узлах можно при помощи команд LIST DB DIRECTORY и LIST NODE DIRECTORY соответственно.


Структуры памяти DB2

В DB2 LUW память, потребляемая сервером DB2, свободно подразделяется на общую память менеджера базы данных (уровень экземпляра) и общую память базы данных (уровень базы данных). В приведенном ниже списке перечислены все адресные пространства DB2 z/OS и их компоненты памяти.

  • System Services Address Space (ssidMSTR) – адресное пространство системных сервисов управляет всеми системными сервисами, включая управление журналами и обработку команд.
  • Database Manager Address Space (DBM1) – адресное пространство менеджера базы данных содержит все буферные пулы: Environment Descriptor Manager Pool (EDM), Sort pool и Record Identifier Pool (RID). DBM1, самое большое адресное пространство DB2, сопоставимо с общей памятью базы данных в DB2 LUW. EDM-пул содержит блоки кэш-памяти для доступа к каталогу, динамические SQL, планы/пакеты и курсоры.
  • Distributed Data Facility Address Space (ssidDDF) – адресное пространство функциональности распределенных данных отвечает за доступ к распределенным данным из удаленных клиентов, а также за доступом к удаленным данным из подсистемы DB2.
  • Internal Resource Lock Manager (IRLM) – менеджер блокировок внутренних ресурсов обрабатывает блокировки и другие виды работ, связанные с сериализацией. В IRLM определяется система хранения для блокировок, сопоставимая с параметром locklist в DB2 LUW.
  • z/OS Workload Managed Address Spaces (WLM) – адресные пространства менеджера рабочей нагрузки z/OS выполняют встроенные процедуры и подпрограммы. Вы можете также столкнуться с адресным пространством хранимых процедур DB2 Stored Procedure Address Space (SPAS), выполняя подпрограммы, созданные до версии DB2 v8.
  • Agent Allied Address Spaces – внешние адресные пространства агента работают для каждого адресного пространства, подключенного к DB2. Они аналогичны собственной памяти агента в DB2 LUW.
  • Утилиты DB2 работают в своих собственных пакетных адресных пространствах и при необходимости используют память из других адресных пространств DB2.

Если в DB2 z/OS нельзя создавать буферные пулы с произвольным именем, то DB2 LUW позволяет называть их как угодно при помощи SQL-выражения CREATE BUFFERPOOL. В DB2 z/OS существует 50 предопределенных буферных пулов с различными размерами страниц. Необходимо выбирать имя буферного пула в зависимости от размера страниц и активизировать пул при помощи команды -ALTER BUFFERPOOL. Кроме того, при создании табличной области в DB2 z/OS размер ее страниц определяется косвенно через буферный пул с требуемым размером страниц. В листингах 4 и 5 демонстрируются и сравниваются запросы информации о буферных пулах в DB2 z/OS и DB2 LUW соответственно.

Листинг 4. Буферные пулы в z/OS
-DIS BPOOL(BP0)                                                           
 DSNB401I  DB1S BUFFERPOOL NAME BP0, BUFFERPOOL ID 0, USE COUNT 357       
 DSNB402I  DB1S BUFFER POOL SIZE = 12500 BUFFERS  AUTOSIZE = NO  
              ALLOCATED       =    12500   TO BE DELETED   =        0     
              IN-USE/UPDATED  =      284   BUFFERS ACTIVE  =    12500     
 DSNB406I  DB1S PGFIX ATTRIBUTE -                                         
              CURRENT = NO                                                
              PENDING = NO                                                
            PAGE STEALING METHOD = LRU                                    
 DSNB404I  DB1S THRESHOLDS -                                              
             VP SEQUENTIAL    = 80                                        
             DEFERRED WRITE   = 30   VERTICAL DEFERRED WRT  =  5,  0      
             PARALLEL SEQUENTIAL =50   ASSISTING PARALLEL SEQT=  0        
 DSN9022I  DB1S DSNB1CMD '-DIS BPOOL' NORMAL COMPLETION
Листинг 5. Буферные пулы в LUW
$ db2  "SELECT SUBSTR(BPNAME,1,15) BPOOL, BUFFERPOOLID, NPAGES, PAGESIZE, 
>  NUMBLOCKPAGES, BLOCKSIZE FROM SYSIBM.SYSBUFFERPOOLS"

BPOOL           BUFFERPOOLID NPAGES      PAGESIZE    NUMBLOCKPAGES BLOCKSIZE
--------------- ------------ ----------- ----------- ------------- -----------
IBMDEFAULTBP               1        2000        4096             0           0

  1 record(s) selected.

Администратор базы данных, приступающий к работе с новой платформой, должен знать текущие конфигурации серверов DB2 и способ их настройки или модернизации при необходимости. Параметры подсистемы DB2 z/OS компонуются и связываются в исполняемый модуль при помощи задания MVS Job DSNTIJUZ, поставляемого IBM. Эти параметры называются DSNZPARM (сокращенно – ZPARM). Для изменения любого параметра подсистемы DB2 необходимо выполнить команду DSNTIJUZ, а затем команду -SET SYSPARM RELOAD, чтобы динамически обновить модуль DSNZPARM. Аналогичная задача на платформе LUW потребует выполнения команд UPDATE DBM CFG или UPDATE DB CFG в зависимости от того, какую конфигурацию необходимо обновить – менеджера базы данных (DBM) или базы данных (DB). Среда DB2 LUW управляется также посредством реестров различного типа. Переменные в этих реестрах можно просматривать и устанавливать при помощи системной команды db2set.

DB2 LUW предоставляет простой способ управлять различными структурами памяти посредством самонастраивающейся системы управления памятью (self-tuning memory management – STMM). Указание STMM в параметре DB CFG self_tuning_mem разрешает DB2 настраивать структуры памяти в зависимости от флуктуаций рабочей нагрузки.

Также DB2 LUW имеет очень полезную команду AUTOCONFIGURE, которую можно использовать для разрешения системе DB2 устанавливать параметры DBM и DB в соответствии с определенным типом рабочей нагрузки (OLTP или DSS). В DB2 z/OS есть опция, разрешающая DB2 автоматически настраивать размер буферного пула (пулов) в соответствии с рабочей нагрузкой. Для этого можно использовать команду ALTER BUFFERPOOL с операндом AUTORESIZE(YES). DB2 будет настраивать размер буферного пула при помощи z/OS WLM.


Табличные пространства и схема хранения

Табличные пространства группируют физические контейнеры для хранения данных различных таблиц и их индексов. Поскольку они отображают данные базы данных на используемую физическую систему хранения (диски, файловые системы, тома), понимание принципов их работы очень важно для администратора. DB2 z/OS хранит данные таблиц в наборах данных Linear Virtual Storage Access Method (VSAM, тип LDS). DB2 LUW хранит табличные данные в файлах, каталогах или на неформатированных устройствах в зависимости от типа табличного пространства.

Табличные пространства, содержащие индексы, в DB2 z/OS называются индексными пространствами; DB2 автоматически создает индексное пространство при создании нового индекса. В отличие от DB2 LUW, в индексное пространство нельзя поместить более одного индекса. При создании в DB2 z/OS таблицы, секционированной по диапазону значений, используемое табличное пространство тоже секционируется, и его разделы не могут хранить более одной таблицы. В DB2 LUW отдельные разделы такой таблицы можно помещать в одно или несколько табличных пространств.

Если в DB2 LUW несколько таблиц обычно группируются в отдельное табличное пространство, в DB2 z/OS чаще всего в каждом табличном пространстве создается одна таблица. Причина в том, что в DB2 z/OS большинство утилит управления данными работает на уровне табличного пространства (или на уровне разделов, если таблица секционирована), поскольку это дает большую свободу при выборе атрибутов хранения или окна управления таблицей. Тем не менее в табличном пространстве можно создавать более одной таблицы, если размеры таблиц невелики. Учтите, что создание нескольких таблиц в одном табличном пространстве будет влиять на все табличное пространство при выполнении некоторых утилит DB2.

Определение системы хранения DB2

В DB2 LUW есть два метода определения системы хранения DB2. В листинге 6 приведен пример использования этих методов.

  • В методе Database Managed Space (DMS) явно указывается набор файлов или физических устройств для каждого табличного пространства, а управление ими передается базе данных DB2. Помещать данные DB2 на неформатированные устройства в данном случае не рекомендуется, поскольку DB2 создает табличные области DMS по умолчанию без кэширования файловой системы. Также этот метод требует указывать исходный размер дискового пространства, и оно должно быть доступно для успешного создания табличного пространства. В табличных пространствах DMS можно добавлять или удалять контейнеры при необходимости. Можно также разрешить увеличение размеров контейнеров, а также указать значение приращения размера и максимальный размер отдельных контейнеров. Можно упростить управление системой хранения DB2, указав параметр Automatic Storage для всей базы данных. Можно указать Automatic Storage (для новых баз данных устанавливается по умолчанию) на уровне базы данных при помощи команд CREATE DATABASE или ALTER DATABASE. При этом на уровне базы данных необходимо указать один или несколько путей к системе хранения, если вы хотите, чтобы DB2 создала контейнеры для каждого табличного пространства.
  • В методе System Managed Space (SMS) указываются местоположения и каталоги, а управление табличным пространством осуществляет файловый менеджер операционной системы. Пространство будет выделяться по запросу. Табличное пространство можно увеличивать только путем добавления свободного пространства к используемой файловой системе. Кроме того, нельзя преобразовать табличное пространство SMS в DMS напрямую.
Листинг 6. Различные варианты систем хранения в DB2 LUW
-- Создание базы данных с автоматической системой хранения запрещено; каждая
-- табличная область будет использовать тип по умолчанию в зависимости
-- от своего типа.
db2 "CREATE DATABASE testdb AUTOMATIC STORAGE NO"

-- Разрешить Automatic Storage для базы данных с отключенной автоматической
-- системой хранения.
db2 "ALTER DATABASE testdb ADD STORAGE ON '/home/dbstor1'"

-- Создать Tablespace, управляемое автоматической системой хранения.
db2 "CREATE TABLESPACE autotbsp MANAGED BY AUTOMATIC STORAGE AUTORESIZE YES
> INITIALSIZE 1G INCREASESIZE 10M MAXSIZE 2G"

-- Создать DMS Tablespace, содержащее 100 страниц по 4 КБ.
-- DB2 установит размер приращения и максимальный размер.
db2 "CREATE TABLESPACE dmstbsp PAGESIZE 4096 MANAGED BY DATABASE USING 
> (FILE '/home/dbstor1/dbfile01.dbf' 100)"

-- Добавить дополнительный контейнер в табличное пространство DMS.
db2 "ALTER TABLESPACE dmstbsp ADD (FILE '/home/dbstor1/dbfile02.dbf' 100)"

-- Изменить табличное пространство DMS для использования Automatic Storage.
db2 "ALTER TABLESPACE dmstbsp MANAGED BY AUTOMATIC STORAGE"

-- Распространить данные по добавленным путям системы хранения.
db2 "ALTER TABLESPACE dmstbsp REBALANCE"

-- Создать табличное пространство SMS.
db2 "CREATE TABLESPACE smstbsp MANAGED BY SYSTEM USING ('/home/db2inst1/smsdir')"
db2 "CREATE TABLE T1(C1 CHAR(1)) IN smstbsp INDEX IN smstbsp"
db2 "CREATE INDEX I1 ON T1(C1)"
-- Как минимум один файл будет создан для каждого объекта, созданного в smstbsp.
-- Только что созданные файлы операционной системы для табличной области SMS:
$ ls -l /home/db2inst1/smsdir
total 40
-rw-------    1 db2inst1 db2adm1        4096 Jul 27 17:12 SQL00002.DAT
-rw-------    1 db2inst1 db2adm1       12288 Jul 27 17:12 SQL00002.INX
-rw-------    1 db2inst1 db2adm1         512 Jul 27 17:06 SQLTAG.NAM

Определение системы хранения в DB2 z/OS

В DB2 z/OS можно указать, как управляется используемая система хранения.

  • Управляется пользователем.
  • Управляется DB2.
  • Управляется z/OS SMS.
  • Поддерживает конструкции z/OS SMS в DDL-выражениях CREATE.

При создании табличных пространств и индексов в DB2 z/OS можно указать, кто будет управлять системой хранения – пользователь (администратор) или DB2. Для создания управляемых пользователем табличных пространств необходимо наличие наборов данных z/OS LDS VSAM, созданных при помощи программы IDCAMS. Этот метод позволит планировать систему хранения DB2 и точно размещать наборы данных DB2 на выбранных томах с прямым доступом. Для табличных пространств, управляемых DB2, DB2 z/OS предоставляет объект базы данных STOGROUP, называемый группой хранения (storage group). Можно назначить один или несколько томов с прямым доступом в отдельную группу хранения и использовать название этой группы при создании объектов. DB2 будет управлять пространством на перечисленных томах и размещать данные в доступных на них местах. С другой стороны, DB2 z/OS может управлять системой хранения совместно с другой подсистемой z/OS, называемой Storage Management System (SMS). В этом случае вся система хранения DB2 будет управляться правилами, написанными администраторами z/OS Storage. Этот метод применяется очень часто, поскольку он предоставляет администраторам полный контроль над системой хранения, , используемой различными пользователями. DB2 позволяет администраторам указывать отдельные SMS-конструкции при создании групп хранения DB2. В листинге 7 приведен пример определения системы хранения в DB2 z/OS.

Листинг 7. Типичное определение системы хранения в DB2 z/OS
-- Создать табличное пространство, управляемое пользователем, в базе данных TESTDB.
CREATE TABLESPACE USERTS USING VCAT DB2X  IN TESTDB;
-- Создать табличное пространство, управляемое не SMS.
CREATE STOGROUP dbasg  VOLUMES(VOLSER1,VOLSER2,VOLSER3) VCAT DB2T;
CREATE TABLESPACE NONSMSTS  USING STOGROUP dbasg  
 PRIQTY 1440 SECQTY 720;  
-- Создать табличное пространство, управляемое SMS посредством
-- операнда VOLUMES ('*').
CREATE STOGROUP smssg  VOLUMES('*')  VCAT DB2T;
CREATE TABLESPACE SMSTS1 USING STOGROUP smssg;
-- Создать группу системы хранения с использованием SMS-конструкций.
CREATE STOGROUP newsmssg VCAT DB2T 
   MGMTCLAS mgmt1 STORCLAS storclas1 DATACLAS dc1 ;

В DB2 z/OS для наборов данных LDS VSAM используются стандартные соглашения по именованию независимо от метода создания табличного пространства. При создании объекта, управляемого пользователем, DB2 вынуждает следовать аналогичным соглашениям по наименованию. Максимальный размер таких наборов данных LDS VSAM косвенно будет зависеть от типа создаваемого табличного пространства и параметров, указанных в выражении CREATE.


Методики перемещения данных

Если вы работаете администратором баз данных, то, наверное, уже выполняли перемещение табличных данных между платформами, одной из которых был сервер z/OS. DB2 z/OS поддерживает загрузку и выгрузку данных в формате с разделителями для свободного их перемещения между гетерогенными продуктами и платформами. В DB2 z/OS некоторые базовые утилиты поставляются вместе с самой DB2, но несколько утилит пакетируются в отдельный набор под названием Utilities Suite.

В свою очередь, утилиты DB2 LUW поставляются с самой DB2. Утилиты DB2 z/OS обычно запускаются при помощи программы DSNUTILB в пакетном режиме. Пакетные задания в z/OS кодируются на языке Job Control Language (JCL), как показано в листинге 8. Поэтому нужно ближе познакомиться с JCL перед началом использования утилит DB2 z/OS. Кроме утилиты LOAD, доступной также в DB2 z/OS, DB2 LUW предлагает EXPORT и IMPORT. Утилита IMPORT может выполнять последовательность операций вставки в таблицу, активизируя таким образом все триггеры, определенные в таблице, чего не происходит при перемещении данных в таблицу с помощью утилиты LOAD. В z/OS можно выполнять массовое перемещение данных, например, перемещение всей подсистемы DB2 или группы больших табличных пространств, используя утилиты DFSMSdss и автономные утилиты DB2. Для подобного массового перемещения данных в LUW можно использовать команды BACKUP и RESTORE с перенаправлением методов restore или программу db2move.

Листинг 8. Типичное задание z/OS JCL для выполнения утилит DB2
//*Строка 1 формулировки задания
//*Строка 2 формулировки задания
//*Будет выполняться для подсистемы DB2 DB2T
//STEP01   EXEC PGM=DSNUTILB,PARM='DB2T'                        
//STEPLIB  DD DISP=SHR,DSN=DB2.V9R1.DB2T.SDSNEXIT               
//         DD DISP=SHR,DSN=DB2.V9R1.SDSNLOAD                    
//SYSPRINT DD SYSOUT=*                                          
//SYSOUT   DD SYSOUT=*                                          
//SYSREC   DD DISP=SHR,DSN=DDS1923.TABLE.DATA
//SYSIN    DD *                                                 
    LOAD DATA RESUME NO LOG NO                                  
    INTO TABLE DEPT    
/*

Изучите свою среду перед запуском LOAD

Соображения по LOAD

  • В DB2 z/OS проверьте количество таблиц в табличном пространстве.
  • В DB2 LUW запланируйте INTEGRITY PENDING.
  • Используйте LOAD QUERY в DB2 LUW и -DIS UTILITY(util-id) в DB2 z/OS.

Хотя утилита Load доступна в версиях для обеих платформ, DB2 z/OS и DB2 LUW, между ними имеются существенные отличия. В DB2 z/OS утилита LOAD при запуске с функцией REPLACE очищает табличное пространство полностью. Поэтому желательно предварительно проверить, имеет ли табличное пространство более одной таблицы. DB2 LUW не поддерживает загрузку одного или нескольких разделов при наличии других разделов. С другой стороны, в DB2 z/OS можно выполнить утилиту load для набора сегментов, и DB2 будет загружать данные в эти сегменты, если они попадают в указанный диапазон. При загрузке DB2 LUW не проверяет ссылочную целостность (relational integrity – RI) данных. Вместо этого затронутые таблицы переводятся в состояние INTEGRITY PENDING. Это состояние эквивалентно состоянию CHECK PENDING в DB2 z/OS.

DB2 z/OS проверяет RI по умолчанию, позволяя при необходимости обойти эту проверку, и только после этого переводит табличное пространство в состояние CHECK PENDING. Если таблица имеет одно или несколько ограничений CHECK, DB2 z/OS при загрузке всегда будет проверять такие ограничения и отвергать строки, нарушающие их. DB2 LUW не выполняет такие проверки. Вместо этого она загружает все строки и переводит таблицу в состояние INTEGRITY PENDING.

В DB2 z/OS можно использовать утилиту UNLOAD. IBM поставляет также пример программы выгрузки под названием DSNTIAUL. Этот пример демонстрирует дополнительные возможности SQL (например, получение данных путем соединения таблиц), не поддерживаемые утилитой UNLOAD. Но утилита UNLOAD позволяет получить данные из ранее выполненных резервных копий; эта функциональная возможность помогает извлекать ретроспективные данные. При выполнении утилиты UNLOAD можно также сгенерировать соответствующее управляющее выражение LOAD и использовать его для загрузки данных в ту же или аналогичную таблицу в любой подсистеме DB2.

Проверка целостности данных

Листинг 9 показывает, как узнать, находится ли табличное пространство в состоянии CHECK PENDING. Для проверки целостности табличных данных можно проиндексировать ключи по строкам таблицы и строки по связанным LOB. При работе в DB2 z/OS можно выполнить утилиту CHECK, а при работе в DB2 LUW можно выполнить выражение SET INTEGRITY и/или команду INSPECT, как показано в листингах 10 и 11.

Листинг 9. Состояние CHECK PENDING, выводимое командой Display table space в DB2 z/OS
-DIS DB(TESTDB) SPACENAM(TESTTS) 
DSNT360I  DB1S ***********************************                       
DSNT361I  DB1S *  DISPLAY DATABASE SUMMARY                               
               *    GLOBAL                                               
DSNT360I  DB1S ***********************************                       
DSNT362I  DB1S     DATABASE = TESTDB  STATUS = RW                        
                  DBD LENGTH = 16142                                     
DSNT397I  DB1S                                                           
NAME     TYPE PART  STATUS            PHYERRLO PHYERRHI CATALOG  PIECE   
-------- ---- ----- ----------------- -------- -------- -------- -----   
TESTTS   TS    0001 RW,CHKP                                              
******* DISPLAY OF DATABASE TESTDB  ENDED      **********************
Листинг 10. Примеры утилиты CHECK для DB2 z/OS
-- Проверить нарушение ограничений CHECK и RI.
CHECK DATA dbname.tbspname SCOPE REFONLY

-- Проверить нарушения и, если они есть, поместить в таблицы исключений и 
-- удалить из исходной таблицы.
CHECK DATA dbname.tbspname 
FOR EXCEPTION in tabowner.tabname USE tabowner.excep_tabname
DELETE YES

-- Проверить все зависимые табличные пространства (содержащие все типы
-- зависимых таблиц) на нарушения RI, ограничения CHECK, LOB-значения и
-- XML-значения.
CHECK DATA dbname.tbspname SCOPE ALL

-- Проверить некорректные LOB-значения и LOB-ссылки.
CHECK LOB TABLESPACE dbname.lobtbsp

-- Проверить индекс на целостность табличных данных с одновременным
-- доступом по чтению/записи.
CHECK INDEX tabowner.indexname SHRLEVEL CHANGE

-- Проверить все индексы во всех таблицах табличного пространства 'tbspname' 
-- базы данных 'dbname'.
CHECK INDEX (ALL) TABLESPACE dbname.tbspname

-- Наконец, сбросить состояние CHECK PENDING без запуска проверки целостности.
REPAIR SET TABLESPACE dbname.tbspname NOCHECKPEND
Листинг 11. Проверка целостности в DB2 LUW
-- Пример запроса о состоянии и режимах доступа отдельных таблиц.
-- 'U' и 'Y' обозначают проверку целостности пользователем или
-- системой соответственно.
-- 'N' обозначает еще непроверенное ограничение.
$ db2 "select substr(creator,1,12) creator, substr(name,1,30) name, 
> case when access_mode='R' then 'Read Only'
> when access_mode='F' then 'Full access'
> when access_mode='N' then 'No Access'
> when access_mode='D' then 'No Data Movement'
> end as "Access mode",
> substr(const_checked,1,1) FK, substr(const_checked,2,1) CC 
> from sysibm.systables order by 4,5"

CREATOR      NAME                           Access mode      FK CC
------------ ------------------------------ ---------------- -- --
DB2INST1     EMPPROJACT                     No Access        N  Y
DB2INST1     ADEFUSR                        No Access        U  U
DB2INST1     EMPLOYEE                       No Access        N  N
DB2INST1     DEPARTMENT                     No Access        N  Y
DB2INST1     CL_SCHED                       Full access      Y  Y
DB2INST1     DEPT                           Full access      Y  Y

-- SET INTEGRITY не будет выполняться, если таблица не находится в состоянии
-- INTEGRITY PENDING, поэтому можно установить состояние INTEGRITY PENDING
-- для определенной таблицы автономно:
$ db2 "SET INTEGRITY FOR db2inst1.employee OFF CASCADE DEFERRED"

-- Перевести таблицу в состояние INTEGRITY PENDING с доступом по чтению
$ db2 "SET INTEGRITY FOR db2inst1.customer OFF READ ACCESS CASCADE DEFERRED"

-- Проверить нарушения ограничений CHECK и ссылочной целостности.
$ db2 "SET INTEGRITY FOR db2inst1.employee IMMEDIATE CHECKED"

-- Проверить нарушения и переместить некорректные строки в таблицы исключений.
$ db2 "SET INTEGRITY FOR db2inst1.employee IMMEDIATE CHECKED
> FOR EXCEPTION in db2inst1.employee USE db2inst1.emp_exception"

-- Сбросить состояние INTEGRITY PENDING для нарушений RI без выполнения
-- проверки. 
$ db2 "SET INTEGRITY FOR db2inst1.employee FOREIGN KEY IMMEDIATE UNCHECKED"

Методы резервирования и восстановления

Утилита/команда RECOVER доступна на обеих платформах, DB2 LUW и DB2 z/OS. RECOVER будет восстанавливать данные из последней по времени резервной копии, затем изменит данные по журналу транзакций, чтобы привести табличное пространство или базу данных в состояние на указанный момент времени. Чтобы узнать подробности о резервной копии (местоположение, RBA, время создания копии), необходимо выполнить запрос к таблице каталога DB2 SYSIBM.SYSCOPY аналогично использованию команды LIST HISTORY в DB2 LUW для чтения информации о восстановлении, хранящейся в файле DB2RHIST.ASC.

В DB2 LUW можно также использовать команду ROLLFORWARD DATABASE, обычно после восстановления оперативной копии (используя команду RESTORE DATABASE), для изменения данных по журналам восстановления. Утилита RECOVER в DB2 z/OS с LOGONLY работает аналогично ROLLFORWARD.

В DB2 z/OS для резервного копирования данных на различных уровнях можно использовать две следующие утилиты:

  • Утилита BACKUP SYSTEM:
    • Вся подсистема DB2 (с журналами или без) с использованием DFSMShsm-компонента z/OS SMS.
  • Программа COPY:
    • Все табличное пространство (несекционированная таблица или все разделы секционированной таблицы).
    • Набор разделов секционированной таблицы.
    • Индексное пространство, разрешенное для COPY.
    • Набор разделов секционированного индекса.
    • Конкретный набор данных несекционированного табличного пространства.
    • Конкретная часть несекционированного индекса.

Резервное копирование данных в DB2 LUW зависит от режима журналирования базы данных. Если для базы данных используется циклический режим журналирования, разрешено только автономное резервное копирование базы данных. Резервное копирование отдельных табличных пространств в этом режиме не поддерживается. Для базы данных можно разрешить режим архивного журналирования и начать оперативное резервное копирование базы данных, а также набора табличных пространств. В листинге 12 продемонстрированы методы оперативного резервного копирования и восстановления базы данных в DB2 LUW.

Листинг 12. Использование команд восстановления в DB2 LUW
-- Разрешить архивирование и выполнить оперативное резервное копирование.
$ db2 "backup db sample online"

Backup successful. The timestamp for this backup image is : 20110728153122

-- Выполнить восстановление; DB2 будет автоматически выбирать последнюю по  
-- времени создания резервную копию.
$ db2 "recover db sample to 2011-07-28-15.33.00.000000"

                                 Rollforward Status

 Input database alias                   = sample
 Number of nodes have returned status   = 1

 Node number                            = 0
 Rollforward status                     = not pending
 Next log file to be read               =
 Log files processed                    = S0000024.LOG - S0000025.LOG
 Last committed transaction             = 2011-07-28-15.31.32.000000 Local

DB20000I  The RECOVER DATABASE command completed successfully.

-- Можно также выполнить RESTORE из резервной копии, а после нее - ROLLFORWARD.
$ db2 "restore db sample taken at 20110728153122 without prompting"
SQL2540W  Restore is successful, however a warning "2539" was encountered
during Database Restore while processing in No Interrupt mode.

$ db2 "restore db sample logs taken at 20110728153122 logtarget /home/db2inst1/logs'
$ ls -l /home/db2inst1/logs
total 104
-rw-------    1 db2inst1 db2adm1       53248 Jul 28 15:53 S0000024.LOG

$ db2 "rollforward db sample query status using local time"

                                 Rollforward Status

 Input database alias                   = sample
 Number of nodes have returned status   = 1

 Node number                            = 0
 Rollforward status                     = DB  pending
 Next log file to be read               = S0000024.LOG
 Log files processed                    =  -
 Last committed transaction             = 2011-07-28-15.31.32.000000 Local

$ db2 "rollforward db sample to 2011-07-28-15.33.00.000000 using local time 
> and complete overflow log path (/home/db2inst1/logs)"
                                 Rollforward Status

 Input database alias                   = sample
 Number of nodes have returned status   = 1

 Node number                            = 0
 Rollforward status                     = not pending
 Next log file to be read               =
 Log files processed                    = S0000024.LOG - S0000025.LOG
 Last committed transaction             = 2011-07-28-15.31.32.000000 Local

DB20000I  The ROLLFORWARD command completed successfully.

В DB2 z/OS можно также выполнить утилиту REPORT RECOVERY для подготовки к восстановлению. При восстановлении табличного пространства в DB2 z/OS индексы, зависящие от затронутых таблиц, автоматически не создаются. Необходимо запланировать и создать эти индексы при помощи утилиты REBUILD INDEXES.

Очистка истории резервного копирования

Длительность хранения резервных копий обычно определяется бизнес-правилами. В DB2 z/OS следует выполнять утилиту MODIFY RECOVERY, чтобы удалить устаревшие записи для табличного пространства из таблицы каталога SYSIBM.SYSCOPY. Эта утилита не удаляет резервные копии наборов данных физически.

  • MODIFY RECOVERY dbname.tsname DELETE DATE(111201) – удалить все записи старше 01 декабря 2011.
  • MODIFY RECOVERY dbname.tsname DELETE AGE(60) – удалить все записи старше 60 дней.
  • MODIFY RECOVERY dbname.tsname RETAIN LAST(30) – удалить все записи, кроме 30 последних по времени.

В DB2 LUW, например, команда PRUNE HISTORY 201105 выполняет удаление записей старше мая 2011 года. DB2 будет сама подставлять значения месяца, даты и других полей временной отметки, если вы их не укажете. Добавив в предыдущую команду AND DELETE, можно физически удалить резервные копии.

Несколько слов о QUIESCE

Несмотря на то, что QUIESCE доступна в обеих системах (в DB2 z/OS и DB2 LUW), обычно эта команда/утилита используется по-разному. В DB2 z/OS можно установить точку регистрации (log point) целостности данных, позволяющую выполнить восстановление до состояния на определенный момент времени (Point In Time – PIT). При выполнении команды QUIESCE TABLESPACE dbname.tbspname DB2 запишет на диск все страницы из буферов, а также запишет номер последовательности журнала (Relative Byte Address/RBA или Log Range Sequence Number/LRSN) в таблицу SYSIBM.SYSCOPY. Это может потребоваться при невозможности частого резервного копирования или для принудительной выгрузки измененных страниц из буферных пулов до выполнения копирования вне DB2. Для выполнения PIT-восстановления можно использовать записанный RBA в команде RECOVER TABLESPACE.

В DB2 LUW, в свою очередь, QUIESCE активизирует постоянный режим блокировки, который можно применить к экземпляру, базе данных или табличному пространству для ограничения доступа обычных пользователей во время выполнения обслуживания. После завершения обслуживания следует выполнить одну из команд UNQUIESCE INSTANCE db2inst1, UNQUIESCE DB sampledb или QUIESCE TABLESPACES FOR TABLE myschema.tabname RESET, чтобы разрешить доступ к данным.


Обслуживание данных

Для поддержки данных в работоспособном состоянии на обеих платформах используются утилиты REORG и RUNSTATS. На обеих платформах доступна также статистическая информация в режиме реального времени (Real Time Statistics – RTS). Для обслуживания индексов в DB2 z/OS есть две следующие утилиты: REORG INDEX и REBUILD INDEX. В DB2 LUW команда REORG INDEX может выполнять обе эти функции. Поскольку утилиты DB2 z/OS выполняются либо на уровне табличных пространств, либо на уровне разделов секционированных таблиц, они будут действовать на все таблицы в табличном пространстве. Следовательно, при работе в DB2 z/OS можно за один раз реорганизовать более одной таблицы или перестроить индексы более чем по одной таблице. В таблице 1 перечисляются и сравниваются методы обслуживания данных, доступные на этих платформах.

Таблица 1. Различные цели и способы выполнения REORG
ЦельВ DB2 z/OSВ DB2 LUW
Реорганизация несекционированного индексаREORG INDEX creator.ixnameREORG INDEX schema.npi_index CLEANUP ONLY
Перестройка несекционированного индексаREBUILD INDEX (creator.ixname)REORG INDEX schema.npi_index
Перестройка всех индексов табличного пространства, содержащего одну таблицуREBUILD INDEX (ALL) TABLESPACE dbname.tbspaceREORG INDEXES ALL FOR TABLE myschema.tabname
Реорганизация раздела секционированного индексаREORG INDEX creator.ixname PART 10Не поддерживается
Автономная реорганизация табличного пространства, содержащего одну таблицуREORG TABLESPACE creator.ixname SHRLEVEL NONEREORG TABLE ALLOW NO ACCESS
Оперативная реорганизация табличного пространства, содержащего одну таблицуЗадайте SHRLEVEL CHANGE и используйте MAPPINGTABLEЗадайте INPLACE ALLOW WRITE ACCESS
Реорганизация двух или более последовательных разделов таблицыREORG TABLESPACE dbname.tsname PART m:n Не поддерживается
Оперативная реорганизация секционированной таблицы, имеющей, по крайней мере, один несекционированный индексПоддерживаетсяНе поддерживается
Проверка необходимости реорганизацииВыполните утилиту RUNSTATS и запрос таблиц каталога или выполните REORG TABLESPACE с ключевыми словами OFFPOSLIMIT m INDREFLIMIT n и REPORTONLY; выполните REORG INDEX с ключевыми словами LEAFDIST n и REPORTONLYREORGCHK ON TABLE myschema.tabname

Мониторинг DB2

В DB2 LUW перед началом мониторинга DB2 на уровне любых объектов необходимо включить переключатели Database Monitor (DBM). Можно выполнить команду GET DBM M0NITOR SWITCHES для отображения уровня мониторинга на сервере.

Аналогично, в DB2 z/OS имеются трассировки различного типа, которые будут выполняться на уровне подсистемы для сбора информации, обычно требующейся для мониторинга и настройки производительности. При выполнении задач мониторинга можно запускать и останавливать трассировку или задать в подсистеме DSNZPARM автоматический запуск и останов трассировок системой DB2.

Листинг 13. Отображение активных трассировок и их назначений в DB2 z/OS
-DIS TRACE(*)                               
 DSNW127I  DB1S CURRENT TRACE ACTIVITY IS - 
 TNO TYPE   CLASS        DEST QUAL IFCID    
 01  STAT   01,03,04,05, SMF  NO            
 01         06,08                           
 02  AUDIT  01           SMF  NO            
 03  ACCTG  01,02,03,07, SMF  NO            
 03         08                              
 04  MON    01           OP1  NO            
 05  AUDIT  03           OP1  NO            
 06  AUDIT  01,02,04,05, OP1  NO   090,091

Функциональность System Management Facility (SMF), отображенная в предыдущем листинге как назначение (DEST), – это вспомогательная информация z/OS, используемая различными подсистемами z/OS для записи разных элементов трассировки. Для чтения записей SMF можно использовать специально написанные подпрограммы (либо собственные, либо приобретенные у поставщика) для формирования пакетных отчетов по конкретному событию или объекту DB2. Кроме того, для отображения текущего состояние подсистемы DB2 или ее приложений/потоков можно использовать средства мониторинга, такие как IBM Tivoli OMEGAMON XE (необходимо приобретать отдельно).

Другие вспомогательные средства для мониторинга и поиска неисправностей в DB2 LUW:

  • db2pd – используется для выдачи информации (аналогичной формируемой программой Snapshot Monitor) об используемой DB2 памяти.
  • db2mtrk – используется для отслеживания или выдачи информации о памяти для баз данных, экземпляров и приложений.
  • db2top – средство мониторинга (для AIX, Linux и Solaris), которое можно запускать в оперативном или пакетном режиме.

В DB2 LUW мониторинг можно выполнять при помощи программ Event Monitor и Snapshot Monitor. Event Monitor можно настроить на конкретный тип событий и в зависимости от этого типа указать DB2 записывать собранную информацию в таблицы DB2, файлы, каналы или в таблицу Unformatted Event Table (новая функциональность в DB2 9.7).

Можно также использовать определенные вспомогательные средства, например, команды db2evtb или db2evmon, при работе с мониторами файловых или табличных событий соответственно. В DB2 LUW при мониторинге экземпляра или базы данных DB2 можно также использовать различные административные представления в схеме SYSIBMADM. Эти динамические представления отображают текущее состояние системы, сгенерированное программой Snapshot Monitor. Можно также собрать эту информацию при помощи команды GET SNAPSHOT или различных snapshot-функций. В листинге 14 приведен пример создания и администрирования Event Monitor в DB2 LUW.

Листинг 14. Выполнение простого монитора событий в DB2 LUW
-- Создать простой монитор событий для каждого выражения 
$ db2 "CREATE EVENT MONITOR file_event_stmt FOR STATEMENTS
> WRITE TO FILE 'stmtevent' MANUALSTART"
-- Событие еще не началось из-за ключевого слова MANUALSTART
$ db2 "SELECT SUBSTR(EVMONNAME,1,18) EVMONNAME, CASE WHEN
> EVENT_MON_STATE(EVMONNAME)=0 THEN 'STOPPED'
> WHEN EVENT_MON_STATE(EVMONNAME)=1 THEN 'STARTED' END AS STATUS
> FROM SYSCAT.EVENTMONITORS"

EVMONNAME          STATUS
------------------ -------
DB2DETAILDEADLOCK  STARTED
FILE_EVENT_STMT    STOPPED

  2 record(s) selected.
-- Проверить наличие целевого каталога и запустить событие
$ db2 "SET EVENT MONITOR FILE_EVENT_STMT STATE=1"
-- Форматирование выходных данных о событии DB2 
$ db2evmon -path /home/db2inst1/db2inst1/NODE0000/SQL00002/db2event/stmtevent > event_out

Доступность и масштабируемость

Совместное использование данных DB2

  • Работает на z/OS Parallel Sysplex.
  • Все члены DB2 размещаются на одном и том же многомашинном кластере.
  • Члены DB2 совместно используют каталог и данные.
  • К преимуществам относятся повышенная доступность, равномерное распределение рабочей нагрузки, поддержка инкрементного расширения, гибкость в обслуживании/обновлении.
  • Поддерживает групповой доступ, доступ определенных членов и доступ одного члена.

Для улучшения доступности данных и серверов данных IBM совершенствует функциональность в каждой новой версии DB2. Одним из таких решений высокой готовности является функциональность DB2 Data Sharing for z/OS, основанная на аппаратных и программных компонентах z/OS.

Совместное использование данных обеспечивается путем формирования двух и более подсистем DB2, обычно работающих на различных физических машинах в z/OS Parallel Sysplex. Отдельные подсистемы DB2, называемые членами, представляют данные для инициаторов запроса данных и совместно используют данные на диске. При подключении к такой группе совместного использования данных DB2 будет запускать задание на доступном члене, имеющем свободные ресурсы. Одна или несколько машин z/OS выступают в качестве Coupling Facility, в которой создаются такие компоненты DB2, как групповые буферные пулы, структура блокировки или совместно используемая область связи для эффективного управления доступом к данным. Такое решение предоставляет также самый простой способ выполнить миграцию и обслуживание отдельных подсистем DB2. Масштабирование серверов DB2 сводится к простому добавлению одного или нескольких членов к существующей группе совместного использования данных.

Функциональность DB2 pureScale Feature, доступная в Linux и UNIX, аналогична функциональности DB2 Data Sharing в z/OS. Ссылки на дополнительную информацию по сравнению двух этих функциональных возможностей приведены в разделе Ресурсы. Отметим, что эта функциональность доступна только как отдельно приобретаемая опция для серверов Enterprise Server Edition и Advanced Enterprise Server Edition.

Еще один способ масштабирования серверов баз данных, называемый Database Partitioning Feature (DPF), позволяет распространять данные на несколько разделов (узлов). DB2 распределяет все табличные данные по разделам базы данных, размещенным на разных физических машинах, на основе карты распределения. В DB2 LUW 9.7 функциональность DPF больше не входит в состав редакций DB2, а предоставляется со всеми версиями IBM InfoSphere Warehouse.

DB2 LUW также предлагает следующие возможности высокой готовности:

  • Автоматическое перенаправление клиента. На главном сервере при помощи команды UPDATE ALTERNATE SERVER FOR DATABASE можно зарегистрировать альтернативный сервер DB2 LUW. Клиенты, подключающиеся к главному серверу DB2 по протоколу TCP/IP, смогут подключаться к указанному альтернативному серверу при потере связи с главным.
  • High Availability Disaster Recovery (HADR) – быстрое восстановление после сбоев. Это решение подразумевает использование дополнительного сервера DB2, выступающего в качестве резервного и способного принять управление на себя в случае выхода со строя главного сервера. Функцию HADR можно запустить после конфигурирования (посредством различных параметров) главной и резервной базы данных и восстановления главной базы данных на резервной системе. Сервер DB2 будет автоматически регистрировать изменения главной базы данных на резервном сервере. Методику автоматического перенаправления клиента можно использовать для HADR-баз данных.

Заключение

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


Благодарности

Автор хотел бы поблагодарить своих коллег Кена Тейлора (Ken Taylor), Камаллу Хэйли Барува (Camalla Haley Baruwa) и Рамеша Чеджарла (Ramesh Chejarla) за ценные комментарии к статье.

Ресурсы

Комментарии

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=853191
ArticleTitle=Сравнение DB2 для z/OS и DB2 для Linux, UNIX и Windows
publish-date=12212012