oracle数据库原理相关

1、ps -ef|grep smon 名字就是实例名称
oracle数据库的构成是 后台进程，加内存分配加数据文件
2、oracle内存结构
sga（系统全局区） 主要oracle的工作区包含：
数据库缓冲缓存 
从磁盘读取出来的数据缓存内存到sga的缓冲缓存区data  buffer
日志缓冲区 
共享池  所有的人都能看到的东西，也是一些数据
有可能包含的内存结构也可以不初始化 大池 java池 流池
pga （用户全局区）每个用户会单独的分一段内存

1、用户发起一个sql
服务器  由监听接收请求 创建一个服务器进程 ps -ef|grep oracle 类似于这种
服务器进程首先扫描内存的数据缓冲区
扫描结果存在 相关行发送到pga 返回给用户
扫描结果不存在 从磁盘获取相关行 复制到缓冲区 相关行发送到pga 返回给用户


dml语句操作 用户发一条dml语句服务进程依然先去扫描缓冲区 如果缓冲命中 直接更新 数据变脏 如果没有命中 
由服务器进程将对应的数据块先从磁盘复制到缓冲区内，在进行更新操作

脏缓冲区 如果缓冲区存储的块和磁盘不一致，该缓冲区就叫做脏缓冲区，脏缓冲区最终会由数据库写入器（DBwn）写入到磁盘中去
DBWn 是数据写入器n代表数字 是一个oracle的一个后台进程  作用是将变脏的缓冲区从数据库缓冲区写入到磁盘中的数据文件
什么情况下写入 采用极懒算法
没有任何数据缓冲区的时候， 脏缓冲区过多 三秒超时 遇到检查点  checkponl 检查点是一个oracle时间遇到检查点就会写入
日志缓冲区
类似于mysql的redo 
ps -ef |grep lg
日志写入器 （LGWR）就是把日志缓冲区的内容写入到redo文件中，三种情况会写入 1、语句提交（commit）的时候，不提交其他用户访问不到
2、 日志缓冲区的占用率达到1/3
3、DBWn要写入脏缓冲区前
共享池share pool 是最复杂的结构  其中包括
1 库缓存 库缓存 着块区域，会按照已经分析的格式缓存最近执行的代码，这样sql多次执行的时候不需要重复的进行代码分析
，可以很大程度提高系统性能
2 数据字典缓存 存储oracle中的对线定义（表，视图，用意词，索引等数据对象）这样在分析sql代码的时候，就不用频繁的去磁盘读取数据字典了
3  pl/sql区 缓存存储过程，函数，触发器等数据库对象，这些对线都存储在数据字典中 通过将其缓存到内存中，可以在重复调用的时候提高性能
大池  large  pool
是一个可选的内存区域 如果数据库采用了共享服务器连接模式则要用到大池 RMAN（oracle的高级备份恢复工具）备份数据库也需要大池
java池 javapool
流池
从重做日志redo中提取变更记录的进程和应用变更记录的进程会用到流池
索引

堆表（Heap Table）和索引组织表（Index Organized Table，简称IOT）是两种不同的数据表存储结构。堆表的数据行在堆中存储，没有特定顺序，
而索引组织表的数据按照主键顺序存储在一个B+树索引中。
堆表的数据行在堆中存储，没有任何特定顺序。插入新数据时，总是追加到堆表文件的最后一页。由于不需要考虑排序，插入速度较快。然而，查找符合某个条件的记录时，
需要读取全部记录进行筛选，这时索引的作用就显现出来。
索引是针对少量特定字段进行排序存储，存储索引键以及数据行在堆表上的绝对位置（页号，页内偏移）。
通过索引可以快速查询到具体记录位置，然后再从表中读取该记录。
索引组织表
索引组织表的数据按照主键顺序存储在一个B+树索引中，索引即数据，数据即索引。使用主键查询时，不需要再访问表，可以直接从索引中获取全部数据。这种结构节约了磁盘空间，降低了IO，提高了查询性能。
然而，当索引组织表上有二级索引，并且频繁使用二级索引进行访问时，二级索引需要回表，效率较低。此外，索引组织表在插入和更新数据时，由于需要排序，速度较慢。

依托于几个进程
抽取源端的日志，再到目标端的应用来完成数据同步
管理进程mgr 监控ogg进程  以及提高端口 清理trail文件（抽取完的数据生成的一个文件）
源端进程
extract 抽取进程，负责捕获数据，并生成trail文件
datapump 投递进程 读取trail文件并将数据投递到目标端
目标端
replicat 应用进程 应用接收的tail文件到数据库

ogg参数文件  /ogg/dirprm

def  文件  /ogg/dirdef  存储元数据（异构数据库会使用比如oracle----mysql）

定义文件的命令
./defgen paramfile 参数文件/参数文件的路径

ogg报错日志
1进程日志 /ogg/dirrpt/进程名.rpt
2ogg错误日志 /ogg/ggserr.log


注意点

1ogg在重新初始化的时候，注意大事务，需要在没有大事务的时候进行初始化。
2ogg同步表，要具有主键或者唯一约束，否则还是可能会造成数据不一致
3ogg目标端，需要根据情况，去禁用涉及用户的外键约束和触发器

