亚洲av成人无遮挡网站在线观看,少妇性bbb搡bbb爽爽爽,亚洲av日韩精品久久久久久,兔费看少妇性l交大片免费,无码少妇一区二区三区

Chinaunix

標(biāo)題: informix數(shù)據(jù)遷移--表卸載問題 [打印本頁]

作者: 8213452 時(shí)間: 2009-05-12 15:54
標(biāo)題: informix數(shù)據(jù)遷移--表卸載問題
在數(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)簡單的程序。

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

作者: liaosnet 時(shí)間: 2009-05-12 15:59
標(biāo)題: 回復(fù) #1 8213452 的帖子
使用onpload工具可以很容易實(shí)現(xiàn)這樣的功能~~

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

作者: 8213452 時(shí)間: 2009-05-12 16:09
這是個(gè)好建議，可行

作者: koolkite 時(shí)間: 2009-05-15 16:03
有誰做過類似的工作，共享些經(jīng)驗(yàn)，謝謝

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

作者: 8213452 時(shí)間: 2009-05-19 10:45
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ù)庫方式可以u(píng)pdate，特殊格式的話那就算了。

作者: liaosnet 時(shí)間: 2009-05-19 10:47
標(biāo)題: 回復(fù) #6 8213452 的帖子
保存在一個(gè)名為onpload的庫里~~dbaccess可以看到~~里面的表名與onpladm種類名類似...

可更改~~

作者: 8213452 時(shí)間: 2009-05-19 10:53
謝謝啊！難怪我運(yùn)行dbaccess的時(shí)候總感覺多了點(diǎn)什么。

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

作者: 8213452 時(shí)間: 2009-05-26 15:21
問題來了！

在使用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庫中session表中對(duì)應(yīng)的runmode由129改為7(express mode改為deluxe mode),試了一下.run job報(bào)錯(cuò)了。
大家還有什么好的建議嗎？

作者: 8213452 時(shí)間: 2009-05-26 15:33
其中有一個(gè)任務(wù)我使用ctrl + c終止了。/tmp目錄下的日志顯示set mode of indexes失敗。dbschema -d dbname -t tabname -ss查看該表結(jié)構(gòu)時(shí)顯示index為disabled.進(jìn)dbaccess可查詢數(shù)據(jù)。
是否可以在dbaccess中手工執(zhí)行set indexs indexname enabled。該操作是否等同于onpladm中的最后操作。

作者: liaosnet 時(shí)間: 2009-05-26 15:37
標(biāo)題: 回復(fù) #11 8213452 的帖子
可以~~onpload前面是導(dǎo)數(shù)據(jù),后面是使index生效...

在DUMPDIR目錄下,你可以看一下日志里是什么原因~執(zhí)行到什么時(shí)候了..

作者: 8213452 時(shí)間: 2009-05-26 15:49
目前依然在執(zhí)行的一個(gè)任務(wù)，dump目錄應(yīng)該是/tmp，在該目錄下對(duì)應(yīng)該任務(wù)有三個(gè)文件
jobname.rej
jobname.flt
jobname.log
其中，前兩個(gè)文件為空。tail jobname.log文件顯示：
.........(內(nèi)容下同)
20:10:06 Records Processed -> 80200000

與crt輸出內(nèi)容相同
停止在導(dǎo)完記錄處。

作者: 8213452 時(shí)間: 2009-05-26 15:58
onstat -g sql 顯示有幾個(gè)onpload任務(wù)及一個(gè)set objmode任務(wù)
其中set objmode內(nèi)容為
set indexs indexname enabled

作者: liaosnet 時(shí)間: 2009-05-26 16:02
標(biāo)題: 回復(fù) #14 8213452 的帖子
額.那他就是在做啟用索引唄~~

作者: 8213452 時(shí)間: 2009-05-26 16:09
那這個(gè)進(jìn)度就不太敢恭維了。我試一下在dbaccess手工執(zhí)行indexs indexname enabled。

