oracle基本管理（4）

审计就是将数据库的指定操作记录下来，以便管理者进行观察。我们可以选择把审计信息记录在数据库表中或操作系统文件中。这由AUDIT_TRAIL初始化参数进行控制的。这个参数有以下几种值：
TRUE或DB：启用审计，并将审计记录写进数据库中。具体是写进了SYS用户中中一个数据字典表AUD$。
OS：启用审计，并将审计结果写进操作系统文件。文件的位置由初始化参数audit_file_dest决定。
FALSE或NONE：禁用审计。
建议DBA把审计信息写进AUD$表中，因为表中的数据我们可以使用SELECT进行各种各样的查询，而操作系统文件，只能使用文本编程器所提供的简单的搜索功能进行查阅。
下面我将此参数设为DB。
sid=42 pid=15> alter system set audit_trail=TRUE scope=spfile;
用语句审计的命令是：AUDIT 语句。
sid=42 pid=15> audit select table;
dba_audit_object视图中，查看审计结果。这个视图是建立在AUD$数据字典表之上的。
ORACLE通常不建议你直接查看数据字典，而最好查看在数据字典上的视图，AUD$表也一样。因为ORACLE为视图专门的有专门的文档说明，而数据字典则没有。
可以通过DBA_AUDIT_TRAIL视图查看审计结果，所有的审计视图，都是以AUD$为基表建立的，这些审计视图中有许多重复的信息。
在语句级的审计中，我们可以进行审计的语句可以查询STMT_AUDIT_OPTION_MAP表。这个表中的NAME列，就是所有可以审计的语句。

所有级别的审级都分为两类，会话审计和访问审计。在语句级别，针对会话审计形式如下“AUDIT 语句BY SESSION”。
语句级的审计默认就是BY SESSION的，因此，BY SESSION可以省略。我们上面看到的，就是会话审计。也就是每个会话中，执行的同一审计操作，只会被记录一次。
但访问审计不同，开启访问审计的命令是：“AUDIT 语句BY ACCESS ”。即使是完全相同的语句，每执行一次，都会被记录一次。
DBA_STMT_AUDIT_OPTS这个视图只显示当前已开启的语句级审计。
审记终止：sid=42 pid=15> noaudit select table;
开启访问型审计audit select table by access;
默认方式下，是即审计成功也审计失败的语句
whenever successful 是只审计成功的操作，whenever not successful ：只审计失败的语句。
只审计失败的SELECT TABLE操作：
sid=42 pid=15> audit select table by access whenever not successful;
审计失败的语句，主要是针对存在的对象，由于权限等方面的原因，执行失败了，这样的语句，才会被审计。
在审计语句中使用BY 用户名来启用审计，这样的审计，是属于BY SESSION审计的另一种形式。审计将只记录和由指定用户发出的语句，并且同一会话针对同一对象的语句，只记录一次。它的使用形式如：
sid=42 pid=15> audit select table by u2 ;
如果将初始化参数AUDIT_TRAIL的值定为：“db,extended”，在记录审计信息时，可以将用户的SQL语句记录下来，下面我们试一下：
sid=49 pid=17> alter system set audit_trail=db,extended scope=spfile;
从DBA_OBJ_AUDIT_OPTS视图中看到当前开启的对象级审计。
audit select on u2.dept1 whenever successful;
可以启用的审计操作有：ALTER、AUDIT、COMMENT、DELETE、GRANT、INDEX、INSERT、LOCK、RENAME、SELECT、UPDATE、REFERENCE、EXECUTE、CREATE、READ、WRITE、FLASHBACK。
对象审计的默认方式是BY ACCESS
noaudit select on u2.dept1 whenever successful;
audit select on u2.dept1 by session whenever successful;

