update对consistent gets的影响

金融AI客服贷款自动化:架构设计与风控模型实践 自然语言处理(NLP)与机器学习技术在金融科技领域正深度重塑传统业务流程。以贷款审批场景为例,基于BERT微调的领域专用模型能精准理解金融术语,结合Drools规则引擎与XGBoost等集成算法,构建起从客户身份核验到风险评估的智能决策链。这种AI驱动方案通过微服务架构实现分钟级响应,典型应用数据显示审批效率提升99%的同时降低25%逾期率。关键技术涉及实时特征计算、模型可解释性保障及多活部署等高可用设计,为银行数字化转型提供核心支撑。 阅读详情

 

chao_ping:

        经过别的session Update之后,select 语句的buffer gets 会变大,这是可以理解的.
因为Oracle需要从别的Block里面得到他需要的Block的之前的映像。

但是,这里的这个参数就好像有点南里理解:
  
SQL> select * from t where object_id=100;
  
  OBJECT_ID OWNER
---------- ------------------------------
        100 cc
  
Execution Plan
----------------------------------------------------------
    0      SELECT STATEMENT Optimizer=FIRST_ROWS (Cost=2 Card=14 Bytes=          420)
    1    0   TABLE ACCESS (BY INDEX ROWID) OF 'T' (Cost=2 Card=14 ytes
           =420)
    2    1     INDEX (RANGE SCAN) OF 'IDX_T' (NON-UNIQUE) (Cost=1 rd=        14)
  
Statistics
----------------------------------------------------------
           0  recursive calls
           0  db block gets
           4  consistent gets
           3  physical reads
           0  redo size
         424  bytes sent via SQL*Net to client
         426  bytes received via SQL*Net from client
           2  SQL*Net roundtrips to/from client
           1  sorts (memory)
           0  sorts (disk)
           1  rows processed
  
另外开一个session, 把这个表全部都UPdate掉. 在这边再次select:  
  
SQL> /
  
  OBJECT_ID OWNER
---------- ------------------------------
        100 cc
  
Execution Plan
----------------------------------------------------------
    0      SELECT STATEMENT Optimizer=FIRST_ROWS (Cost=2 Card=14 Bytes=          420)
  
    1    0   TABLE ACCESS (BY INDEX ROWID) OF 'T' (Cost=2 Card=14 Bytes          =420)
  
    2    1     INDEX (RANGE SCAN) OF 'IDX_T' (NON-UNIQUE) (Cost=1 Card=          14)
  
Statistics
----------------------------------------------------------
           0  recursive calls
           0  db block gets
         557  consistent gets
           0  physical reads
          52  redo size
         424  bytes sent via SQL*Net to client
         426  bytes received via SQL*Net from client
           2  SQL*Net roundtrips to/from client
           0  sorts (memory)
           0  sorts (disk)
           1  rows processed
  
SQL> /
  
  OBJECT_ID OWNER
---------- ------------------------------
        100 cc
  
Execution Plan
----------------------------------------------------------
    0      SELECT STATEMENT Optimizer=FIRST_ROWS (Cost=2 Card=14 Bytes=          420)
  
    1    0   TABLE ACCESS (BY INDEX ROWID) OF 'T' (Cost=2 Card=14 Bytes          =420)
  
    2    1     INDEX (RANGE SCAN) OF 'IDX_T' (NON-UNIQUE) (Cost=1 Card=          14)
  
Statistics
----------------------------------------------------------
           0  recursive calls
           0  db block gets
           4  consistent gets
           0  physical reads
           0  redo size
         424  bytes sent via SQL*Net to client
         426  bytes received via SQL*Net from client
           2  SQL*Net roundtrips to/from client
           0  sorts (memory)
           0  sorts (disk)
           1  rows processed
  
SQL> /
  
  OBJECT_ID OWNER
---------- ------------------------------
        100 cc
  
