标签云
asm恢复 bbed bootstrap$ dul In Memory kcbzib_kcrsds_1 kccpb_sanity_check_2 MySQL恢复 ORA-00312 ORA-00607 ORA-00704 ORA-00742 ORA-01110 ORA-01555 ORA-01578 ORA-01595 ORA-08103 ORA-600 2131 ORA-600 2662 ORA-600 3020 ORA-600 4000 ORA-600 4137 ORA-600 4193 ORA-600 4194 ORA-600 16703 ORA-600 kcbzib_kcrsds_1 ORA-600 KCLCHKBLK_4 ORA-15042 ORA-15196 ORACLE 12C oracle dul ORACLE PATCH Oracle Recovery Tools oracle加密恢复 oracle勒索 oracle勒索恢复 oracle异常恢复 Oracle 恢复 ORACLE恢复 ORACLE数据库恢复 oracle 比特币 OSD-04016 YOUR FILES ARE ENCRYPTED 勒索恢复 比特币加密文章分类
- Others (2)
- 中间件 (2)
- WebLogic (2)
- 操作系统 (103)
- 数据库 (1,767)
- DB2 (22)
- MySQL (77)
- Oracle (1,608)
- Data Guard (52)
- EXADATA (8)
- GoldenGate (24)
- ORA-xxxxx (166)
- ORACLE 12C (72)
- ORACLE 18C (6)
- ORACLE 19C (15)
- ORACLE 21C (3)
- Oracle 23ai (8)
- Oracle ASM (69)
- Oracle Bug (8)
- Oracle RAC (54)
- Oracle 安全 (6)
- Oracle 开发 (28)
- Oracle 监听 (29)
- Oracle备份恢复 (590)
- Oracle安装升级 (97)
- Oracle性能优化 (62)
- 专题索引 (5)
- 勒索恢复 (86)
- PostgreSQL (30)
- pdu工具 (6)
- PostgreSQL恢复 (9)
- SQL Server (32)
- SQL Server恢复 (13)
- TimesTen (7)
- 达梦数据库 (3)
- 达梦恢复 (1)
- 生活娱乐 (2)
- 至理名言 (11)
- 虚拟化 (2)
- VMware (2)
- 软件开发 (39)
- Asp.Net (9)
- JavaScript (12)
- PHP (2)
- 小工具 (22)
-
最近发表
- ORA-00756 ORA-10567故障数据0丢失恢复
- 数据库文件变成32k故障恢复
- tcp连接过多导致监听TNS-12532 TNS-12560 TNS-00502错误
- 文件系统格式化MySQL数据库恢复
- .sstop勒索加密数据库恢复
- 解决一次硬件恢复之后数据文件0kb的故障恢复case
- Error in invoking target ‘libasmclntsh19.ohso libasmperl19.ohso client_sharedlib’问题处理
- ORA-01171: datafile N going offline due to error advancing checkpoint
- linux环境oracle数据库被文件系统勒索加密为.babyk扩展名溯源
- ORA-600 ksvworkmsgalloc: bad reaper
- ORA-600 krccfl_chunk故障处理
- Oracle Recovery Tools恢复案例总结—202505
- ORA-600 kddummy_blkchk 数据库循环重启
- 记录一次asm disk加入到vg通过恢复直接open库的案例
- CHECKDB 发现了 N 个分配错误和 M 个一致性错误
- 达梦数据库dm.ctl文件异常恢复
- Oracle Recovery Tools修复ORA-00742、ORA-600 ktbair2: illegal inheritance故障
- 可能是 tempdb 空间用尽或某个系统表不一致故障处理
- 11.2.0.4库中遇到ORA-600 kcratr_nab_less_than_odr报错
- [MY-013183] [InnoDB] Assertion failure故障处理
月归档:七月 2011
触发器引起ORA-04091
原因:在行级触发器中,不能查询自身表
场景重现:通过触发器实现test_count表中统计test表中行数
--创建子表 create table TEST (id NUMBER, name varchar2(100), primary key (id)); --创建统计表 create table test_count (test_count int); --创建触发器 CREATE OR REPLACE TRIGGER T_TEST AFTER INSERT OR DELETE ON TEST FOR EACH ROW DECLARE A NUMBER; BEGIN SELECT COUNT(*) INTO A FROM TEST; UPDATE TEST_COUNT SET TEST_COUNT = A; END T_TEST;
模拟错误:
INSERT INTO TEST (ID,NAME)VALUES(2,'abc'); ORA-04091: table CHF.TEST is mutating, trigger/function may not see it ORA-06512: at "CHF.T_TEST", line 2 ORA-04088: error during execution of trigger 'CHF.T_TEST'
处理方法:
通过自治事务实现(修改触发器)
CREATE OR REPLACE TRIGGER T_TEST AFTER INSERT OR DELETE ON TEST FOR EACH ROW DECLARE A NUMBER; PRAGMA AUTONOMOUS_TRANSACTION; BEGIN SELECT COUNT(*) INTO A FROM TEST; UPDATE TEST_COUNT SET TEST_COUNT = A; COMMIT; END T_TEST;
PRAGMA AUTONOMOUS_TRANSACTION
当前的触发器作为已有事务的子事务运行,子事务自治管理,子事务的commit、rollback操作不影响父事务的状态
Read by other session等待事件
今天中午发现福建生产库报负载有点异常,处理思路记录下来:
1、使用top命令查看系统,发现系统负载是比以前要搞(平时都是1以下,今天已经稳定在4左右,总是有部分进城占用cpu比较高,系统cpu等待明显)
1.1)第一反应是有人执行sql导致,抓取占用cpu较高的spid,查询出对应sql,发现都是一些比较简单sql
1.2)查询这些spid的客户端是应用服务器,也就是说不是人为执行,那在一个稳定的系统中,不会出现sql突然改变的原因
2、查询系统是否因为有对象被阻塞导致,查询发现无对象被阻塞
3、查询系统等待事件,发现几十个read by other session等待,都是从一台web的服务器上连接过来
SELECT * FROM v$session WHERE wait_class#<>6;
4、read by other session等待事件比较陌生,幸好伴随有db file sequential read的等待事件,初步怀疑读取数据到内存中等待导致
5、查询资料发现
read by other session Definition: When information is requested from the database, Oracle will first read the data from disk into the database buffer cache. If two or more sessions request the same information, the first session will read the data into the buffer cache while other sessions wait.
In previous versions this wait was classified under the “buffer busy waits” event.
However, in Oracle 10.1 and higher this wait time is now broken out into the “read by other session” wait event. Excessive waits for this event are typically due to several processes repeatedly reading the same blocks, e.g. many sessions scanning the same index or performing full-table scans on the same table. Tuning this issue is a matter of finding and eliminating this contention.
Confio concludes with a summary that “read by other session waits” are very similar to buffer busy waits
When a session waits on the “read by other session” event, it indicates a wait for another session to read the data from disk into the Oracle buffer cache.
If this happens too often the performance of the query or the entire database can suffer. Typically this is caused by contention for “hot” blocks or objects so it is imperative to find out which data is being contended for. Once that is known this document lists several alternative methods for solving the issue.
总结:两个或者多个会话同时需要把硬盘中的对象装载到data buffer中,当其中一个会话把对象装入后,其他会话就处于read by other session等待状态;这个是oracle 10g 从oracle 9i的buffer busy waits中分离出来的,也是需要一种热块现象
6、根据FILE#,BLOCK#查询热块对象
SELECT OWNER, SEGMENT_NAME, SEGMENT_TYPE, TABLESPACE_NAME, A.PARTITION_NAME
FROM DBA_EXTENTS A
WHERE FILE_ID = &FILE_ID
AND &BLOCK_ID BETWEEN BLOCK_ID AND BLOCK_ID + BLOCKS – 1;
7、通过这个对象查询出对应的操作语句
select * from v$sql where upper(sql_text) like ‘%object_name%’;
8、直接查找热点块对象语句
SELECT * FROM (SELECT O.OWNER, O.OBJECT_NAME, O.OBJECT_TYPE, SUM(TCH) TOUCHTIME, FROM X$BH B, DBA_OBJECTS O WHERE B.OBJ = O.DATA_OBJECT_ID AND B.TS# > 0 GROUP BY O.OWNER, O.OBJECT_NAME, O.OBJECT_TYPE ORDER BY SUM(TCH) DESC) WHERE ROWNUM <= 10 --或者 SELECT E.OWNER, E.SEGMENT_NAME, E.SEGMENT_TYPE FROM DBA_EXTENTS E, (SELECT * FROM (SELECT ADDR, TS#, FILE#, DBARFIL, DBABLK, TCH FROM X$BH ORDER BY TCH DESC) WHERE ROWNUM < 11) B WHERE E.RELATIVE_FNO = B.DBARFIL AND E.BLOCK_ID <= B.DBABLK AND E.BLOCK_ID + E.BLOCKS > B.DBABLK;
9、直接查找热点块操作语句
SELECT /*+rule*/ HASH_VALUE, SQL_TEXT FROM V$SQLTEXT WHERE (HASH_VALUE, ADDRESS) IN (SELECT A.HASH_VALUE, A.ADDRESS FROM V$SQLTEXT A, (SELECT DISTINCT A.OWNER, A.SEGMENT_NAME, A.SEGMENT_TYPE FROM DBA_EXTENTS A, (SELECT DBARFIL, DBABLK FROM (SELECT DBARFIL, DBABLK FROM X$BH ORDER BY TCH DESC) WHERE ROWNUM < 11) B WHERE A.RELATIVE_FNO = B.DBARFIL AND A.BLOCK_ID <= B.DBABLK AND A.BLOCK_ID + A.BLOCKS > B.DBABLK) B WHERE A.SQL_TEXT LIKE '%' || B.SEGMENT_NAME || '%' AND B.SEGMENT_TYPE = 'TABLE') ORDER BY HASH_VALUE, ADDRESS, PIECE;
10、也可以通过awr查询出来相关对象
Segments by Buffer Busy Waits
语句需要通过这些等待对象进行判断
到了1点钟左右,数据库read by other session等待事件消失,数据库恢复正常负载(因为系统还能够承受,所以当时没有采用kill进程的方法)
事后对查询出来的热点块对象和操作语句,已经访问服务器和开发确认的结果为:这个是一个报表功能,但是平时没有人用,所以也没有关注,今天突然被人用了下,导致这个问题发生,他们承诺在升级下个版本中解决这个问题。
发表在 Oracle性能优化
评论关闭
Mysql Merge表
MERGE引擎类型允许你把许多结构相同的表合并为一个表。然后,你可以执行查询,从多个表返回的结果就像从一个表返回的结果一样。每一个合并的表必须有同样的表定义。
MERGE存储引擎在下面这种使用场合会最为有用,如果需要把日志纪录不停的录入MySQL数据库,并且每天、每周或者每个月都创建一个单一的表,而且要制作来自多个表的合计查询,MERGE表这时会非常有效。然而,这项功能有局限性。你只能合并MyISAM表而且必须严格遵守相同的表定义的限制。
创建方法如下:
mysql> create table t1(id int not null primary key,name varchar(20)) engine=myisam;
Query OK, 0 rows affected (0.03 sec)
mysql> create table t2(id int not null primary key,name varchar(20)) engine=myisam;
Query OK, 0 rows affected (0.00 sec)
mysql> create table mrg(id int not null primary key,name varchar(20)) engine=merge union(t1,t2) insert_method=first;
Query OK, 0 rows affected (0.00 sec)
测试:
1、在t1中插入数据
mysql> insert into t1 values(1,’tttttt’);
Query OK, 1 row affected (0.03 sec)
mysql> insert into t1 values(2,’tttttt’);
Query OK, 1 row affected (0.00 sec)
2、查询t1表
mysql> select * from t1;
+—-+——–+
| id | name |
+—-+——–+
| 1 | tttttt |
| 2 | tttttt |
+—-+——–+
2 rows in set (0.00 sec)
3、查询mrg表
mysql> select * from mrg;
+—-+——–+
| id | name |
+—-+——–+
| 1 | tttttt |
| 2 | tttttt |
+—-+——–+
2 rows in set (0.00 sec)
4、在t2中插入数据
mysql> insert into t2 values(1,’ssssss’);
Query OK, 1 row affected (0.00 sec)
5、查询t2表
mysql> select * from t2;
+—-+——–+
| id | name |
+—-+——–+
| 1 | ssssss |
+—-+——–+
1 row in set (0.00 sec)
6、查询mrg表
mysql> select * from mrg;
+—-+——–+
| id | name |
+—-+——–+
| 1 | tttttt |
| 2 | tttttt |
| 1 | ssssss |
+—-+——–+
3 rows in set (0.00 sec)
7、mrg表中插入数据并测试
mysql> insert into mrg values(1,’ssssss’);
ERROR 1062 (23000): Duplicate entry ’1′ for key ‘PRIMARY’
mysql> insert into mrg values(2,’ssssss’);
ERROR 1062 (23000): Duplicate entry ’2′ for key ‘PRIMARY’
mysql> insert into mrg values(3,’ssssss’);
Query OK, 1 row affected (0.00 sec)
mysql> insert into t2 values(4,’ssssss’);
Query OK, 1 row affected (0.00 sec)
mysql> insert into mrg values(4,’ssssss’);
Query OK, 1 row affected (0.00 sec)
mysql> select * from t1;
+—-+——–+
| id | name |
+—-+——–+
| 1 | tttttt |
| 2 | tttttt |
| 3 | ssssss |
| 4 | ssssss |
说明:因为我们设置的 INSERT_METHOD为FIRST,因此插入数据进入t1表,而t1表中有主键,所以部分数据插入失败
1. 此表类似于SQL中的union机制。
2. 此表结构必须与基本表完全一致,包括列名、顺序。UNION表必须同属一个DATABASE。
3. 基本表类型必须是MyISAM。
4. 可以通过修改.mrg文件来修改MERGE表,每个基本表的名字占一行。注意:修改后要通过FLUSH TABLES刷新表缓存。
5. 对基本表的更改可以直接反映在此表上。
6. INSERT_METHOD的取值可以是: 0 不允许插入 FIRST 插入到UNION中的第一个表 LAST 插入到UNION中的最后一个表。(4.0之后可用)
7. 定义在它上面的约束没有任何作用,约束是由基本表控制的,例如两个基本表中存在着同样的一个Key值,那么在MERGE表中会有两个一样的Key值。
发表在 MySQL
评论关闭