相容性問題

修訂標記指出已新增或變更的文字。垂直線 ( | ) 指出已針對 8.2 版 FixPak 4 (相當於 8.1 版 FixPak 11) 新增或變更的資訊。

舊版相容性

新產品的 Fixpak 層次及安裝

您可能需要安裝 DB2(R) 產品,但其所在的層次不同於目前安裝在電腦的另一個 DB2(R) 產品版本。 DB2 產品需要位在相同層次。

如果您正要安裝的產品所在的層次比已安裝在同一部電腦的其它 DB2 產品版本還要新,您將需要把現存的 DB2 產品更新為更新的層次。比方說, 如果您正要安裝的 DB2 Connect(TM) for iSeries(TM) 位於 Fixpak 10 層次, 您的其它 DB2 產品位於 Fixpak 9 層次,則您需要將 Fixpak 10 套用到目前安裝的 DB2 產品後,再安裝位於 Fixpak 10 層次的 DB2 Connect(TM) for iSeries(TM)

相反地,如果您是在已安裝更新 DB2 產品版本的電腦上安裝產品,將有一些需要遵循的準則:

在 Windows(R) 作業系統上
fixpak 可以用來將產品直接安裝在同一層次的系統上。 在完成安裝之後,可以使用下列命令來新增授權:
   db2licm -a filename
其中 filename 是授權檔的名稱, 您可以在原始媒體的 db2\license 目錄下找到這個檔案。您也可以將這個授權新增到 fixpak 的 db2\license 目錄, 然後安裝作業將安裝這個授權。
在 UNIX(R) 及 Linux(R) 作業系統上
先決條件

在安裝額外的產品或元件之前,您必須停止下列項目:

  • 現存的 DB2 實例
  • DB2 管理伺服器 (DAS)

必須停止屬於 DB2 安裝的實例及 DAS,因為在安裝 DB2 時, 將安裝這些額外的 DB2 產品或元件。

如需進一步指示,請參閱 FixPak Readme

程序

  1. 有三種方法,用於安裝 DB2 層次低於目前安裝在系統的 DB2 產品的額外 DB2 產品或元件。 請選擇下列其中一種方法:
    執行 db2setup 程式
    利用 GUI 以互動方式執行 db2setup,或利用回應檔以無聲自動方式執行 db2setup。 在利用 db2setup 安裝額外產品或元件期間,請不要執行任何配置,如實例建立。

    如果 DB2 DAS 不存在於目前系統,且額外的產品或元件需要或支援 DB2 DAS, 則 db2setup 將在安裝期間安裝 DB2 DAS。在某些平台上, 在利用 db2setup 建立 DB2 DAS 期間,您可能會經歷錯誤。 這些是預期的錯誤,因此可以忽略它們。

    您可以在 DB2 產品 CD,或在您正要安裝的額外產品或元件的映像檔上找到 db2setup 程式。

    如需使用 db2setup 的詳細資訊,請參閱 Command Reference安裝與配置補充資料

    執行 db2_install Script
    db2_install Script 會安裝任何目前在安裝 DB2 時未安裝的元件, 但非英文語言及訊息元件除外。因此,您應該使用 db2_install,安裝新的產品或元件, 因為它將不會更新現存的 DB2 元件。

    您可以在 DB2 產品 CD,或在您正要安裝的額外產品或元件的映像檔上找到 db2_install Script。

    如需使用 db2_install Script 的詳細資訊,請參閱安裝與配置補充資料

    使用系統安裝程式
    使用系統安裝程式,安裝新的產品或元件。

    如需使用系統安裝程式的詳細資訊,請參閱安裝與配置補充資料

  2. 在安裝額外產品或元件之後,必須執行下列作業:
    1. 將一般 fixpak 重新套用到所有預先存在的產品,以便新的及預先存在的產品位於相同層次。

      為了說明這個實務,假設下列狀況:

      • DB2 Universal Database(TM) Enterprise Server Edition 目前安裝在 FixPak 10 層次。
      • 接著,根據先前步驟中的指示,將 DB2 Query Patroller(TM) 安裝在 FixPak 7。

      您必須重新套用一般 FixPak 10,作為後置安裝步驟。

      註:
      在安裝 fixpak 期間,您可能會得到如下的錯誤訊息:
      套件 db2cliv81 已安裝在
      系統。
      
      修補程式 nnnnnnn-nnn 安裝已異常
      終止。
      
      若要重新安裝這個修補程式,請首先解除安裝,
      然後再嘗試重新安裝。
      發生這個錯誤的原因是系統中的 db2cliv81 已位在與正要安裝的 fixpak 層次相同的層次。 您可以忽略這類錯誤。請使用系統安裝程式,確認 DB2 元件或套件確實位在正要安裝的相同 fixpak 層次。
    2. 執行 db2iupdt 命令,更新屬於目前 DB2 安裝的現存 DB2 實例。
    3. 執行 dasupdt 命令,更新與目前 DB2 安裝相關聯的 DB2 DAS。
    4. 需要時,請執行 db2isetup 命令,建立新的 DB2 UDB 實例或配置現存的實例。
    如需 fixpak 安裝、實例及 DB2 DAS 更新,以及其他後置安裝步驟的詳細資料,請參閱 FixPak Readme

DB2 UDB 8.2 版資料庫的舊版相容性

如果您利用 DB2 Universal Database(TM) 8.2 版建立資料庫,您將無法在 8.1 版層次中使用該資料庫。該資料庫只能使用於 8.2 版或更新層次。

