高新区政务中心数据库的目前运行状态报告及解决办法.doc

西安高新区政务服务中心行政审批（监察）系统后台Oracle数据库目前的配置、结构及运行的状态分析报告-分析人：汪令琦-根据高新区管委会信息中心的要求，本人通过对oracle数据库的数据字典的查询，对目前高新区政务服务中心行政审批（监察）系统后台Oracle数据库目前的配置、结构及运行的状态做如下的分析： 通过查询分析如下：高新区政务中心数据库即ORCL，始建于2010年4月23日，运行于归档模式，可读可写（正常状态）通过查询分析如下：高新区政务中心行政审批（监察）系统后台oracle数据库的运行计算机的主机名为pc-200911111546，数据库的实例名为orcl,oracle数据库管理系统的版本为10.2.0.1.0通过查询分析如下：安装oracle数据库管理系统版本的方面的详细信息通过查询分析如下：该数据库共有3个控制文件，实属同一目录下不同文件名而已。个人建议：从上面分析可以得知控制的文件是存放在同一个文件系统下的，而oracle数据库的控制文件是数据库中极其重要的文件，该文件是一个较小的二进制文件，它记载了物理数据库的当前状态。每一个控制文件只属于一个数据库，为防止控制文件的损坏或丢失，建议对控制文件进行备份、移动控制文件。解决办法：怎样添加和移动控制文件（1） 关闭数据库：SQLshutdown immediate（2） 移动控制文件：SQLhost copy E:oracleproduct10.2.0oradataorclCONTROL01.CTL F:BackupdatabaseCONTROL01.CTLSQL host copy E:oracleproduct10.2.0oradataorclCONTROL02.CTL F:BackupdatabaseCONTROL02.CTLSQL host copy E:oracleproduct10.2.0oradataorclCONTROL03.CTL F:BackupdatabaseCONTROL03.CTL（3） 启动数据库startup（4） 改变控制文件control_files命令修改SPFILE控制文件的位置：SQLalter system set control_files = F:BackupdatabaseCONTROL01.CTL, F:BackupdatabaseCONTROL02.CTL, F:BackupdatabaseCONTROL03.CTL SCOPE=SPFILE;（5） 查询下控制文件的位置是否已更改由此可知控制文件的路径已经做出更改了。通过查询分析如下：高新区政务服务中心行政审批（监察）系统后台的数据库一共有3组重做日志，每个重做日志组中只有一个成员，每个重做日志的大小为52428800KB，只有一个没有归档，剩下两个都为归档模式。Oracle数据库当前正在操作的重做日志组为第一组（status列为CURRENT）。解释说明status状态的含义：inactive：表示实例恢复已不再需要这组联机重做日志组了。active:表示这组联机日志是活动的但不是当前的组，在实例恢复时需要这组联机重做日志组。如这组重做日志正在归档中。Current:表示这组联机重做日志是当前组，并也隐含该联机重做日志组是活动的。Unused：表示oracle服务器从来没有写过该组联机重做日志组，这是重做日志刚被添加到数据库中的状态。个人建议：通过上面的查询我们可以发现所有的重做日志组中都只有一个成员。为了数据库的安全建议将每个重做日志组的成员（文件）都增加到3个。本人还建议将重做日志的组增加到5个以便易于维护数据库的重做日志。为了提高数据库的运行效率，每个重做日志成员（文件）的大小宜设置为15MB。通过查询分析如下：高新区政务服务中心行政审批（监察）系统后台的oracle数据库的所有重做日志文件都存放在相同目录（E:oracleproduct10.2.0oradataorcl）下。注意：stale:表示该文件中的内容是不完全的。Invalid:表示该文件不可以被访问。Deleted:表示该文件已不再有用了。空白：表示该文件正在使用。个人建议：通过上面的查询可知重做日志文件都存放在同一个文件系统下，若此文件系统损坏，后果将不堪设想。本人建议将重做日志重做到不同的文件系统上，保护数据的安全。大家学过数据库理论的都会知道，oracle数据库有快速提交技术的作用，正是这种优秀的提交技术，使得oracle数据库服务器能够保证所有的已经提交的数据一定会被记录在重做日志文件上。一旦数据库崩溃，oracle服务器就能使用重做日志文件中的这些数据来进行数据库的恢复工作。说白了，引入重做日志文件的目的就是恢复数据库。从上面的查询我们可以发现只有一个日志组，虽然恢复数据库只要一个日志文件就足够了，但是我们要考虑效率。在数据库中日志文件是一个频繁操作的文件，计算机操作的文件越大，系统的效率就越低，因此为了确保系统的效率，日志文件应尽可能的小，但是这样也带来一个问题，就是小文件可能很快的被写满，为了解决这个世纪性的难题，oracle数据库提供了使用多组（group）重做日志。解决办法：1. 查看数据库现有配置由上可以看出这么重要的数据库所有重做日志组中只有一个成员2.查看下数据库的每个重做日志文件存放的位置由上可知所有的重做日志文件都存放在了一张磁盘上，如果这张磁盘坏了想不丢失数据都难了哦。3.下面计划将重做日志文件存放在3个不同的磁盘中，本文档由于在测试环境下，所以假设有3个磁盘，Disk3、Disk6、Disk9,并在每个磁盘上创建利于将来的维护ORCLONLINELOG，用来存放重做日志文件（成员）。下面我要做的时候就是向数据库中增加两个新的重做日志组分别为第4组和第5组，并在每个组中增加3个成员。4.查看下新添加的两个新重做日志组的是否成功由上可知新添加的日志组分别为第4组合第5组，每个组中包含3个成员5.查看下新添加的重做日志文件是否存在了规定的路径下6.从上面查询可知第2组为当前组，所以本人先删除第三组重做日志，因为第三组为inactive：表示实例恢复已不再需要这组联机重做日志组了7，查看下第三组是否删除成功了由上可知，第三组重做日志已经成功的删除成功了8. 在数据库中重新加入他所需的第三组重做日志9. 查看下第三组重做日志是否已经添加成功由上可知第三组重做日志已经成功添加成功了，并有3个成员10.现在删除第一组重做日志11. 在数据库中重新加入他所需的第一组重做日志12. 查看下第一组重做日志是否已经添加成功由上可以发现第一组重做日志、第三组重做日志、第四组重做日志、第五组重做日志都重新进行了重做日志，并且每个组都为3个成员，而且每个成员的大小都为所需的15M13.接下来到了我们攻坚的阶段了（重新配置数据库也应该算改革了吧），细心的人会发现通过上面的查询，我们第二组重做日志组，我没有进行操作，是吧？因为第二组重做日志组为当前组是不能删除的，而我们又必须对它要进行重组日志组，该怎么办呢？很简单，下面我们就进行重组日志组进行切换。通过查询分析如下：高新区政务中心行政审批（监察）系统后台的oracle数据库运行在非存档模式，ARCH后台进程为禁用模式（自动存档禁用）。解决办法：1.关闭数据库2.用加载的方式启动数据库3.将运行模式修改为归档模式4.打开数据库5.查看下运行模式由上可知该数据库已经运行在归档模式了6.通过查询分析如下：高新区政务中心行政审批（监察）系统后台oracle数据库的一共有12个表空间，它们的数据块大小为8KM，都是联机在线状态，除了TEMP之外都受到重做日志的保护，其中TEMP为临时表空间（排序时用），而UNDOTBS1为还原表空间，其它的都为永久的表空间。通过查询分析如下：给出了每个表空间所属的数据文件的文件号、文件名、状态及字节大小。个人建议：通过以上查询分析可以得知，所有的数据文件都存放在了同一个文件系统目录下面，这样就会导致本文件系统的I/O输入输出量过大。本人建议非系统表空间（如user）所对应的数据文件迁移到其它文件系统中。通过查询分析如下：显示结果给出了高新区政务中心的oracle数据库系统中的所有用户和他们创建的日期。-数据库的联机（热）备份-1. 1.首先在磁盘上创建一个目录，并在此目录下在创建两个DISK3