分类 数据库 下的文章

http://www.dbsnake.net/how-to-disable-asm-instance-amm.html
--参考
特别注意的是——如果要禁掉ASM实例的AMM,就一定不要同时reset memory_target和memory_max_target,
而是应该将memory_target设为0并只reset memory_max_target,但很恶心的是基本上所有的MOS文档都在说要同时reset memory_target和memory_max_target,

http://www.dbsnake.net/how-to-disable-asm-instance-amm.html
--参考
特别注意的是——如果要禁掉ASM实例的AMM,就一定不要同时reset memory_target和memory_max_target,
而是应该将memory_target设为0并只reset memory_max_target,但很恶心的是基本上所有的MOS文档都在说要同时reset memory_target和memory_max_target,
所以如果你没有注意到这一点,你会发现你怎么也禁不掉ASM实例的AMM。
未验证(如果是我下一次操作,可能会进行测试,这种影响较小,操作简便)

Oracle数据库中常见有LOB字段,通过以下SQL可以查到LOB字段属于数据库的哪张表

SQL> select *

   from (select owner,
                segment_name || '~' || partition_name segment_name,
                segment_type,
                bytes / 1024 / 1024 / 1024 size_G
           from dba_segments
          ORDER BY BLOCKS desc)
  where rownum < 11;

OWNER SEGMENT_NAME SEGMENT_TYPE SIZE_G


HWICHDB3 SYS_LOB0001459936C00001$$~ LOBSEGMENT 199.016601
HWICHDB3 C_CLIENT_VIP_MONTH~ TABLE 89.6533203
HWICHDB3 BW_INV_MAKE_APPLYITEM~ TABLE 63.1503906
HWICHDB3 EB_STOREPDT_ITEM~ TABLE 44.2568359
HWICHDB3 C_VOUCHERS_STORE~ TABLE 43.8935546
HWICHDB3 IDX_VOUCHERS_STORE_01~ INDEX 41.4667968
HWICHDB3 IDX_FA_STORAGE_FTP_91~ INDEX 36.8662109
HWICHDB3 IDX_FA_STORAGE_FTP_10~ INDEX 34.40625
HWICHDB3 CARDMAIN_MONTH~ TABLE 30.9667968
HWICHDB3 IDX_FA_STORAGE_FTP_90~ INDEX 30.3808593

10 rows selected

SQL> select e.owner, l.table_name, l.segment_name

    from dba_extents e, dba_lobs l
   where e.owner = l.owner
     and e.segment_name = l.segment_name
     and e.segment_type = 'LOBSEGMENT'
     and l.segment_name like 'SYS_LOB0001459936C00001$$';

OWNER TABLE_NAME SEGMENT_NAME


HWICHDB3 M_RETAIL_R_GETSTORAGE_C_LOG SYS_LOB0001459936C00001$$
HWICHDB3 M_RETAIL_R_GETSTORAGE_C_LOG SYS_LOB0001459936C00001$$
HWICHDB3 M_RETAIL_R_GETSTORAGE_C_LOG SYS_LOB0001459936C00001$$
HWICHDB3 M_RETAIL_R_GETSTORAGE_C_LOG SYS_LOB0001459936C00001$$
HWICHDB3 M_RETAIL_R_GETSTORAGE_C_LOG SYS_LOB0001459936C00001$$
HWICHDB3 M_RETAIL_R_GETSTORAGE_C_LOG SYS_LOB0001459936C00001$$
HWICHDB3 M_RETAIL_R_GETSTORAGE_C_LOG SYS_LOB0001459936C00001$$

select owner, table_name, column_name, segment_name, index_name
2 from dba_lobs
3 where table_name = 'M_RETAIL_R_GETSTORAGE_C_LOG';

OWNER TABLE_NAME COLUMN_NAME SEGMENT_NAME INDEX_NAME


HWICHDB3 M_RETAIL_R_GETSTORAGE_C_LOG TEXT SYS_LOB0001459936C00001$$ SYS_IL0001459936C00001$$
————————————————
版权声明:本文为CSDN博主「灰帽DBA」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.csdn.net/Evils798/article/details/115358704

上午收到一个请求,创建索引,原表100G多B,行数4.3亿。语句如下:

ALTER TABLE arehouse_operation_log ADD lab_in varchar(32) NULL COMMENT 'lab';

CREATE INDEX warehouse_operation_log_lab_in_IDX USING BTREE ON warehouse_operation_log (lab_in);

在mysql 8.0.33上,

1061 - Duplicate key name 'warehouse_operation_log_lab_in_IDX'
时间: 1438.837s

约23分钟
执行过程中,不确定执行进度,使用语句查询
show processlist; 找到语句对应的id
select * from sys.session where conn_id = '93290' and trx_state='ACTIVE'\G;
查看执行进度
发现 process 一直卡在44.46,但未报错
突然到100%完成。所有,这个进度只能证明sql在运行,并不能真实反映进度信息。

Oracle - dg坏块修复(二)
一、概述
本文是坏块修复(一)的续篇,这篇文章将介绍如何在dg环境中模拟坏块,以及出现坏块该如何修复。实验分为以下几个步骤。

  1. 主库表出现坏块
  2. dg库表出现坏块

- 阅读剩余部分 -