Update时间过慢性能分析

最新推荐文章于 2023-01-24 12:36:22 发布

clfeurmz573210

最新推荐文章于 2023-01-24 12:36:22 发布

阅读量294

点赞数

文章标签：数据库操作系统

问题分析

update语句是oracle软件提供的，因此，在用户进程通过监听器连接到服务器进程的这个过程中不会影响到update语句的任何性能问题。在nomount状态下，操作系统虽然分配给oracle内存，实例已经启动，但此时oracle中仅仅加载了参数文件，只提供给oracle服务器一些基本信息，比如控制文件地址，实例名等，没有任何数据存在。和nomount状态一样，oracle在启动到mount状态下也只不过多装载了控制文件，我们的数据库只有启动到了open状态才装载数据文件的内容，用户才能“真正”接触到这些数据。

当实例已经正常打开到open状态下，我们就要分析这个update语句的执行顺序。Oracle会首先进行语法检查，这里要么出错立即显示报错信息，要么语法书写正确并直接显示执行结果，和update语句执行过慢没有关系。其次oracle会进行语义检查，这里进行update操作一定涉及到表，语义检查就要检查这个表是否存在，oracle服务器就会首先到shared pool中的data dictionary cache中检索是否有该表，如果有，那么再到shared pool中的library cache里查找是否有相同的sql语句被执行过，如果有，那么直接在内存里就可以完成该update语句的执行，如果没有，那么在library cache中生成该条sql语句的执行计划，以便其它相同sql语句再次被访问。如果在内存中没有该表，那么oracle就会去数据库的db file文件里找到该表，然后把它调动到内存的data dictionary cache中，以便该表在内存中直接被使用。从这步我们可以看出，即使在最差的情况下（shared pool中没有要查找的表和相同的sql语句），也就是多了三次i/o操作和生成执行计划的时间，并没有造成太大的时间损耗，这应该也不是问题的主要矛盾。oracle在这条sql语句的执行过程中，进行了语法、语义的检查后，那么就该执行这条sql语句了，被修改数据的前镜像会写入到undo表空间里，这些被修改数据可以作为实例恢复使用。此时脏块也只是在内存中（db buffer cache），在达到了一定条件（触发ckpt进程、四分之一满、表空间离线等）时，dbwn后台进程会把脏块写入到db file中，在这个过程中，内存中会产生相应的重做日志（redo log buffer），记录所改变的操作(如dml操作)，同样的，在达到一定条件（三分之一满、1M、commit、dbwr之前）时，lgwr后台进程会把这些的重做日志顺序写入到redo log file中，这些重做日志信息在实例恢复的时候可以实现前滚。此时Sql语句已经基本执行完毕。

我们可以看到，这个过程中，虽然可能导致update语句执行快慢问题，但都不是主要原因。

那么，我们要对update语句有个大致了解，update属于dml语句，oracle为了保证事务的一致性，oracle会在操作的那行加上一个行级排他锁和一个表级共享锁，以保证在一个用户操作过程中，其它用户不能对该用户当前的会话进行任何操作，此时，如果用户a正在执行此操作，而该用户并没有进行提交操作，事务没有结束，此时用户b也在执行这个操作，那么此时用户b无法对这个会话进行任何操作，直到用户a提交或执行ddl操作完成此次事务为止。否则，用户b将永远处于等待状态。我认为这是出现update语句执行过慢的一个主要原因。