wukaiqiang 发布的文章

今天出差成都，刚好酒店对面就是万达广场，所以就去找点当地的美食试试。一个人走来走去，挑来挑去，吃了一份30多块钱的冒菜，虽然便宜，也吃得全身冒汗，撑肠拄腹，路过小吃的时候，给老板说先付钱摊了，回头来取，等后来再路过的时候， 发现已经吃不下了，和老板商量了，明天再来取。

下午5点哥们提议去看电影，本着无事可做，打发时间的心态，就去了。结果在电影院里，我被惊到开始反思人生的意义。

情节其实可是概括出来，就是刑警三大队侦破一桩杀人强奸案的过程中，嫌疑人之一王大勇（刑讯过程中）意外死在了审讯室中，导致三大队的全体成员被判刑，刑满释放后继续追凶的故事。

这里面有镜头语言的紧凑，故事逻辑的缜密，前后铺垫，虽然也很值得体会，但都不是我所关注的，。我只想说一些打动我内心的点。

刚毕业的新人警察，和即将退伍的老警察对于大案的不同看法，体现了不同人物的视角。

警察变成刑满释放人员，是一次人生的重大打击，改变了所有人的人生轨迹，光是妻离子散就会把人打的不成人形，何况从受人尊重的公务员变成了被人鄙视的社会底层，甚至是生存艰难的境地，所有人，面对现实，显得真实而乐观

追凶变成了程队后面人生唯一的追求，不疯魔，不成活，后面他想要放弃的时候， 翻遍通讯录，却不知道发给谁，我突然想到了自己的通讯录，分享某一个感受的时候，可是手机里面也找不到可以分享的人。只能说孤独的原因不同，同样是孤独而已。

其他人为了心中那份迟来的正义，也付出了巨大代价。后面所有的人都走了，最后留下的只有程队。看的过程中，我想到了西游记，就像是一路上，真实的取经的只有玄奘法师一人而已，后面再看影评，真实的故事里面，从始至终都只有一个程队在追凶的路上，因为这里面的牺牲太大了。

电影的改编，让故事更好看，更有温度。为现实增加了一抹温暖的兄弟情。

专业的影评也说了很多社会层面的问题，这个我能理解，但没有特别深刻的体会，毕竟处于底层，没有关注社会问题的大眼界。穷则独善其身，达则兼济天下。

对于其他人的离去，是中年人没资格去追求正义理想。家庭的责任，子女的教育，父母的赡养，财米油盐，这些都是压在中年人身上打一座座大山。

如果放弃背负这些责任，人生又会陷入另一个旋涡，一直单身的人，你会失去被社会正常看待的机会。你会被视为失败者，没有价值的，有问题的人。

对白中还有一个小金句：男人没出息，女人就老的快。我很快就联想到自己和前任，特别想去照顾她，晚上鼓起勇气去了一个电话，意料之中的无人接听，很多事情错过了就要放下，执着只是作茧自缚。

最后对于当前的自己说一句，用真诚和智慧面对世界。关注自己的内心和身体的健康。找一个合适的人，比什么工作好，前途光明都来的有意义。

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在运行，并不能真实反映进度信息。

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. ...
  7. 31