在 DB2(R) UDB 8.2 版層次建立的資料庫可能具有額外的功能,無法在舊版中使用。如果您嘗試將新的資料庫移至舊版 DB2 UDB, 這種差異可能會導致非預期及不想要的行為。

註:
將資料庫從 8.2 版移回至 8.1 版的唯一方法,就是資料庫原先是在 8.1 版下建立。 即使如此,只有在執行 db2demigdb 工具後, 才能進行舊版移轉。但是,如果您使用了已在 8.2 版變更的內建函數, 則可能會遇到問題。
| | |

DB2 UDB 用戶端支援的說明

|

DB2 用戶端快速入門一書中的「DB2 用戶端概觀」一節有如下的陳述:

DB2 用戶端可以連接至比用戶端版次晚兩個版次或早一個版次的 DB2 伺服器, |以及連接至同一版次的伺服器。
|

該陳述的修正如下:

|

儘管在某些環境中從第 N 版用戶端至第 N + 2 版伺服器的連線是可能的, |但是只有第 N 版在服務範圍內時,DB2 支援團隊才會提供支援。 |一旦從服務撤銷第 N 版,DB2 支援團隊將不再支援這個配置。 |DB2 支援團隊不再支援 DB2 第 7 版用戶端連接到 DB2 第 8 版伺服器,因為已從服務撤銷第 7 版。

從 DB2 UDB 8.2 版移轉回 DB2 UDB 8.1 版時的健康登錄變更

移轉回 DB2 UDB 8.1 版時,會失去對 DB2 UDB 8.2 版層次所做的任何登錄變更。 登錄將回復至 8.1 版 HealthRules.reg 檔, 其中含有在您升級至 DB2 UDB 8.2 版並開始使用 HealthRules2.reg 檔中的設定前即已存在的設定。

替代 FixPak (Linux 及 UNIX)

在 DB2 Universal Database (UDB) 第 8 版之前, FixPak 僅用來更新已安裝在某固定位置中的 DB2 UDB 資料包或檔案集。 這表示 FixPak 安裝已將現存檔案換成 FixPak 中所提供的更新檔案。 多個 DB2 FixPak 層次無法存在於單一系統上。 現在,對於 Linux(TM) 型及 UNIX(R) 型作業系統而言, DB2 UDB Enterprise Server Edition (ESE) 可以存在於相同系統的多個修正套件層次中。此特性從 8.1.2 版的正式作業環境之後就受到支援,且使用下列兩種 FixPak 來達成:

一般 FixPak
替代 FixPak
註:
  1. 如果多個 FixPak 安裝對您的環境來說不是必要的,就需要執行它。 如果您在相同系統中需要位於不同 fixpak 層次的 DB2 UDB 第 8 版 ESE 實例, 可以考慮安裝多個 FixPak。例如,多個 FixPak 可讓您在測試環境中驗證 FixPak 內含的變更, 不會影響到正式作業系統。
  2. 從 IBM(R) DB2 UDB Enterprise Server Edition (ESE) for Linux(TM) 及 UNIX(R) 8.1.2 版開始,將修正套件安裝為多個修正套件時, 可在正式作業環境中予以支援。
  3. 在 Linux,僅於下列平台上才能使用替代 FixPak:
  4. 在相同系統的不同 fixpak 層次執行的兩個以上的 DB2 實例不支援產生「DB2 內部程序呼叫 (IPC)」的作業, 如「聯合」查詢。所有包括在相同系統上這些作業中的實例都應該位於相同 DB2 fixpak 層次。
  5. DB2 UDB 第 8 版替代 FixPak 只在支援的 Linux 及 Unix 平台上支援 DB2 ESE。

若要將多個 FixPak 實例更新為不同 FixPak 層次,請執行下列其中一個作業:

如需有關替代 FixPak 的進一步資訊:

Query Patroller 8.2.2 版查詢資料與舊版 FixPak 相容

從 8.2.2 版 (相當於 8.1 版 FixPak 9) 開始,在 32 位元環境中擷取的 TRACK_QUERY_INFO Query Patroller 控制表格內容可以在 64 位元環境中使用。 這種功能可讓資料更容易移轉至 64 位元環境。 在 8.2.2 版的 TRACK_QUERY_INFO Query Patroller 控制表格中擷取的資訊無法用來產生該查詢的歷程資料, 或是無法用來執行任何先前 FixPak 層次下保留的查詢。

「資料倉儲中心」先前的伺服器支援限制

DB2 Universal Database (UDB) Enterprise Server Edition 第 8 版「資料倉儲中心」的先前伺服器支援有下列限制:

大型物件 (LOB) 支援
系統網路架構 (SNA) 支援
如果使用 SNA 連接至倉儲來源和目標,您必須將配置變更為 TCP/IP over SNA, 或使用 Windows NT(R) 倉儲代理站。
支援 EXPORT 與 LOAD 公用程式
「資料倉儲中心」第 8 版 LOAD 公用程式不支援第 7 版目標資料庫。 如果想要將您的目標保留為第 7 版資料庫, 則您必須將 LOAD 步驟變更為「SQL 選取」及「插入」步驟。 「SQL 選取」和「插入」 步驟使用後面跟著 SELECT 和 INSERT 陳述式的 DELETE* 陳述式。「SQL 選取」和 「插入」步驟需要資料庫來記載所有交易。因此,「SQL 選取」和「插入」步驟的效能不及 EXPORT 和 LOAD 公用程式。

在 DB2 UDB for OS/390 第 6 版及 DB2 UDB for z/OS 第 7 版上,SQLJ 及 SQL 輔助程式支援需要開發中心 APAR

