Введение

Типичная задача перемещения данных в среде DB2 состоит из следующих трех шагов.

1. Экспорт данных из исходной базы данных во временный файл обмена данными в двоичном или в текстовом формате.
2. Перемещение этого файла между соответствующими системами.
3. Импорт или загрузка данных из этого файла в целевую базу данных.

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

Таких проблем можно избежать при использовании опции FROM CURSOR утилиты LOAD. Если указана опция FROM CURSOR, то утилита LOAD обращается непосредственно к результирующему набору SQL-запроса как к источнику данных для операции загрузки, что избавляет от необходимости создания временного файла для обмена данными. Таким способом опция LOAD FROM CURSOR позволяет быстро и легко перемещать данные между разными табличными пространствами или между разными базами данных. Операции LOAD FROM CURSOR могут быть выполнены в командной строке, а также внутри приложения или хранимой процедуры с помощью хранимой процедуры ADMIN_CMD продукта DB2. Эта статья описывает функцию LOAD FROM CURSOR и демонстрирует примеры ее использования для двух интерфейсов – процессора командной строки (CLP) продукта DB2 и хранимой процедуры ADMIN_CMD.

Перемещение таблицы в другое табличное пространство

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

Наши учебные сценарии начинаются с создания базы данных DB2 SAMPLE. Эта задача может быть решена посредством вызова команды db2sampl в командной строке (листинг 1).

				
C:\>db2sampl

  Creating database "SAMPLE"...
  Connecting to database "SAMPLE"...
  Creating tables and data in schema "FECHNER"...

  'db2sampl' processing complete.

Помимо других таблиц, база данных SAMPLE содержит таблицу с именем SALES. По умолчанию эта таблица была создана в табличном пространстве USERSPACE1 (листинг 2). Для проверки этого обстоятельства можно выполнить запрос к представлениям системного каталога SYSCAT.TABLES и SYSCAT.TABLESPACES продукта DB2.

				
C:\>db2 "CONNECT TO SAMPLE"

   Database Connection Information

 Database server        = DB2/NT 9.5.2
 SQL authorization ID   = FECHNER
 Local database alias   = SAMPLE

C:\>db2 "SELECT TABLES.TABSCHEMA, TABLES.TABNAME, TBSPACES.TBSPACE FROM SYSCAT.TABLES AS
TABLES, SYSCAT.TABLESPACES AS TBSPACES WHERE TABLES.TBSPACEID = TBSPACES.TBSPACEID AND
TABNAME = 'SALES'"

TABSCHEMA
         TABNAME
                  TBSPACE

------------------------------------------------------------------------------------------
-------- ---------------------------------------------------------------------------------
----------------- ------------------------------------------------------------------------
--------------------------
FECHNER
         SALES
                  USERSPACE1


  1 record(s) selected.

В дополнение к табличному пространству USERSPACE1 существует второе табличное пространство IBMDB2SAMPLEREL, которое также предназначено для хранения пользовательских данных. В этом учебном сценарии пространство IBMDB2SAMPLEREL служит в качестве целевого табличного пространства для перемещения таблицы SALES. Чтобы увидеть все табличные пространства какой-либо базы данных, необходимо выполнить команду DB2 под названием LIST TABLESPACES. В листинге 3 показано, как это сделать.

				
C:\>db2 "LIST TABLESPACES"

           Tablespaces for Current Database

 Tablespace ID                        = 0
 Name                                 = SYSCATSPACE
 Type                                 = Database managed space
 Contents                             = All permanent data. Regular table space.
 State                                = 0x0000
   Detailed explanation:
     Normal

 Tablespace ID                        = 1
 Name                                 = TEMPSPACE1
 Type                                 = System managed space
 Contents                             = System Temporary data
 State                                = 0x0000
   Detailed explanation:
     Normal

 Tablespace ID                        = 2
 Name                                 = USERSPACE1
 Type                                 = Database managed space
 Contents                             = All permanent data. Large table space.
 State                                = 0x0000
   Detailed explanation:
     Normal

 Tablespace ID                        = 3
 Name                                 = IBMDB2SAMPLEREL
 Type                                 = Database managed space
 Contents                             = All permanent data. Large table space.
 State                                = 0x0000
   Detailed explanation:
     Normal

