ITPub博客

7.tidb缓存7.1虽然结果都是从tikv中读出，但是执行计划中使用了表连接、hash join、子查询，做不到从某个tikv中得到数据，可能散落在多个tikv中。从多个tikv中汇聚到tidb server的缓存中，汇聚成2个表，然后两表再做连接。7.2事务（比如要改3g的数据）要先放缓存中，然后提交。 7.3线程池需要缓存。 7.4解析、编译中用到的元数据也放在tidb

4.sql语句的执行 解析好的执行计划给到excutor，excutor去执行 执行计划。复杂：范围查询、join、子查询、表连接、嵌套查询等等，走distsql模块，将对tikv复杂的请求封装起来，提供一个简单的方法。最终呈现：转化成多个对单表的范围查询。 简单（点查）：根据主键索引、唯一索引进行等值查询，查一行或零行的这种，走KV模块。  点查（KV）和

1.处理客户端的连接protocol layer 2.sql语句的解析和编译语句解析和编译（parse、compile）解析 编译 前面语法解析完生成的ast语法树传给compile验证（preprocess）：合法性验证，表是否在数据库中存在等等逻辑优化：不需要的列消除（类似去重distinct）、外连接变内连接、等等物理优化：根据前面的结果，结合统计信息，去看走全

1.protocol layer（处理客户端的连接）parse、compile（sql的解析和编译，生成执行计划）主要负责sql语句的解析和编译（可以理解为优化），生成语句的执行计划给excutor执行2.excutor（拿着执行计划到tikv节点上执行）distsql（索引扫描查由这个负责）kv（点查，根据索引之类的，直接从kv里找）sql语句的执行执行计划给excutor来执行、distsql

主库：查看闪回功能是否开启select flashback_on from v$database;创建闪回空间路径mkdir -p /oracle/fast查询归档一天的产生量，根据割接的时长，配置对应的闪回区大小。select to_char(completion_time,'yyyy-mm-dd') as date1,count(0) a

手工打补丁错误汇总1.rootcrs.pl -prepatch execution failed2.OPatch failed with error code 733.OUI-67073错误一(rootcrs.pl -prepatch execution failed)在跑二步骤的2节点命令时，若出现下图错误，建议手动关集群之后重新再跑一遍命令。手动关集群方法root:<grid_home&

跟踪会话的级别Level 1：跟踪SQL语句，等于sql_trace=trueLevel 4：包括变量的详细信息Level 8：包括等待事件Level 12：包括绑定变量与等待事件16  在11g中为每一次执行生成STAT信息，仅在11.1之后可用32  比level 1少执行计划64  和level 1 相比 在第一次执行后还可能生成执行计划信息 ； 条件是某个游标

介绍：作为官方的rac监控，oswatch有着至关重要的作用，可以协助dba进行详细排查。在系统卡顿、网络异常等情况下，外部通过网络的监控检测不到内部情况，而oswatch很好的解决了这个问题，因为它是布置在服务器上的，并且性能消耗极低。下载：mos ID 301137.1OSwatch安装:1、创建osw空间 在RAC集群两个节点上分别建立Oswatch目录/osw，大小为5

概念：大意就是，通过dblink连接另一个数据库的表是，对另一个数据库的表进行dml操作，同时也可能在同一个事务中对本库中的本地表做事务提交操作，那么对于dblink的表，需要确保远端的数据库也要提交，那么在本地像远端确认提交的时候，先由本地库发一个prepare的确认信息，远端回复prepare了以后，本地在执行commit信息；此种情况就是在本地执行commit以后，此时远端库还没有完全com

1.全表扫描TABLE ACCESS FULL多块读优化方式：前面带*，有谓词。访问的列少的话，存在多个谓词过滤条件（where），创建组合索引，选择性高的放前面，顺序排放2.rowid查询使用rowid获取数据，单块读，性能最好TABLE ACCESS BY USER ROWID 产生原因：对rowid进行等值查询where rowid='xxxxxxxxxxxx'优化

背景XX银行一套业务系统反馈晚上跑批非常慢，后来客户发现是在处理truncate分区表分区的时候慢。数据库版本 12.1.0.2操作系统类型 linux初步分析truncate的实质是在不修改数据块的情况下，通过修改segment header的data_object_id,hwm,extent map，aux map等信息来实现清空表的目的，其中还涉及数据字典基表以及L1、L2位图块的修改，所以

误操作truncate oracle bbed 修复

处理方式：如果是drop的可以在回收站中找查看回收站是否开启SHOW PARAMETER RECYCLEBIN;value是on为开着关闭回收站（只是记录，非操作流程）SQL> ALTER SYSTEM SET RECYCLEBIN=OFF; System altered. SQL> ALTER SESSION SET RECYCLEBIN=OFF; Se

监听：scan 监听：LISTENER=(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=IPC)(KEY=LISTENER))))            # line added by Agent

故障描述2021年8月30日9点15分客户反映统一号源库卡顿，楼下自助挂号机异常等待，经查证为his的故障，his库内存满载，导致其他库到his库的dblink查询出现故障。大页的概念内存都是以页的形式划分的，默认情况下每页是4K，这就意味着如果物理内存很大，则映射表的条目将会非常多，会影响CPU的检索效率。因为内存大小是固定的，为了减少映射表的条目，可采取的办法只有增加页的尺寸。这种增大的内存页

一、背景概述XX客户生产数据库2021年1月22日上午排查故障，客户提供高峰期卡顿时间发生在月结。由于报告保存时间为7天，无法查找到月初的报告，通过增加业务模拟环境，经过仔细诊断，发现业务产生时间段操作系统整体资源使用率较低，数据库latch争用较为严重。二、问题分析 Latch Activity(门闩活动) Latch Miss Sources(latch丢失源) 

建控制文件报错ORA-01189 ORA-011101 跳过有问题的数据文件重建控制文件或只用system01.dbf重建；跳过就是建控制文件的语句里少写那个报错的数据文件，建好后offlinealter database open RESETLOGS;alter database datafile 7 offline;select file_name,tablespace_name,file_i

如果考到一半，缺了部分数据文件方法：重新考失败的数据文件，如下图，缺少了1、2、5数据文件备库执行。如果是缺数据文件连接rman target sys/oracle@blj auxiliary sys/oracle@bljdg拷 1，2，5号数据文件，后面的format是指定备库恢复出来的位置和名字。backup as copy reuse datafile 1 auxiliary format

1.下载jdkhttps://www.oracle.com/java/technologies/javase-java-archive-javase6-downloads.html#jdk-6u45-oth-JPR下载jdk-6u45-linux-x64.bin2.配置防火墙和SELINUXRedhat7操作系统配置防火墙，开放应用端口，例如7001；# firewall-cmd --perman

介绍该PASSWORD_VERSIONS列显示该帐户存在的密码版本的列表。10G指的是较早的不区分大小写的Oracle密码版本，11G指的是基于SHA-1的密码版本，并12C指的是基于SHA-2的SHA-512密码版本。10g密码不区分大小写，11及以上区分根据用户名+密码转换的隐式密钥select 'alter user ' ||&nbsp