informix數(shù)據(jù)遷移--表卸載問題

8213452

在數(shù)據(jù)遷移時(shí)選取unload/load工具進(jìn)行數(shù)據(jù)卸裝.
但,當(dāng)單表數(shù)據(jù)量過大時(shí),使用load裝載會(huì)遇到臨時(shí)表空間不足的問題.裝載被終止.例如,表記錄6000W,unload成一個(gè)20G的文件.
使用文件拆分的方法可以將單個(gè)文件拆分成多個(gè)文件,再進(jìn)行l(wèi)oad可以解決該問題.但在分拆時(shí)會(huì)有數(shù)據(jù)格式的問題,且有大量的表需要遷移.該方法效率不高,暫時(shí)不考慮.
另外,可以在unload中加入限制條件,將單個(gè)表按照條件unload成多個(gè)文件,再進(jìn)行l(wèi)oad.例如以時(shí)間為單位.編寫一個(gè)稍微復(fù)雜的程序可以完成該功能,實(shí)現(xiàn)時(shí)需考慮起始時(shí)間、時(shí)間粒度等。關(guān)鍵在于我暫時(shí)只想寫點(diǎn)簡(jiǎn)單的程序。

所以想咨詢各位的是，有沒有更方便的方法或工具，在數(shù)據(jù)卸載時(shí)以行為單位導(dǎo)出。例如：每100W行形成一個(gè)文件。

liaosnet

使用onpload工具可以很容易實(shí)現(xiàn)這樣的功能~~

http://blog.chinaunix.net/u/28641/showart_1677913.html

8213452

這是個(gè)好建議，可行

koolkite

有誰(shuí)做過類似的工作，共享些經(jīng)驗(yàn)，謝謝

adaready

用onpladm。
我曾經(jīng)做過的案例中，3000w行的數(shù)據(jù)，大概在15分鐘左右完成。作為比較，dbload/unload/load之類的，大概要4-5小時(shí)。

8213452

onpladm這個(gè)工具資料太少了，即便是IBM所給的手冊(cè)里也是不全。以創(chuàng)建query為例，里面居然沒有詳細(xì)其SQL格式，以至于我根本就不知道里面的SQL是要加雙引號(hào)的。后來看別人的例子才知道。

現(xiàn)在遇到一個(gè)問題，找了半天也沒找到資料，求教于諸位
在執(zhí)行job時(shí)運(yùn)行的是默認(rèn)的query，而不是我定義的query。如何執(zhí)行自定義的query。
使用onpladm list query -p proj 顯示有兩個(gè)query
一個(gè)是和job名稱相同
一個(gè)是手工創(chuàng)建的

另外想咨詢一下，創(chuàng)建的project和job以什么方式保存，可不可以直接進(jìn)行修改？例如：文件方式的話可以修改文件，數(shù)據(jù)庫(kù)方式可以u(píng)pdate，特殊格式的話那就算了。

liaosnet

保存在一個(gè)名為onpload的庫(kù)里~~dbaccess可以看到~~里面的表名與onpladm種類名類似...

可更改~~

8213452

謝謝��！難怪我運(yùn)行dbaccess的時(shí)候總感覺多了點(diǎn)什么。

8213452

text數(shù)據(jù)類型，unload出來改一下，再load就更新了。不錯(cuò)不錯(cuò)，速度很快，這個(gè)工具還是很好用的。可以批量作業(yè)。

8213452

問題來了！

在使用onpladm導(dǎo)回?cái)?shù)據(jù)時(shí)遇到問題。試了幾個(gè)大表，裝載完記錄時(shí)停止不動(dòng)了。應(yīng)該是在做enable index之類的操作。因?yàn)楸碛涗洍l數(shù)有1億多，且rowsize比較大，剛開始以為enable index耗時(shí)較大就一直等著。等了兩天也沒響應(yīng)，應(yīng)該是有問題了。試了一些小一點(diǎn)的表，均可正常完成導(dǎo)入。
嘗試修改load模式，將onpload庫(kù)中session表中對(duì)應(yīng)的runmode由129改為7(express mode改為deluxe mode),試了一下.run job報(bào)錯(cuò)了。
大家還有什么好的建議嗎？