权限审计可以审计利用各种权限进行的操作。一条“AUDIT SELECT ANY TABLE”，这样的命令，即是开启SELECT ANY TABLE权限审计，也是开启SELECT ANY TABLE语句审计。
在DBA_PRIV_AUDIT_OPTS视图中，可以看到已经开启的权限审计。这个视图和DBA_STMT_AUDIT_OPTS视图完全一样，而DBA_STMT_AUDIT_OPTS是显示已开启的语句级审计。
audit select any table;

“AUDIT SESSION”命令，可以启用会话的审计，这可以在审计表中记录会话的登录、注销时间。在会话注销时，还可以在DBA_AUDIT_TRAIL视图中显示出会话总的逻辑读、物理读等资源占用情况。DBA_AUDIT_TRAIL视图中以下几列和会话审计相关：
LOGOFF_TIME ：会话退出登录的时间
LOGOFF_LREAD ：会话的逻辑读
LOGOFF_PREAD ：会话的物理读
LOGOFF_LWRITE ：会话的逻辑写
LOGOFF_DLOCK ：会话检测出来的死锁
SESSION_CPU ：会话所使用的CPU
audit session;
noaudit session;

ALL_DEF_AUDIT_OPTS 缺省审计选项
DBA_STMT_AUDIT_OPTS 语句审计选项
DBA_PRIV_AUDIT_OPTS 权限审计选项
DBA_OBJ_AUDIT_OPTS 方案对象审计选项
DBA_AUDIT_TRAIL 所有审计线索条目
DBA_AUDIT_EXISTS 有关 AUDIT EXISTS/NOT EXISTS 的记录
DBA_AUDIT_OBJECT 有关方案对象的记录
DBA_AUDIT_SESSION 所有连接和断开连接条目
DBA_AUDIT_STATEMENT 语句审计记录

我们可以有两种方式连接数据库，通过网络和不通过网络。如果客户端程序和ORACLE服务器在同一台主机上，那么，客户端和服务器端的连接就可以不通过网络。
在进入SQL*Plus前，设置环境变量ORACLE_SID的值为数据库的SID。我们在创建数据库时，要为数据库指定两个名字，一个是全局数据库名，我们就简称数据库名。
另一个就是数据库SID。数据库SID在数据库创建后是无法改变的。在连接数据库时，ORACLE就是以数据库SID为准的。
因为一台主机上可能有多个数据库，客户端程序必须知道自己所连接数据库的SID是什么，这样才能进一步的连接到指定的数据库上。
远程连接必须有监听程序的协助，当客户程序通过网络请求连接数据库服务器时，必须由监听程序负责接收客户端的连接请求，并为客户端按排和服务器的进一步的连接。

第一步：客户端通过网络向监听程序发送了一个“CONN 用户名/密码@服务名”。
第二步，监听器启动一个专门的服务器进程。并将客户端的连接转给专用服务器进程。
第三步，现在客户端直接的和专用服务器进程连接交互。监听器的任务已经结束了。服务器进程第一步要根据用户提供的用户名、密码，和存放在数据字典中的密码进行核对。
如果密码正确，此时就算客户端和ORACLE真正的建立了连接，这也被称作ORACLE为用户创建了会话。创建会话并没有什么新的动作，只是在服务器进程核对密码后，就算创建了会话。

连接很好理解，指的是客户端和服务器进程间的连接途径。会话指的是一种状态，就是当用户名、密码经核对正确后，服务器进程随时等待客户端向它发送请求、命令。
也就是在密码正确后，服务器进程随时候命，这就是创建了会话。
监听器在这整个过程中，发挥了桥粱的作用。它在主机上随时等待着客户端的连接请求。一旦发现网络上有客户端传来了连接请求，它马上开启一个服务器进程，并让客户端和服务器进程建立连接。
监听器一头连接客户端，一头连接服务器。需要在客户端、服务器端分别进行设置。在服务器端的设置，叫做在监听器上注册服务器。
另外，监听器自身也需要配置。通常注册服务器的配置和监听器自身的配置都放在一个文件中，就是LISTENER.ORA。
而客户端，也要知道自己该把连接信息发送到哪里，客户端的配置信息记录在tnsnames.ora文件中。