Execution Plan
----------------------------------------------------------
    0      SELECT STATEMENT Optimizer=FIRST_ROWS (Cost=2 Card=14 Bytes=          420)
    1    0   TABLE ACCESS (BY INDEX ROWID) OF 'T' (Cost=2 Card=14 Bytes          =420)
    2    1     INDEX (RANGE SCAN) OF 'IDX_T' (NON-UNIQUE) (Cost=1 Card=          14)
  
Statistics
----------------------------------------------------------
           0  recursive calls
           0  db block gets
           4  consistent gets
           0  physical reads
           0  redo size
         424  bytes sent via SQL*Net to client
         426  bytes received via SQL*Net from client
           2  SQL*Net roundtrips to/from client
           0  sorts (memory)
           0  sorts (disk)
           1  rows processed
  
SQL> select count(*) from t;
  
   COUNT(*)
----------
       6996
  
Execution Plan
----------------------------------------------------------
    0      SELECT STATEMENT Optimizer=FIRST_ROWS (Cost=2 Card=1)
    1    0   SORT (AGGREGATE)
    2    1     TABLE ACCESS (FULL) OF 'T' (Cost=2 Card=1307)
  
Statistics
----------------------------------------------------------
           0  recursive calls
          12  db block gets
          20  consistent gets
           0  physical reads
           0  redo size
         368  bytes sent via SQL*Net to client
         426  bytes received via SQL*Net from client
           2  SQL*Net roundtrips to/from client
           1  sorts (memory)
           0  sorts (disk)
           1  rows processed

这里如果update 只是很少记录的话,那么这边的consistent gets地数量也会小很多.
这个时可以理解的.
  
update 整个表,为什么检索这条记录,Buffer gets会增加这么多?
标被另外sesision update 之后:
SQL> /
  
   COUNT(*)
----------
       6996
  
Execution Plan
----------------------------------------------------------
    0      SELECT STATEMENT Optimizer=FIRST_ROWS (Cost=2 Card=1)
    1    0   SORT (AGGREGATE)
    2    1     TABLE ACCESS (FULL) OF 'T' (Cost=2 Card=1307)
  
Statistics
----------------------------------------------------------
           0  recursive calls
          12  db block gets
        7033  consistent gets
           0  physical reads
         832  redo size
         368  bytes sent via SQL*Net to client
         426  bytes received via SQL*Net from client
           2  SQL*Net roundtrips to/from client
           0  sorts (memory)
           0  sorts (disk)
           1  rows processed
  
那个session commit 之后:
SQL> /
  
   COUNT(*)
----------
       6996
  
Execution Plan
----------------------------------------------------------
    0      SELECT STATEMENT Optimizer=FIRST_ROWS (Cost=2 Card=1)
    1    0   SORT (AGGREGATE)
    2    1     TABLE ACCESS (FULL) OF 'T' (Cost=2 Card=1307)
  
Statistics
----------------------------------------------------------
           0  recursive calls
          12  db block gets
          21  consistent gets
           0  physical reads
          60  redo size
         368  bytes sent via SQL*Net to client
         426  bytes received via SQL*Net from client
           2  SQL*Net roundtrips to/from client
           0  sorts (memory)
           0  sorts (disk)
           1  rows processed

但是,如果即使update 其他整个表(除了object_id=100)对应的记录所在地lock,

  Quote:

  
SQL>  update t set owner='c' where dbms_rowid.ROWID_BLOCK_NUMBER(rowid)<>17470;
  
6380 rows updated.
  
Execution Plan
----------------------------------------------------------
    0      UPDATE STATEMENT Optimizer=FIRST_ROWS (Cost=2 Card=4 Bytes=9
           6)
  
    1    0   UPDATE OF 'T'
    2    1     TABLE ACCESS (FULL) OF 'T' (Cost=2 Card=4 Bytes=96)
  
Statistics
----------------------------------------------------------
           0  recursive calls
        6530  db block gets
          19  consistent gets
           0  physical reads
     1561860  redo size
         622  bytes sent via SQL*Net to client
         577  bytes received via SQL*Net from client
           3  SQL*Net roundtrips to/from client
           1  sorts (memory)
           0  sorts (disk)
        6380  rows processed


