Oracle process/session/cursor/tx/tm的简单学习

Oracle的部署模式

Oracle安装时有专用模式和共享模式的区别

共享模式（Shared mode）：
在共享模式下，会话可以同时读取数据库的数据，多个会话可以并发地进行读取操作。
这意味着多个会话可以共享相同的数据快照，并且彼此之间不会阻塞。

独占模式（Exclusive mode）：在独占模式下，会话可以对数据库进行读取和修改操作。
当会话处于独占模式时，它会获取适当的锁资源，以防止其他会话并发地读取或修改相同的数据。
这种模式在写入和修改数据时非常常见。

需要注意的是，共享模式适用于读取操作，但不适用于写入和修改操作。
如果有写入和修改操作，需要考虑使用独占模式（Exclusive Mode）或其他适合的模式来保证数据的一致性和完整性。

另外，具体使用共享模式的可行性和效果还取决于数据库的配置、硬件资源、数据量、应用程序的设计和代码实现等多个因素。
在实际应用场景中，建议综合考虑这些因素，并进行性能测试和优化，以选择和配置合适的数据库模式

因为一般情况下Oracle数据库都需要实时修改 OLTP, 所以建议都是使用 独占模式 进行安装与部署. 

process

Oracle 的process 包含的内容其实比较多. 

有background 也有 foreground
前台进程（foreground process）和后台进程（background process）。

前台进程是由客户端应用程序启动的与用户交互的进程，
它负责接收和处理来自客户端应用程序的请求，并将这些请求发送到数据库服务器进行处理。
前台进程与用户会话（session）相关联，负责处理用户的查询、事务处理和其他数据库操作。

后台进程则是在数据库启动时由数据库实例自动创建的进程，它们在后台运行以执行各种关键任务.

后台任务主要有DBWR LGWR CKPT 等等进程. 

需要注意 process的数量不全是 客户端连接过来的.一般一个数据库可能有 50-70的非前端用户进程使用. 

session

这里主要讨论专用模式下的session

专用模式下. 一个客户端连接到Oracle数据库. 
数据库会创建一个单独的process 与数据库进行交互. 专用模式下. session 与前台process 基本上是一对一的关系. 

所以独占模式下基于session的临时表就存在于session的存在时间. session失效了 临时表就会历史取消和删除. 
全局临时表是在数据库中定义的一种特殊类型的表，它在创建时会被分配给所有会话，
但其中存储的数据是会话私有的，并且在每个会话结束时自动清空。

其实不管是全局临时表还是实表临时表最好是增加清理和删除机制, 避免占用太多的系统资源. 

所以基于session的全局临时表 如果使用连接池时必须要在事务完成之后进行一次dispose. 将连接返还给连接池. 

会话级别隔离：使用连接池获取数据库连接时，可以通过设置 setSessionInitMode(oracle.jdbc.OracleConnection.SESSION_INIT_NEW) 
来确保每个连接的会话是全新的。这样可以避免不同会话之间共享全局临时表的数据，确保每个会话都有属于自己的临时表数据空间，保证隔离性。

连接回收与关闭：在使用连接池获取连接后，及时释放该连接以便连接池能回收并重新分配给其他会话。
确保在会话结束时关闭连接，以释放相关的资源，包括全局临时表的数据。这样可以确保下一个会话获得的连接不会共享之前会话的全局临时表数据。

适当的临时表设计：在设计全局临时表的时候，应该考虑到不同会话之间的隔离需求。可以通过为每个会话添加唯一的会话标识列，
或者将会话 ID 作为会话的前缀，避免不同会话之间的数据冲突。

cursor

专用模式下 process与session 可以理解为部分一对一的关系

但是一个session并不是只能够执行一个SQL.

一个session 执行SQL时是可以并发进行处理. 他的返回结果是通过 cursor 游标方式进行关联. 
所以可以看到. 正常的awr报告, 每一个session可能有 40-60个cursor.

高并发的情况下, cursor/session 的比率会升高 占用的资源也会升高. 

session与TCP的关系

session 与 前台进程对应. 也跟客户端和数据库之间的TCP有一定的对应关联.

当使用连接池时, 连接池会管理客户端与数据库的 TCP连接, 并且能够保持 min 的最少连接信息

客户端创建对数据库的连接时是一个成本很高的过程. 

不仅有TCP连接的建立,还需要oracle数据库创建process.session 并且分配PGA等等过程. 

所以当如果大量的连接建立时 一般会导致响应速度变慢. 

数据库的连接数与process其实没有特定的关系. 但是如果是专用(仅部署了Oracle数据库,并且是专用模式) 
接数的上涨可能与数据库process的变化量保持正相关.