监听器启动完毕后，有两种方法在其上注册服务器信息：静态注册和动态注册。
这两种方式中，ORACLE推荐使用动态注册，因为它使用更简单、功能也更强。但是静态注册在有些时候（比如排查网络故障时）也是必不可少的。
LISTENER.ORA默认方式下，它的位置在ORACLE_HOME\network\admin中
文件中其余的内容主要分两大部分，监听器自身的信息和数据库信息。下面我们先说一下监听器自身的配置信息。在“LISTENER = ”等号后的内容就是监听器自身的信息：
其中最前面的LISTENER，就是监听器的名字。如果你有多个监听器，下一个监听器的名字可以是LISTENER1，或者是其他的。第一个监听器ORACLE默认的名字就是LISTENER。
另外一个监听地址：(PROTOCOL = IPC)(KEY = EXTPROC1)，这个其实我们不用管它。它是ORACLE中调用外部C函数时使用的协议。此项目不需更改。
一个监听器中通常只需要这两个地址信息就行。

监听器和数据库可以不在同一主机上，但这样有时会对性能有一定的影响，通常应该将监听器和数据库存在同一主机中。

监听器配置文件Listener.ora中的如下部分：
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(GLOBAL_DBNAME = UPL)
(ORACLE_HOME = F:\oracle\product\10.2.0\db_1)
(SID_NAME = three10g)
)
)
目的是让监听器知道可以通过监听器连接的数据库有哪些。这就叫在监听器上注册数据库。这种注册方法，也叫静态注册。

除了静态注册外，我们还可以动态注册数据库。动态注册数据库，不需要在Listener.ora中添加任何有关数据库的信息，只需要设置一个初始化参数SERVICE_NAMES即可。
客户端连接描述符中的SERVICE_NAME，只要等于初始化参数SERVICE_NAMES的值，客户端即可连接到指定的数据库。
alter system set service_names=up,looking ;
这就是动态注册，数据库中的PMON进程，将把初始化参数的值，传送给监听器。
这样，当客户程序要求连接UP数据库或LOOKING数据库时，监听器根据PMON传送过来的信息，就可以知道UP或LOOKING数据库指的究竞是谁。

GLOBAL_DBNAME对应客户端传递过来的服务名。SID_NAME是最终要连接的数据库SID。
这个参数是必须要有值的，如果你没有为此参数准备值，ORACLE将自动把初化始参数DB_NAME（也就是全局数据库名）的值赋给SERVICE_NAMES。
ORACLE的动态注册是由PMON进程负责的。它根据初始化参数SERVICE_NAMES中的服务名，自动生成LISTENER.ORA中SID_LIST_LISTENER里面的SID_DESC数据库信息。
PMON根据初始化参数SERVICE_NAMES，自动将GLOBAL_DBNAME定为SERVICE_NAMES的值。将SID_NAME定为数据库的SID。但是，PMON默认只会到1521端口处，寻找监听器。
因为，PMON找不到监听器。我们可以在服务器的TNSNAMES.ORA中，添加专门的信息，来告诉PMON监听器到底在哪。注意，不是在客户端的TNSNAME.ORA，而是服务器的TNSNAMES.ORA中添加信息。因为这个信息是让PMON看的，也就是让服务器看的。而不是让客户端程序看的，我添加如下信息：
LSN1421 =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = jb)(PORT = 1421))
)
这里要指定监听器所在的主机和端口号。我的监听器是在JB主机的1421号端口。然后我们还要设置一个初始化参数local_listener，告诉它监听器的地址信息在LSN1421连接描述符中：
sid=49 pid=17> alter system set local_listener=lsn1421;