这个select 的成本还是不变
SQL> select * from t where object_id=100;
  
  OBJECT_ID OWNER
---------- ------------------------------
        100 zc
  
Execution Plan
----------------------------------------------------------
    0      SELECT STATEMENT Optimizer=FIRST_ROWS (Cost=1 Card=1 Bytes=3
           0)
  
    1    0   TABLE ACCESS (BY INDEX ROWID) OF 'T' (Cost=1 Card=1 Bytes=
           30)
  
    2    1     INDEX (RANGE SCAN) OF 'IDX_T' (NON-UNIQUE) (Cost=1 Card=
           1)
  
Statistics
----------------------------------------------------------
           0  recursive calls
           0  db block gets
           4  consistent gets
           0  physical reads
           0  redo size
         436  bytes sent via SQL*Net to client
         504  bytes received via SQL*Net from client
           2  SQL*Net roundtrips to/from client
           0  sorts (memory)
           0  sorts (disk)
           1  rows processed
  
如果只是update 改记录所在地Block的某一个记录,那么buffer gets增加为2:

  Quote:

SQL> update t set owner='c' where dbms_rowid.ROWID_BLOCK_NUMBER(rowid)=17470 and rownum=1;
  
1 row updated.
  
Execution Plan
----------------------------------------------------------
    0      UPDATE STATEMENT Optimizer=FIRST_ROWS (Cost=2 Card=1 Bytes=2
           4)
  
    1    0   UPDATE OF 'T'
    2    1     COUNT (STOPKEY)
    3    2       TABLE ACCESS (FULL) OF 'T' (Cost=2 Card=1 Bytes=24)
  
Statistics
----------------------------------------------------------
          37  recursive calls
           2  db block gets
           8  consistent gets
           0  physical reads
         384  redo size
         623  bytes sent via SQL*Net to client
         588  bytes received via SQL*Net from client
           3  SQL*Net roundtrips to/from client
           1  sorts (memory)
           0  sorts (disk)
           1  rows processed


SQL> /
  
  OBJECT_ID OWNER
---------- ------------------------------
        100 zc
  
Execution Plan
----------------------------------------------------------
    0      SELECT STATEMENT Optimizer=FIRST_ROWS (Cost=1 Card=1 Bytes=3
           0)
  
    1    0   TABLE ACCESS (BY INDEX ROWID) OF 'T' (Cost=1 Card=1 Bytes=
           30)
  
    2    1     INDEX (RANGE SCAN) OF 'IDX_T' (NON-UNIQUE) (Cost=1 Card=
           1)
  
Statistics
----------------------------------------------------------
           0  recursive calls
           0  db block gets
           6  consistent gets
           0  physical reads
          52  redo size
         436  bytes sent via SQL*Net to client
         504  bytes received via SQL*Net from client
           2  SQL*Net roundtrips to/from client
           0  sorts (memory)
           0  sorts (disk)
           1  rows processed

如果update 了这个记录所在地Block的全部记录,那么consisteng gets 就会是何update 整个表所在地记录一样的结果:
SQL> update t set owner='c' where dbms_rowid.ROWID_BLOCK_NUMBER(rowid)=17470 ;  
  
616 rows updated.
  
Execution Plan
----------------------------------------------------------
    0      UPDATE STATEMENT Optimizer=FIRST_ROWS (Cost=2 Card=1 Bytes=2
           4)
  
    1    0   UPDATE OF 'T'
    2    1     TABLE ACCESS (FULL) OF 'T' (Cost=2 Card=1 Bytes=24)
  
Statistics
----------------------------------------------------------
           0  recursive calls
         630  db block gets
          19  consistent gets
           0  physical reads
      150724  redo size
         624  bytes sent via SQL*Net to client
         576  bytes received via SQL*Net from client
           3  SQL*Net roundtrips to/from client
           1  sorts (memory)
           0  sorts (disk)
         616  rows processed