Прежде чем копировать содержимое таблицы SALES в табличное пространство IBMDB2SAMPLEREL, вы должны в целевом табличном пространстве создать пустую таблицу с такой же структурой, как у таблицы SALES. Поскольку в одной и той же схеме невозможно иметь две таблицы с одинаковыми именами, новая таблица создана с временным именем SALES_TMP. Создание пустой таблицы с такой же структурой, как у уже существующей таблицы, может быть осуществлено посредством указания опции LIKE в команде CREATE TABLE (листинг 4). Табличное пространство для новой таблицы SALES_TMP определяется в явном виде с помощью опции IN.

				
C:\>db2 "CREATE TABLE FECHNER.SALES_TMP LIKE FECHNER.SALES IN IBMDB2SAMPLEREL"
DB20000I  The SQL command completed successfully.

Теперь можно переходить к операции перемещения данных. Команда DECLARE CURSOR определяет курсор, который читает все данные из таблицы-источника SALES, используя для этого обычное утверждение SELECT. Имя курсора (в данном случае – C1) может быть выбрано произвольно. Затем на этот курсор ссылается команда LOAD для заполнения целевой таблицы SALES_TMP. В рассматриваемом примере (листинг 5) команда LOAD записывает свои сообщения в файл системного журнала load_sales_tmp.msg. Операция LOAD выполняется с опцией NONRECOVERABLE. Это означает, что операция LOAD не может быть выполнена повторно в фазе rollforward процедуры восстановления базы данных. Таким образом, после операции перемещения данных должно быть выполнено резервное копирование базы данных или, как минимум, резервное копирование табличного пространства. Команда LOAD имеет другие опции, позволяющие избежать такой ситуации, однако рассмотрение этих опций не входит в задачу этой статьи. Для получения более подробной информации обратитесь к описанию команды LOAD в информационном центре DB2 Information Center (см. раздел Ресурсы).

				
C:\>db2 "DECLARE C1 CURSOR FOR SELECT * FROM FECHNER.SALES"
DB20000I  The SQL command completed successfully.

C:\>db2 "LOAD FROM C1 OF CURSOR MESSAGES C:\load_sales_tmp.msg INSERT INTO
FECHNER.SALES_TMP NONRECOVERABLE"

Number of rows read         = 41
Number of rows skipped      = 0
Number of rows loaded       = 41
Number of rows rejected     = 0
Number of rows deleted      = 0
Number of rows committed    = 41

После успешного копирования всех строк таблицы SALES в таблицу SALES_TMP исходная таблица SALES может быть удалена (с помощью утверждения DROP TABLE). Затем целевая таблица SALES_TMP переименовывается в SALES (с помощью утверждения RENAME TABLE). При работе с утверждением RENAME TABLE следует помнить, что может быть изменено только имя таблицы, но не имя схемы для этой таблицы. Таким образом, важно с самого начала создать таблицу SALES_TMP в правильной схеме (листинг 6).

				
C:\>db2 "DROP TABLE FECHNER.SALES"
DB20000I  The SQL command completed successfully.

C:\>db2 "RENAME TABLE FECHNER.SALES_TMP TO SALES"
DB20000I  The SQL command completed successfully.

С помощью показанного выше запроса к представлениям каталога DB2 можно проверить, что таблица SALES была перемещена из ее исходного табличного пространства USERSPACE1 в его новое табличное пространство IBMDB2SAMPLEREL (листинг 7).

				
C:\>db2 "SELECT TABLES.TABSCHEMA, TABLES.TABNAME, TBSPACES.TBSPACE FROM SYSCAT.TABLES AS
TABLES, SYSCAT.TABLESPACES AS TBSPACES WHERE TABLES.TBSPACEID = TBSPACES.TBSPACEID AND
TABNAME = 'SALES'"