1. 数据库基本信息
监控项：DB Name、Instance Name、快照时间范围（Snap Id/Start Time/End Time）、数据库版本、主机配置（CPU 核心数、内存）
2. 关键性能指标（KPI）汇总
监控项：
DB Time（数据库总工作时间）：反映系统负载，若显著高于 Elapsed Time（物理时间），说明系统繁忙
CPU Usage（CPU 使用率）：按 “用户态（User%）、系统态（Sys%）、空闲（Idle%）” 拆分
Wait Time 占比：等待时间 /(DB Time+Wait Time)，超过 50% 说明系统存在严重等待瓶颈
Redo Size（ redo 日志生成量）：反映事务繁忙程度，突发增长可能是批量操作或异常 SQL
等待事件分析（定位系统瓶颈核心）
AWR 报告中 “Top 5 Timed Events” 是核心中的核心，需重点关注非空闲等待事件（排除 Idle 类），按影响优先级排序：
1. I/O 相关等待（最常见）
关键事件：
db file sequential read：单块 I/O（索引扫描、表访问 by rowid），平均等待时间 > 20ms 需优化
db file scattered read：多块 I/O（全表扫描），等待时间长可能是 SQL 未走索引或表太大
direct path read/write：直接路径 I/O（批量操作、备份恢复），突发增长需排查是否有异常批量任务
解读：I/O 等待高说明存储性能不足或 SQL 读取数据量过大
优化方向：SQL 调优（避免全表扫描）、索引优化、存储扩容 / 缓存优化、分区表拆分
2. 锁等待（并发冲突）
关键事件：
enqueue：队列锁（如 TX 锁：事务冲突，TM 锁：表级锁），需结合 “Enqueue Activity” 查看锁类型
library cache pin/library cache lock：共享池锁（SQL 解析冲突、PL/SQL 编译冲突）
row lock contention：行级锁冲突（多事务更新同一行数据）
解读：锁等待高说明并发控制不合理，存在事务阻塞
优化方向：缩短事务时长、避免长事务占用锁资源、优化 SQL 执行效率、调整隔离级别
关键词：enqueue、TX 锁、行锁冲突、阻塞
3. 内存相关等待（内存不足）
关键事件：
log buffer space：redo 日志缓冲区不足（事务提交频繁，日志写入磁盘慢）
shared pool latch：共享池闩锁（SQL 解析过度、软解析率低）
buffer busy waits：数据缓冲区争用（多个会话同时访问同一数据块）
解读：内存等待高说明 SGA（共享池、缓冲区缓存、redo 缓冲区）配置不合理
优化方向：调整 SGA 参数（如 SHARED_POOL_SIZE、DB_CACHE_SIZE、LOG_BUFFER）、开启绑定变量（提高软解析率）、优化热点数据访问

1. 确认基础信息
提问业务 / 用户：
是所有用户慢，还是特定用户 / 地区慢？（判断是否为网络 / 权限问题）
是所有功能慢，还是特定模块（如查询、提交订单）慢？（定位应用模块）
什么时候开始慢的？（是否和版本发布、数据量增长、批量任务相关）
关键词：范围（全量 / 特定）、模块、时间节点
2. 基础环境排查（排除底层硬件 / 网络问题）
网络排查：
工具：ping（延迟）、traceroute/mtr（路由跳转）、curl -w（接口响应时间）
指标：网络延迟 > 50ms、丢包率 > 1% 需警惕；跨区域访问慢优先查 CDN / 专线
服务器硬件排查：
CPU：top/htop（Linux）、任务管理器（Windows），使用率持续 > 80% 可能过载
内存：free -m（Linux）、资源监视器（Windows），可用内存 < 10% 可能导致 Swap 频繁
磁盘：iostat -x（Linux）、perfmon（Windows），磁盘 IO 利用率 > 90%、avgqu-sz>2 需优化
关键词：网络延迟、CPU 使用率、内存不足、磁盘 IO 过载
二、第二步：分层深入分析（按优先级排序）
（一）应用层分析（最常见慢因：代码 / 配置 / 线程问题）
应用层是系统慢的核心来源（如代码低效、线程阻塞、配置不合理），需结合日志和监控工具：
1. 应用日志分析
关键日志：
访问日志（Nginx/Apache）：筛选响应时间 > 3s 的请求（如$request_time），统计慢请求的 URL、请求方式、客户端 IP
应用日志（Java：Logback/Log4j，Python：logging）：查看 ERROR/WARN 日志（如数据库连接超时、第三方接口调用失败）、业务日志（如关键流程耗时打印）
工具：ELK（Elasticsearch+Logstash+Kibana）、Graylog（日志聚合分析）
关键词：慢请求 URL、超时日志、异常堆栈
2. 应用性能监控（APM 工具）
工具：SkyWalking、Pinpoint、New Relic、Spring Boot Admin（Java）
监控重点：
接口响应时间：拆分 “请求接收→业务处理→数据库调用→响应返回” 各阶段耗时
线程状态：是否有大量线程阻塞（BLOCKED）、等待（WAITING），排查死锁（如 Java 用 jstack 导出线程栈）
资源池状态：数据库连接池（是否耗尽）、线程池（核心线程数 / 队列大小是否合理）
典型问题：
线程池参数不合理（核心线程数过少，队列满导致任务排队）
死锁（多线程竞争资源顺序不一致）
同步锁过度使用（如 synchronized 修饰非必要方法，导致并发阻塞）
优化方向：
优化代码逻辑（如减少循环嵌套、避免重复计算）
调整线程池 / 连接池参数（如 HikariCP 的 maximum-pool-size）
解除死锁（调整锁竞争顺序）
异步化处理（如将非核心流程（日志记录、通知）改为异步线程执行）
关键词：APM、线程阻塞、连接池耗尽、异步化