ITPub博客

环境介绍项目源端目标端操作系统Windows Server 2008R2 64bitOracle Linux 7.8 64bit数据库版本Oracle 11.2.0.1Oracle 19c存储系统文件系统ASM字节序littlelittle  准备测试数据create tablespace mytbs1 datafile 'C:\oradata\mytbs1.dbf&#

首先将performance_schema这个数据库下的需要进行跟踪的指标打开： update setup_consumers set enabled=’yes’ where name like ‘%wait%’; select * from setup_consumers where name like ‘%wait%’; 创建一个视图方便后续查询： create view sys.te

首先将performance_schema这个数据库下的需要进行跟踪的指标打开： update setup_consumers set enabled=’yes’ where name like ‘%wait%’; select * from setup_consumers where name like ‘%wait%’; 创建一个视图方便后续查询： create view sys.

首先将performance_schema这个数据库下的需要进行跟踪的指标打开：update setup_consumers set enabled='yes'  where name like '%wait%';select * from setup_consumers where  name like '%wait%';创建一

sysbench --test=oltp --db-driver=mysql --mysql-table-engine=innodb --mysql-host=192.168.177.130 --mysql-port=3306 --mysql-db=testdb \--mysql-user='root' --mysql-password='123456' --tes

近期，一客户历史数据库屡次遇到ORA-00600: internal error code, arguments: [13011]。附带的，还有ORA-01499SQL> analyze table WRH$_IOSTAT_DETAIL validate structure cascade;analyze table WRH$_IOSTAT_DETAIL validate structure

某政府客户，近期不断有数据库性能问题。某日，应用维护人员请求DBA介入杀会话， 因业务办理很不顺畅。首先看到有严重的阻塞：从gv$session_blockers可以看出，被阻塞的会话有156个。业务基本上已经进行不下去了。通过以下SQL查询阻塞的源头：select distinct b.blocker_instance_id, b.blocker_sid, b.blocker_sess_seri

某客户的数据库告警日志中不断提示：Thu Jul 02 10:26:36 2020Errors in file /u01/app/oracle/diag/rdbms/orcl2/orcl2/trace/orcl2_j001_106746.trc:Errors in file /u01/app/oracle/diag/rdbms/orcl2/orcl2/trace/orcl2_j001_106746

某客户的一个历史库遇到错误, 数据库不定期崩溃,从日志中可以看到如下内容:Errors in file /u01/app/oracle/diag/rdbms/orcl2/orcl2/trace/orcl2_smon_6364.trc  (incident=336027):ORA-00600: internal error code, arguments: [13013], [5001],

      某医院客户，核心数据库有两个备库。因想将其中一个备库主机挪作测试使用，所以，想把数据库切换成读写模式。这样，就涉及到了做备库的failover动作。这个failover是在另外一个备库，主库都存活的情况下进行的。      Faiover进行得很顺利。Failover之后，修改了此数据库的DG的几个参数，当天以为事情就这么完了

我们在Oracle RAC上，可以创建针对数据库创建一个service，例如：srvctl add service -d orcl -s test1 -i orcl1,orcl2 ...srvctl modify service -d orcl -s test1 -y AUTOMATICcrsctl modify res ora.orcl.test1.svc -attr "AUTO_ST

一套11.2.0.4的RAC，节点时间采用ntpdate使用cron job的方式进行同步。 节点1因硬件故障宕机之后，集群服务久久不能启动。连上主机，采用crsctl stop has -f，crsctl start has的方式进行重启，同时采用crsctl stat res -t -init的方式查看集群基础服务启动的状态。发现CTSS启动时有报错，最终呈现offline的状态。

        背景：客户有两套较大的数据库(一套为10T（A数据库）, 一套为20T（B数据库）)想迁移存储，版本均为12.2.0.1, 采用了ASM管理磁盘，单实例。操作系统分别为linux 6, linux 7。客户想将B数据库的存储迁移到较差的存储，作为只读用途。腾空B数据库的存储之后，将B数据库占用的性能较好的存储分配给A数据库，再将A数据库的数据

slave中出现错误：2020-04-09T07:40:18.719203Z 16 [ERROR] Slave SQL for channel '': Could not execute Write_rows event on table mytestdb.t1; Duplicate entry '6' for key 'PRIMARY', Erro

RMAN> run { allocate channel ch00 device type 'SBT_TAPE' PARMS="SBT_LIBRARY=oracle.disksbt, ENV=(BACKUP_DIR=/tmp)"; backup datafile 1 format='%U';}2> 3> 4> 5>

yum -y install make automake libtool pkgconfig libaio-devel

客户反馈一个备库的数据库软件的LV最近几天增长得比较快，新产生的trace文件也较多。这个备库位于HPUX平台，版本11.2.0.4, 存在较多的读取业务。到达，客户现场之后，在trace目录下发现很多server process的trace文件较大，一般都有十几兆，大的有四十多兆。显然这个有点不正常。查看了几个trace文件，发现其中的module为TEST.exe，其中的数据库连接来自于这个e

      首先在本文开始前介绍几个Oracle数据库中的概念。LMS进程：实际上就是GCS(Global Cache Service Processes)。这个是在RAC环境中才会有的进程，负责管理集群的资源，并协调集群资源的访问。这里的资源主要指的是Buffer Cache。LMS进程对于RAC来说极为重要，因为集群的Cache Fusion的动作由它来完成，如果

背景：客户找到我们，反馈有一套10.2.0.4版本的Oracle数据库，运行在Solaris Sparc 10的HA架构上, 因为共享存储被写满与不恰当的操作（这是后来的Sun工程师确认），导致数据库异常。查看环境时，共享存储不能被集群软件挂载，同时，数据库告警日志中除了归档日志写满的告警之外，未发现有其他错误。同时，存储工程师确认存储正常。后续Sun主机工程师修复了挂载故障后发现，数据库的当前重

今天在还原一个测试数据库时，删除原库文件之后使用pfile启动数据库实例，一直报错：SQL> startup nomount pfile='?/dbs/test.txt'ORA-00119: invalid specification for system parameter LOCAL_LISTENERORA-00130: invalid listener address