SQL语句执行过程
------为什么需要使用数据库？一是存储、二是方便检索和处理数据------
以Oracle为例
客户端输入SQL，通过网络到达数据库实例，实例访问数据库。
一个数据库实例会产生很多进程，分为前台进程、后台进程。前台进程是Server Process，后台进程主要包括：DB Writer、LogWriter、PMON、SMON、CheckPoint、归档Log。
前台进程
Server Process是主要处理用户请求、反馈用户结果的进程，当接收到SQL后，先将SQL解析为执行计划，然后再执行，获取数据，返回用户结果。
在这个过程中，是消耗资源的，主要有CPU、IO，那么Oracle为了尽量减少资源消耗，在内存区分配了两块缓存，SharedPool（保存SQL和执行计划）和BufferCache（缓存DBF数据）。所以ServerProcess会先到SharedPool中查找有无对应的SQL和执行计划，若无，再解析，消耗CPU，然后再将解析结果缓存到SharedPool中，接着再到BufferCache中查找是否有数据，若无，则从DBF中读取，消耗PIO，然后将DBF数据缓存到BufferCache中。
这里放张Oracle内存结构图，其中服务器进程就是ServerProcess
SharedPool
SharedPool划分为三部分空间：Free、LibraryCache（缓存SQL和执行计划）、RowCache（缓存数据字典）
前面说到ServerProcess会先到SharedPool中查找是否有对应的SQL和执行计划，其实是到LibraryCache中查找，若没有，则进行硬解析，若找到了，则进行软解析。
将SQL解析为执行计划，分为两步：
1、Check 语法、对象是否存在、是否有权限等（消耗CPU 30%左右资源）
2、从N种方案中，通过消耗资源、执行速度等多维度对比选出最优执行方案（消耗CPU 70%左右资源）
其中，硬解析包括这两个步骤，而软解析只包括第一个步骤，并且无论硬解析、软解析都需要Check，需要频繁访问数据字典，所有RowCache的存在使得软解析异常的节约资源。
硬解析的过程会占用Free中的新空间，然后转移到LibraryCache中，而Free中会留下一些小碎片（Free中有Chain、Chunk的概念），若全部是小碎片，同时又有硬解析大SQL时，没有比较大的Chunk保存该SQL时，会产生ORA-4031错误。
解决ORA-4031的方法：
1、清空SharedPool缓存，alter system flush shared_pool; --治标不治本
2、尽量减少硬解析，统一SQL风格、使用占位符绑定变量达到SQL共享，也可修改cursor_sharing值为force
3、增加SharedPool空间
4、增加保留区空间（保留区是SharedPool为了缓存大SQL专门预设的区域）
BufferCache
BufferCache是高速缓存，其内存组织结构也是Chain，还有Buffer（缓存Block）。
作用主要是：1、缓存DBF的Block，减少PIO；2、构造CR块，从undo中获取未提交的block修改前的数据，构造CR块，供其他进程读取。
BufferCache中存在多种双向链Chain，CBC（CacheBufferChain）按照Buffer地址串起来、LRU 最近最少使用链、LRUW 最近最少被修改的链，全部是脏块，供DBWriter使用。
DBF
DBF是数据文件，相对应的缓存是BufferCache，其构成有段、区、块（Block）
段：可以理解为表头，是区中的一部分
区：物理上连续的块，除去段，其他区的块保存数据，是给段分配空间的最小单位
块：数据库IO的最小单位，存放数据行，一般会有多个行，原则上一行只存在一个块中
后台进程
DB Writer：将ServerProcess缓存到BufferCache中的修改后的数据写入磁盘存储，DBF
LogWriter：将ServerProcess产生的RedoLog写入磁盘存储，Log File
PMON：管理ServerProcess，停止并清除不再使用的进程，比如用户失去链接
SMON：管理SharedPool，整理SQL和执行计划
归档LOG：将磁盘中的RedoLog归档至另外一个地方
结论
可见，前台进程，主要是接收客户指令，和内存交互，并将结果提交至内存，后台进程，则主要将内存中的信息同步至存储。