OCI 线程安全

Younth_0701

结帖：
OCI的线程安全需要一点额外的处理，简单的讲，OCI的环境句柄不支持同时挂多个服务，多个context 多个 statement 并同时进行 增删改查操作或者其他的DDL操作，其本身是不支持并行的，即便使用了OCI的互斥锁，或者操作系统的互斥锁，其互斥后的操作也是线性的，想实现共享的环境句柄通过加锁可以解决稳定问题，但达不到期望的并行效率效果。
sqlora.dll是很多连接或者中间件的数据库连接配件（以前在delphi/C++builder的数据源配置中很多有用这个的，texcdo中间件我也见过用这个的），这次看到yu老师不知道从哪里搞到的sqlora8的源码，看里头作者的意思是，环境句柄还是使用独占式的，一个线程一个连接，连接过程中独占环境句柄，多个就弄连接池，一堆环境句柄，这个效果是可期的，在session中查到的连接数也是符合预期的。
补充一点：关于线程操作：
使用OCI的线程函数和结构实现多线程，应该是oci最推荐的，比一般的操作系统的多线程多了一些操作步骤，但估计是最稳定的，只是函数太多，想做一个线程，估计得增加不少OCI线程结构变量，各种都有，一一与操作系统对应，我用着不太习惯，比操作系统的略繁琐；
使用三方的线程库 如 pthread 这是跨平台的，也可以；
直接使用贴合操作系统的原生线程API，也可以的。

yulihua49

newkid 发表于 2021-1-14 22:28
按你的说法，把数据取出来拿到数据库外面“计算”一番再写回去，比直接在数据库内部表对表复制还快？你们的 ...

我也只会手画拍照片了，哈哈。

在线程A，是连续读，发送后不管，只消耗一个读的时间。
后边3个计算服务器，96个线程，15个数据库连接，实测这个连接数（DB的线程数）最快。
这就跟paralell不同了，它无法控制线程数，上来就是海量的线程，慢的一塌糊涂。（测试用的update table set  flg=0 where   时间段；   没有复杂的处理，慢的一塌糊涂。）

15个连接是最优的，而那个复杂的计算完全被96线程的并行掩盖掉了。就是说，15个连接在update的同时，96个连接在计算，时间完全是并行的。因此整体时间体现为数据库的处理时间，这个时间是sqlldr的40%。当然sqlldr是从本地文件入的，而且是全部列。它只使用了一个线程，没有并行。
我的另一个流程是A从本地文件读（全部列），后台insert，其它一样。速度也差不多。

yulihua49

newkid 发表于 2021-1-14 22:28
按你的说法，把数据取出来拿到数据库外面“计算”一番再写回去，比直接在数据库内部表对表复制还快？你们的 ...

业务要求此架构，经优化测试，意外发现比直接update快。
分析：
A线程只做select，1000行一包分发到后边线程，发送后不管，循环读。
后边数据包被发送到3台服务器，每台31核共96个线程进行计算，最后通过15个数据库连接进行批量update。实测这样最快。对于数据库而言，加上读线程，一个16个线程，在两个节点上分担的还算均匀。
期间手动执行：update table set flg=0 where 日期； 执行同一个数据集合，没有复杂计算，RAC里只有一个节点工作，结果非常慢。加parelell更慢，两个节点产生无数线程，都不知道他们在干啥，怎么分担的负载。每个测试周期都要执行一次这个指令（把所有数据设置成未处理），最耗时的就是这一步。

yulihua49

newkid 发表于 2021-1-14 22:28
按你的说法，把数据取出来拿到数据库外面“计算”一番再写回去，比直接在数据库内部表对表复制还快？你们的 ...

回的贴又丢了，向帮它提升点人气都不行。我写了很多说明，不知道那句话导致删帖，一点点加，试试看。
业务要求此架构，经优化测试，意外发现比直接update快。分析：
A线程只做select，1000行一包分发到后边线程，发送后不管。
后边3套服务器共96线程计算，最后15个连接数据库，这个数最快。

测试完需要一个命令：
update table set flg=0 where 日期；
在整个测试过程，居然这一步是最耗时的。只用到一个RAC节点，一个线程。
+paralell，产生无数的线程，慢的要命。

yulihua49

yulihua49

yulihua49 发表于 2021-2-1 17:52

A线程只做select，1000行一包分发到后边线程，发送后不管。
后边3套服务器共96线程计算，最后15个连接数据库，这个数最快。

测试完需要一个命令：
update table set flg=0 where 日期；
在整个测试过程，居然这一步是最耗时的。只用到一个RAC节点，一个线程。
+paralell，产生无数的线程，慢的要命。

newkid

Oracle 官方公众号文章：https://mp.weixin.qq.com/s/3G73s9ITpVnTQaT6bb4gww

newkid

并行如果调试得好，效率是很惊人的！

yulihua49

newkid 发表于 2021-2-1 22:35
并行如果调试得好，效率是很惊人的！

当年单位也有DBA高手，弄不出来。
我不知道他们是否看到过你发的那篇文章。

一大堆帖子终于审核通过了，比从火星打来回还慢。

yulihua49

newkid 发表于 2021-2-1 22:35
并行如果调试得好，效率是很惊人的！

至少我回答你一点：
我图上的那个体系，操作起来，比单线程的select........insert,update,sqlldr等等方式快，这应该不用怀疑。这就是OCI的潜力，是存储过程比不了的。

当然这个体系过于复杂，一般人做不来。