那么select 的成本:
SQL> /
  
  OBJECT_ID OWNER
---------- ------------------------------
        100 zc
  
Execution Plan
----------------------------------------------------------
    0      SELECT STATEMENT Optimizer=FIRST_ROWS (Cost=1 Card=1 Bytes=3
           0)
  
    1    0   TABLE ACCESS (BY INDEX ROWID) OF 'T' (Cost=1 Card=1 Bytes=
           30)
  
    2    1     INDEX (RANGE SCAN) OF 'IDX_T' (NON-UNIQUE) (Cost=1 Card=
           1)
  
Statistics
----------------------------------------------------------
           0  recursive calls
           0  db block gets
         622  consistent gets
           0  physical reads
          52  redo size
         436  bytes sent via SQL*Net to client
         504  bytes received via SQL*Net from client
           2  SQL*Net roundtrips to/from client
           0  sorts (memory)
           0  sorts (disk)
           1  rows processed

 

biti_rainy  回复: buffer gets?


因为 产生 consistent gets 的时候决定于  CR block 的生成 ,select count(*) from x$bh where state = 3; 这里的数量的变化代表着  CR block 重构的生成 ,对于oracle来说,若查询到一条记录,发现已经被更改,于是拷贝当前block到新的地方,从回滚段取回before image 再rollback而重构block,这样的block的 state 为3 ,对于block中每一条记录都会去重构一次( 发现被修改,拷贝到新的block(CR),然后row--->ITL  --> transaction table ---> undo record  --->rollback新的blcok(CR)),所以跟一个块中的记录数有关。
  
      但这里要注意,虽然重构了很多CR,但是在我的曾经的测试中发现一次select中一个block的CR block似乎,不超过 3 blocks .也就是说同一个 DBA 的 cache  buffer chain 下的 CR 类型的blocks不超过3,我估计是为了节约内存和降低 该  latch(cache  buffer chain) 上由于搜索所等待的时间的一种策略。因为 CR block一旦产生后就没有用处了(实际上这个数是一个oracle隐藏参数控制的)

 

测试如下

SQL> create table test(a number);
  
Table created.
  
SQL> insert into test select rownum from t where rownum < 1001;
  
1000 rows created.
  
SQL> commit;
  
Commit complete.
  
SQL> select count(*) from t;
  
   COUNT(*)
----------
     154986
  
SQL> update test set a = 0 where a = 1;
  
1 row updated.
  
SQL> update test set a = 0 where a < 100;
  
99 rows updated.
  
SQL>  
  
通过打开不同的sqlplus反复执行下面的语句观察 后面 的 x$bh 查询表的变化
  
SQL>  select * from test where a < 101;
  
100 rows selected.
  
Execution Plan
----------------------------------------------------------
    0      SELECT STATEMENT Optimizer=CHOOSE
    1    0   TABLE ACCESS (FULL) OF 'TEST'
  
Statistics
----------------------------------------------------------
           0  recursive calls
           4  db block gets
         110  consistent gets
           0  physical reads
          52  redo size
        2475  bytes sent via SQL*Net to client
        1091  bytes received via SQL*Net from client
           8  SQL*Net roundtrips to/from client
           0  sorts (memory)
           0  sorts (disk)
         100  rows processed
  
SQL>  
  
SQL> select ts#,file#,dbablk,state,obj from x$bh where state = 3 order by 1,2,3,4;
  
        TS#      FILE#     DBABLK      STATE        OBJ
---------- ---------- ---------- ---------- ----------
          0          1        133          3 4294967294
          0          1        925          3          6
          0          1        930          3          6
          0          1      11579          3         10
          0          1      11579          3         10
          0          1      27273          3         34
          0          1      33837          3          6
          0          1      34264          3          8
          0          1      34264          3          8
          0          1      34264          3          8
          0          1      34264          3          8
  
        TS#      FILE#     DBABLK      STATE        OBJ