TABSCHEMA
         TABNAME
                  TBSPACE

------------------------------------------------------------------------------------------
-------- ---------------------------------------------------------------------------------
----------------- ------------------------------------------------------------------------
--------------------------
FECHNER
         SALES
                  IBMDB2SAMPLEREL


  1 record(s) selected.

C:\>db2 "TERMINATE"
DB20000I  The TERMINATE command completed successfully.

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

Точно так же, как таблица может быть перемещена между табличными пространствами в пределах одной базы данных, она может быть перемещена и между двумя разными базами данных. Это означает, что с помощью опции LOAD FROM CURSOR таблица также может быть скопирована из одной базы данных в другую базу данных. Это может быть реализовано следующими способами.

• Способ 1 – получение доступа к исходной базе данных изнутри целевой базы данных с использованием механизмов DB2 для объединенных баз данных.
• Способ 2 – использование опции дистанционного доступа команды LOAD FROM CURSOR

Оба способа обладают определенными преимуществами, которые будут проанализированы в этой статье.

Способ 1 использует объединенный доступ к исходной базе данных для копирования содержимого таблицы. Для использования способа 1 требуется, чтобы целевая база данных была сконфигурирована как объединенная база данных. Поэтому параметр FEDERATED соответствующего экземпляра DB2 должен иметь значение YES (UPDATE DBM CFG). После изменения параметра FEDERATED в DBM CFG экземпляр DB2 должен быть перезапущен (db2stop/db2start). В этом учебном сценарии исходная и целевая базы данных исполняются в пределах одного и того же экземпляра DB2. В качестве целевой базы данных мы создаем вторую базу данных (пустую) с именем MYSAMPLE. В случае тестовой базы данных без специальных требований для этого можно использовать команду CREATE DATABASE без дополнительных опций (листинг 8).

				
C:\>db2 "UPDATE DBM CFG USING FEDERATED YES"
DB20000I  The UPDATE DATABASE MANAGER CONFIGURATION command completed
successfully.
SQL1362W  One or more of the parameters submitted for immediate modification
were not changed dynamically. Client changes will not be effective until the
next time the application is started or the TERMINATE command has been issued.
Server changes will not be effective until the next DB2START command.

C:\>db2stop
2008-09-22 14.55.36     0   0   SQL1064N  DB2STOP processing was successful.
SQL1064N  DB2STOP processing was successful.

C:\>db2start
2008-09-22 14.55.53     0   0   SQL1063N  DB2START processing was successful.
SQL1063N  DB2START processing was successful.

C:\>db2 "CREATE DATABASE MYSAMPLE"
DB20000I  The CREATE DATABASE command completed successfully.

Аналогично, в целевой базе данных MYSAMPLE необходима пустая таблица с такой же структурой, как у таблицы SALES в исходной базе данных SAMPLE. Таким образом, вам следует извлечь DDL из таблицы SALES в исходной базе данных с помощью утилиты db2look (листинг 9).

				
C:\>db2look -d sample -e -z fechner -t sales -o sales.ddl
-- USER is: FECHNER
-- Specified SCHEMA is: FECHNER
-- The db2look utility will consider only the specified tables
-- Creating DDL for table(s)

-- Schema name is ignored for the Federated Section
-- Output is sent to file: sales.ddl
-- Binding package automatically ...
-- Bind is successful
-- Binding package automatically ...
-- Bind is successful

Результатом вызова утилиты db2look является файл sales.ddl, содержащий утверждение CREATE TABLE для таблицы SALES. Если в таблице SALES были определены ограничения и/или индексы, то соответствующие определения также были бы извлечены и записаны в файл sales.ddl. Результаты показаны в листинге 10.

				
-- This CLP file was created using DB2LOOK Version 9.5
-- Timestamp: 23.09.2008 07:35:10
-- Database Name: SAMPLE         
-- Database Manager Version: DB2/NT Version 9.5.2          
-- Database Codepage: 1208
-- Database Collating Sequence is: IDENTITY


