计算机安全服务体系中,安全服务不包括

计算机安全服务体系中，安全服务不包括数据来源的合法性服务。计算机安全服务包括：

认证服务：当某个实体（如人或事物）声称具有一个特定的身份时，认证服务将提供某种方法来证实这一声明是正确的。口令是提供认证服务的一种常用方法。

访问控制服务：防止对任何资源（如计算资源、通信资源或信息资源）进行未经授权的使用。举例来说，防止非法用户进入系统及合法用户对系统资源的非法使用，这就是访问控制的基本任务。

机密性服务：保护信息不泄露给那些没有权限掌握这一信息的实体。加密是提供机密性服务的一种常用方法。

数据完整性服务：防止数据在存储或传输过程中被非法更改或删除。

非否认服务：防止发送方或接收方事后否认消息的发送或接收。数字签名是提供非否认服务的一种常用方法。

*** 作系统加固服务：进行安全加固的 *** 作系统包括 Windows、Linux、AIX、HP-Unix、Solaris。 *** 作系统的加固内容一般包括账号管理和认证授权、协议安全配置、服务和共享配置等。

数据库安全加固服务：进行安全加固的数据库系统包括 Oracle、SQL Server、DB2。一般包括账号管理和认证授权、通信协议安全管理、日志安全配置和审计。

Oracle的安全措施主要有三个方面，一是用户标识和鉴定；二是授权和检查机制；三是审计技术（是否使用审计技术可由用户灵活选择）；除此之外，Oracle还允许用户通过触发器灵活定义自己的安全性措施。

一、用户标识和鉴定

在Oracle中，最外层的安全性措施是让用户标识自己的名字，然后由系统进行核实。Oracle允许用户重复标识三次，如果三次未通过，系统自动退出。

二、授权与检查机制

Oracle的权限包括系统权限和数据库对象的权限两类，采用非集中的授权机制，即DBA负责授予与回收系统权限，每个用户授予与回收自己创建的数据库对象的权限。

Oracle允许重复授权，即可将某一权限多次授予同一用户，系统不会出错。Oracle也允许无效回收，即用户没有某种权限，但回收此权限的 *** 作仍算成功。

1. 系统权限

Oracle提供了80多种系统权限，如创建会话、创建表、创建视图、创建用户等。DBA在创建一个用户时需要将其中的一些权限授予该用户。

Oracle支持角色的概念。所谓角色就是一组系统权限的集合，目的在于简化权限管理。Oracle除允许DBA定义角色外，还提供了预定义的角色，如CONNECT，RESOURCE和DBA。

具有CONNECT角色的用户可以登录数据库，执行数据查询和 *** 纵。即可以执行ALTER TABLE，CREATE VIEW，CREATE INDEX，DROP TABLE，DROP VIEW，DROP INDEX，GRANT，REVOKE，INSERT，SELECT，UPDATE，DELETE，AUDIT，NOAUDIT等 *** 作。

RESOURCE角色可以创建表，即执行CREATE TABLE *** 作。创建表的用户将拥有对该表的所有权限。

DBA角色可以执行某些授权命令，创建表，对任何表的数据进行 *** 纵。它涵盖了前两种角色，此外还可以执行一些管理 *** 作，DBA角色拥有最高级别的权限。

例如DBA建立一用户U1后，欲将ALTER TABLE，CREATE VIEW，CREATE INDEX，DROP TABLE，DROP VIEW，DROP INDEX，GRANT，REVOKE，INSERT，SELECT，UPDATE，DELETE，AUDIT，NOAUDIT等系统权限授予U1，则可以只简单地将CONNECT角色授予U1即可：

GRANT CONNECT TO U1；

这样就可以省略十几条GRANT语句。

2. 数据库对象的权限

在Oracle中，可以授权的数据库对象包括基本表、视图、序列、同义词、存储过程、函数等，其中最重要的是基本表。

对于基本表Oracle支持三个级别的安全性：表级、行级和列级。

（1）表级安全性

表的创建者或者DBA可以把表级权限授予其他用户，表级权限包括：

ALTER：修改表定义

DELETE：删除表记录

INDEX：在表上建索引

INSERT：向表中插入数据记录

SELECT：查找表中记录

UPDATE：修改表中的数据

ALL：上述所有权限

表级授权使用GRANT和REVOKE语句。