---------- ---------- ---------- ---------- ----------
          0          1      34268          3          8
          0          1      34268          3          8
          0          1      34268          3          8
          0          1      34268          3          8
          0          1      34768          3          2
          0          1      34768          3          2
          0          1      34788          3         18
          2          3          3          3      24825
          2          3          3          3      24825
          2          3          3          3      24825
          2          3          3          3      24825
  
        TS#      FILE#     DBABLK      STATE        OBJ
---------- ---------- ---------- ---------- ----------
          2          3          3          3      24825
          2          3        643          3      27155
          2          3        643          3      27155
          2          3        643          3      27155
          2          3        643          3      27155
  
27 rows selected.

 

 

AutoClaw真·一键本地智能体:不依赖Docker、CPU可用、故障自愈 本地智能体(Local Agent)是当前AI工程落地的关键形态,其核心在于将大模型能力与系统级操作深度耦合,实现低延迟、高可控的自动化任务执行。技术原理上,它通过意图解析—技能调度—结果渲染三层解耦架构,分离LLM推理与系统命令调用,显著降低硬件门槛。其技术价值不仅体现为‘一键部署’的便捷性,更在于对环境熵值(如Docker存储/网络/权限冲突)、国产化网络波动、终端硬件碎片化等现实约束的主动收敛。典型应用场景包括个人知识管理、NAS自动化运维、边缘设备(树莓派/Mac M1)上的轻量AI助手,以及企业内 阅读详情

相关推荐

Oracle数据库性能优化实战:从慢SQL定位到整库吞吐翻倍的排查路径

数据库性能优化是后端开发与DBA的核心技能,其本质是理解SQL执行计划、索引机制与实例内存配置的协同原理。当一条SQL出现高逻辑读或全表扫描时,往往意味着索引失效或统计信息过期,进而拖慢整库吞吐。掌握AWR报告分析、执行计划解读与SGA/PGA调优,能显著提升系统响应速度与并发能力。在电商订单查询、分页列表、存储过程批处理等高频场景中,合理的索引设计与SQL改写可带来数量级的性能收益。本文围绕Oracle性能优化,系统梳理从慢SQL定位到实例参数调整的完整排查链路,帮助开发者建立可复用的优化闭环。

weixin_30247781的博客 306

oracle consistent gets,求consistent gets 高的处理方法

