加微信 ora_service

需要解决2个问题: 主要是第二个1.标量子查询改成left join2.instr关联改成等值关联

根据你的描述, 基本能够得出的结论就是, 你的execute immediate 没有使用using , 使用的是下面的写法, 每次执行都需要硬解析, 如果循环次数多, 时间长很多是正常的:execute immediate 'select /*+ tag1 */count(*) from t1 where object_id='||i into v_cnt;如果你使用的是带using(绑定变量写

据我了解, 系统没有记录这个参数的变更历史, 可能要用log_miner根据时间段找一下SYS.OPTSTAT_USER_PREFS$表的dml.

导入后表中某个字段内容发生改变, 只能是业务逻辑上的原因, 看看是不是其他表上有trigger做的这个操作

这种情况一般是索引不存在了, 如果是表不存在了, 除了报错没有其他可选.如果索引不存在了, 相当于一个hint里面的一部分写错, 其他部分还是可以继续生效的, 使用缺一个index() 的 hint, 执行计划是不变,还是生成其他执行计划, 就要看具体情况了.

pg不支持类似mysql 的like操作, 你可以使用命令 psql -c 'show all'|grep wal   或者使用查询  select name,setting from pg_settings where name like '%wal%';

执行计划改变, 肯定是要生成新的游标, 你这个是因为原来的child从内存清除了, 新的又从0开始了. 执行计划不变也可能生成很多子游标,比如insert values语句的执行计划不会变, 但是可能有上千个子游标.  sql有多个游标的根本原因是不能共享了, 不能共享的原因有很多种,执行计划改变只是其中的一种, 具体你可以看看v$sql_shared_cursor

有的远程终端,比如mobaxterm, 确实会有这个问题. 我用securecrt就没有这个问题

你可以把具备这样条件的一支股票数据拉下来存成csv, 给出开始日期, 拉升结束日期, 突破箱体向上的日期, match_recognize对这种需求还是比较容易实现的

楼上的方法是可以的, 把insert 换成 delete 就ok了BEGIN delete from 远端表 where emid=:old.emid and ledt=:old.ledt and period=:old.period;END;

这个会判断ddl类型是modify not null, 才会根据modify的字段进行delete:create or replace trigger ddl_trigger_test001before alter on SCHEMAdeclarev_ddl_sql clob;v_sql_text_piece ora_name_list_t;n pls_integer;v_tabname varc

如果两个字段都有独立的索引, 可以select stat_description,stat_value from mysql.innodb_index_stats where table_name='t' and stat_description in ('A','B');如果字段上没有索引, 那就只能对表的两个字段分别做count(distinct ) 了.

undo表空间内部由多个自动管理的rollback segment组成,  你说的这种情况, 就是有的rollback segment在表空间的很高的高水位上(dba_extents里面可以查, block_id最大对应的rollback segment), 它的存在, 导致你只能回收undb表空间到这个高水位的位置.如果要降低undo表空间大小, 两种方法:1. 新建一个undo表空间new_u

1.如果undo表空间没有设置成自动扩展, 单纯的设置undo_retention是没有意义的;2.如果undo表空间设置了自动扩展,  也无法保证设置的这个时间, 因为可能自动扩展的空间也没有了(表空间达到最大,文件系统满等情况)3.如果要确保设置的undo_retntion生效, 需要undo表空间自动扩展, 同时还要ALTER TABLESPACE undotbs RETENTION GUA

select 1;

3个建议:1.开启并行2.如果是分区表, 建议开启增量收集3.如果不是分区表, 降低采样比例

采纳上面的答案, 这是想否定今天的"每日一题"吗?

不用远大于, 等于所有表的段大小之和已经是最低要求了.  两个亿级记录的大表关联, 如果是OLTP业务, 返回几条记录, 正常的逻辑读也就10多个.  下面这个例子, 逻辑读只有21, 执行时间接近21小时还没跑完.  这个判断标准, 一两句还真说不清, 多学习一些优化原理就明白了.  

这个软件可以了解一下: https://www.tosska.cn/tosska-sql-tuning-expert-tse-oracle-free-download-zh/ 复杂SQL, 还是得靠人.

原SQL将righ join改成inner join是没问题的, 因为这个right join本身就是一个inner join的逻辑,  但是为什么优化器没有使用正确的执行计划, 根据现有的信息, 还是看不出来.  

执行计划使用的是filter, 你这个where 条件像是子查询里面的. 这种问题最好是能把完整的sql_text给出来.

这个要看for update后面有没有其他关键字:  如果没有其他关键字, 就会一直等待;  如果使用了wait n, 等待n秒后报错(resource busy);  如果使用了skip locked,会跳过被锁的记录

下面这些top SQL,都有很大的优化空间. 执行时间几千秒的SQL, 有点不可思议.

在create table时,如果你的not null约束不是直接写在字段后面, 而是通过check或constraint子句增加的, 通过sqlplus都不会显示; plsql developer能显示使用check增加的not null , 但是不会显示通过constraint增加的not null.CREATE TABLE T_check( "ID" NUMBER,             

如果是append方式插入, 就会申请新空间; 如果是传统方式(conventional)插入, 就会使用当前释放的100G空间.

原厂谁在处理啊? 能不能让他联系下我, 或许我能给他一点线索. 

这种功能性问题, 测试一下就知道了. 记得我之前回答过相同的问题. 这里又有人问了两次, 还采纳了错误的回答, 我就贴一下我的测试结果:

用awrddrpt生成比较报告. 应该是D

故障现象看上去像是解析过多导致的, 系统首先需要解决的是解析的问题. 其次SQL性能差也是长期存在的问题, 两个都是慢性病,都是需要解决的问题.

如果这是故障时段的awr, 那需要比较一下正常时段的AWR,找到故障点;  如果这个awr就是正常的awr, 那么这个系统的性能问题很严重, 需要做一次大的优化了, 不是参数优化, 主要是SQL优化. 

8小时范围, 有2个索引对象的Segments by ITL Waits占比较多, 超过了10%. 这是后台解析awr使用了一些审核规则. 其实等待的总数量很少,一共才130多次, 可以忽略不计.  如果数量很大, 那可能就要调整这些索引的initran参数了. 当然, 这是dba的优化方法, 可能从业务角度去优化,效果会更好.

硬件配置高, SQL执行效率低, SQL优化能解决问题.

每秒500M的吞吐量, 说明磁盘可能是普通磁盘, 不是SSD. 做个SQL优化, 磁盘的压力减少了, 各种等待事件自然就减少了.很多dba看到direct path read的第一反应就是改隐含参数, 能减轻磁盘压力, 但SQL性能问题的根源还是没有解决.

mos Doc ID 2898530.1 说要打Patch 32700548 .  是刚升级的吗? 是执行这个SQL就会报错吗?

free 命令看到的free少, 不一定是问题. 用vmstat 看看si/so , 如果这两个值大, 那就说明真的不够了.  数据库是否需要优化, 一般用AWR来分析, awr里面也能反映出os是否需要调整.

oracle 后台进程每秒对v$session 做快照, 把状态是ACTIVE的记录临时存放到v$active_session_history;每隔10秒的v$active_session_history记录会保存到dba_hist_active_sess_history (AWR)如果你的SQL执行时间超过10秒, 应该会出现在dba_hist_active_sess_history(超过awr

没有使用ssd盘, log file sync 这个速度也是正常;  log file sync 会影响enq:  TM  -  contention, 但是平均等待10毫秒, 不会导致enq:  TM  -  contention 平均等待185毫秒;主要矛盾应该还是行锁相关语句: 有些update 语句从发起到commit的这个过程比较长, 其他session的update 在等行锁(enq:

索引最大高度是24.  组合索引最大column 数量是32

楼上回答的第一句话是错误的. explain plan for不是用来查看已经执行过的SQL的执行计划,而是用来预估SQL的执行计划,SQL并没有执行.已经执行过的SQL, 如果还在内存, 可以用select * from table(dbms_xplan.display_cursor())命令查看;  如果保存到了awr,可以用select * from table(dbms_xplan.dis

有人说优化最难,这个难就难在优化不像ora-xxxxx和其他报错信息那样可以百谷Mos. 其实掌握了基本原理,优化是很轻松的事. 为客户解决性能问题,更是一件愉快的,有成就感的事.

oracle的优化器会根据不同的数据分布, 生成对应的执行计划, 不需要改写:   场景1的执行计划应该是b去重后Nested loops a;  场景2的执行计划应该是a Nested Loops b; 场景3的执行计划应该是hash join (semi), 还会根据具体的数据分布情况, 再做细分(b表id字段的重复度,a表的字段个数等)

AD

从10g 开始, 默认表空间是users, 之前版本是system, 这个题目出的不够严谨

BD 

如果有default 分区，就不能add partition。 如果要add ， 就要先drop default ； 如果default 有数据， 一般建议使用split partition来实现新增分区的功能。

用两次row_number，分别partition by一个字段和两个字段

EF