❶ 数据库事务隔离级别 一般用哪个
术式之后皆为逻辑，一切皆为需求和实现。希望此文能从需求、现状和解决方式的角度帮大家理解隔离级别。
隔离级别的产生
在串型执行的条件下，数据修改的顺序是固定的、可预期的结果，但是并发执行的情况下，数据的修改是不可预期的，也不固定，为了实现数据修改在并发执行的情况下得到一个固定、可预期的结果，由此产生了隔离级别。
所以隔离级别的作用是用来平衡数据库并发访问与数据一致性的方法。
事务的4种隔离级别
READ UNCOMMITTED 未提交读，可以读取未提交的数据。READ COMMITTED 已提交读，对于锁定读(select with for update 或者 for share)、update 和 delete 语句， InnoDB 仅锁定索引记录，而不锁定它们之间的间隙，因此允许在锁定的记录旁边自由插入新记录。 Gap locking 仅用于外键约束检查和重复键检查。REPEATABLE READ 可重复读，事务中的一致性读取读取的是事务第一次读取所建立的快照。SERIALIZABLE 序列化
在了解了 4 种隔离级别的需求后，在采用锁控制隔离级别的基础上，我们需要了解加锁的对象(数据本身&间隙)，以及了解整个数据范围的全集组成。
数据范围全集组成
SQL 语句根据条件判断不需要扫描的数据范围（不加锁）；
SQL 语句根据条件扫描到的可能需要加锁的数据范围；
以单个数据范围为例，数据范围全集包含：（数据范围不一定是连续的值，也可能是间隔的值组成）
1. 数据已经填充了整个数据范围：（被完全填充的数据范围，不存在数据间隙）
整形，对值具有唯一约束条件的数据范围 1～5 ，
已有数据1、2、3、4、5，此时数据范围已被完全填充；
整形，对值具有唯一约束条件的数据范围 1 和 5 ，
已有数据1、5，此时数据范围已被完全填充；
整形的数据范围 1～5 ，
已有数据 1、2、3、4、5，但是因为没有唯一约束，
所以数据范围可以继续被 1～5 的数据重复填充；
整形，具有唯一约束条件的数据范围 1～5 ，
已有数据 2，5，此时数据范围未被完全填充，还可以填充 1、3、4 ；
整形的数据范围 1～5 ，数据范围内当前没有任何数据。
更新丢失：当多个事务选择了同一行，然后基于最初选定的值更新该行时，
由于每个事物不知道其他事务的存在，最后的更新就会覆盖其他事务所做的更新；
脏读： 一个事务正在对一条记录做修改，这个事务完成并提交前，这条记录就处于不一致状态。
这时，另外一个事务也来读取同一条记录，如果不加控制，
第二个事务读取了这些“脏”数据，并据此做了进一步的处理，就会产生提交的数据依赖关系。
这种现象就叫“脏读”。
不可重复读：一个事务在读取某些数据后的某个时间，再次读取以前读过的数据，
却发现其读出的数据已经发生了改变，或者某些记录已经被删除了。
这种现象就叫“不可重复读”。
幻读：一个事务按相同的查询条件重新读取以前检索过的数据，
却发现其他事务插入了满足其查询条件的新数据，这种现象称为“幻读”。
可以简单的认为满足条件的数据量变化了。
Record Locks
索引记录锁，索引记录锁始终锁定索引记录，即使表中未定义索引，
这种情况下，InnoDB 创建一个隐藏的聚簇索引，并使用该索引进行记录锁定。
Gap Locks
间隙锁是索引记录之间的间隙上的锁，或者对第一条记录之前或者最后一条记录之后的锁。
间隙锁是性能和并发之间权衡的一部分。
对于无间隙的数据范围不需要间隙锁，因为没有间隙。
Next-Key Locks
索引记录上的记录锁和索引记录之前的 gap lock 的组合。
假设索引包含 10、11、13 和 20。
可能的next-key locks包括以下间隔，其中圆括号表示不包含间隔端点，方括号表示包含端点：
(负无穷大, 10] (10, 11] (11, 13] (13, 20] (20, 正无穷大) 对于最后一个间隔，next-key将会锁定索引中最大值的上方，
2. 数据填充了部分数据范围：（未被完全填充的数据范围，是存在数据间隙）
3. 数据范围内没有任何数据（存在间隙）
如下：
在了解了数据全集的组成后，我们再来看看事务并发时，会带来的问题。
无控制的并发所带来的问题
并发事务如果不加以控制的话会带来一些问题，主要包括以下几种情况。
1. 范围内已有数据更改导致的：
2. 范围内数据量发生了变化导致：
因为无控制的并发会带来一系列的问题，这些问题会导致无法满足我们所需要的结果。因此我们需要控制并发，以实现我们所期望的结果(隔离级别)。
MySQL 隔离级别的实现
InnoDB 通过加锁的策略来支持这些隔离级别。
行锁包含：
左右滑动进行查看
"上确界"伪记录的值高于索引中任何实际值。
上确界不是一个真正的索引记录，因此，实际上，这个 next-key 只锁定最大索引值之后的间隙。
基于此，当获取的数据范围中，数据已填充了所有的数据范围，那么此时是不存在间隙的，也就不需要 gap lock。
对于数据范围内存在间隙的，需要根据隔离级别确认是否对间隙加锁。
默认的 REPEATABLE READ 隔离级别，为了保证可重复读，除了对数据本身加锁以外，还需要对数据间隙加锁。
READ COMMITTED 已提交读，不匹配行的记录锁在 MySQL 评估了 where 条件后释放。
对于 update 语句，InnoDB 执行 "semi-consistent" 读取，这样它会将最新提交的版本返回到 MySQL，
以便 MySQL 可以确定该行是否与 update 的 where 条件相匹配。
总结&延展：
唯一索引存在唯一约束，所以变更后的数据若违反了唯一约束的原则，则会失败。
当 where 条件使用二级索引筛选数据时，会对二级索引命中的条目和对应的聚簇索引都加锁；所以其他事务变更命中加锁的聚簇索引时，都会等待锁。
行锁的增加是一行一行增加的，所以可能导致并发情况下死锁的发生。
例如，
在 session A 对符合条件的某聚簇索引加锁时，可能 session B 已持有该聚簇索引的 Record Locks，而 session B 正在等待 session A 已持有的某聚簇索引的 Record Locks。
session A 和 session B 是通过两个不相干的二级索引定位到的聚簇索引。
session A 通过索引 idA，session B通过索引 idB 。
当 where 条件获取的数据无间隙时，无论隔离级别为 rc 或 rr，都不会存在间隙锁。
比如通过唯一索引获取到了已完全填充的数据范围，此时不需要间隙锁。
间隙锁的目的在于阻止数据插入间隙，所以无论是通过 insert 或 update 变更导致的间隙内数据的存在，都会被阻止。
rc 隔离级别模式下，查询和索引扫描将禁用 gap locking，此时 gap locking 仅用于外键约束检查和重复键检查（主要是唯一性检查）。
rr 模式下，为了防止幻读，会加上 Gap Locks。
事务中，SQL 开始则加锁，事务结束才释放锁。
就锁类型而言，应该有优化锁，锁升级等，例如rr模式未使用索引查询的情况下，是否可以直接升级为表锁。
就锁的应用场景而言，在回放场景中，如果确定事务可并发，则可以考虑不加锁，加快回放速度。
锁只是并发控制的一种粒度，只是一个很小的部分：
从不同场景下是否需要控制并发，(已知无交集且有序的数据的变更，MySQL 的 MTS 相同前置事务的多事务并发回放)
并发控制的粒度，(锁是一种逻辑粒度，可能还存在物理层和其他逻辑粒度或方式)
相同粒度下的优化，(锁本身存在优化，如IX、IS类型的优化锁)
粒度加载的安全&性能(如获取行锁前，先获取页锁，页锁在执行获取行锁操作后即释放，无论是否获取成功)等多个层次去思考并发这玩意。
❷ SQL Server事务隔离级别和Oracle中的区别
SQL Server事务隔离级别和Oracle中的区别
设置一个事务的隔离级别
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
ET TRANSACTION READ ONLY;
设置增个会话的隔离级别
ALTER SESSION SET ISOLATION_LEVEL SERIALIZABLE;
ALTER SESSION SET ISOLATION_LEVEL READ COMMITTED;
❸ 数据库中姓名的数据格式请回答
REF CURSOR游标:
动态游标，在运行的时候才能确定游标使用的查询。分类：
强类型（限制）REF CURSOR，规定返回类型
弱类型（非限制）REF CURSOR，不规定返回类型，可以获取任何结果集。
TYPE ref_cursor_name IS REF CURSOR [RETURN return_type]
Oracle 的隔离级别
SQL92定义的隔离级别在理论上很完善，但是 Oracle 显然认为在实际实现的时候并不应该完全照搬SQL92的模型。
- Oracle不支持 SQL92 标准中的“读取未提交数据（read uncommitted）”隔离级别，想要脏读都没可能。
- Oracle 支持 SQL92 标准中的“读取已提交数据（read committed）”隔离级别，（这也是Oracle默认的隔离级别）。
- Oracle不支持 SQL92 标准中的“可重现的读取（repeatable read）”隔离级别，要想避免“不可重现的读取（nonrepeatable read）”可以直接使用“序列化（serializable）”隔离级别。
- Oracle 支持 SQL92 标准中的“序列化（serializable）”隔离级别，但是并不真正阻塞事务的执行（这一点在后文还有详述）。
- Oracle 还另外增加了一个非SQL92标准的“只读(read-only)”隔离级别。
oracle startup的时候分为三个步骤：
1. Start an instance.
2. Mount the database.
3. Open the database.
三个步骤中所要做的工作主要如下：
1、start an instance
命令为 startup nomount
在这一步中主要工作有：
Reading the parameter file initsid.ora
Allocating the SGA
Starting the background processes
Opening the ALERT file and the trace files
读参数文件是为了读里面的dbname,各个内存参数的大小，比如sga的大小，以便分配内存，还有控制文件的路径等。在这一步并不打开控制文件，所以如果你要重建控制文件的时候，需要工作在这个状态下。
2、Mount the database.
命令为 startup mount,如果在nomount状态下命令为: alter database mount
在这一步中主要工作有：
Associating a database with a previously started instance
Locating and opening the control files specified in the parameter file
Reading the control files to obtain the names and status of the data files and redo log files
在这一步,主要用到的文件是控制文件.然后读控制文件,得到各个数据文件和联机日志文件的名字和状态(online or offline) ,但是并不去检查各个文件是否存在.所以如果你要修改数据文件的名字和重建联机日志文件等操作,就需要工作在mount状态下.因为下一步要打开各个数据文件和联机日志文件,所以如果数据文件不存在,你就需要在mount状态下,恢复文件,才能使下一步不报错误.
3、Open the database.
命令为 startup,如果在mount状态下命令为: alter database open.
在这一步中主要工作有：
Opening the online data files
Opening the online redo log files
在这一步中,数据库主要的工作是打开第2步中在控制文件中读到的在线的联机日志文件和数据文件.如果数据文件和联机日志文件不存在,oracle就会报错.oracle打开数据文件和日志文件之后,会对数据文件和日志文件进行一致性检查,如果发现不一致,会启动SMON进程进行实例恢复.
另外，在整个过程中密码文件都是必须的，因为要验证操作的用户是否具有适当的权限。这个只是从宏观上来看oracle启动的整个过程。