在 Windows(R) 或 UNIX 作業系統中使用 Application Development Client for DB2 Universal Database (UDB) 第 8 版的「開發中心」時, 必須在伺服器上安裝下列 APAR 以啟用 SQLJ 及「SQL 輔助程式」支援:

DB2 UDB for z/OS(R) 第 7 版
DB2 UDB for OS/390(R) 第 6 版

從 DB2 UDB 啟動 SQL 輔助程式的兩個版本

您可以從 DB2 Universal Database 第 8 版內呼叫第 7 版和第 8 版的「SQL 輔助程式」。 您可以從「DB2 資料倉儲中心」啟動第 7 版。所有其他中心可啟動最新第 8 版。產品線上說明有「SQL 輔助程式」第 7 版的其他資訊。

變更 Unicode 伺服器行為

在第 7 版中,Unicode 伺服器會忽略應用程式在連線時所傳送的圖形字碼頁, 並假設使用 UCS2 Unicode (字碼頁 1200)。第 8 版 Unicode 伺服器目前注意用戶端所傳送的字碼頁。

移轉期間的資料庫配置參數變更

DB2 UDB 8.2 版使用新的 16K 資料庫配置參數檔,名為 SQLDBCONF。 這是從 DB2 UDB 8.1 版 4K 資料庫配置參數檔 (名為 SQLDBCON) 分割出來的檔案。

在移轉至 DB2 UDB 8.2 版後, 本產品會移轉 8.1 版 4K 檔案的內容,並使用 16K 檔案來記載資料庫配置參數變更。8.1 版 4K 檔案會予以保留,但不會使用。

如果您移轉回 DB2 UDB 8.1 版, DB2 UDB 8.1 版產品就會回復為使用原始 8.1 版 4K 檔案,來記載資料庫配置參數變更。 8.2 版 16K 檔案會予以保留,但是 DB2 UDB 8.1 版產品無法辨識它。實際上,在移轉至 8.2 版及移轉回 8.1 版之間, 對於 16K 資料庫配置參數檔所做的變更會隱藏起來,讓舊版 DB2 UDB 看不到,因為這些變更並不會移轉至原始 4K 檔案。

此外,如果您重新移轉至 DB2 UDB 8.2 版,DB2 UDB 8.2 版產品會認定 16K 資料庫配置檔已經存在,並且會回復為使用 8.2 版 16K 檔案,來記載資料庫配置參數變更。 8.1 版 4K 檔案會予以保留,但是 DB2 UDB 8.2 版產品無法辨識它。實際上,在移轉回 8.1 版及重新移轉至 8.2 版之間, 對於 4K 資料庫配置參數檔所做的變更會隱藏起來,讓新版 DB2 UDB 看不到,因為這些變更並不會移轉至現存的 16K 檔案。

db2diag.log 格式訊息加強功能

在 8.2 版中,已用若干方法改善了 db2diag.log 檔案格式。 日誌檔現在更易於以手動方式讀取,而且更易於以軟體剖析。 改善的部份包括:

也產生了其他變更,如將資料庫欄位名稱變更為 DB

事件記錄已新增為 db2diag.log 檔案的診斷訊息。 這樣事件的範例如下:

事件記錄具有在 LEVEL 欄位中指定的「事件」。 雖然事件不是錯誤,但是它們可能記載於 4 (資訊) 或 3 (警告) 以外的診斷層次, 取決於它們的重要性而定。

現在 db2set 設定檔登錄變數及 DB 或 DBM 配置參數會記載於日誌中

從 8.2 版開始,下列更新將記載於 db2diag.log 檔案中:

由於這些更新的訊息都很重要,所以它們會記載於高的診斷層次中。

下列類型的 db2set 設定檔登錄更新會記載於日誌中:

修改
db2set variableName=value 命令產生如下的 db2diag.log 項目:
2004-04-22-19.19.14.156959-240 I79582C286         LEVEL: Event
PID     : 2437242              TID  : 1           PROC : db2set
INSTANCE: db2user              NODE : 000
FUNCTION: DB2 UDB, oper system services, db2set_main, probe:40
CHANGE  : CFG DB2SET: DB2DBDFT: From: "OLDDB" To: "SAMPLE"
刪除
db2set -r 命令產生如下的 db2diag.log 項目:
CHANGE  : CFG DB2SET: DB2DBDFT: From: "SAMPLE" To: ""
註:
在前述範例中,標頭資訊會予以省略。
重設
db2set variableName=value 命令產生如下的 db2diag.log 項目:
CHANGE  : CFG DB2SET: Profile registry was reset
註:
在前述範例中,標頭資訊會予以省略。

DB 及 DBM 配置參數更新的範例如下:

CHANGE  : CFG DB SAMPLE: "Maxlocks" From: "10" To: "20"

CHANGE  : CFG DBM: "Diaglevel" From: "3" To: "1"

CHANGE  : CFG DBM: Reset to the system defaults
註:
在前述範例中,標頭資訊會予以省略。

若要尋找這些配置更新訊息,請使用 db2diag 工具。例如:

產品相容性

DB2 Universal Database for Linux, UNIX and Windows 支援 JDK 1.4.2

在所有 DB2 UDB 支援的 32 位元及 64 位元工作站作業系統環境上, DB2 Universal Database(TM) (UDB) for Linux、UNIX 及 Windows(R) 8.2.2 版 (相當於 8.1 版 FixPak 9) 均支援 JDK 1.4.2。 這個支援包括 (但不限於) 建置及執行 Java(TM) 用戶端應用程式的支援、 從命令行建置及執行 Java(TM) 常式的支援、從支援 Java(TM) 常式的「DB2 開發中心」建置及執行 Java 常式的支援, 以及執行其它 DB2 工具的支援。

