今天看到一个名词，数据库实例用户和实例隔离用户，那么什么是实例隔离用户呢，于是搜索以下，就涉及到了进程。
援引DB2中国上面的回答：
要理解DB2的fenced user, 需要先理解db2的fenced process.
DB2在V95之后从多进程模式改为多线程模式，也就是说绝大部分数据库核心程序都运行在db2sysc这个进程中。这种单进程多线程的架构改善了性能，但是同时增加了运行“不安全代码”带来的风险。因为大家都运行在一个进程里，任何一段不安全的代码出现问题会导致整个DB2引擎崩溃。
因此DB2增加了额外的进程专门来执行这些风险比较高的代码，ps -ef可以看到db2fmp这个进程。那些风险比较高的代码会被运行在db2fmp进程里，db2sysc会和这个进程通信。这样当这些不安全的代码出现问题是只会导致db2fmp崩溃，而db2核心进程不受影响。
fenced user就是db2fmp进程运行时的用户，因为某些用户可能不希望这些代码在具有相对较高权限的用户下运行，所以会指定一个不同于实例用户的fenced user。
这些不安全的代码主要是第三方的代码，比如说用户自己用c实现的store procedure和UDF. 或一些第三方的库文件，比如说federation server的wrapper去访问Oracle数据库时需要用到的Oracle的OCI库。
在fenced进程中运行不安全的代码通过隔离增加了db2核心进程的安全性，但同时也增加了因为进程间通信带来的额外性能开销。在某些情况下DB2允许用户自己决定是把“不安全的代码”运行在fenced process还是db2核心进程里，比如说在create wrapper的时候有一个Fenced的选项，用户可以指定yes或no。（2011-09-21）
在本地虚拟机上用 ps -ef | grep db2查看进程，结果如下图所示：
在图中我们可以看到db2的以下进程：
- db2fmcd
- db2dasrrm
- db2fmd
- db2wdog
- db2sysc
- db2ckpwd
- db2vend
- db2acd
- db2fmp
- db2bp
2..线程模型：
  每一个db2sysc派生出来的线程/进程(db2agent,db2loggr,db2pclnr等)都可以称为EDU(Engine Dispatched Unit)，引擎处理单元。
