“alter database switchover to xx“过程不当导致的primary-primary 双主问题
关于切换时primary-primary 双主问题,看起来是因为使用“alter database switchover to xx” 执行切换时的流程上缺陷问题:首先在以往传统的switchover切换方式下,切换的流程是这样的:假如当前A库(primary),B库(standby)1. 在A库(primary)库上,执行切换语句"alter database commit to sw
pprof 分析mysqld 内存调用(笔记)
---- Install TCMALLOC 1.unpack tar zxvf gperftools-2.9.1.tar.gz ./configure --enable-frame-pointers --prefix=/u
mysql 5.7 vs 8.0默认值变化(笔记)
Changed Server DefaultsOption/ParameterOld DefaultNew DefaultServer changescharacter_set_serverlatin1utf8mb4collation_serverlatin1_swedish_ciutf8mb4_0900_ai_ciexplicit_defaults_for_timestampOFFONoptim
[ERROR] [MY-012872] [InnoDB] [FATAL] Semaphore wait has lasted > 600 seconds
InnoDB: ###### Diagnostic info printed to the standard error stream2021-11-19T14:52:21.671328+08:00 0 [ERROR] [MY-012872] [InnoDB] [FATAL] Semaphore wait has lasted > 600 seconds. We intentionally
[InnoDB] Assertion failure: ut0ut.cc:553 thread 140235111884544【笔记】
APPLIES TO:MySQL Server - Version 8.0 and laterInformation in this document applies to any platform.SYMPTOMSOn : 8.0 version, Server Crash ERROR----------------------- [InnoDB] Assertion fai
MYSQL The Server Shutdown Process(笔记)
The server shutdown process takes place as follows:The shutdown process is initiated.This can occur initiated several ways. For example, a user with the SHUTDOWN privilege can execute a 
MYSQL 8.0 Upgrade &Downgrade的几点注意
ImportantDowngrade from MySQL 8.0 to MySQL 5.7, or from a MySQL 8.0 release to a previous MySQL 8.0 release, is not supported. The only supported alternative is to restore a backup taken before upgrad
关于log file switch and checkpoint机制
转自同事周乙的研究总结,记录一下!关于ckpt的机制 何时发生check point?1. 每次redo file switch。2. 当达到参数LOG_CHECKPOINT_TIMEOUT设置值。3. 当有(
rac 正常关闭实例service不会自动漂移,只有在实例异常abort才会发生自动failover
关于正常计划性地shutdown 实例,服务不会自动漂移,只有在实例异常的情况下才会发生自动failover的情况。不过我们可以在srvctl stop instance时加上 “-f“ ,作用就是让服务自动failover到另外一个节点。-f This option fails the running services ov
延迟块清除导致rac节点传输undo header块
节点11)创建表及索引,并插入数据:create table cwdtest.tab91 (id number,name varchar2(100),created date);create index cwdtest.idx_tab91_01 on cwdtest.tab91(id) pctfree 0;2)节点1 进行update:SYS@t1nnps1> update cwdtest.
ORA-15137: The ASM cluster is in rolling patch state
之前卸载12.1的GI再安装19.9的GI,在创建asmdisk的时候报错:ORA-15137: The ASM cluster is in rolling patch state.Case 1. Update the patch level on all nodes, As root user$ clscfg -patchExample:# <grid home>/bin/clscf
Cursor Cache Hit Ratio超过100%
这种Ratio超过100的是正常的吗?目前我们的监控对这种超过的处理有点问题11g到19c各个版本都有这个情况。 这是正常现象, Cursor Cache Hit Ratio指标的来源是:session cursor cache hits / (parse count (total) - parse count (hard))。其中session cursor ca
sqlplus as sysdb登录报ora-01017
1.报错信息:cnsh281177:t3fxqdb > sqlplus '/as sysdba' SQL*Plus: Release 12.1.0.2.0 Production on Wed Apr 14 09:28:15 2021 Copyright (c) 1982, 2014, Oracle. All rights reserved.&n
SQL的reload以及Invalidations
关于SQL的游标版本不高,但reload以及Invalidations次数相对比较多。基本上是每一次Invalidations便伴随着一次reload. 关于load以及Invalidations的说明如下, Invalidations - An invalidation is a measure of the number of times a cached cursor
关于obsolete child cursor问题
查MOS发现如下bug:Bug 22994542 Child cursor counts increase with TYPECHECK_MISMATCH with Unified Auditing 里面给出了一个workaround 是调整隐藏参数 _cursor_obsolete_threshold。 _cursor_obsolete_threshol
转载ORA-01591错误故障处理(ji)
ORA-01591错误故障处理摘要:在访问某些表的特定行时报ORA-01591错误select * from BF_INCOME_EXPENSES_Twhere account_id = 36816153and user_id = 39964213and city_code = '185'ORA-01591: 锁定已被有问题的分配事务处理72.0.1608712挂起SQL
ORA-29702: error occurred in Cluster Group Service operation
ORA-29702: error occurred in Cluster Group Service operationIf you are working on Solaris and having Oracle database 10g or above, you might face ORA-29702 issue after reboot of your server
Innodb内存管理解析[转载]
本文转自http://mysql.taobao.org/monthly/2021/01/06/本文主要介绍innodb的内存管理,涉及基础的内存分配结构、算法以及buffer pool的实现细节,提及change buffer、自适应hash index和log buffer的基本概念和内存基本配比,侧重点在内存的分配和管理方式。本文所述内容基于mysql8.0版本。基础内存分配在5.6以前的版本
Bug 31625618 DML Over a LOB Column ORA-3137 [3146]When the Bind Size is > 256k
19c的bug, Bug 31625618 DML Over a LOB Column Using Long Bind Fails with ORA-3137 [3146] [4] / ORA-3137 [3146] [94] When the Bind Size is > 256k Bytes 这个bug补丁是前段时间刚出来,影响版
ORACLE通过透明网关建dblink连接Postgresql的几个问题
问题1:where条件查询失败ORA-00997:select "big","small" from "test_bigint"@dblink_b_bak where "big"='1';select "big","small" from "test_b