當您安裝 DB2 UDB 8.2 版時,如果未安裝最新支援版本的開發者套件,也將安裝它, 除非 DB2 UDB 安裝只是用來更新先前的 DB2 UDB 第 8 版安裝。 如果您正要更新先前的 DB2 UDB 第 8 版安裝,則必須從 CD 安裝 Java 開發者套件。

下表指出 DB2 支援的 32 位元及 64 位元工作站作業系統環境, 以及它們每一個支援的最新 JDK 層次。如需舊版 JDK 支援的相關資訊, 請參閱 Java Application Development 網頁,網址為 http://www.ibm.com/software/data/db2/udb/ad/v8/java/

表 1. 含對應支援 JDK 層次的 DB2 支援環境
DB2 支援環境 最新支援 JDK 層次
Windows IA/AMD 32 位元 JDK 1.4.2
Windows IA 64 位元 JDK 1.4.2
Windows AMD/EM64T 64 位元 JDK 1.4.2
AIX(R) 4.3.3 32 位元 JDK 1.3.1 SR6 [2]
AIX(R) 5 (混合式 [1]) JDK 1.4.2
Solaris (混合式 [1]) JDK 1.4.2
HPUX RISC & Itanium (混合式 [1]) JDK 1.4.2.01
Linux AMD/EM64T 32 位元、64 位元 (混合式 [1]) JDK 1.4.2 [3]
Linux IA 32 位元 JDK 1.4.2
Linux IA 64 位元 JDK 1.4.2
Linux 390 31 位元 JDK 1.4.2
Linux 390 64 位元 JDK 1.4.2
Linux PPC (混合式 [1]) JDK 1.4.2
註:
  1. 混合式代表一個包含 32 位元及 64 位元支援的安裝映像檔
  2. JDK 1.3.1 Service Release 6 是 AIX(R) 4.3.3 唯一支援的 JDK 版本。
  3. 在含 JDK 1.4.2 的 Linux AMD/EM64T (32 位元及 64 位元) 上,沒有 DB2 圖形式使用者介面工具支援。

接下來提供設定「Linux Java 環境」的更新程序。

設定 Linux Java 環境

先決條件

程序

若要在支援 DB2 JDBC 的 Linux 上建置 Java 應用程式,請:

  1. 安裝及配置「Linux 支援的開發軟體」主題中所列出的其中一個支援的開發者套件, 您可以在 Application Development Guide: Building and Running Applications 手冊中找到這個主題。

    若要執行 Java 儲存程序或使用者定義的函數, Linux 執行時期鏈結器必須能夠存取某些 Java 共用檔案庫, 而且 DB2 UDB 必須能夠載入這些檔案庫及 Java 虛擬機器。 執行儲存程序及使用者定義的函數的程序只在安全位置 (定義在 /etc/ld.so.conf 檔案) 中載入檔案庫。 /usr/lib 就是這些安全位置之一。剩餘的指示顯示哪些檔案庫需要 /usr/lib 中的符號鏈結。

  2. /usr/lib 建立符號鏈結,以指向 Java 共用檔案庫。 根據您正在使用的 JDK 版本,您將具有不同共用檔案庫的鏈結:
    若為 IBM(R) Developer Kit 1.3
    建立 libjava.so、libjvm.so 及 libhpi.so 的符號鏈結。您可以藉由以 root 身分執行下列命令來建立符號鏈結:
    cd /usr/lib
       ln -fs JAVAHOME/jre/bin/libjava.so .
       ln -fs JAVAHOME/jre/bin/classic/libjvm.so .
       ln -fs JAVAHOME/jre/bin/libhpi.so . 
    其中 JAVAHOME 是 IBM(R) Developer Kit 的基本目錄。 如果 DB2 UDB 找不到這些檔案庫, 則當您嘗試執行 Java 常式時,將得到 -4301 錯誤,而且管理通知日誌中將有關於找不到檔案的訊息。
    若為 IBM(R) Developer Kit 1.4.1
    建立 libjava.so、libjvm.so、libhpi.so 及 libjsig.so 的符號鏈結。 您可以藉由以 root 身分執行下列命令來建立符號鏈結:
    cd /usr/lib
      ln -fs JAVAHOME/jre/bin/libjava.so
      ln -fs JAVAHOME/jre/bin/classic/libjvm.so
      ln -fs JAVAHOME/jre/bin/libhpi.so
      ln -fs JAVAHOME/jre/bin/libjsig.so
    其中 JAVAHOME 是 IBM Developer Kit 的基本目錄。 如果 DB2 UDB 找不到這些檔案庫, 則當您嘗試執行 Java 常式時,將得到 -4301 錯誤,而且管理通知日誌中將有關於找不到檔案的訊息。
    若為 Linux 平台 (不是 AMD64/EM64T) 上的 IBM Developer Kit 1.4.2
    建立 libjava.so、libjvm.so、libhpi.so、libjsig.so、 libjitc.so、libxhpi.so 及 libdbgmalloc.so 的符號鏈結。您可以藉由以 root 身分執行下列命令來建立符號鏈結:
    cd /usr/lib
      ln -fs JAVAHOME/jre/bin/libjava.so
      ln -fs JAVAHOME/jre/bin/classic/libjvm.so
      ln -fs JAVAHOME/jre/bin/libhpi.so
      ln -fs JAVAHOME/jre/bin/libjsig.so
      ln -fs JAVAHOME/jre/bin/libjitc.so
      ln -fs JAVAHOME/jre/bin/libxhpi.so
      ln -fs JAVAHOME/jre/bin/libdbgmalloc.so
    其中 JAVAHOME 是 IBM Developer Kit 的基本目錄。 如果 DB2 UDB 找不到這些檔案庫, 則當您嘗試執行 Java 常式時,將得到 -4301 錯誤,而且管理通知日誌中將有關於找不到檔案的訊息。
    若為 Linux AMD64/EM64T 上的 IBM Developer Kit 1.4.2
    這個開發者套件不同於其它 Linux 平台上的套件。 請遵循隨後的替代程序一節所概述的指示,並將下列一行放在 /etc/ld.so.conf
       JAVAHOME/jre/bin
    其中 JAVAHOME 是 IBM Developer Kit 的基本目錄。 如果 DB2 UDB 找不到這些檔案庫,則在嘗試執行 Java 常式時, 將發生 -4301 或 -1042 錯誤。