共享服务器的工作原理
专用服务器进程中，每一个客户连接，都要开启一个专用的服务器进程，来为客户程序完成各种数据库请求。
如果现在连接数据库的客户端比较多，而服务器上的内存等硬件资源已经达到了限制。这时，我们就可以考虑使用共享服务器模式，让一个服务器进程，能为多个客户程序提供服务。
共享服务器模式的工作方式如下：
步1：用户进程连接到监听器。
步2：在监听器的安排下，用户进程连接到调度程序。在用户进程后续的连接时间中，将一直和此调度程序连接。此处假设用户进程被监听器分配到了调度程序D001上。
步3：调度程序将用户进程要求执行的命令放进SGA中的请求队列。
步4：服务器进程从请求队列取出待执行的请求。这就好像机场、车站外的的士载客点一样。多个共享服务器进程就像排在载客点的多辆出租车。
请求队列就是排好队的乘客。乘客和某一辆出租车没有固定的对应关系，这次排队时，是A出租车载的他。下一次排队时，有可能是B出租车载他。
而专用服务器模式，其实就相当于为每个用户进程安排一辆专车。
步5：服务器进程将执行命令的结果放入D001调度程序的响应队列。每个调度程序，在SGA中都有一个响应队列。
但所有的调度程序共用一个请求队列。也就是说，所有的请求服务器执行的命令，都被放进一个共公的命令队列，就是请求队列。
服务器进程从请求队列中取出请求，执行完毕后，将结果放在每个调度程序自己的响应队列。在这里，命令的执行结果被放进了D001的响应队列中。
此步完成后，服务器进程马上可以再到请求队列中取出一个请求，为其他的用户进程完成命令。我们称这个为服务器进程马上被释放。
步6：D001调度程序到它自己的响应队列中把结果取出。
步7：调度程序将结果返回给用户进程。

配置共享服务器，第一步就是配置调度程序的个数。有关调度程序的初始化参数有两个：
DISPATCHERS ：初始开启的调度程序数量。参数类型：动态。
MAX_DISPATCHERS ：最多可以开启的调度程序数量。参数类型：动态。
除调度程序外，共享服务器模式所使用的服务器进程和专用服务器下的并不一样。我们要使用专门的参数，在初始时启动一定数量的共享服务器进程。设置共享服务器进程数量也有两个参数：
SHARED_SERVERS ：初始启动的共享服务器进程数。参数类型：动态。
MAX_SHARED_SERVERS ：最多可以启动的共享服务器进程数。参数类型：动态。
共享服务器模式的配置，必须要配置的参数是DISPATCHERS和SHARED_SERVERS。
alter system set dispatchers="(protocol=tcp)(dispatchers=5)";
也可以指定调度程序的地址调度程序的主机名和端口：
DISPATCHERS="(ADDRESS=(PROTOCOL=tcp)(HOST=JB)(PORT=1421)) (DISPATCHERS=5)"
alter system set shared_servers=3;
配置TNSNAMES.ORA文件,所有的配置信息都和前面专用服务器模式中的一样，只将SERVER 的值由过去的DEDICATED（专用），改为SHARED（共享）就行了。

注意，在TNSNAMES.ORA文件中，共享服务器模式的连接描述符可以和专用服务器模式的连接描述符混合在一起。
在同一时刻，ORACLE即可以有共享服务器模式的会话，也可以有专用服务器模式的会话。实事上，既使在共享服务器模式中，也离不开专用服务器类型的连接。
因为一些管理性操作，如打开与关闭数据库，只能在专用服务器模式的连接中才能完成。


此会话就是以共享服务器方式连接的数据库。怎么证明此点呢？显示一下当前会话的SID。注意是会话SID，Session ID，会话编号。
select sid from v$mystat where rownum=1;
select server,sid from v$session;
V$SESSION是专门记录会话信息的视图。SID列是会话编号，SERVER列就是会话的连接模式。如果值为DEDICATED，会话就是专用服务器模式。而如果值为NONE，就是共享服务器模式。