CONNECT TO SAMPLE;

------------------------------------------------
-- DDL Statements for table "FECHNER "."SALES"
------------------------------------------------
 

CREATE TABLE "FECHNER "."SALES"  (
		  "SALES_DATE" DATE , 
		  "SALES_PERSON" VARCHAR(15) , 
		  "REGION" VARCHAR(15) , 
		  "SALES" INTEGER )   
		 IN "IBMDB2SAMPLEREL" ; 


COMMIT WORK;

CONNECT RESET;

TERMINATE;

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

• в начале файла утилита db2look сгенерировала утверждение CONNECT для применения его к исходной базе данных SAMPLE. Поскольку вы собираетесь применить следующие утверждения к целевой базе данных MYSAMPLE, необходимо изменить утверждение CONNECT соответствующим образом;
• поскольку в целевой базе данных MYSAMPLE отсутствует табличное пространство IBMDB2SAMPLREL для пользовательских данных, в утверждении CREATE TABLE замените имя табличного пространства на USERSPACE1.

				
CONNECT TO SAMPLE; -> CONNECT TO MYSAMPLE;

IN "IBMDB2SAMPLEREL" ; -> IN "USERSPACE1";

После внесения в файл sales.ddl описанных выше изменений осуществляется выполнение учебного сценария посредством вызова процессора командной строки (CLP) продукта DB2 (листинг 12).

				
C:\>db2 -tf sales.ddl

   Database Connection Information

 Database server        = DB2/NT 9.5.2
 SQL authorization ID   = FECHNER
 Local database alias   = MYSAMPLE


DB20000I  The SQL command completed successfully.

DB20000I  The SQL command completed successfully.

DB20000I  The SQL command completed successfully.

DB20000I  The TERMINATE command completed successfully.

До настоящего момента в целевой базе данных MYSAMPLE была создана только пустая копия таблицы SALES. Следующий шаг в подготовке операции перемещения данных – каталогизирование исходной базы данных SAMPLE в виде дистанционной базы данных. Вполне очевидно, что для рассматриваемого учебного сценария это не является обязательным условием, поскольку обе базы данных (исходная и целевая) исполняются на одном и том же сервере в пределах одного и того же экземпляра DB2. Однако что касается реальной среды, то для экземпляра DB2, осуществляющего хостинг целевой базой данных, потребуется выполнение следующих команд CATALOG, разрешающих TCP/IP-доступ к исходной базе данных (листинг 13).

				
C:\>db2 "CATALOG TCPIP NODE SRCNODE REMOTE localhost SERVER 50000"
DB20000I  The CATALOG TCPIP NODE command completed successfully.
DB21056W  Directory changes may not be effective until the directory cache is
refreshed.

C:\>db2 "CATALOG DATABASE SAMPLE AS SRCDB AT NODE SRCNODE AUTHENTICATION SERVER"
DB20000I  The CATALOG DATABASE command completed successfully.
DB21056W  Directory changes may not be effective until the directory cache is
refreshed.

C:\>db2 "TERMINATE"
DB20000I  The TERMINATE command completed successfully.

Последний шаг в подготовке операции LOAD FROM CURSOR состоит в конфигурировании объединенного доступа к таблице SALES в исходной базе данных SAMPLE. Эта задача решается внутри целевой базы данных MYSAMPLE посредством создания нескольких специальных объектов, необходимых для объединенного доступа к другой базе данных (листинг 14).