替代程序

不需明確地對 /usr/lib 目錄中的共用檔案庫建立鏈結,您可以將儲存 Java 共用檔案庫的目錄名稱新增到 /etc/ld.so.conf 檔案。這個檔案需要 root 許可權。在更新 /etc/ld.so.conf 之後,您必須以 root 身分執行 ldconfig 命令, 才能啟動變更。如果您遇到任何與這個替代程序相關的問題,請依先前的指示在 /usr/lib 目錄中建立鏈結。

64 位元作業系統需要 Microsoft XP 修正程式

如果 DB2 系列產品與配置為使用 NetBIOS 通訊協定的 Microsoft(R) XP 64 位元作業系統 (2600) 搭配使用,您必須向 Microsoft 取得快速修復程式。 請利用 Knowledge Base 文章號碼 Q317437 來洽詢 Microsoft。

Windows XP 作業系統

只有 DB2 Universal Database (UDB) Personal Edition 產品支援 Windows XP Home Edition 作業系統。

下列 DB2 產品支援 Windows XP Professional 作業系統:

下列 DB2 產品僅基於開發或測試目的,支援 Windows XP (產品環境需要 Windows 2000 或 Windows Server 2003):

可以使用 DB2 UDB HADR 個別付費的選項

在 DB2 Universal Database(TM) (UDB) 8.2 版中,DB2 UDB Workgroup Server Edition 及 DB2 UDB Express Edition 的客戶 (當使用權是以依每一位使用者計價的模式為基礎時) 無法安裝 DB2 UDB High Availability Disaster Recovery (HADR) 個別付費的選項。這個問題已在 DB2 UDB 8.2 版 FixPak 1 (相當於 8.1 版 FixPak 8) 中修正好了。

DB2 Warehouse Manager (8.2 版) 及 IBM DB2 OLAP Server FP3 及更新版本

DB2 Warehouse Manager Standard Edition 8.2 版中的 OLAP 公用程式與 IBM DB2 OLAP Server(TM) FP3 (Essbase API 層次 6.5.4) 及更新版本不相容。 建議您使用 DB2 OLAP Server FP2 (Essbase 6.5.3) 或更舊版本,直到這個問題解決為止。

原始 I/O 日誌支援 (含 2.6 核心程式的 Linux)

若要以 DB2 Universal Database (UDB) 8.2.2 版 (相當於 8.1 版 FixPak 9) 之前的原始 I/O 裝置來使用日誌, 則需要利用原始公用程式,將實體裝置連結至 Linux 原始字元裝置驅動程式。 從 DB2 UDB 8.2.2 版 (相當於 8.1 版 FixPak 9) 開始,在 2.6 Linux 核心程式上, 可以直接指定日誌的原始 I/O。 例如,若要對 SAMPLE 資料庫的原始日誌使用裝置分割區 /dev/sdb1,請發出下列命令:

db2 update db cfg for sample using newlogpath /dev/sdb1

雖然 DB2 UDB 仍然支援對原始 I/O 使用原始公用程式的方法, 但是最新的發行版已即將棄用這個特性,而且可能在未來除去它。 最好直接指定裝置來使用新方法。

資料倉儲中心支援 Red Hat Linux

DB2 Universal Database 8.2 版支援 Red Hat Enterprise Linux AS 第 3 版及 2.1 版。但是,「資料倉儲中心」只支援 Red Hat Enterprise Linux AS 2.1 版。「資料倉儲中心」使用的 DataDirect ODBC 驅動程式不支援 Red Hat Enterprise Linux AS 3.1 版。因此,「資料倉儲中心」不支援來自 Red Hat Enterprise Linux AS 3.1 版代理站的 ODBC 倉儲來源及倉儲目標。

WebSphere MQ 交易管理程式與 DB2 for OS/390 需要連線集中器

在 IBM(R) WebSphere(R) MQ (舊稱 IBM MQSeries(R)) 環境中執行應用程式時, WebSphere(R) MQ 可以充當符合 XA 標準的交易管理程式,協調任何分散式、兩段式確定交易。 當 WebSphere(R) MQ 以這種方式充當交易管理程式,而且資料來源是來自 DB2 系列產品時, 有數個配置需求。這些需求大部份已於文件中說明了。 例如,您必須在 DB2 執行時期用戶端中將 DB2 配置參數 TP_MON_NAME 設為 "MQ"。

不過,有一個未以文件說明的配置需求。 當連接到成為 DB2 for OS/390(R) 伺服器的資料來源時, 需求是 DB2 Connect 所特有的:當使用 WebSphere MQ 協調包括 DB2 for z/OS(R) 及 DB2 for iSeries 伺服器的分散式交易時, 必須在閘道啟用 DB2 Connect 連線集中器特性。 當 MAX_CONNECTIONS 配置參數的值大於 MAX_COORDAGENTS 的值時, 將啟用連線集中器。如果您未啟用連線集中器,將造成非預期的交易行為。