数据库的管理性操作，如打开、关闭数据库，必须在专用服务器模式的连接中才能完成，下面我用SYS用户，以共享服务器模式连接数据库，然后执行关闭数据库的操作：
sid=41 pid=23> conn sys/abcde@sh1 as sysdba
已连接。
sid=41 pid=17> shutdown immediate;
ORA-00106: 无法在连接到调度程序时启动/关闭数据库
共享服务器模式下，无法执行关闭数据库的操作。

MAX_DISPATCHERS指定了最大可以启用的调度程序数量。在数据库运行过程中，如果发现调度程序过高，可以通过设置DISPATCHERS的值，来启用更多的调度程序。
假如来来启用了200个调度程序，想再多启用30个调度程序，使用如下命令即可：
alter system set dispatchers="(protocol=tcp)(dispatchers=230)";
不过，我们所启用的调度程序总数不能超过MAX_DISPATCHERS的限制。
如果调度程序多数比较空闲，也可以通过减少DISPATCHERS参数的值，减少一些调度程序。我们可以通过V$DISPATCHER来观察调度程序的负载情况，此视图重要的列意义如下：
NAME ：调度程序名。通常是D000、D001、D002，等等。
NETWORK ：调度程序的地址、端口号。
PADDR ：调度程序在操作系统中的进程地十。
STATUS ：调度程序状态。如果为WAIT，则表示调度程序正处于空闲状态。
ACCEPT ：此调度程序是否可以接受新的连接。
MESSAGES ：调度程序所处理信息的条数
BYTES ：调度程序所处理信息的字节数
BREAKS
OWNED ：属于此调度程序的虚拟线路数
CREATED ：此调度程序创建的虚拟线路数
IDLE ：调度程序总的空闲时间，单位是百分之一秒。
BUSY ：调度程序总的工作时间，单位是百分之一秒。
我们可以主要通过STATUS列来判断调度程序是否够用。每时每刻最好都有状态为WAIT的空闲调度程序。另外，查看IDLE和BUSY的比率也很重要。
如果如果所有调度程序都不是空闲状态，且BUSY列的值远远大于IDLE列的值。这就证明每个调度程序都处在繁忙中。那么，再有客户程序发出命令、请求，这必然造成等待。
此时，如果服务器上内存还有空余，可以再开启一些调度程序。

MAX_SHARED_SERVERS指定最大的共享服务器数量。共享服务器的数量完全由系统在MAX_SHARED_SERVERS范围内自动控制。
例如SHARED_SERVERS的值为50，而MAX_SHARED_SERVERS日的值为150。哪么，SHARED_SERVERS所规定的50个共享服务器进程在初始时就被启动。
在系统繁忙时，ORACLE可以启动更多的共享服务器进程，比如说在最繁忙的时刻共启动了90个共享服务器进程。当系统不繁忙时，空闲的共享服务器进程会被回收，系统最终还是保持50个启动的共享服务器进程。
需要注意的是，ORACLE并不会自动启动调度程序。
如果你初始启动了200个调度程序，现在这200个调度程序都已经非常繁忙了，ORACLE也不会自动启动更多的调度程序，必须DBA使用alter system set dispatchers……语句手动的启动更多的调度程序。
我们可以通过v$shared_server和v$shared_server_monitor观察共享服务器的运行。下面先看一下v$shared_server视图：
它的大部分列的意义和v$dispatcher中的列差不多：

初始化参数：SHARED_SERVER_SESSIONS
此参数的意义非常简单，设置以共享服务器模式开启的会话的最大数量。
在v$shared_server_monitor视图有一个MAXIMUM_SESSIONS列，显示在实例启动以来，以共享服务器模式连接的会话的最大数量，此数值是一个峰值，不是累计值。
如果此最大会话数的峰值接近或等于初始化参数SHARED_SERVER_SESSIONS的值。我们就要考虑增大SHARED_SERVER_SESSIONS的值了。
注意SHARED_SERVER_SESSIONS参数在9i中是静态的，修改后要想生效必须重启数据库。在10g中，它已经是一个动态参数了。