下面的sql执行时长在18S+,可consistent gets 确实如此的高,是否正常呢,或者在sql的格式上是否有调整的空间呢,盼指导回复(表product 500W+)select *from (select ttt.*,(productinputnum * 15 + zspicinputnum * 3 +commentinputnum * 2) / 14800 * 60 sjscore,n...

weixin_39522486的博客 360

告别Windows!Oculus Quest 2在Mac M1上的串流实战(scrcpy+SideQuest避坑指南)

本文为Mac M1用户提供了Oculus Quest 2在macOS上实现高清低延迟串流的实战指南。通过使用开源工具scrcpy和SideQuest,绕开官方限制,详细讲解了从环境准备、无线调试到画质与延迟优化的完整步骤,重点解决了Apple Silicon芯片Mac的连接与性能问题,助你告别Windows依赖。

weixin_29224309的博客 309

oracle consistent gets,consistent gets很高,怎样调整?

select dept_no, count(m2d.m_2_d_id) as all_countfrom a_m_plan_day m2d,a_m_plan_series series,a_m_plan_classplanClass,a_m_plan_prj prjwhere m2d.m_plan_prj_id = prj.m_plan_prj_id andprj.m_plan_c...

weixin_36146690的博客 450

Spark入门:从零到能跑的实战教程

Spark 的强大在于它统一了大数据处理的多种场景,从批处理到流处理,从 SQL 到机器学习。对于初学者来说,理解 Spark 的核心理念——内存计算和分布式抽象,是最重要的一步。接着,学会用 PySpark 搭建环境,能读数据、能写 SQL,基本上就入门了。剩下的路,就是通过实战去加深理解。写到这里,相信你对 Spark 已经有了一个比较完整的认识。下一步,不妨自己动手写几个 PySpark 脚本,跑一跑日志数据,或者尝试用 Spark SQL 做一个统计。

Morpheon的博客 1371

【STM32Cube HAL】输入捕获(六)——脉宽测量

1

HAHAHA 4908

Oracle 有关 Consistent gets 的测试

一.Consistentgets 说明   我们使用autotrace 查看执行计划和统计信息时,会显示类似如下信息:     0  recursive calls   :递归调用。一般原因:dictionary cache未命中;动态存储扩展;PL/SQL语句  0  db block gets    :bufer中读取的block数量,用于insert,update,delete,...

Data & Analysis 611

一文吃透 SAP IDoc 状态码:从 TEDS1 到 WE02 排障,再到 ABAP 自动化监控

在 SAP 集成场景里,IDoc 往往是最常见、也最容易被低估的一条生命线:采购订单、发票、主数据、库存移动……只要系统之间要稳定地交换结构化业务数据,IDoc 就经常登场。真正让人头疼的,并不是 IDoc 本身,而是它在链路里到底走到了哪一步、卡在了哪里、该找谁背锅。这篇文章把常用的 IDoc 状态码按出站、入站拆开讲清楚,并且把每个状态对应的真实世界故障现象、排查入口、以及可以落地的 ABAP 监控代码串起来,让你看到状态码就能想到动作。

2007 年 ~ 2025 年,深耕 SAP 技术 18 年 408

Consistent gets

针对以上3个概念进行的说明解释及关系如下: 1、DB Block Gets(当前请求的块数目)当前模式块意思就是在操作中正好提取的块数目,而不是在一致性读的情况下而产生的块数。正常的情况下,一个查询提取的块是在查询开始的那个时间点上存在的数据块,当前块是在这个时刻存在的数据块,而不是在这个时间点之前或者之后的数据块数目。 2、Consistent Gets(数据请求总数在回滚段Buffer中

一名DBA的学习和成长记录 3524

大规模新闻聚合爬虫实战:Python爬取数百万新闻数据的完整指南

本文详细介绍了如何构建一个大规模新闻聚合爬虫,结合Python异步爬虫技术,实现高效、稳定的新闻数据采集。增加NLP模块对新闻内容做自动分类、情感分析。引入机器学习模型检测新闻真实性。使用分布式爬虫框架进一步提升规模。增加多媒体内容抓取与处理。

2201_76125261的博客 1554

我在腾讯上构建了一个人人能用的机载适航知识库

当ChatGPT掀起生成式AI的浪潮时,工程师们发现了一个尴尬的现实:询问“如何编写软件合格审定计划”,AI的回答可能充满似是而非的术语,却无法精确关联FDO-178C的对应内容。现在市面上有许多的AI大模型+适航知识库的方案,之前我的文章介绍了一种本地大模型加知识库的解决方法。此外,ima知识库的容量大小可以到30GB(企鹅大气),只要管理好文件的格式,理论上是完全可以把机载适航相关的内容容纳进去的。后续会不断增加适航法规,适航规章,适航标准,适航书籍,适航相关的论文,以及网上其他一些优秀的内容。

qq_41854911的博客 1224

oracle 整理表碎片

公司数据库10.2.0.1.0  通过命令set autotrace traceonly   explain stat select count(1) from T; 发现consistent gets 读取比表实际行数多10倍,可能是数据库删除太多数据导致。 0 recursive calls 0 db block gets 557965 consis

怀素的专栏 604

倍福--TwinSAFE功能块的使用

在安全模块的程序设计中,输入变量取反,或者把PLC的变量连接到安全的功能块程序中, 操作流程 1.1. 功能块输出取反 例如修改IN,右击属性,然后可在Single-Channel选项中选择是NO还是NC的输入信号。 1.2. PLC标准变量作为安全程序的输入 1.2.1. 建立两个PLC变量 1.2.2. 安全程序区创建变量 1.2.3. 功能块变量链接 首先,PLC变量不能直接连到Estop功能块的输入变量中,否则会报错,但PLC可以连接到SafeAnd这些功能块,然后再转出来,如下所示

weixin_41883890的博客 5313

++++update对consistent gets的影响

update对consistent gets的影响 http://blog.youkuaiyun.com/biti_rainy/article/details/39489

我的Oracle DBA之路 346

大中型超市收银系统(可直接运行)

光步前台收银系统系统功能:商品销售、商品退货、挂单、收银员权限、会员销售、单品取消、整单取消、商品查询、脱机销售、脱机数据上传,基本资料下载,开钱箱、小票打印、收款结算,支持多币种付款方式(现金、储值卡、礼券、微信等),支持多种促销。运行环境:.net 4.0登陆信息用户名:1001 密码:123456内置商品信息,商品编码可输入00001000 - 00010000,测试效果相关功能键F5 结算 F9挂单 F11商品查询 F8退货 Insert单品取消 Del整单取消 F12开钱箱F2 会员 Ctrl+Z退出系统 Home 锁屏 相关源码待公开

Camera2Demo

在Camera2 的基础上进行封装,使得Camera2一堆初始化逻辑与Activity分离,降低耦合度,完成预览拍照并保存的操作

oracle exp consistent,Oracle一致性读(consistents gets)

很多数据库的并发控制方式是通过MVCC(多版本并发控制)实现的。这种方式使得数据库可以通过读取数据块的快照,而不会发生读操作阻塞写操作的情况。Oracle通过undo回滚段实现一致性读取。当一条sql在读取数据块的时候,会记录读取时刻的SCN1,并且将这个SCN1与读取数据块头部ITL槽中的SCN2做比较,如果SCN1先来看一下一致性读的一个例子:drop table ming.t190514 ...

weixin_42468321的博客 320

汉书HE8,好用的汇编代码编写工具

汉书HE8,好用的汇编代码编写工具早期编写汇编代码所用功能强大

对于'Consistent Gets',''Physical Reads'和'DB Block Gets'的理解和解释

db block get s : number of data blocks read in CURRENT mode ie) not in a read consistent fashion, but the current version of the data blocks. 产生db_block_get s的主要方式: 1.DML like Update, D...

EasyPM 244

老版QQ原生表情gif动态

这是老版的QQ表情,不过全是动态的的,Windows照片查看器是不会动的,可以右击用浏览器打开查看,再说一遍是老版的,只是分享给宁愿用老版也要动态的人。

(转)关于 db block gets,consistent gets,physical reads的概念

看到这篇文章,对于这3个概念感觉还是理解不足,转载过来以备研究查看在Oracle的文档中有这样的解释:Recursive Calls: Number of recursive calls generated at both th...

cnytev3277的博客 114

《Oracle逻 辑读写深入分析》之分析逻辑读次数受哪些因素的影响(笔记)[以跟踪文件中的事件来计数consistent gets次数,非用公式计算]

跟踪文件里的一些字符串表示的意思: kdstgr:表示数据块,即表对应的段中除了段头块外的块(存储数据行的)或是索引的对应的段中除了段头块外的块(存储索引条目的)。 Kdusru:  以当前模式读入,以用于更新操作(Read in current mode for Update  ) ·     ktugus:  获取回滚段头(Get Undo Segment header  ) ·

haiross的专栏 2642

db block gets&&consistent gets&&physical reads

db block get s : number of data blocks read in CURRENT mode ie) not in a read consistentfashion, but the current version of the data blocks. 产生db_block_gets的主要方式: 1.DML like Update, Delete will nee