編碼字集識別碼 (CCSID) 5039 的替代 Unicode 轉換表

Microsoft Japanese Windows Shift-JIS 字碼頁已登錄為 IBM 編碼字集識別碼 (CCSID) 943。但是,HP-UX 平台上的 Shift-JIS 字碼頁已登錄為 CCSID 5039。 CCSID 5039 僅含有「日本工業標準 (JIS)」中的字元,沒有任何供應商定義的字元。 您可以在 HP-UX 上使用 CCSID 5039 的 DB2 Universal Database (UDB) 資料庫,來儲存 Shift-JIS 字元,但 CCSID 5039 與 CCSID 943 之間將發生字碼頁轉換。 當使用 Microsoft ODBC 應用程式時,您可能會在將 CCSID 5039 中的資料轉換為 Unicode 時遇到問題, 因為 IBM 的字碼頁轉換表與 Microsoft 的字碼頁轉換表之間有差異。

從 CCSID 5039 轉換為 Unicode 時,以下所列的字元將造成不同的字碼點, 這會根據使用的轉換表而定 (IBM 或 Microsoft)。對於這些字元而言, IBM 轉換表符合「日本工業標準」JISX0208 及 JISX0221。

表 2. CCSID 5039 至 Unicode 字碼點轉換
Shift-JIS 字碼點 (字元名稱) IBM 主要字碼點 (Unicode 名稱) Microsoft 主要字碼點 (Unicode 名稱)
X'815C' (EM 破折號) U+2014 (EM 破折號) U+2015 (水平列)
X'8160' (波狀破折號) U+301C (波狀破折號) U+FF5E (完整寬度的 ~ 字元)
X'8161' (雙垂直線) U+2016 (雙垂直線) U+2225 (並行)
X'817C' (減號) U+2212 (減號) U+FF0D (完整寬度的連字號-減號)

例如,當使用 IBM 轉換表時,具有 CCSID 5039 字碼點 X'815C' 的字元 EM 破折號會轉換為 Unicode 字碼點 U+2014, 但是在使用 Microsoft 轉換表時,則會轉換為 U+2015。 這可能會對 Microsoft ODBC 應用程式產生潛伏的問題,因為它們會將 U+2014 視為無效的字碼點。 為了避免這些潛伏的問題,除了預設 IBM 轉換表之外,DB2 UDB 還會提供從 CCSID 5039 轉換至 Unicode 的替代 Microsoft 轉換表。 您需要將預設 IBM 轉換表換成替代 Microsoft 轉換表。請注意,從 Unicode 轉換至 CCSID 5039 的預設 IBM 轉換表符合 Microsoft 版本。

將編碼字集 (CCSID) 5039 的 Unicode 轉換表換成 Microsoft 轉換表

從 CCSID 5039 轉換為 Unicode 時,就會使用 DB2 Universal Database (UDB) 預設字碼頁轉換表。 如果您想要使用不同版本的轉換表,如 Microsoft 版本, 則必須以手動方式置換預設轉換表 (.cnv) 檔案。

先決條件

在置換 sqllib/conv 目錄中的現存字碼頁轉換表檔案之前,您應該備份檔案,以防您想要變回它。 在 UNIX 及 Linux 上,sqllib/conv 目錄會鏈結至 DB2 UDB 安裝路徑。

限制

若要能夠有效地置換轉換表,每一個連接至相同資料庫的 DB2 UDB 用戶端,都必須已變更了它的轉換表。 不然,不同的用戶端可能使用不同的字碼點來儲存相同的字元。

程序

若要置換 DB2 UDB 預設轉換表,以便從 CCSID 5039 轉換為 Unicode,請遵循下列步驟:

  1. sqllib/conv/ms/5039ucs2.cnv 複製至 sqllib/conv/5039ucs2.cnv
  2. 重新啟動 DB2 UDB。

編碼字集識別碼 (CCSID) 954 的替代 Unicode 轉換表

日文 EUC 字碼頁的 IBM 編碼字集識別碼 (CCSID) 已登錄為 CCSID 954。 CCSID 954 是日文 UNIX 及 Linux 平台常用的編碼。 使用 Microsoft ODBC 應用程式連接至 CCSID 954 的 DB2 Universal Database (UDB) 資料庫時, 您可能會在將資料從 CCSID 954 轉換為 Unicode 時遇到潛伏的問題。 發生潛伏的問題是因為 IBM 的字碼頁轉換表與 Microsoft 的字碼頁轉換表之間有差異。 IBM 轉換表符合「日本工業標準 (JIS)」JISX0208、JISX0212 及 JISX0221 中指定的字元名稱。

從 CCSID 954 轉換為 Unicode 時,下列字元將造成不同的字碼點, 這會根據使用 IBM 或 Microsoft 轉換表而定。

表 3. CCSID 954 至 Unicode 字碼點轉換
EUC-JP 字碼點 (字元名稱) IBM 主要字碼點 (Unicode 名稱) Microsoft 主要字碼點 (Unicode 名稱)
X'A1BD' (EM 破折號) U+2014 (EM 破折號) U+2015 (水平列)
X'A1C1' (波狀破折號) U+301C (波狀破折號) U+FF5E (完整寬度的 ~ 字元)
X'A1C2' (雙垂直線) U+2016 (雙垂直線) U+2225 (並行)
X'A1DD' (減號) U+2212 (減號) U+FF0D (完整寬度的連字號-減號)
X'8FA2C3' (分列) U+00A6 (分列) U+FFE4 (完整寬度的分列)

