数据库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。