作者: koolkite 時(shí)間: 2009-05-27 16:27
標(biāo)題: 回復(fù) #5 adaready 的帖子
如果只是對(duì)單表的操作貌似還可以接受，但是如果實(shí)施在整庫遷移的時(shí)候呢？我曾利用那些命令編寫一個(gè)shell腳本進(jìn)行整庫處理，結(jié)果發(fā)現(xiàn)并發(fā)到8個(gè)任務(wù)的時(shí)候，總是會(huì)出現(xiàn)錯(cuò)誤，不知道為什么

作者: prefect 時(shí)間: 2009-05-27 17:47

原帖由 koolkite 于 2009-5-27 16:27 發(fā)表
如果只是對(duì)單表的操作貌似還可以接受，但是如果實(shí)施在整庫遷移的時(shí)候呢？我曾利用那些命令編寫一個(gè)shell腳本進(jìn)行整庫處理，結(jié)果發(fā)現(xiàn)并發(fā)到8個(gè)任務(wù)的時(shí)候，總是會(huì)出現(xiàn)錯(cuò)誤，不知道為什么

HPL之所以快是因?yàn)?他把data在memory排好了table格式后直接寫入DB，所以你要注意你系統(tǒng)總的memory用量，如果memory不夠，甚至用光了swap，那就......

作者: koolkite 時(shí)間: 2009-05-31 10:52
標(biāo)題: 回復(fù) #18 prefect 的帖子
后來我修改了腳本，是通過逐表遷移的方式去操作，結(jié)果發(fā)現(xiàn)時(shí)間上耗費(fèi)挺多的，效率不是很好，各位有什么好的建議

作者: 8213452 時(shí)間: 2009-05-31 10:56
機(jī)器配置8*2198MHZ power5 ,內(nèi)存32G.
在導(dǎo)入大表(記錄數(shù)1億左右) 時(shí)會(huì)無響應(yīng).等了2天還是沒有反應(yīng).

該問題一直沒辦法解決,現(xiàn)在想嘗試使用其它方式,方法如下:
將onpladm的導(dǎo)入模式由express改為deluxe模式。
該方式是否可行？如果可行的話如何修改？

導(dǎo)入模式修改操作在x-windows下操作似乎很容易。但在命令行下如何實(shí)現(xiàn)，有知道的朋友請(qǐng)告知一下。由于x終端服務(wù)無法啟動(dòng)，所以只能使用命令行方式。
另外，job在onpload:session中定義，其中runmode字段是定義導(dǎo)入模式的，之前嘗試update該字段后導(dǎo)入未成功�？刹豢梢赃@樣修改？

作者: 8213452 時(shí)間: 2009-05-31 10:58
標(biāo)題: 回復(fù) #19 koolkite 的帖子
可以并行幾個(gè)任務(wù)，但是任務(wù)太多的話會(huì)比較占資源。一次運(yùn)行3個(gè)應(yīng)該沒問題。

作者: 8213452 時(shí)間: 2009-05-31 11:00
問題在哪？
為什么會(huì)沒有響應(yīng)，到底是在執(zhí)行哪一步時(shí)沒有響應(yīng)？
還是確實(shí)需要那么長時(shí)間？
很疑惑啊！
但工作就是工作，先把事情弄完再研究吧

作者: 8213452 時(shí)間: 2009-06-01 09:37
將runmode字段update 為4225便可將導(dǎo)入模式設(shè)置為deluxe without replication.
使用此模式導(dǎo)入時(shí)僅會(huì)設(shè)置constraint,而不會(huì)disable index.導(dǎo)入速度相對(duì)要慢一點(diǎn),但可以接受.

當(dāng)使用express模式導(dǎo)大表無響應(yīng)時(shí)可修改導(dǎo)入模式重新導(dǎo)入.

歡迎光臨 Chinaunix (http://www.72891.cn/)

<abbr id="17ank"></abbr>