例如,當使用 IBM 轉換表時,具有 CCSID 954 字碼點 X'A1BD' 的字元 EM 破折號會轉換為 Unicode 字碼點 U+2014, 但是在使用 Microsoft 轉換表時,則會轉換為 U+2015。 因為轉換對映的這個差異,所以您可能在 DB2 UDB Unicode 資料庫,或在 DB2 UDB 954 資料庫的圖形直欄中,對相同字元具有兩個不同的字碼點。 這可能會對 Microsoft ODBC 應用程式產生潛伏的問題,因為它們會將 U+2014 視為無效的字碼點。 為了避免這些潛伏的問題,除了預設 IBM 轉換表之外, DB2 UDB 還會提供從 CCSID 954 轉換至 Unicode 的替代 Microsoft 轉換表。 您需要將預設 IBM 轉換表換成替代 Microsoft 轉換表。請注意,從 Unicode 轉換至 CCSID 954 的預設 IBM 轉換表符合 Microsoft 版本。

將編碼字集 (CCSID) 954 的 Unicode 轉換表換成 Microsoft 轉換表

從 CCSID 954 轉換為 Unicode 時,就會使用 DB2 Universal Database (UDB) 預設字碼頁轉換表。 如果您想要使用不同版本的轉換表,如 Microsoft 版本, 則必須以手動方式置換預設轉換表 (.cnv) 檔案。

先決條件

在置換 sqllib/conv 目錄中的現存字碼頁轉換表檔案之前,您應該備份檔案,以防您想要變回它。 在 UNIX 及 Linux 上,sqllib/conv 目錄會鏈結至 DB2 UDB 的安裝路徑。

限制

若要讓這種情況生效,每一個連接至相同 CCSID 954 資料庫的 DB2 UDB 用戶端,都必須已變更了它的轉換表。 如果您的用戶端是日文 Windows,其 ANSI 字碼頁是 Shift-JIS (CCSID 943), 則您也需要將 CCSID 943 與 Unicode 之間的 DB2 預設轉換表變更為 Microsoft 版本。 不然,不同的用戶端可能使用不同的字碼點來儲存相同的字元。

程序

若要置換 DB2 UDB 預設轉換表,以便從 CCSID 954 轉換為 Unicode,請遵循下列步驟:

  1. sqllib/conv/ms/0954ucs2.cnv 複製至 sqllib/conv/0954ucs2.cnv
  2. 重新啟動 DB2 UDB。

若要置換 DB2 UDB 預設轉換表,以便在 CCSID 943 與 Unicode 之間進行轉換,請遵循下列步驟:

  1. sqllib/conv/ms/0943ucs2.cnv 複製至 sqllib/conv/0943ucs2.cnv
  2. sqllib/conv/ms/ucs20943.cnv 複製至 sqllib/conv/ucs20943.cnv
  3. 重新啟動 DB2 UDB。

編碼字集 ID (CCSID) 943 的替代 Unicode 轉換表

當使用已登錄為 IBM 編碼字集 ID (CCSID) 943 的 Microsoft Japanese Windows Shift-JIS 字碼頁時, 您在 CCSID 943 與 Unicode 之間轉換字元可能會遇到下列兩個問題。 發生潛伏的問題是因為 IBM 與 Microsoft 字碼頁轉換表之間有差異。 為了避免這些潛伏的問題,除了預設 IBM 轉換表之外, DB2 Universal Database (UDB) 還會提供 CCSID 943 與 Unicode 之間的替代 Microsoft 轉換表。

問題 1

基於歷史原因,CCSID 943 字碼頁中有 300 個以上的字元, 每一個都是以兩個或三個字碼點來表示。使用輸入方法編輯器 (IME) 及字碼頁轉換表僅會導致輸入這些相等字碼點的其中一個。例如, 羅馬數字 1 'i' 的小寫字元具有兩個相等的字碼點:X'EEEF' 及 X'FA40'。當您輸入 'i' 時,Microsoft Windows IME 總是產生 X'FA40'。 一般說來,IBM 及 Microsoft 都使用相同的主要字碼點來代表字元,但是下列 13 個字元除外:

表 4. CCSID 943 Shift-JIS 字碼點轉換
字元名稱 (Unicode 字碼點) IBM 主要 Shift-JIS 字碼點 Microsoft 主要 Shift-JIS 字碼點
羅馬數字 1 (U+2160) X'FA4A' X'8754'
羅馬數字 2 (U+2161) X'FA4B' X'8755'
羅馬數字 3 (U+2162) X'FA4C' X'8756'
羅馬數字 4 (U+2163) X'FA4D' X'8757'
羅馬數字 5 (U+2164) X'FA4E' X'8758'
羅馬數字 6 (U+2165) X'FA4F' X'8759'
羅馬數字 7 (U+2166) X'FA50' X'875A'
羅馬數字 8 (U+2167) X'FA51' X'875B'
羅馬數字 9 (U+2168) X'FA52' X'875C'
羅馬數字 10 (U+2169) X'FA53' X'875D'
括入括弧內的表意文字語系 (U+3231) X'FA58' X'FA58'
編號符號 (U+2116) X'FA59' X'8782'
電話符號 (U+2121) X'FA5A' X'8754'