Colin Lau Oracle 836

让我纠结的三个概念--gets

在Oracle的文档中有这样的解释:Recursive Calls: Number of recursive calls generated at both the user and system level. Oracle D...

ciyu1946的博客 247

Oracle索引走歪了?5种伪高效执行路径深度解析

索引扫描(INDEX RANGE SCAN)是关系型数据库加速查询的基础机制,但其实际性能高度依赖优化器对数据分布、谓词选择率和访问路径的准确估算。当统计信息失真、列值倾斜、回表开销过大或绑定变量窥探失效时,即便执行计划显示‘走索引’,也可能引发逻辑读爆炸、物理IO抖动与CPU空转等隐性性能陷阱。本文聚焦Oracle Cost-Based Optimizer(CBO)在真实生产环境中的典型误判场景,结合直方图、覆盖索引、复合索引设计及SQL Plan Baseline等关键技术手段,系统揭示索引被选中却不高

weixin_34160277的博客 200

Oracle数据库高水位线(HWM)原理与五种实战释放方法详解

在数据库管理与性能优化领域,空间管理和查询效率是核心议题。Oracle数据库通过高水位线(HWM)机制来管理段(如表)的空间分配,其原理类似于标记数据块使用过的最高位置。这种设计虽然简化了空间分配,但也带来了潜在的性能问题:即使数据被删除,HWM也不会自动下降,导致全表扫描时仍需读取大量空块,造成不必要的I/O开销和存储浪费,直接影响数据库性能与存储成本。为了解决这一常见的性能瓶颈,DBA和开发者需要掌握有效的HWM释放技术。本文聚焦于表重建、在线表重定义、分区表策略、段空间收缩以及CTAS与索引重建这五种