当db2sysc进程被db2wlog创建后，它自己不再创建新的进程，所有的EDU都以线程方式创建。
查看db2sysc运行的线程：db2pd -edus (interval=3)
2.1实例级edus
实例启动时第一个产生的进程是db2sysc,然后db2sysc会派生一系列的线程来工作。
- db2sysc:系统管理器线程，负责启动/关闭/管理实例的运行。线程由主进程派生，和主进程名字相同。
- db2alarm:复杂处理db2sysc进程里面所有警告事件。
- db2thcln:stack栈清理线程，等待任何edu退出，然后清理堆内存。
- db2licc:许可证管理线程
- db2ipccm:IPC通信管理器。每个数据库分区有一个。复杂本地连接。
- db2tcpcm:TCP通信管理器，TCP/IP连接请求的通信监听器。
- db2resync:同步管理线程，支持使用2阶段提交的应用。
- db2aiothr:异步I/O收集器线程，它收集已经完成的异步I/O请求，一旦收集，完成的I/O请求将会被提交器提取，以备之后处理。
- db2cart:决定哪个日志文件可以被归档并且调用userexit线程来做真正的归档。每个实例都有一个。仅当数据库启用userexit时才运行。
- db2chkau:DB2审计使用，记录日志到审计日志中。审计启用时才有此线程。
- db2fmtlg:当数据库配置了logretain on和userexit off时，在日志路径里预分配日志文件。主进程在正常运行时从一个日志文件切换到另一个日志文件时，无需等待。
- db2glock:全局死锁检测器。协调每个数据库分区db2dlock收集的信息来检查死锁情况。多分区环境中，运行在编目分区中。
2.2 数据库级edus
- db2dlock，本地死锁检测器。每个数据库分区有一个。扫描locklist和查找死锁条件。当检测到死锁，随机回滚其事务
- db2glock，仅在多分区数据库中的编目分区运行，用来协调每个分区db2dlock收集到的信息
- db2evm，事件监视器线程。捕获定义的事件，然后写入时间监视器定义的输出文件中。
- db2hadrp/db2hadrs，HADR主/备服务器线程，控制同步和监控心跳。
- db2lfr，日志文件读线程，每个数据库有单独的线程。用于处理各个日志文件的日志文件阅读器
- db2loggr，用于处理日志文件以处理事务处理和恢复
- db2loggw，用于将日志记录写入日志文件，将日志从日志缓冲区写入磁盘上的日志文件中。
- db2logmgr，用于日志管理器。管理可恢复数据库的日志文件。控制事件管理器线程和备份/恢复线程。
- db2logts，用于跟踪表空间修改时哪些日志文件中有日志记录。此信息记录在数据库目录中的 DB2TSCHG.HIS 文件中。通过启用过滤前滚无用的日志，来加速表空间前滚恢复。
- db2lused，用于更新对象用途
- db2pfchr，用于缓冲池预取程序，在应用读之前，从磁盘读取数据和索引信息到缓冲区。NUM_IOSERVERS决定其数量
- db2pclnr，用于缓冲池页清除程序，将脏页从缓冲区异步写入磁盘中。由NUM_IOCLEANERS决定其数量。
- db2redom，用于重做主进程。在恢复期间，它处理重做日志记录并将日志记录指定给db2redow来进行处理。
- db2redow，用于重做工作程序。在恢复期间，它按照重做主进程的请求来处理重做日志记录。
- db2shred，用于处理日志页中的各个日志记录
- db2stmm，用于自调整内存管理功能，一直连接到数据库，如果数据库处于exclusive模式则inactive
- db2taskd，用于分发后台数据库任务。这些任务由名为 db2taskp 的线程执行。
- db2wlmd，用于自动收集工作负载管理统计信息，数据库启动时此线程启动。
2.3 应用级别edus
应用级别edus也称为工作代理。当监听器线程接受到客户端连接时，它会从空闲代理池中委派一个空闲的代理db2agent。如果没有空闲的代理，则会创建新的db2agent。这个db2agent变成此应用的协调代理，会代表应用执行所有的数据库操作。有4中类型工作代理：
2.3.1协调代理coordinator agent----db2agent
协调代理会代替应用协调工作并用IPC或TCP/IP和其他代理通信。每个客户端应用连接请求都有一个协调代理。除非启用connection concentrator。在多分区环境中，协调代理位于应用连接的分区上。
2.3.2活动的子代理active subagent----db2agntp
在多分区环境中或者分区内并行环境中(启用dbm参数INTRA_PARALLEL)，协调代理会将数据库请求分配到活动的子代理db2agntp。这些子代理完成工作并将结果集返回给协调代理，最后返回给应用。
2.3.3相关子代理associated subagent-----db2agnta
当子代理完成工作时，它就变成空闲的相关子代理。如果空闲的代理数量少于num_poolagents，那么它的名字从db2agntp变为db2agnta,并返回到应用的代理池中，但是它仍然与应用相关。如果需要，可能会被协调代理或活动子代理调用，再次为此应用服务。同时它也可能被其他应用所使用。(当没有空闲的代理或不能创建更多的代理时)
2.3.4无关联代理unassociated agent----db2agent(idle)
没有与之相关的应用的空闲代理。可以被任何客户端练级使用或被协调代理/活动的子代理调用。
其数量由dbm参数NUM_POOLAGENTS决定。db2代理池被所有数据库共享。
2.3.5应用级edus
db2agent ，每个应用都有一个协调代理，除非启用connection concentrator
db2agnsc ,并行恢复代理，在前滚恢复和重启恢复中，并行处理日志中事务。可以节省恢复时间
db2agnti , 独立的协调代理，不许要客户端的实际连接，完成DB2内部工作
db2agntp ,代替协调代理当前正在处理任务的子代理，可以提供内部分区并行处理能力。
db2agnta，曾经被协调代理使用过但仍然与之关联的空闲子代理。
db2agntdp ,数据库合用代理
db2agntgp ,合用网关代理程序