• Упаковщик обеспечивает доступ к внешним источникам данных. Внешним источником данных может быть другая СУБД (система управления базами данных), такая как Oracle или SQL Server, или всего лишь таблица Excel. Выбор соответствующего упаковщика определяется источником данных, к которому нужно получать доступ. Такие упаковщики содержатся в отдельном продукте IBM под названием WebSphere® Federation Server. Если требуется доступ к другой базе данных семейства продуктов DB2, например к DB2 LUW или к DB2 z/OS, то необходим упаковщик DRDA. Этот упаковщик уже включен в состав DB2 LUW, поэтому в данном случае в продукте WebSphere Federation Server нет необходимости. Упаковщик DRDA создается посредством выполнения в целевой базе данных следующей тривиальной команды: CREATE WRAPPER DRDA.
• Сервер – термин «сервер» в данном случае несколько сбивает с толку, поскольку фактически под ним понимается исходная база данных, которая играет роль сервера (данных). Для того чтобы оповестить целевую базу данных об исходной базе данных, создается серверный объект, специфицирующий тип источника данных (DB2/UDB VERSION 9.5), используемый упаковщик (DRDA) и комбинацию «идентификатор пользователя/пароль» для доступа к исходной базе данных. Имя самой исходной базы данных предоставляется с помощью опции DBNAME. Имя пользователя и пароль должны быть указаны в кавычках. Чтобы избежать удаления этих кавычек интерпретатором командной строки, они маскируются с помощью символа «обратная косая черта» (\). Имя серверного объекта может быть выбрано произвольно. В этом учебном сценарии используется имя SRCSRV.
• Отображение пользователя (User mapping) должно быть определено для каждого пользователя, желающего получить доступ к дистанционной базе данных с помощью ранее заданного серверного объекта. Отображение пользователя определяет, как авторизационный идентификатор в локальной базе данных (MYSAMPLE) отображается на авторизационный идентификатор в дистанционной базе данных (SAMPLE). В этом учебном сценарии локальный и дистанционный пользователи идентичны, тем не менее отображение пользователя должно быть определено.
• Псевдоним представляет собой локальное имя для дистанционной таблицы в исходной базе данных. Задание псевдонима для дистанционной таблицы позволяет обращаться к ней из целевой базы данных с помощью SQL-запросов, как к любой другой локальной таблице.

				
C:\>db2 "CONNECT TO MYSAMPLE"

   Database Connection Information

 Database server        = DB2/NT 9.5.2
 SQL authorization ID   = FECHNER
 Local database alias   = MYSAMPLE

C:\>db2 "CREATE WRAPPER DRDA"
DB20000I  The SQL command completed successfully.

C:\>db2 "CREATE SERVER SRCSRV TYPE DB2/UDB VERSION 9.5 WRAPPER DRDA AUTHORIZATION
\"fechner\" PASSWORD \"password\" OPTIONS (DBNAME 'SRCDB')"
DB20000I  The SQL command completed successfully.

C:\>db2 "CREATE USER MAPPING FOR fechner SERVER SRCSRV OPTIONS (REMOTE_AUTHID 'fechner',
REMOTE_PASSWORD 'password')"
DB20000I  The SQL command completed successfully.

C:\>db2 "CREATE NICKNAME FECHNER.SRCTAB FOR SRCSRV.FECHNER.SALES"
DB20000I  The SQL command completed successfully.

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

Теперь, когда объединенный доступ к таблице в исходной базе данных сконфигурирован, операция LOAD FROM CURSOR работает точно так же, как было показано выше. Сначала определяется курсор, который читает все строки в дистанционной таблице с использованием созданного ранее псевдонима. Затем к этому курсору обращается команда LOAD (листинг 15).

				
C:\>db2 "DECLARE C1 CURSOR FOR SELECT * FROM FECHNER.SRCTAB"
DB20000I  The SQL command completed successfully.

C:\>db2 "LOAD FROM C1 OF CURSOR MESSAGES C:\load_sales.msg INSERT INTO FECHNER.SALES
NONRECOVERABLE"

Number of rows read         = 41
Number of rows skipped      = 0
Number of rows loaded       = 41
Number of rows rejected     = 0
Number of rows deleted      = 0
Number of rows committed    = 41

C:\>db2 "TERMINATE"
DB20000I  The TERMINATE command completed successfully.

