信息安全，高于一切

    昨天下午检查数据库的碎片情况，用下面的语句：
select 'alter table '||trim(t.owner)||'.'||t.name ||'move;' from tmp_frag t;
把查询出来的结果在sqlplus中执行，然后用下面的语句检查失效的对象：
select c.object_type, c.object_name
  from all_objects c
 where c.status = 'INVALID'
   and c.owner in ('SNS', 'HMDBA','TSPDB','TSPBUSI') ;
--查找无效的索引：
select * from sys.dba_indexes t where t.status !='VALID';
发现有200个失效的索引、主外键，马上用下面的语句取出重建语句：  
--使约束启用语句：
select 'alter table '||t.owner||'.'||t.table_name||' enable constraint  '|| t.index_name ||';'
from sys.dba_indexes t
where t.owner in('SNS','HMDBA','TSPDB','TSPBUSI') and t.status='UNUSABLE';
--重建索引语句：
select 'alter index '||t.table_owner||'.'||t.index_name||' rebuild nologging online;'
from sys.dba_indexes t
where t.owner in('SNS','HMDBA','TSPDB','TSPBUSI') and t.status='UNUSABLE';
把上面的结果放到sqlplus中执行，直到没有失效对象。
   索引和主外键失效后，马上就引起了系统的故障，持续时间超过一个小时。纵观这个故障完全是由于违反信息安全所导致的，首先是在白天违规操作线网数据库，公司整天强调信息安全，三令五申强调严禁在白天操作线网设备，自己作为一个老员工还顶风违规，可见思想是多么的麻痹，安全意识是多么的淡薄，完全把信息安全当作儿戏。其次，这个操作没有任何的方案，完全是临场发挥，没有考虑到问题的严重后果，万幸的是这个数据库不是客服的数据库，数据量比较少，否则一定会引起系统的瘫痪，客服系统几千个表中，随便找一个表都是几百M的数据，那些大日志表都在几个G的数据，一旦索引失效，必将引起全表扫描，系统不瘫痪那才是一件怪事。而且一个大表在线重建索引至少要超过半个小时，还要占用大量的空间，那200个索引10个小时都建不完，那后果是不敢想的。
    因此今天是幸运的，但是这个侥幸的心理是要不得的，下次如果还不按照规则办事，不遵守信息安全，可能就不会有这么幸运了，看来信息安全还是学习的不够深刻，只是学了一点皮毛而已。违反信息安全不但给自己带来麻烦，还会牵连到相关的人员，因为公司违反信息安全是要负连带责任的，要写出故障分析报告、至少项目组内通报批评、按照违规等级进行经济处罚，全项目组进行信息安全学习。这样做的目的只有一个，那就是要求每个人都要严格按照相关的规定办事，严格遵守信息安全和线网操作六戒律。只有这样做才能保证线网的安全，而且信息安全也是保护自己的工具，只有一切按照相关规范来做，才能取得最好的结果，否则随意发挥，那后果是不堪设想的。

附上六戒律见下：

1. 所有涉及网络的修改操作（包括软、硬件）决不允许在白天操作。
2. 对现网设备进行任何操作均要得到用户的签字确认。
3. 对现网设备进行所有的变更操作必须制定详细的操作技术方案（含安全倒回措施），重大变更方案必须通过公司对口部门的审核；变更前必须进行数据备份，完成后必须进行业务测试。
4. 所有的技术方案要细化到命令行，操作人员必须严格按审核后的方案实施，禁止现场随意发挥，擅自进行方案以外的其它操作。
5. 所有软件版本都要来自公司正常渠道，所有非法软件严禁上网运行。
6. 工程实施中，设备加电前必须完成设备的硬件自检，设备割接前必须完成设备的软件自检。

本文出自 “srsunbing” 博客，请务必保留此出处http://srsunbing.blog.51cto.com/3221858/718081