(2）行级安全性

Oracle行级安全性由视图实现。用视图定义表的水平子集，限定用户在视图上的 *** 作，就为表的行级提供了保护。视图上的授权与回收与表级完全相同。

例如，只允许用户U2查看Student表中信息系学生的数据，则首先创建信息系学生的视图S_IS，然后将该视图的SELECT权限授予U2用户。

有客户遇到SQL性能不稳定 突然变差导致系统性能出现严重问题的情况 对于大型的系统来说 SQL性能不稳定 有时突然变差 这是常常遇到的问题 这也是一些DBA的挑战

对于使用Oracle数据库的应用系统 有时会出现运行得好好的SQL 性能突然变差 特别是对于OLTP类型系统执行频繁的核心SQL 如果出现性能问题 通常会影响整个数据库的性能 进而影响整个系统的正常运行 对于个别的SQL 比如较少使用的查询报表之类的SQL 如果出现问题 通常只影响少部分功能模块 而不会影响整个系统

那么应该怎么样保持SQL性能的稳定性？

SQL的性能变差 通常是在SQL语句重新进行了解析 解析时使用了错误的执行计划出现的 下列情况是SQL会重新解析的原因

SQL语句没有使用绑定变量 这样SQL每次执行都要解析

SQL长时间没有执行 被刷出SHARED POOL 再次执行时需要重新解析

在SQL引用的对象（表 视图等）上执行了DDL *** 作 甚至是结构发生了变化 比如建了一个索引

对SQL引用的对象进行了权限更改

重新分析（收集统计信息）了SQL引用的表和索引 或者表和索引统计信息被删除

修改了与性能相关的部分参数

刷新了共享池

当然重启数据库也会使所有SQL全部重新解析

SQL重新解析后 跟以前相比 性能突然变差 通常是下列原因

表和索引的优化统计信息被删除 或者重新收集后统计信息不准确 重新收集统计信息通常是由于收集策略（方法）不正确引起 比如对分区表使用 *** yze命令而不是用dbms_stats包 收集统计信息时采样比例过小等等 Oracle优化器严重依赖于统计信息 如果统计信息有问题 则很容易导致SQL不能使用正确的执行计划

SQL绑定变量窥探(bind peeking) 同时绑定变量对应的列上有直方图 或者绑定变量的值变化范围过大 分区数据分布极不均匀

） 绑定变量的列上有直方图

假如表orders存储所有的订单 state列有 种不同的值 表示未处理 表示处理成功完成 表示处理失败 State列上有一个索引 表中绝大部分数据的state列为 和 占少数 有下面的SQL

select * from orders where state=:b

这里:b 是变量 在大多数情况下这个值为 则应该使用索引 但是如果SQL被重新解析 而第一次执行时应用传给变量b 值为 则不会使用索引 采用全表扫描的方式来访问表 对于绑定变量的SQL 只在第一次执行时才会进行绑定变量窥探 并以此确定执行计划 该SQL后续执行时全部按这个执行计划 这样在后续执行时 b 变量传入的值为 的时候 仍然是第一次执行时产生的执行计划 即使用的是全表扫描 这样会导致性能很差

） 绑定变量的值变化范围过大

同样假如orders表有一列created_date表示一笔订单的下单时间 orders表里面存储了最近 年的数据 有如下的SQL

Select * from orders where created_date >=:b

假如大多数情况下 应用传入的b 变量值为最近几天内的日期值 那么SQL使用的是created_date列上的索引 而如果b 变量值为 个月之前的一个值 那么就会使用全表扫描 与上面描述的直方图引起的问题一样 如果SQL第 次执行时传入的变量值引起的是全表扫描 那么将该SQL后续执行时都使用了全表扫描 从而影响了性能

） 分区数据量不均匀

对于范围和列表分区 可能存在各个分区之间数据量极不均匀的情况下 比如分区表orders按地区area进行了分区 P 分区只有几千行 而P 分区有 万行数据 同时假如有一列product_id 其上有一个本地分区索引 有如下的SQL

select * from orders where area=:b and product_id =:b

这条SQL由于有area条件 因此会使用分区排除 如果第 次执行时应用传给b 变量的值正好落在P 分区上 很可能导致SQL采用全表扫描访问 如前面所描述的 导致SQL后续执行时全部使用了全表扫描

其他原因 比如表做了类似于MOVE *** 作之后 索引不可用 对索引进行了更改 当然这种情况是属于维护不当引起的问题 不在本文讨论的范围

综上所述 SQL语句性能突然变差 主要是因为绑定变量和统计信息的原因 注意这里只讨论了突然变差的情况 而对于由于数据量和业务量的增加性能逐步变差的情况不讨论

为保持SQL性能或者说是执行计划的稳定性 需要从以下几个方面着手

规划好优化统计信息的收集策略 对于Oracle g来说 默认的策略能够满足大部分需求 但是默认的收集策略会过多地收集列上的直方图 由于绑定变量与直方图固有的矛盾 为保持性能稳定 对使用绑定变量的列 不收集列上的直方图 对的确需要收集直方图的列 在SQL中该列上的条件就不要用绑定变量 统计信息收集策略 可以考虑对大部分表 使用系统默认的收集策略 而对于有问题的 可以用DBMS_STATS LOCK_STATS锁定表的统计信息 避免系统自动收集该表的统计信息 然后编写脚本来定制地收集表的统计信息 脚本中类似如下

exec dbms_stats unlock_table_stats…

exec dbms_stats gather_table_stats…

exec dbms_stats lock_table_stats…

修改SQL语句 使用HINT 使SQL语句按HINT指定的执行计划进行执行 这需要修改应用 同时需要逐条SQL语句进行 加上测试和发布 时间较长 成本较高 风险也较大

修改隐含参数 _optim_peek_user_binds 为FALSE 修改这个参数可能会引起性能问题（这里讨论的是稳定性问题）

使用OUTLINE 对于曾经出现过执行计划突然变差的SQL语句 可以使用OUTLINE来加固其执行计划 在 g中DBMS_OUTLN CREATE_OUTLINE可以根据已有的执行正常的SQL游标来创建OUTLINE 如果事先对所有频繁执行的核心SQL使用OUTLINE加固执行计划 将最大可能地避免SQL语句性能突然变差

注 DBMS_OUTLN可以通过$ORACLE_HOME/rdbms/admin/dbmsol sql脚本来安装

使用SQL Profile SQL Profile是Oracle g之后的新功能 此处不再介绍 请参考相应的文档

除此之外 可以调整一些参数避免潜在的问题 比如将 _btree_bitmap_plans 参数设置为FALSE（这个参数请参考互联网上的文章或Oracle文档）

lishixinzhi/Article/program/Oracle/201311/18054

---