Как указывалось выше, операция LOAD FROM CURSOR в сочетании с объединенным доступом требует большего объема конфигурирования, чем при использовании описанного позднее способа. Однако главное преимущество объединенного подхода состоит в возможности загрузки данных из источников данных, отличных от DB2. Использование объединенного подхода позволяет получить доступ к таким источникам данных, как Oracle, SQL Server и многие другие реляционные и нереляционные источники данных, а затем скопировать их контент посредством создания псевдонима и выполнения операции LOAD FROM CURSOR, ссылающейся на этот псевдоним. Упаковщики, необходимые для доступа к иным источникам данных (помимо DB2), поставляются вместе с продуктом WebSphere Federation Server.

Более простой способ создания копии таблицы в другой базе данных

Теперь, после ознакомления с дистанционным подходом LOAD FROM CURSOR, основанным на использовании псевдонимов, проанализируем еще один подход, который требует меньших усилий. Для этого начнем с удаления всех строк, которые мы только что импортировали в таблицу SALES в целевой базе данных MYSAMPLE (листинг 16).

				
C:\>db2 "CONNECT TO MYSAMPLE"

   Database Connection Information

 Database server        = DB2/NT 9.5.2
 SQL authorization ID   = FECHNER
 Local database alias   = MYSAMPLE

C:\>db2 "DELETE FROM FECHNER.SALES"
DB20000I  The SQL command completed successfully.

При использовании этого альтернативного подхода нет необходимости в конфигурировании объединенного доступа к дистанционной базе данных. Вместо этого достаточно указать эту дистанционную базу данных в утверждении DECLARE CURSOR с помощью опции DATABASE. Для того чтобы этот подход работал, дистанционная база данных должна быть каталогизирована в системном каталоге баз данных локального экземпляра DB2. Соответствующие команды CATALOG уже были представлены выше. Кроме того, в процессе определения курсора специфицируются имя пользователя и пароль для дистанционного доступа. Сама команда LOAD остается неизменной (листинг 17).

				
C:\>db2 "DECLARE C1 CURSOR DATABASE SRCDB USER fechner USING password FOR SELECT * FROM
FECHNER.SALES"
DB20000I  The SQL command completed successfully.

C:\>db2 "LOAD FROM C1 OF CURSOR MESSAGES C:\load_sales_2.msg INSERT INTO FECHNER.SALES
NONRECOVERABLE"

Number of rows read         = 41
Number of rows skipped      = 0
Number of rows loaded       = 41
Number of rows rejected     = 0
Number of rows deleted      = 0
Number of rows committed    = 41

C:\>db2 "TERMINATE"
DB20000I  The TERMINATE command completed successfully.

Возможность описанного выше выполнения дистанционной операции LOAD FROM CURSOR поддерживается, начиная с версии DB2 9.1. Подход, основанный на объединенном доступе, уже работал в версии 8. Новый подход обеспечивает два преимущества – по простоте использования и производительности. Очевидно, что новый подход очень прост в использовании. Преимущества по производительности по сравнению с объединенным подходом обусловлены тем, что вовлечено меньше слоев передачи данных. Однако не следует забывать о таком преимуществе объединенного подхода, как возможность доступа к иным источникам данных помимо DB2.

Различия между CLP и ADMIN_CMD применительно к опции LOAD FROM CURSOR

В код приложения также может быть встроено большое число команд администрирования посредством их исполнения с помощью специальной хранимой процедуры ADMIN_CMD. Это также верно для операции LOAD FROM CURSOR. Использование хранимой процедуры ADMIN_CMD не зависит от местоположения кода приложения. Другими словами, не имеет значения, где находится этот код – на стороне клиента (например, Java-приложение) или на стороне сервера (например, хранимая процедура SQL/PL). Следующий пример демонстрирует использование хранимой процедуры ADMIN_CMD внутри специальной хранимой процедуры на SQL/PL. Файл create_load_routine.sql содержит исходный текст на SQL/PL для учебной хранимой процедуры с именем REMOTE_LOAD_FROM_CURSOR (листинг 18).

				
CREATE PROCEDURE FECHNER.REMOTE_LOAD_FROM_CURSOR ()
    SPECIFIC REMOTE_LOAD_FROM_CURSOR
    LANGUAGE SQL