weixin_30787531的博客 407

Oracle慢SQL优化:六种执行计划获取方法详解

在数据库性能调优中,执行计划是破解SQL运行逻辑的核心线索。Oracle优化器基于统计信息与系统参数生成计划,但同一语句在不同时刻可能产生迥异的执行路径。面对突发的慢SQL,仅靠单一工具往往无法定位根因。结合工程实践,系统详解Oracle常用的六种执行计划获取方法:EXPLAIN PLAN用于快速推演,AUTOTRACE查看真实资源消耗,DISPLAY_CURSOR直接读取共享池计划,10046事件捕获等待事件,V$SQL_PLAN支持批量分析,AWR提供历史回溯。通过对比适用场景、输出要点与常见误区,帮助

weixin_33875839的博客 267

Oracle数据库锁表问题深度解析:从ORA-01013错误到根治方案

在数据库管理与运维领域,锁机制是保障数据一致性的核心技术,但不当的锁竞争会导致严重的性能问题。其原理在于多个事务并发访问同一数据资源时,需要通过锁来实现串行化控制。理解锁的价值在于平衡并发性能与数据一致性,避免业务阻塞。常见的应用场景包括高并发交易系统、批量数据处理和在线事务处理(OLTP)系统。本文聚焦于Oracle数据库中典型的ORA-01013错误,深入探讨其背后的锁表问题,提供从紧急定位、安全解锁到根因分析的完整解决方案,并分享实用的监控脚本与架构防御实践,帮助DBA和开发者有效应对锁表挑战。

WGH100817的博客 524

Oracle体系架构:从内存进程到故障排查的认知地图

数据库的性能与稳定性,往往取决于内存、进程与文件之间如何高效协作。Oracle作为企业级数据库的典型代表,其体系架构中的共享池、缓冲区缓存、日志缓冲区以及各类后台进程,共同构成了一套精密的运行引擎。理解这些组件并非为了背诵名词,而是为了掌握数据从SQL解析到最终落盘的完整流转链路。只有从原理层面看懂内存与进程的分工,才能解释为何大量硬解析会拖慢系统、为何提交后断电不丢数据、为何冷迁移前必须干净关闭实例。在实际运维中,无论是排查告警日志、处理表空间不足,还是优化存储过程的执行效率,都离不开对体系架构的整体认知

weixin_33842304的博客 398
上一篇: v$waitstat 和 save undo segment header /save undo block
下一篇: 如果在shared_pool中keep cursor(sql)
biti_rainy
博客等级 码龄24年 43粉丝 47原创
评论 1
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值