Введение

Утилита db2relocatedb является частью СУБД DB2 UDB версий V7 и V8 и может быть весьма мощным инструментом в руках администратора базы данных, который хорошо знает ее возможности и умеет с ней обращаться. Эта утилита позволяет перемещать всю базу данных, либо один или несколько контейнеров табличных пространств из одного физического местоположения в другое без необходимости выполнения резервного копирования и восстановления (процессов, которые могут отнимать значительное количество ресурсов и времени). Также утилита db2relocatedb позволяет переименовывать базы данных и переводить базу данных с одного экземпляра сервера базы данных на другой.

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

В начало

Что представляет собой db2relocatedb?

Помимо данных, вносимых пользователями, база данных DB2 содержит целый набор внутренних метаданных, описывающих, где можно найти эти данные, кому они принадлежат и как они связаны между собой. Управление метаданными всегда скрыто за внутренними механизмами DB2 и недоступно напрямую для пользователей и администраторов БД. На простейшем уровне db2relocatedb является тем инструментом, который может изменять метаданные в тех случаях, когда это нельзя сделать другими способами или когда для этого потребовалось бы выполнить слишком много действий (по сравнению с использованием db2relocatedb), приводящих к неприемлемым простоям в работе.

Например, можно изменить имя и путь базы данных с помощью команд архивации и восстановления DB2. При этом база данных архивируется и восстанавливается под новым именем и/или в новом местоположении. Архивация может производиться в онлайновом режиме, однако восстановление базы данных выполняется в автономном режиме, и время, когда база данных будет недоступна, может превышать допустимый предел.

Другой пример – изменение местоположение контейнера табличного пространства. Это также можно сделать с помощью команд архивации и восстановления (точнее говоря, с помощью переадресованного восстановления). Тем не менее, если табличное пространство управляется базой данных (табличное пространство DMS), то для того, чтобы сначала добавить контейнер в новое местоположение, а затем удалить его из старого местоположения, можно использовать SQL-оператор ALTER TABLESPACE. Недостатком такого подхода является то, что такие операции необходимо выполнять последовательно, и после каждого из таких шагов может происходить ребалансировка табличного пространства.

Те же самые задачи можно выполнить с помощью утилиты db2relocatedb, и во многих случаях на это уйдет меньше времени (и усилий), чем при работе "внутри" DB2. Но это далеко не все, что позволяет делать db2relocatedb. Ниже перечислены все задачи, при выполнении которых эта утилита может оказаться полезной:

• Изменение имени базы данных
• Изменение директории/диска, на котором хранится база данных
• Изменение одного или нескольких контейнеров табличных пространств
• Изменение пути журнала регистрации событий, связанного с базой данных
• Изменение экземпляра сервера БД, связанного с базой данных
• Копирование/перемещение базы данных (на тот же или на другой компьютер) и изменение одного или нескольких из вышеупомянутых параметров

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

В начало

Где можно найти эту утилиту?

Утилита db2relocatedb впервые появилась в составе пакета исправлений DB2 UDB V7 Fixpak 4. Изначально ее описание содержалось в примечаниях к выпуску, но затем оно было добавлено в документацию по продукту. Также db2relocatedb входит в состав всех редакций версии V8.

Утилита db2relocatedb – это приложение на стороне сервера (т. е. выполняемое в той же системе, в которой находится база данных), поэтому она является частью любой серверной установки. В зависимости от платформы эту утилиту можно найти по следующему пути:

UNIX: Директория экземпляра/sqllib/bin/db2relocatedb
Windows: Буква диска\sqllib\bin\db2relocatedb.exe

В начало

Основы

Синтаксис утилиты db2relocatedb описан в документации, но эту информацию можно также получить из командной строки. В DB2 версии V7 для этого можно просто выполнить команду db2relocatedb, не указывая никаких параметров. В версии V8 вы получите ошибку DBT1017N, сообщающую о том, что вы использовали неверный синтаксис. Тем не менее вы можете получить расширенное описание этой ошибки, выполнив команду db2 ? dbt1017n, в результате чего вам будет показан полный синтаксис утилиты:

DBT1017N The syntax of the DB2RELOCATEDB tool is incorrect.

Explanation:

 The DB2RELOCATEDB tool has the following syntax:
     db2relocatedb -f <config_file>

 <configFile>: Name of file containing  configuration information.

 # Утилита DB2RELOCATEDB имеет следующий синтаксис:
 # db2relocatedb -f <файл_конфигурации>

 # <файл_конфигурации> - имя файла, содержащего конфигурационную информацию.

 File format is:

       DB_NAME=oldName,newName
       DB_PATH=oldPath,newPath
       INSTANCE=oldInst,newInst
       NODENUM=nodeNumber
       LOG_DIR=oldDirPath,newDirPath
       CONT_PATH=oldContPath1,newContPath1
       CONT_PATH=oldContPath2,newContPath2
       ...

 #  Формат файла:
 # 
 #     DB_NAME=староеИмя,новоеИмя 
 #     DB_PATH=старыйПуть,новыйПуть
 #     INSTANCE=старыйЭкземпляр,новыйЭкземпляр
 #     NODENUM=номерРаздела
 #     LOG_DIR=стараяДиректория,новаяДиректория
 #     CONT_PATH=старыйПутьКонтейнера1,новыйПутьКонтейнера1
 #     CONT_PATH= старыйПутьКонтейнера2,новыйПутьКонтейнера2
 #      ...

 Notes:

o   Database name, database path, and instance name are all
    required fields.  If one of these fields is not changing then
    it is not necessary to list the old and new value for it,
    just give the old/current one.

