客户反映说一个库前几天因为磁盘损坏,导致操作系统宕机。几经折腾终于把盘恢复了,却又发现数据库无法启动了。并且已经使用trace里面的backup controlfile重建了控制文件,但还是无法正常启动。   检查之后

Mysqldump是MySQL数据库逻辑备份的常用工具,在日常的维护工作中经常会用到。这里对这个工具的使用做一个简单的介绍。有以下 3 种方法来调用mysqldump: (1)备份指定的数据库,或者此数据库中某些表。 shell

  一、       MySQL的权限类型简介 MySQL数据库提供了3种不同层次的权限类型。 1) 管理权限。此类权限用来管理数据库服务器,这些权限是全局的,不单独针对特定的数据库。

一客户反映说有一个库的内存始终处于高位,让查看具体原因。登录上去后,查看资源使用情况,果然,内存使用率始终在95%以上。   查看占用内存最高的进程,发现asm_dia0这个进程的内存占用率高达31%。

某客户一个新环境主机solaris 11上的Oracle 11.2.0.4.4的RAC系统,查询dba_segments视图的时候,如果只返回几条数据时是正常的。但是如果查询整个dba_segments视图的时候,就异常缓慢,需要近20分钟才能完成。 最

早上过来发现有一个RAC库的2节点上无法识别到一个数据文件,该表空间无法使用,导致整个应用层出问题。 检查后,发现该文件是昨天一个同事新添加的,添加的命令窗口还在,命令语句也没有问题,但是文件却被创建到

    今天早上接到一个库的内存告警,2节点的内存使用率已经超过90%,1节点也在不断上升中,马上也要达到90%了。          (图1,1节点的内存使用状况)            (图2,2节点的

首先,切换到grid用户,连接到ASM实例: nbasdb1:/grid$id uid=1001(grid) gid=1001(oinstall) nbasdb1:/grid$sqlplus / as sysdba   SQL*Plus: Release 11.2.0.4.0 Production on Wed Dec 10 09:54:38 201

今天在客户这里对一个库做逻辑导出的时候,报了ORA-39095 Dump File Space Has Been Exhausted的错误。检查后发现,导出文件格式中设置了%U的参数,filesize 设置为4G,由于库比较大,当导出文件数量达到99的时候

因业务需要,有时候要使用数据库里面的job调用服务器上的脚本完成特定功能。这里演示一下如果利用dbms_scheduler包完成工作。以及可能会遇到的各种错误及解决方法。 1.       首先

有时候,我们需要通过dblink查询远程服务器上分区表的数据。查询全表不会有问题,但是如果想查询某个分区的数据,会发现直接查询是不支持的。以下是关于按分区查询的不同方式的测试结果: 远端有分区表sales SQ

    在生产环境中,在表的数量较多且数据量较大的情况下,按oracle的默认设置,每天收集统计信息是不现实的。同时也为保证SQL执行计划的稳定性,需要将某些表的统计信息收集好后固定起来。一般使用dbms_stats

在某客户的数据库中发现一个错误的执行计划,希望将其从内存中删除,但是生产库上又不能随便flush shared pool。因此尝试用dbms_shared_pool.purge来清除。 这里先做个实验来测试一下效果。   创建一个测试表