BEGIN

    DELETE FROM FECHNER.SALES;--

    CALL SYSPROC.ADMIN_CMD ('LOAD FROM (DATABASE SRCDB SELECT * FROM FECHNER.SALES) OF
CURSOR INSERT INTO FECHNER.SALES NONRECOVERABLE');--
END;

Первое утверждение в хранимой процедуре – DELETE – предназначено для удаления существующих строк в локальной целевой таблице SALES. Затем выполняется дистанционная операция LOAD FROM CURSOR посредством вызова ADMIN_CMD с помощью соответствующей команды LOAD. По сравнению с операцией LOAD FROM CURSOR, выполняемой из командной строки, имеют место следующие различия:

• определение требуемого курсора не производится специально посредством выполнения утверждения DECLARE CURSOR. Вместо этого определение курсора осуществляется с помощью соответствующего утверждения SELECT в рамках команды LOAD. Этот синтаксис является корректным только в том случае, если операция LOAD FROM CURSOR встроена в вызов ADMIN_CMD, и не является корректным при использовании командной строки;
• дистанционная база данных определена с помощью опции DATABASE команды LOAD. Специфицировать комбинацию «идентификатор пользователя/пароль» для дистанционного доступа не представляется возможным. Обратите внимание на последствия этого ограничения при тестировании своей хранимой процедуры.

Но сначала вам следует создать свою хранимую процедуру в целевой базе данных MYSAMPLE (листинг 19).

				
C:\>db2 "CONNECT TO MYSAMPLE"

   Database Connection Information

 Database server        = DB2/NT 9.5.2
 SQL authorization ID   = FECHNER
 Local database alias   = MYSAMPLE

C:\>db2 -tf create_load_routine.sql
DB20000I  The SQL command completed successfully.

Первый вызов теста закончился неудачей и сопровождается следующим сообщением: SQL30082N Security processing failed with reason "3" ("PASSWORD MISSING"). SQLSTATE=08001 (листинг 20).

				
C:\>db2 "CALL FECHNER.REMOTE_LOAD_FROM_CURSOR"
SQL30082N  Security processing failed with reason "3" ("PASSWORD MISSING").
SQLSTATE=08001

C:\>db2 "TERMINATE"
DB20000I  The TERMINATE command completed successfully.

Глубинная причина этого сообщения об ошибке – способ, посредством которого было установлено соединение с базой данных: db2 "CONNECT TO MYSAMPLE". При выполнении утверждения CONNECT не было назначено какого-либо имени пользователя/пароля, поэтому соединение было установлено с задействованием того имени пользователя, которое использовалось при входе в операционную систему. В этом случае DB2 не знает о пароле подключенного пользователя. Теперь при выполнении операции LOAD FROM CURSOR в рамках хранимой процедуры DB2 пытается установить дистанционное соединение с базой данных SAMPLE, задействуя для этого авторизационный идентификатор локального пользователя. Однако, поскольку DB2 не знает соответствующего пароля (вследствие того, что он не был указан в явном виде в утверждении CONNECT), дистанционный доступ терпит неудачу. Таким образом, ошибка имеет следующие причины:

• поскольку при выполнении операции LOAD FROM CURSOR с использованием ADMIN_CMD невозможно задать пользователя для дистанционного доступа, операция LOAD автоматически пытается установить соединение с дистанционной базой данных с задействованием авторизационного идентификатора, принадлежащего соединению с локальной базой данных;
• если локально подключенный пользователь выполнил утверждение CONNECT без явного специфицирования пароля, то его пароль неизвестен DB2 и, соответственно, не может быть использован при попытке установить соединение с дистанционной базой данных.

Другое следствие описанного свойства дистанционной операции LOAD FROM CURSOR при посредстве ADMIN_CMD (состоящего в невозможности специфицировать в явном виде пользователя для дистанционного доступа): пользователь, который в данный момент подключен к локальной базе данных, вынужден обращаться к дистанционной базе данных с помощью того же авторизационного идентификатора. Это ограничение не действует в случае объединенного доступа к дистанционной базе данных, поскольку в этом случае существует дополнительный слой абстракции в форме отображений пользователя, которые должны быть специфицированы.

Теперь, когда мы выяснили причину ошибки, повторно подключитесь к локальной базе данных, указав имя пользователя и пароль в явном виде. После этого второй вызов вашей хранимой процедуры выполнится без каких-либо ошибок (Return Status = 0), как показано в листинге 21.

				
C:\>db2 "CONNECT TO MYSAMPLE USER fechner"
Enter current password for fechner:

   Database Connection Information

 Database server        = DB2/NT 9.5.2
 SQL authorization ID   = FECHNER
 Local database alias   = MYSAMPLE

C:\>db2 "CALL FECHNER.REMOTE_LOAD_FROM_CURSOR"

  Return Status = 0

C:\>db2 "TERMINATE"
DB20000I  The TERMINATE command completed successfully.

Заключение

С помощью учебных сценариев в статье демонстрируется использование опции LOAD FROM CURSOR продукта DB для быстрого и простого копирования данных как в пределах одной базы данных, так и между разными базами данных. Кроме того, в статье разъясняются особенности выполнения операций LOAD FROM CURSOR внутри кода приложения с помощью хранимой процедуры ADMIN_CMD. Кроме того, вы узнали, как сконфигурировать объединенный доступ к другой базе данных DB2 таким образом, чтобы можно было прозрачно читать/записывать таблицы/представления в дистанционной базе данных точно так же, как локальные таблицы/представления.

Ресурсы

Научиться

• Оригинал статьи Fast and easy data movement using DB2's LOAD FROM CURSOR feature (EN).
  
  
• Прочитайте статью Moving data using the CURSOR file type (EN) (Перемещение данных с использованием файлов типа CURSOR) для получения более глубокой информации по темам, затронутым в этой статье.
  
  
• Посетите информационный центр DB2 9.5 Information Center for Linux, UNIX, and Windows (EN) для получения полного пакета онлайновой документации в формате HTML по продукту DB2 9.5 LUW.
  
  
• Web-сайт поддержки продукта DB2 9 for Linux UNIX and Windows Support Site (EN) позволяет осуществлять поиск пакетов типа APAR, загружать исправления, получать документацию по DB2 LUW в формате PDF и т.д.
  
  
• Ознакомьтесь со статьями серии Best practices for DB2 for Linux, UNIX, and Windows (EN) (Типовые методики по продукту DB2), в которых предлагаются практические рекомендации для наиболее распространенных конфигураций продукта DB2 9. Применяя эти рекомендации, вы сможете реализовать техническую политику IBM относительно DB2 и тем самым повысить отдачу от своих серверов данных DB2. Эти статьи были написаны ведущими специалистами IBM из групп разработки и консалтинга, после чего были подвергнуты масштабной проверке.
  
  
• Дополнительная техническая литература (EN) по этой и другим темам.
  
  

Получить продукты и технологии

• Загрузите ознакомительные версии программных продуктов IBM (EN) и приобретите опыт работы с инструментами разработки и продуктами связующего уровня семейств DB2®, Lotus®, Rational®, Tivoli® и WebSphere®.
  
  

Обсудить

• Примите участие в обсуждении материала на форуме.
  
  
• Блоги developerWorks (EN): Присоединяйтесь к сообществу developerWorks (EN).
  
  

Об авторе

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

Комментарии

В начало

Содержание

• Введение
• Перемещение таблицы в другое табличное пространство
• Создание копии таблицы в другой базе данных с помощью псевдонима
• Более простой способ создания копии таблицы в другой базе данных
• Различия между CLP и ADMIN_CMD применительно к опции LOAD FROM CURSOR
• Заключение
• Ресурсы
• Об авторе
• Комментарии