o   Blank lines or lines beginning with a comment character (#)
    will be ignored.
    
 #   Примечания:
 #
 #    o Нужно обязательно указывать имя и местоположение
 #       базы данных, а также имя экземпляра.
 #       Если какое-то из этих полей не меняет своего значения,
 #       то указывать новое значения для него не обязательно,
 #       просто укажите старое (текущее) значение.
 #
 #    o   Пустые строки или строки, начинающиеся со знака решетки (#),
 #        игнорируются.  

Как видно из вышеприведенного листинга, утилита требует указания конфигурационного файла, в котором указывается, какие параметры внутренней структуры базы данных будут изменены (не забывайте, что фактическое перемещение необходимых файлов выполняет сам пользователь). Ниже приведено подробное описание всех параметров конфигурационного файла:

DB_NAME: обязательный параметр – имя базы данных. Если имя базы данных не изменяется, то вам необходимо указать лишь текущее имя (т. е., новое имя указывать не обязательно). Однако если вы изменяете имя базы данных, вы должны перечислить через запятую оба имени - как старое, так и новое.

DB_PATH: обязательный параметр – местоположение базы данных, которое было указано при ее создании. Если путь к базе данных не изменяется, то вам необходимо указать лишь ее текущее местоположение. Однако если вы изменяете местоположение базы данных, вы должны перечислить через запятую оба пути к ней - как старый, так и новый.

INSTANCE: обязательный параметр – имя экземпляра сервера DB2. Если имя экземпляра не изменяется, вам необходимо указать лишь текущее имя. В противном случае вы должны перечислить через запятую имена обоих экземпляров - как старого, так и нового.

NODENUM: необязательный параметр – номер раздела базы данных, с которым вы работаете. Если значение этого параметра не указывается, то используется значение по умолчанию, равное 0. Для получения дополнительной информации по использованию этого параметра обратитесь к разделу "Базы данных с несколькими разделами".

LOG_DIR: необязательный параметр – местоположение log-файлов базы данных. Обычно для изменения пути, по которому располагаются log-файлы, используют команду UPDATE DB CFG USING NEWLOGPATH, однако это можно сделать и с помощью утилиты db2relocatedb.

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

Если вы хотите произвести несколько одинаковых изменений (например, перемещение из одной общей директории в другую), вы можете использовать подстановочный знак звездочки, как в следующем примере:

  CONT_PATH=/староеМестоположение/*,/новоеМестоположение/*


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

В начало

Директория базы данных

В момент создания базы данных DB2 создается директория, в которой хранятся табличные пространства по умолчанию, а также различные управляющие файлы (например, SQLSPCS.1/2 и SQLDBCON). Местоположение этой директории определяется на основе информации, указанной пользователем (путь базы данных), и информации о конфигурации среды (имя экземпляра и номер раздела/сегмента).

Обратите внимание: если не указать путь к базе данных при ее создании, будет использоваться значение конфигурационного параметра DFTDBPATH. По умолчанию его значением будет являться домашняя директория владельца экземпляра в UNIX или директория установки СУБД DB2 в Windows.

Давайте рассмотрим несколько простых примеров и посмотрим, как DB2 определяет местоположение директории базы данных.

Пример 1. База данных с одним разделом

Внутри экземпляра db2inst1 выполняется следующий оператор:

  CREATE DATABASE TESTDB ON /db2/путьБазыДанных

База данных DB2 будет создана в следующей директории:

 /db2/путьБазыДанных/db2inst1/NODE0000/SQL00001

Как вы видите, сначала DB2 использует путь, указанный в операторе CREATE DATABASE (в нашем примере это /db2/путьБазыДанных). Затем к нему добавляется имя экземпляра (/db2inst1). После этого добавляется номер раздела базы данных (/NODE0000). В нашем примере разделу присваивается значение 0, поскольку мы имеем дело с однораздельной базой данных. Наконец, к полученному значению добавляется директория вида SQL#####, обеспечивающая уникальность полного пути (/SQL00001) и отделяющая базу данных от остальных баз, которые могут быть созданы в той же директории. При создании дополнительных баз данных им назначаются директории SQL00001, SQL00002, SQL00003 и т. д.

Пример 2. База данных с несколькими разделами

Экземпляр db2mpp будет располагаться в трех разделах (0, 10 и 20). С помощью следующего оператора создается база данных с тремя разделами:

  CREATE DATABASE MPPDB ON /база_данных

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

 /база_данных/db2mpp/NODE0000/SQL00001
 /база_данных/db2mpp/NODE0010/SQL00001
 /база_данных/db2mpp/NODE0020/SQL00001


В дополнение к этому DB2 создаст директорию с именем sqldbdir. Она будет располагаться по тому же пути, что и директории SQL#####. В последнем примере будут созданы следующие директории:

 /db2/путьБазыДанных/db2inst1/NODE0000/sqldbdir

 /база_данных/db2mpp/NODE0000/sqldbdir
 /база_данных/db2mpp/NODE0010/sqldbdir
 /база_данных/db2mpp/NODE0020/sqldbdir


Информация, хранящаяся в директории sqldbdir, называется каталогом тома базы данных, или каталогом локальной базы данных. Эта информация сообщает вам следующее: "вы можете найти базу данных TESTDB в каталоге SQL00001". Вы можете получить ее, выполнив команду LIST DB DIRECTORY ON <путь>. Важно помнить, что эта директория является критичной для работы DB2 (и любого другого инструмента, такого как db2relocatedb), поскольку без нее найти базу данных будет невозможно. Как вы увидите в следующих примерах, эту директорию необходимо перемещать или копировать при каждом перемещении или копировании базы данных с использованием db2relocatedb.

В начало

Базы данных с несколькими разделами

Если необходимо внести изменения в многораздельную базу данных (в случае использования редакции DB2 UDB EEE для версии V7 или редакции DB2 UDB ESE с функцией разделения данных для версии V8), необходимо учитывать следующие моменты.

• Во-первых, каждый раздел имеет свой собственный набор метаданных. Вследствие этого в большинстве случаев вам потребуется запустить утилиту в каждом разделе. В случае изменения имени экземпляра, имени базы данных или пути базы данных требуется внести изменения во все разделы. Если этого не сделать, база данных либо не запустится, либо вы можете столкнуться с непредвиденными проблемами при дальнейшей работе. Тем не менее, если вы хотите изменить местоположение только одного контейнера табличного пространства на одном из разделов, вам достаточно запустить утилиту db2relocatedb лишь в этом разделе.
  
  
• Во-вторых, для каждого раздела, в котором вы планируете запустить утилиту db2relocatedb, необходимо создать отдельный файл конфигурации. Причина этого заключается в необходимости использования параметра NODENUM, значение которого должно совпадать с номером раздела, в котором используется утилита.
  
  
• В-третьих, утилиту нельзя использовать для изменения номера раздела, связанного с разделом базы данных. Например, раздел базы данных с номером 10 не может стать разделом базы данных с номером 20.
  
  
• Наконец, параметр NODENUM НЕ обеспечивает того, что утилита db2relocatedb будет выполняться в указанном разделе. Другими словами, если в конфигурации значение параметра NODENUM равно 10, но вы запускаете утилиту в разделе базы данных с номером 0 (физически расположенном на другом компьютере), то она не найдет раздел с номером 10, чтобы запуститься в нем. Как уже было сказано, некоторая информация (например, значение параметра NODENUM в случае многораздельной базы данных) должна присутствовать в конфигурационном файле независимо от того, модифицируется ли значение параметра или нет. Это необходимо для того, чтобы утилита могла найти базу данных и ее файлы, расположение которых основано на имени экземпляра, пути и номере раздела БД.

В начало

Примеры

Примечание. Перед запуском утилиты db2relocatedb база данных должна быть остановлена.

Пример 1. Изменение имени базы данных с одним разделом

Имя базы данных: TESTDB
Путь базы данных: /home/db2inst
Имя экземпляра: db2inst


Сценарий: вы хотите изменить имя базы данных с TESTDB на NEWNAME.

Конфигурационный файл "example1.cfg"

DB_NAME=TESTDB,NEWNAME
DB_PATH=/home/db2inst
INSTANCE=db2inst

Команда:

  db2relocatedb –f example1.cfg

Пример 2. Изменение имени базы данных с несколькими разделами

Имя базы данных: PRODUCTS
Путь базы данных: /dbdir
Имя экземпляра: db2mpp1
Разделы: 1, 2, 3


Сценарий: вы хотите изменить имя базы данных с тремя разделами с PRODUCTS на OLDPROD.

Конфигурационный файл "example2-1.cfg"

DB_NAME=PRODUCTS,OLDPROD
DB_PATH=/db2dir
INSTANCE=db2mpp1
NODENUM=1
    

Конфигурационный файл "example2-2.cfg"

DB_NAME=PRODUCTS,OLDPROD
DB_PATH=/db2dir
INSTANCE=db2mpp1
NODENUM=2
    

Конфигурационный файл "example2-3.cfg"

DB_NAME=PRODUCTS,OLDPROD
DB_PATH=/db2dir
INSTANCE=db2mpp1
NODENUM=3
    

Команды:

  { If on different physical machines, go to node 1 (else "export DB2NODE=1") }
  db2relocatedb –f example2-1.cfg

  { If on different physical machines, go to node 2 (else "export DB2NODE=2") }
  db2relocatedb –f example2-2.cfg

  { If on different physical machines, go to node 3 (else "export DB2NODE=3") }
  db2relocatedb –f example2-3.cfg


Если вы являетесь опытным администратором многораздельных баз данных, вы, возможно, сможете предложить более удобный способ, позволяющий избежать отдельного выполнения команд в каждом разделе. Например, можно было бы хранить все файлы в местоположении, доступном для всех разделов, и выполнять команду, подобную следующей:

  db2_all "db2relocatedb –f {общее_местоположение}/example2-\$DB2NODE.cfg"


Пример 3. Изменение пути базы данных

Имя базы данных: SALES
Путь базы данных: /home/kschlamb
Имя экземпляра: kschlamb


Сценарий: размер домашней директории экземпляра БД оказался меньше необходимого. Вы решили изменить путь базы данных на /salesdb.

Как уже было сказано, при создании базы данных создаются следующие директории:

  /home/kschlamb/kschlamb/NODE0000/SQL00001
  /home/kschlamb/kschlamb/NODE0000/sqldbdir


Первым шагом вам необходимо вручную переместить эти две директории в местоположение, указанное ниже. Помните, что путь базы данных – это лишь часть структуры каталогов DB2, и это необходимо учитывать при задании нового местоположения. Для перемещения файлов вы можете использовать любую команду операционной системы (например, cp/rm, mv, tar).

  /salesdb/kschlamb/NODE0000/SQL00001
  /salesdb/kschlamb/NODE0000/sqldbdir


Следующим шагом необходимо создать файл конфигурации и запустить утилиту db2relocatedb.

Конфигурационный файл "example3.cfg"

DB_NAME=SALES
DB_PATH=/home/kschlamb,/salesdb
INSTANCE=kschlamb
    

Команда:

  db2relocatedb –f example3.cfg


Пример 4. Изменение контейнеров табличных пространств

Имя базы данных: FINANCE
Путь базы данных: /finance/database
Имя экземпляра: fin


Сценарий: у вас имеется три большие файловые системы – /finance/fs1, /finance/fs2 и /finance/fs3. Вы распределяете табличное пространство между этими тремя файловыми системами с помощью следующего SQL-оператора:

  CREATE TABLESPACE BIGTS MANAGED BY SYSTEM USING
    ('/financ/fs1/BIGTS', '/financ/fs2/BIGTS', '/financ/fs3/BIGTS')


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

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

Независимо от того, какой из этих способов вы будете использовать, сначала необходимо переместить из старого местоположения в новое следующие директории (помните, что мы создали табличное пространство, управляемое системой; в случае табличного пространства, управляемого базой данных, вместо директорий нужно будет переносить DMS-файлы):

  /financ/fs1/BIGTS   =>   /finance/fs1/BIGTS
  /financ/fs2/BIGTS   =>   /finance/fs2/BIGTS
  /financ/fs3/BIGTS   =>   /finance/fs3/BIGTS


Далее необходимо создать файл конфигурации и запустить утилиту db2relocatedb.

Конфигурационный файл "example4.cfg"

DB_NAME=FINANCE
DB_PATH=/finance/database
INSTANCE=fin
CONT_PATH=/financ/fs1/BIGTS,/finance/fs1/BIGTS
CONT_PATH=/financ/fs2/BIGTS,/finance/fs2/BIGTS
CONT_PATH=/financ/fs3/BIGTS,/finance/fs3/BIGTS
#
# Мы также можем использовать подстановочные 
# символы,чтобы внести все изменения 
# с помощью одной команды.
# Вместо трех вышеприведенных операторов можно 
# использовать любой из следующих:
#
#  CONT_PATH=/financ/fs*,/finance/fs*
#  CONT_PATH=/financ/*,/finance/*
#  CONT_PATH=/financ*,/finance*
    

Команда:

  db2relocatedb –f example4.cfg


Пример 5. Перемещение базы данных на новый компьютер (изменение имени экземпляра, пути и имени базы данных)

Имя базы данных: TESTDB
Путь базы данных: /testinst_filesystem
Имя экземпляра: testinst


Сценарий: у вас имеется тестовая база данных, которую необходимо перенести в рабочую среду. Для этого база данных переносится в экземпляр с названием prodinst, ее имя меняется на PRODDB, а путем БД становится директория /proddb.

Как уже было сказано, при создании базы данных создаются следующие директории:

  /testinst_filesystem/testinst/NODE0000/SQL00001
  /testinst_filesystem/testinst/NODE0000/sqldbdir


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

  /proddb/prodinst/NODE0000/SQL00001
  /proddb/prodinst/NODE0000/sqldbdir


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

При некоторых способах копирования файлов их хозяином может остаться владелец старого экземпляра. Чтобы передать файлы владельцу нового экземпляра, используйте команду "chown".

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

Конфигурационный файл "example5.cfg"

DB_NAME=TESTDB,PRODDB
DB_PATH=/testinst_filesystem,/proddb
INSTANCE=testinst,prodinst
    

Команда:

  db2relocatedb –f example5.cfg


Пример 6. Усложненный вариант

Имя базы данных: TESTDB
Путь базы данных: /db2/Databases
Имя экземпляра: db2inst


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

  /db2/Databases/db2inst/NODE0000/SQL00001/*
  /db2/Databases/db2inst/NODE0000/sqldbdir/*
  /db2/Databases/DMS1
  /db2/Databases/SMS1/*
  /largedir/DMS2
  /largedir/SMS2/*
  /dev/rDMS3


Сценарий: база данных переносится таким образом, что имя и путь изменяются на NEWDB и /dbdirectory соответственно. В дополнение к этому контейнеры DMS2 и SMS2 переносятся из директории /largedir в директорию /dbdirectory. Местоположение контейнеров DMS1 и SMS1 по отношению к каталогу базы данных не меняется.

После останова базы данных администратор БД должен вручную переместить файлы/директории из вышеперечисленных местоположений в следующие местоположения:

  /dbdirectory/db2inst/NODE0000/SQL00001/*
  /dbdirectory/db2inst/NODE0000/sqldbdir/*
  /dbdirectory/DMS1
  /dbdirectory/SMS1/*
  /dbdirectory/DMS2
  /dbdirectory/SMS2/*
  /dev/rDMS3 {без изменений}


Следующим шагом необходимо создать файл конфигурации и запустить утилиту db2relocatedb. Обратите внимание на то, что db2relocatedb предполагает, что все контейнеры, расположенные по старому пути, переносятся в новое местоположение, поэтому нет необходимости использовать параметр CONT_PATH для контейнеров DMS1 и SMS1. Этот параметр необходимо указать только для контейнеров SMS2 и DMS2.

Конфигурационный параметр "example6.cfg"

DB_NAME=TESTDB,NEWDB
DB_PATH=/db2/Databases,/dbdirectory
INSTANCE=db2inst
CONT_PATH=/largedir/DMS2,/dbdirectory/DMS2
CONT_PATH=/largedir/SMS2,/dbdirectory/SMS2
#
# Вместо двух последних строк можно
# использовать следующую строку:
#
#  CONT_PATH=/largedir/*,/dbdirectory/*
    

Команда:

  db2relocatedb –f example6.cfg

В начало

Полезные советы и приемы

• Все примеры в этой статье даны для операционной системы UNIX. Тем не менее их можно использовать и для платформы Windows (за исключением того, что в качестве путей базы данных можно использовать лишь буквы дисков).
  
  
• Утилита db2relocatedb работает в оффлайновом режиме. Ее нельзя использовать, если база данных не остановлена. Данная утилита не использует в своей работе механизмы базы данных и может разрушить работающую систему (что может привести к порче данных и невозможности запуска БД).
  
  
• Изменения, вносимые утилитой db2relocatedb в файлы и управляющие структуры базы данных, нигде не протоколируются и поэтому необратимы. Вследствие этого после применения утилиты настоятельно рекомендуется выполнить полную архивацию (особенно если база данных является восстанавливаемой с помощью сохраняемых log-файлов).
  
  
• Если вы производите значительные изменения или действия, которые будет сложно отменить, подумайте о том, чтобы сделать резервную копию базы данных, прежде чем выполнять эти действия.
  
  
• Если вы используете технологию разделенного зеркального резервирования DB2 ("split/mirror") и утилиту db2inidb, вы можете воспользоваться опцией RELOCATE USING для скрытого вызова db2relocatedb в процессе инициализации резервной системы. Это может оказаться полезным при создании резервной системы с внутренними путями, отличающимися от путей, используемых в основной системе.
  
  
• Хотя утилита db2relocatedb позволяет изменять местоположения контейнеров табличных пространств, она не позволяет изменять их количество и размер (для табличных пространств, управляемых базой данных). Это можно сделать только с помощью переадресованного восстановления.
  
  
• Если вы переносите базу данных из местоположения, в котором расположены другие базы данных, обязательно копируйте директорию sqldbdir, а не перемещайте ее. Помните, что эта директория нужна DB2 для того, чтобы можно было определить местоположение остальных баз.
  
  
• Если вы переносите или копируете базу данных из местоположения, в котором расположены другие базы данных, то при копировании директории sqldbdir вы также копируете дополнительную информацию об этих базах. В этом нет ничего страшного, но вы должны иметь в виду, что при выполнении команды LIST DB DIRECTORY ON <новыйПуть> вы увидите эти базы данных, хотя фактически они не существуют. По сути, это "зависшие" записи, которые невозможно удалить. Это означает, что в этой директории вы не сможете создать базы данных, имена которых совпадают с этими "зависшими" именами. Однако вы можете создать базы данных с такими именами, расположив их в другой директории.
  
  
• Ничто не мешает вам переместить все базы данных из одного местоположения в другое; для этого требуется лишь создать файл конфигурации и запустить утилиту db2relocatedb для каждой из них.
  
  
• Вы можете использовать утилиту db2relocatedb для переноса контейнеров табличных пространств, управляемых базой данных, расположенных на raw-устройствах. Однако при работе с этими устройствами вы не можете использовать такие команды операционной системы, как cp или mv. Однако будьте аккуратны – обычно операционная система записывает в начало raw-устройства свои собственные метаданные, которые не следует копировать. DB2 помещает свои данные начиная со смещения в 512 байт (1024 байт в HP-UX), поэтому следует копировать данные из старого местоположения и записывать их в новое начиная именно с этой отметки.
  
  
• Если вы переносите базу данных и забыли перенести контейнер, или же забыли указать его в конфигурационном файле (в случае изменения его местоположения), у вас остается возможность подключиться к базе данных. Не забудьте выполнить команду LIST TABLESPACES SHOW DETAIL, чтобы проверить состояние всех табличных пространств и убедиться, что ни одно из них не находится в состоянии OFFLINE. Это состояние говорит о том, что DB2 не удалось найти один или несколько контейнеров. В этом случае остановите базу данных, устраните проблему и запустите утилиту db2relocatedb еще раз (утилита способна определить, какая часть работы уже была выполнена, поэтому ее повторный запуск ничего не нарушит).

В начало

Заключение

Утилита db2relocatedb – это мощный инструмент, позволяющий администратору базы данных управлять метаданными DB2 и упрощающий выполнение таких операций, как перенос или переименование баз данных. При этом также сокращается время простоя базы данных. В условиях увеличения объема баз данных такие возможности облегчают работу администраторов БД. Не забудьте про наши советы, и вы убедитесь, что утилита db2relocatedb действительно очень полезна.

Ресурсы

• Оригинал статьи "The db2relocatedb tool" (EN).
  
  
• Справочник команд DB2 UDB (EN).
  
  
• Справочное руководство по утилитам переноса данных DB2 UDB (EN).
  
  

Об авторе

Оценить эту статью

Комментарии

В начало

Содержание

• Введение
• Что представляет собой db2relocatedb?
• Где можно найти эту утилиту?
• Основы
• Директория базы данных
• Базы данных с несколькими разделами
• Примеры
• Полезные советы и приемы
• Заключение
• Ресурсы
• Об авторе
• Комментарии