数据库锁与事件等待

数据库的锁是保证数据库一致性的核心资源.
因为有锁的存在, 冲突的其他方必须有等待.
等待会导致响应时间变慢,吞吐量下降. 
但是是作为一个数据库实现一致性的必备条件 
主要分类有如下: 

Concurrency
User I/O
System I/O
Administrative
Other
Scheduler
Configuration
Cluster
Application
Queueing
Idle
Network
Commit

select a.WAIT_CLASS from v$event_name a group by a.WAIT_CLASS;

Oracle 12c 有 1800 余个等待事件. 
其中 enq 开头的有 720个 比较容易看到的主要有:

enq: TX - allocate ITL entry
enq: TX - contention
enq: TX - index contention
enq: TX - row lock contention
enq: TM - contention

需要注意:
“Enqueue” 是 Oracle 数据库中用于管理并发访问和数据一致性的一种机制。它是一种资源锁，用于控制对共享资源（如表、索引、行等）的并发访问
以确保数据库的数据一致性和完整性。

在 Oracle 数据库中，enqueue 锁分为多种类型，每种类型都对应着不同的资源锁。一些常见的 enqueue 锁类型包括：

TX：行级事务锁，用于控制对表中行的并发修改。
TM：表级锁，用于控制对整个表的并发访问，例如表的结构变更。
TM - contention：表示表级锁的争用，通常发生在多个会话同时对同一表进行 DDL 操作时。
SQ：序列器锁，用于控制对序列器的并发访问，以确保序列号的唯一性。
CI：区间并发锁，用于控制对索引的并发修改，以保证索引的一致性。
RO：只读锁，用于控制对某些资源的只读访问，以确保读取一致性。
当一个会话（进程）需要访问一个资源时，它会在 enqueue 队列中请求相应的锁。如果该资源的锁目前被其他会话持有，
则请求会进入等待状态，直到锁可用为止。当锁可用时，请求会话获得锁，并可以访问相应的资源。

通过监控 enqueue 等待情况，可以帮助识别数据库中的并发冲突和争用问题，以及设计和优化适当的并发控制策略，以提高数据库的性能和稳定性。

锁的简单解释-主要来源自Wetab

1. enq: TX - contention” 是 Oracle 数据库中的一种等待事件，表示等待行级事务锁（TX）的争用。
当多个会话同时试图修改同一行数据时，会发生行级事务锁的争用。

行级事务锁用于控制对表中行的并发修改。当一个会话开始修改某一行数据时，会获取该行的行级事务锁。
如果其他会话同时试图修改相同的行，它们就需要等待行级事务锁的释放，以确保数据一致性和完整性。

当出现 “enq: TX - contention” 等待事件时，意味着有多个会话正在等待获取相同行的行级事务锁。
这可能是因为同时修改相同行的会话数量较多、对事务隔离级别的要求较高或者业务逻辑造成的。

解决 “enq: TX - contention” 等待事件的方法包括：

调整事务隔离级别：使用适当的事务隔离级别可以减少行级事务锁的争用。例如，将隔离级别从 Serializable 降低到 Read Committed。
减少事务的长度和范围：尽量缩短事务的执行时间和涉及的数据范围，以减少行级事务锁的保持时间。
并发控制优化：通过分析和优化表结构、索引设计，以及调整应用程序逻辑，减少同时修改相同行的需求。
考虑使用更高级的锁机制：如果业务需求允许，可以考虑使用更细粒度的锁（如行级锁）或乐观锁，以减少锁的争用和冲突。

总之，处理 “enq: TX - contention” 等待事件需要根据具体情况进行分析和优化，以提高并发性能和减少锁的争用

2. enq: TM - contention” 是 Oracle 数据库中的一种等待事件，表示等待事务管理（Transaction Management）的争用。
当多个会话同时竞争事务管理资源时，会发生事务管理的争用。

事务管理包括分配事务编号、管理数据库日志、维护事务的隔离、并发控制等操作。当多个会话同时请求事务管理资源时，
会出现 “enq: TM - contention” 事件，表示有会话在等待获取或释放事务管理资源。

“enq: TM - contention” 事件的出现可能是因为以下原因：

高并发事务：当有大量的会话并发执行事务操作时，会导致对事务管理资源的竞争。
长时间事务：长时间运行的事务会持有事务管理资源较长时间，导致其他会话等待获取这些资源。
数据库锁竞争：数据库中的锁机制也可能导致事务管理资源的争用，例如行级锁、表级锁等。