IBM 產品 (如 DB2 UDB) 主要使用 IBM 字碼點 (如 X'FA4A') 來呈現大寫的羅馬數字 1 'I',但是 Microsoft 產品卻使用 X'8754' 來代表相同的字元。Microsoft ODBC 應用程式可以將 'I' 字元當作 X'8754' 插入 CCSID 943 的 DB2 UDB 資料庫, 而「DB2 UDB 控制中心」則可以將相同字元當作 X'FA4A' 插入相同的 CCSID 943 資料庫。但是,ODBC 應用程式僅能尋找那些具有 'I' 編寫成 X'8754' 的橫列, 而「DB2 UDB 控制中心」僅能尋找那些具有 'I' 編寫成 X'FA4A' 的橫列。若要讓「DB2 UDB 控制中心」能夠選取 'I' 作為 X'8754',您需要將 CCSID 943 與 Unicode 之間的預設 IBM 轉換表換成替代 Microsoft 轉換表。

問題 2

從 CCSID 943 轉換為 Unicode 時,以下所列的字元將造成不同的字碼點, 這會根據使用 IBM 轉換表或 Microsoft 轉換表而定。對於這些字元而言, IBM 轉換表符合「日本工業標準」JISX0208、JISX0212 及 JISX0221。

表 5. CCSID 943 至 Unicode 字碼點轉換
Shift-JIS 字碼點 (字元名稱) IBM 主要字碼點 (Unicode 名稱) Microsoft 主要字碼點 (Unicode 名稱)
X'815C' (EM 破折號) U+2014 (EM 破折號) U+2015 (水平列)
X'8160' (波狀破折號) U+301C (波狀破折號) U+FF5E (完整寬度的 ~ 字元)
X'8161' (雙垂直線) U+2016 (雙垂直線) U+2225 (並行)
X'817C' (減號) U+2212 (減號) U+FF0D (完整寬度的連字號-減號)
X'FA55' (分列) U+00A6 (分列) U+FFE4 (完整寬度的分列)

例如,當使用 IBM 轉換表時,具有 CCSID 943 字碼點 X'815C' 的 字元 EM 破折號會轉換為 Unicode 字碼點 U+2014。 但是,使用 Microsoft 轉換表時,它會轉換為 U+2015。 因為轉換對映的這個差異,所以您可能在 DB2 UDB Unicode 資料庫, 對相同字元具有兩個不同的字碼點。 這可能會對 Microsoft ODBC 應用程式產生潛伏的問題,因為它們會將 U+2014 視為無效的字碼點。 為了避免這個潛伏的問題,您需要將 CCSID 943 與 Unicode 之間的預設 IBM 轉換表換成替代 Microsoft 轉換表。

在 CCSID 943 與 Unicode 之間使用替代 Microsoft 轉換表應該限制在封閉環境中, 在這裡 DB2 UDB 用戶端及 DB2 UDB 資料庫全都具有字碼頁 CCSID 943, 而且全都正在使用相同的替代 Microsoft 轉換表。如果您有一個 DB2 UDB 用戶端正在使用預設 IBM 轉換表, 有另一個 DB2 UDB 用戶端正在使用替代 Microsoft 轉換表, 而且這兩個用戶端正在將資料插入 CCSID 943 的相同 DB2 UDB 資料庫,則相同字元可以在資料庫中儲存為不同的字碼點。

將編碼字集 (CCSID) 943 的 Unicode 轉換表換成 Microsoft 轉換表

在 CCSID 943 與 Unicode 之間轉換時,將使用 DB2 Universal Database (UDB) 預設字碼頁轉換表。如果您想要使用不同版本的轉換表,如 Microsoft 版本, 則必須以手動方式置換預設轉換表 (.cnv) 檔案。

先決條件

在置換 sqllib/conv 目錄中的現存字碼頁轉換表檔案之前, 您應該備份檔案,以防您想要變回它。在 UNIX 及 Linux 上,sqllib/conv 會鏈結至 DB2 UDB 安裝路徑。

限制

若要能夠有效地置換轉換表,每一個連接至相同資料庫的 DB2 UDB 用戶端,都必須已變更了它的轉換表。 不然,不同的用戶端可能使用不同的字碼點來儲存相同的字元。

程序

若要置換 DB2 UDB 預設轉換表,以便在 CCSID 943 與 Unicode 之間轉換字元:

  1. sqllib/conv/ms/0943ucs2.cnv 複製至 sqllib/conv/0943ucs2.cnv
  2. sqllib/conv/ms/ucs20943.cnv 複製至 sqllib/conv/ucs20943.cnv
  3. 重新啟動 DB2 UDB。

不支援 MVS 作業系統

儘管文件中會提到 MVS,但 DB2 Universal Database 已不再支援 MVS(TM) 作業系統。 MVS 已換成 z/OS。

備份及還原作業 (Linux 390)

如果您使用 Linux 390 作業系統,可能無法使用多個磁帶裝置來進行備份及還原作業。

以 Hummingbird Exceed 存取開發中心時啟用檢視畫面停駐

在 UNIX 上以 Hummingbird(R) Exceed 存取「開發中心」時,必須先啟用 XTEST 擴充 2.2 版, 才能在「開發中心」內拖移檢視畫面的標題列,以移動及停駐檢視畫面。

若要啟用 XTEST 擴充:

  1. 從「開始」功能表中選取程式集 -> Hummingbird Connectivity 7.0 -> 超出 -> XConfig。這時會開啟 XConfig 視窗。
  2. 選用項目:若您的配置需要密碼,請輸入 XConfig 密碼。
  3. 按兩下通訊協定圖示。這時會開啟「通訊協定」視窗。
  4. 選取 X 相符測試相容性勾選框。
  5. 通訊協定視窗中,按一下擴充... 按鈕。這時會開啟「通訊協定擴充」視窗。
  6. 在「啟用擴充」清單中,選取 XTEST(X11R6) 勾選框。
  7. 按一下確定
[ 頁面頂端 |前一頁 | 下一頁 | 目錄 ]