这个线路是虚拟的，只有当用户发送请求后才真正的存在，因此它被称为虚拟线路。而CIRCUITS参数，就是设置这样的虚拟线路的总条数。我们可以通过V$CIRCUIT视图，看到当前的虚拟线路：
select DISPATCHER, server,saddr,bytes from v$circuit;
DISPATCH列是调度程序的地址，SERVER是共享服务器进程的地址，此列中值都为0，说明当前现在并没有共享服务器进程为这条线路中的请求服务。
这也说明当前并没有用户请求在这条线路上传输。BYTES是通过这条虚拟线路传输的总的字节数。每个共享服务器模式的会话连接后，都会有这样一个虚拟线路，SADDR列就是线路对应会话的地址。
在V$session视图中，保存有每个会话的地址和会话编号，我们可以两个视图关联起来，以获得每个虚拟线路对应的会话编号：
sid=49 pid=17> select DISPATCHER, a.server, sid,bytes from v$circuit a, v$session b where a.saddr=b.saddr;
在v$shared_server_monitor视图中，有一个MAXIMUM_CONNECTIONS列，记录了自实例启动以来虚拟线路的峰值。如果此峰值接近或等于CIRCUITS参数的值，那么就要考虑提高CIRCUITS的值了。
此参数在10g中是动态的，在9i中它也是静态的。

在专用服务器模式中，PGA主要的内容有堆栈空间、用户会话数据和游标状态。这其中用户会话数据用于存储用户进程的一些状态信息，比如用户进程的语言环境，是使用单字节还是多字节等等。
游标状态是用户进程要求执行的SQL语句的信息。这两部分合起来又叫UGA。
在专用服务器模式下，UGA的数据都在PGA中，只有一个专用的服务器进程可以查看到。
而在共享服务器模式下，为了便于多个服务器进程为某一用户提供服务，UGA的数据必须对所有的共享服务器进程可见，因此，UGA被挪进了SGA中，具体是挪进了SGA的共享池中。
而堆栈空间是不需被多个服务器进程所共享的。因为堆栈空间只保存某一次用户调用执行期间的本地数据，比如说一个存储过程中有一个变量A，这个变量A就是在堆栈空间中的。
变量不是需要被多个服务器进程共享的，因为每次执行此过程时，变量A的值都有可能不一样。堆栈空间中都是这些不需要共享的信息。
因此在共享服务器模式下，PGA中只存储堆栈空间。其他的有关用户进程的信息，都被挪进了SGA中的共享池，以便多个服务器进程共享。

大池是SGA的一个可选部分。你可以不配置大池。但是如果使用共享服务器模式，最好要配置大池。
因为在共享服务器模式中，UGA被挪进了共享池中。这加大了共享池的压力，而如果配置的有大池的话，UGA就会被转移到大池中，这可以有效的减少共享池的负担。
因此，在共享服务器模式下，虽然大池仍是可选的，但是建议一定要配置大池。

总的来说，在专用服务器下，ORACLE的整体性能更高。但是，如果你的内存、CPU资源有限，连接客户端又比较多，最重要的是每个客户在连接后只完成很少量的动作，那么你就可以考虑共享服务器了。
如果每个客户连接都要完成很多、很繁重的任务，是不适合共享服务器的。
共享服务器在实际的应用中，使用的并不是太多。因为一条用户请求在共享服务器模式下，相比专用服务器，要经过更多的步骤才可以处理完毕，这使它的总体性能要比专用服务器差。
现在有许多很好的中间件，中间件处理数据库和应用程序中件。应用程序的要求，先被发送到中间件，由中间件再传给数据库。
而现在的中间件中，都有一个连接池的概念，而连接池实现了和共享服务器中比较相似的功能。使用连接池+专用服务器，总体性能要比共享服务器高。