資料庫load
❶ hibernate的load能否直接查詢資料庫，而不是緩存
程序的操作時這樣的：
1.先從資料庫load一個id為固定值的記錄；
2.修改這個記錄
3.update到資料庫
4.從資料庫里再load相同id的記錄，來判斷是否已經更新到資料庫。
上面會出現：第4步判斷已經更新到資料庫，當資料庫繁忙的時候，實際並沒有實際update到資料庫，而再次load的時候是獲取到緩存中的記錄，導致判斷已經更新到資料庫中，而實際在後來查詢資料庫發現這筆記錄並沒有更新
❷ DB2資料庫LOAD時候怎麼輸出日誌到文件
load命令有個參數MESSAGES XXX.MSG，以下語句供參考
sql">LOADFROMxx..;
❸ 怎麼向資料庫LOAD進*.jpg文件
usesjpeg;
procereTfrm_Swatch.bb_AddPicClick(Sender:TObject);
Var
PicName,ExtName:String;
JpegImage:TJpegImage;
BitMap:TBitMap;
begin
ifOpenPictureDialog.Executethen
Begin
tb_Pic.Append;
PicName:=OpenPictureDialog.FileName;
ExtName:=ExtractFileExt(PicName);
ifUpperCase(ExtName)='.BMP'then
begin
BitMap:=TBitMap.Create;
Try
BitMap.LoadFromFile(PicName);
dbi_Pic.Picture.Graphic.Assign(BitMap);//dbi_Pic是TDBImage控制項
tb_Pic.Post;
finally
BitMap.Free;
End;
end;
if(UpperCase(ExtName)='.JPG')or
(UpperCase(ExtName)='.JPEG')then
begin
JpegImage:=TJpegImage.Create;
Try
JpegImage.LoadFromFile(PicName);
dbi_Pic.Picture.Graphic.Assign(JpegImage);
tb_Pic.Post;
finally
JpegImage.Free;
End;
end;
end;
end;
回復人：kxy(2000-07-1310:11:00)得20分
不用管什麼圖像格式，全部當作二進制文件。
顯示的時候，不要用TDBImage(除非你要編輯此圖像)用Image
保存到sql
var
TheStream:TMemoryStream;
begin
....
TheStream.LoadFromFile(...);
...
TBlobFiled(Table1.FieldByname(...)).LoadFromStream(TheStream);
....
end;或者TBlobFiled(Table1.FieldByname(...)).LoadFromFile(TheFile);讀出使用TBlobField(...).SaveToStream;or.SaveToFile;
❹ DataTable的Load方法性能怎麼樣
load方法默認會把資料庫欄位的限制導入進去,非空,唯一值,主鍵
效率只能說一般，建議用while read。
最簡單的是 read -->fill,但是這樣不利於格式的自定義
❺ GreatDB資料庫使用loaddata有哪些關鍵參數
"1.?load-analysis-num
GreatDB用於處理一條?load?data?請求數據包解析的工作線程數。
全局參數。可以動態修改
默認值?=?3。參數值范圍?>=1
注意：
當load?data導入數據的瓶頸在dbscale解析數據包處時，調大該參數可以顯著提高load?data的性能。但當該值大於1時，數據實際導入後端?mysql?的順序將可能與文件中的順序不一致，通常這是可以忽?略的。
2.?max-load-analysis-wait-size
GreatDB?用於處理load?data數據包解析的?analysis節點的處理隊列最大長度。
全局參數。可以動態修改
默認值?=?30。參數值范圍?>=2
注意：
GreatDB對analysis節點進行數據包填充時，總是填充到max-load-analysis-wait-size指定的大小，並且analysis節點在待處理的數據包數量小於該值的一半時會喚醒父線程進行數據包填充。
建議該值使?用默認值或適當調高，如果需要導入的數據量非常的大時。
另外如果該值過大，會導致GreatDB緩存過多的數據包，將會導致GreatDB在load?data過程中對機器內存的消耗過多，極端情況下可能會OOM。
3.?max-load-ready-packets
GreatDB?處理load?data時，每個後端數據包發送?線程緩存的最大待發送數據包的數量。
全局參數。可以動態修改
默認值?=?64。參數值范圍?>=10
注意：
GreatDB往後端發送的LOAD?DATA數據包每個是16M，默認值64即1G。每個後端partition對應一個數據包發送線程。當後端mysql處理過慢時可能導致數據包在數據包發送線程上堆積，但堆積的量達?到max-load-ready-packets時，GreatDB將掛起該load?data任務直到堆積的量小於max-load-ready-?packets。
4.?max-load-once-packet-num
GreatDB?向後端執行一次load的數據包數目。
會話級別參數。可以動態修改
默認值?=?64。參數值范圍?>=10
注意：
對於分片表場景，如果一張表load數據量過大,一次load會導致主從延時巨大。此時可以調整本參數,設置每load一定包數就提交一次。
但是這么設置會有一定風險：
?
就是如果load過程中報錯，那麼之前load的數據會已經進入資料庫，所以此時資料庫會有部分臟數據，並且無法確認臟數據量。
一個數據包的大小取決與認證節點的?max_packet_size?,?默認值為?0?，表示不啟用該功能，整個load只提交一次。
"
❻ GBase 8a資料庫通過LOAD方式載入時，如果出現功能報錯，如何排查
前提參數設置
// 默認值是3，這個是session級別的，無需恢復
gbase> set gcluster_log_level=7;
Query OK, 0 rows affected (Elapsed: 00:00:00.00)
// 默認值是0，建議先show一下原始值，排查完了記得改回去。
gbase> set global gbase_sql_trace_level=15;
Query OK, 0 rows affected (Elapsed: 00:00:00.12)
// 默認值是0，這個是session級別，無需恢復
gbase> set gbase_sql_trace=1;
Query OK, 0 rows affected (Elapsed: 00:00:00.01)
執行語句
gbase> load data infile 『ftp://gbase:[email protected]/t1.txt』 into table testdb.t1;
Query OK, 4 rows affected (Elapsed: 00:00:00.35)
Task 394392 finished, Loaded 4 records, Skipped 0 records
查看日誌
/opt/gbase/gcluster/log/gcluster/express.log
# SQL處於check permission狀態
# 獲得表的鎖
# 如果長時間無法拿到鎖，通過gcadmin showlock 看看對應的表的鎖在哪個節點哪個ID持有
2019-07-03 15:02:41.352 [LOCK][INFO ][S:2108][Q:13221]:acquired WRITE lock: testdb.t1580D5F90-B287-4199-B057-E6FBD44B5BFA, lwp:35693
2019-07-03 15:02:41.352 [LOCK][INFO ][S:2108][Q:13221]:acquired READ lock: testdb.t1, lwp:35693
2019-07-03 15:02:41.353 [LOCK][INFO ][S:2108][Q:13221]:acquired READ lock: testdb.t1.rsync, lwp:35693
# 讀取數據源ftp文件信息
# 檢查資料庫和FTP之間的性能問題，包括網路和FTP伺服器的設置
2019-07-03 15:02:41.354 [LOAD][INFO ][S:2108][Q:13221]:Start cluster load
2019-07-03 15:02:41.358 == Information : Trying 192.168.163.100...
2019-07-03 15:02:41.362 == Information : Connected to 192.168.163.100 (192.168.163.100) port 21 (#0)
2019-07-03 15:02:41.370 <= Recv header : 220 (vsFTPd 3.0.2)
2019-07-03 15:02:41.371 => Send header : USER gbase
2019-07-03 15:02:41.371 <= Recv header : 331 Please specify the password.
2019-07-03 15:02:41.371 => Send header : PASS gbase1234
2019-07-03 15:02:41.419 <= Recv header : 230 Login successful.
2019-07-03 15:02:41.419 => Send header : PWD
2019-07-03 15:02:41.419 <= Recv header : 257 "/home/gbase"
2019-07-03 15:02:41.419 == Information : Entry path is '/home/gbase'
2019-07-03 15:02:41.419 => Send header : TYPE I
2019-07-03 15:02:41.419 == Information : ftp_perform ends with SECONDARY: 0
2019-07-03 15:02:41.420 <= Recv header : 200 Switching to Binary mode.
2019-07-03 15:02:41.420 => Send header : SIZE t1.txt
2019-07-03 15:02:41.420 <= Recv header : 213 8
2019-07-03 15:02:41.420 => Send header : REST 0
2019-07-03 15:02:41.420 <= Recv header : 350 Restart position accepted (0).
2019-07-03 15:02:41.421 == Information : Remembering we are in dir ""
2019-07-03 15:02:41.421 == Information : Connection #0 to host 192.168.163.100 left intact
2019-07-03 15:02:41.422 == Information : Trying 192.168.163.100...
2019-07-03 15:02:41.422 == Information : Connected to 192.168.163.100 (192.168.163.100) port 21 (#0)
2019-07-03 15:02:41.424 <= Recv header : 220 (vsFTPd 3.0.2)
2019-07-03 15:02:41.424 => Send header : USER gbase
2019-07-03 15:02:41.425 <= Recv header : 331 Please specify the password.
2019-07-03 15:02:41.425 => Send header : PASS gbase1234
2019-07-03 15:02:41.465 <= Recv header : 230 Login successful.
2019-07-03 15:02:41.465 => Send header : PWD
2019-07-03 15:02:41.465 <= Recv header : 257 "/home/gbase"
2019-07-03 15:02:41.465 == Information : Entry path is '/home/gbase'
2019-07-03 15:02:41.465 => Send header : TYPE I
2019-07-03 15:02:41.465 == Information : ftp_perform ends with SECONDARY: 0
2019-07-03 15:02:41.465 <= Recv header : 200 Switching to Binary mode.
2019-07-03 15:02:41.465 => Send header : SIZE t1_2.txt
2019-07-03 15:02:41.466 <= Recv header : 213 8
2019-07-03 15:02:41.466 => Send header : REST 0
2019-07-03 15:02:41.466 <= Recv header : 350 Restart position accepted (0).
2019-07-03 15:02:41.466 == Information : Remembering we are in dir ""
2019-07-03 15:02:41.466 == Information : Connection #0 to host 192.168.163.100 left intact
#准備分派任務
2019-07-03 15:02:41.467 [LOAD][INFO ][S:2108][Q:13221]:AddNodeLoadFileNum host[::ffff:192.168.163.101]add num [1].
2019-07-03 15:02:41.474 [LOCK][INFO ][S:2108][Q:13221]:unlocked: testdb.t1
2019-07-03 15:02:41.474 [LOCK][INFO ][S:2108][Q:13221]:acquired WRITE lock: testdb.t16ef6f8a9-87f0-4d6c-8043-899367d02df3, lwp:35693
2019-07-03 15:02:41.475 [LOAD][INFO ][S:2108][Q:13221]:AddNodeLoadFileNum cur node state:[ip:::ffff:192.168.163.100:num:0][ip:::ffff:192.168.163.101:num:1].
# 此時SQL已經在loading狀態，
# 開始下發任務。一般是某個節點性能導致，或者數據非常傾斜。
# a) 可以測試從每個資料庫的數據節點，用ftp直接獲取數據文件的性能
# 比如 curl ftp://XXXXX/XX.csv > 1.txt
# 多跑幾次，看看哪個節點比較慢
# b) 排查機器的內存是否出現SWAP, 操作系統/var/log/messages是否有磁碟報錯
# c) 查看CPUINFO是否有異常降頻
# d) 用top、iotop、nmon等工具觀察一段時間系統資源，是否有資源緊張
#
2019-07-03 15:02:41.476 [SQLDISP][INFO ][S:2108][Q:13221]:Target:::ffff:192.168.163.101, SQL:set scn = 395447.
2019-07-03 15:02:41.521 [SQLDISP][INFO ][S:2108][Q:13221]:Target:::ffff:192.168.163.101, SQL:LOAD DATA INFILE 'ftp://gbase:*********@192.168.163.100/t1.txt#offset=0&length=8&firstblock&ffsize=8,ftp://gbase:*********@192.168.163.100/t1_2.txt#offset=0&length=8&firstblock&ffsize=8' INTO TABLE `testdb`.`t1_n1` DATA_FORMAT 3 FILE_FORMAT UNDEFINED HOST '::ffff:192.168.163.101' CURRENT_TIMESTAMP 1562137361 SCN_NUMBER 395447 GCLUSTER_PORT 5258 INTO SERVER (HOST '::ffff:192.168.163.100, ::ffff:192.168.163.101', PORT '5050', USER 'root', DATABASE 'testdb', TABLE 't1_n1, t1_n2', COMMENT 'table_host 0 1 0 # 1 0 1, scn 395447, group -1').
2019-07-03 15:02:42.004 [LOAD][INFO ][S:2108][Q:13221]:ReceNodeLoadFileNum host[::ffff:192.168.163.100] rece num [0].
2019-07-03 15:02:42.004 [LOAD][INFO ][S:2108][Q:13221]:ReceNodeLoadFileNum host[::ffff:192.168.163.101] rece num [1].
2019-07-03 15:02:42.004 [LOAD][INFO ][S:2108][Q:13221]:ReceNodeLoadFileNum cur node state:[ip:::ffff:192.168.163.100:num:0][ip:::ffff:192.168.163.101:num:0].
2019-07-03 15:02:42.004 [LOAD][INFO ][S:2108][Q:13221]:Task 395447 finished, Loaded 8 records, Skipped 0 records
# 拿到排它鎖，要切換版本了。
2019-07-03 15:02:42.008 [LOCK][INFO ][S:2108][Q:13221]:acquired WRITE lock: testdb.t1.09B5BEEC-1EF7-4FA6-9850-C4217A781E0F, lwp:35693
# 設置SCN
2019-07-03 15:02:42.008 [SQLDISP][INFO ][S:2108][Q:13221]:Target:::ffff:192.168.163.101, SQL:SET SELF SCN = 395447.
2019-07-03 15:02:42.009 [SQLDISP][INFO ][S:2108][Q:13221]:Target:::ffff:192.168.163.100, SQL:SET SELF SCN = 395447.
2019-07-03 15:02:42.009 [SQLDISP][INFO ][S:2108][Q:13221]:Target:::ffff:192.168.163.100, SQL:SET SELF SCN = 395447.
2019-07-03 15:02:42.009 [SQLDISP][INFO ][S:2108][Q:13221]:Target:::ffff:192.168.163.101, SQL:SET SELF SCN = 395447.
# 以指定的SCN來刷新數據
2019-07-03 15:02:42.011 [SQLDISP][INFO ][S:2108][Q:13221]:Target:::ffff:192.168.163.100, SQL:flush commit "testdb"."t1_n1" scn_number 395447.
2019-07-03 15:02:42.011 [SQLDISP][INFO ][S:2108][Q:13221]:Target:::ffff:192.168.163.100, SQL:flush commit "testdb"."t1_n2" scn_number 395447.
2019-07-03 15:02:42.019 [SQLDISP][INFO ][S:2108][Q:13221]:Target:::ffff:192.168.163.101, SQL:flush commit "testdb"."t1_n2" scn_number 395447.
2019-07-03 15:02:42.055 [SQLDISP][INFO ][S:2108][Q:13221]:Target:::ffff:192.168.163.101, SQL:flush commit "testdb"."t1_n1" scn_number 395447.
# 驗證SCN
2019-07-03 15:02:42.060 [SQLDISP][INFO ][S:2108][Q:13221]:Target:::ffff:192.168.163.101, SQL:select scn from information_schema.tables where table_schema = 'testdb' and table_name = 't1_n1'.
2019-07-03 15:02:42.061 [SQLDISP][INFO ][S:2108][Q:13221]:Target:::ffff:192.168.163.100, SQL:select scn from information_schema.tables where table_schema = 'testdb' and table_name = 't1_n1'.
2019-07-03 15:02:42.061 [SQLDISP][INFO ][S:2108][Q:13221]:Target:::ffff:192.168.163.100, SQL:select scn from information_schema.tables where table_schema = 'testdb' and table_name = 't1_n2'.
2019-07-03 15:02:42.061 [SQLDISP][INFO ][S:2108][Q:13221]:Target:::ffff:192.168.163.101, SQL:select scn from information_schema.tables where table_schema = 'testdb' and table_name = 't1_n2'.
2019-07-03 15:02:42.063 [SQLDISP][INFO ][S:2108][Q:13221]:Target:::ffff:192.168.163.101, SQL:set autocommit=1.
2019-07-03 15:02:42.063 [SQLDISP][INFO ][S:2108][Q:13221]:Target:::ffff:192.168.163.100, SQL:set autocommit=1.
2019-07-03 15:02:42.063 [SQLDISP][INFO ][S:2108][Q:13221]:Target:::ffff:192.168.163.100, SQL:set autocommit=1.
2019-07-03 15:02:42.063 [SQLDISP][INFO ][S:2108][Q:13221]:Target:::ffff:192.168.163.101, SQL:set autocommit=1.
# SQL處於commit階段 或者 rollback階段
# 提交commit成功
2019-07-03 15:02:42.067 [COMMIT][INFO ][S:2108][Q:13221]:commit table(testdb.t1) success for scn:395447.
2019-07-03 15:02:42.068 [LOAD][INFO ][S:2108][Q:13221]:successful to cluster load
# 釋放鎖
2019-07-03 15:02:42.068 [LOCK][INFO ][S:2108][Q:13221]:unlocked: testdb
2019-07-03 15:02:42.069 [LOCK][INFO ][S:2108][Q:13221]:unlocked: testdb.t1.09B5BEEC-1EF7-4FA6-9850-C4217A781E0F
2019-07-03 15:02:42.070 [LOCK][INFO ][S:2108][Q:13221]:unlocked: testdb.t1.rsync
2019-07-03 15:02:42.071 [LOCK][INFO ][S:2108][Q:13221]:unlocked: testdb.t1580D5F90-B287-4199-B057-E6FBD44B5BFA
2019-07-03 15:02:42.072 [LOCK][INFO ][S:2108][Q:13221]:unlocked: testdb.t16ef6f8a9-87f0-4d6c-8043-899367d02df3
❼ 資料庫中unload/load語句做什麼用
load 是表導出到文件
unload 文件導入到表
load from /usr/aaa.unl insert into aaa
unload to /usr/aaa.unl select * from aaa
可以用DELIMITER '|' 指定分隔符
❽ Hibernate中get方法和load方法的區別
hibernate中get方法和load方法的根本區別
如果你使用load方法，hibernate認為該id對應的對象（資料庫記錄）在數據
庫中是一定存在的，所以它可以放心的使用，它可以放心的使用代理來延遲載入該對象。在用到對象中的其他屬性數據時才查詢資料庫，但是萬一資料庫中不存在該
記錄，那沒辦法，只能拋異常ObjectNotFoundException，所說的load方法拋異常是指在使用該對象的數據時，資料庫中不存在該數據
時拋異常，而不是在創建這個對象時。由於session中的緩存對於hibernate來說是個相當廉價的資源，所以在load時會先查一下
session緩存看看該id對應的對象是否存在，不存在則創建代理。所以如果你知道該id在資料庫中一定有對應記錄存在就可以使用load方法來實現延
遲載入。
對於get方法，hibernate會確認一下該id對應的數據是否存在，首先在session緩存中查找，然後在二級緩存中查找，還沒有就查資料庫，資料庫中沒有就返回null。
雖然好多書中都這么說：「get()永遠只返回實體類」，但實際上這是不正確的，get方法如果在session緩存中找到了該id對應的對象，如果剛好該
對象前面是被代理過的，如被load方法使用過，或者被其他關聯對象延遲載入過，那麼返回的還是原先的代理對象，而不是實體類對象，如果該代理對象還沒有
載入實體數據（就是id以外的其他屬性數據），那麼它會查詢二級緩存或者資料庫來載入數據，但是返回的還是代理對象，只不過已經載入了實體數據。
前面已經講了，get方法首先查詢session緩存，沒有的話查詢二級緩存，最後查詢資料庫；反而load方法創建時首先查詢session緩存，沒有就創建代理，實際使用數據時才查詢二級緩存和資料庫。
總之對於get和load的根本區別，一句話，hibernate對於load方法認為該數據在資料庫中一定存在，可以放心的使用代理來延遲載入，如果在使用過程中發現了問題，就拋異常；而對於get方法，hibernate一定要獲取到真實的數據，否則返回null。
❾ hibernate的load怎麼用
hibernate中get方法和load方法的根本區別
如果你使用load方法，hibernate認為該id對應的對象（資料庫記錄）在資料庫中是一定存在的，所以它可以放心的使用，它可以放心的使用代理來延遲載入該對象。在用到對象中的其他屬性數據時才查詢資料庫，但是萬一資料庫中不存在該記錄，那沒辦法，只能拋異常ObjectNotFoundException，所說的load方法拋異常是指在使用該對象的數據時，資料庫中不存在該數據時拋異常，而不是在創建這個對象時。由於session中的緩存對於hibernate來說是個相當廉價的資源，所以在load時會先查一下session緩存看看該id對應的對象是否存在，不存在則創建代理。所以如果你知道該id在資料庫中一定有對應記錄存在就可以使用load方法來實現延遲載入。
對於get方法，hibernate會確認一下該id對應的數據是否存在，首先在session緩存中查找，然後在二級緩存中查找，還沒有就查資料庫，資料庫中沒有就返回null。
雖然好多書中都這么說：「get()永遠只返回實體類」，但實際上這是不正確的，get方法如果在session緩存中找到了該id對應的對象，如果剛好該對象前面是被代理過的，如被load方法使用過，或者被其他關聯對象延遲載入過，那麼返回的還是原先的代理對象，而不是實體類對象，如果該代理對象還沒有載入實體數據（就是id以外的其他屬性數據），那麼它會查詢二級緩存或者資料庫來載入數據，但是返回的還是代理對象，只不過已經載入了實體數據。
前面已經講了，get方法首先查詢session緩存，沒有的話查詢二級緩存，最後查詢資料庫；反而load方法創建時首先查詢session緩存，沒有就創建代理，實際使用數據時才查詢二級緩存和資料庫。
總之對於get和load的根本區別，一句話，hibernate對於load方法認為該數據在資料庫中一定存在，可以放心的使用代理來延遲載入，如果在使用過程中發現了問題，就拋異常；而對於get方法，hibernate一定要獲取到真實的數據，否則返回null。