OceanBase (DBA)一面面经

1. Oracle高可用和ob高可用,和他们的实现方式?

2.ob的三副本了解吗,ob的三副本怎么保障强一致的?

3.三副本能实现强一致吗?

4.了解ob的数据协调协议吗?说说原理

5.聊聊Oracle,讲一些SQL调优的实际案例?

6.刚才聊到了分区表的分区裁剪,假如不调整谓词条件的情况下,有什么方法也能加速SQL?

7.并行了解吗,说一下并行的机制,怎么使用的?

8.为什么生产环境不推荐使用并行?主要对哪些资源有压力

9.redo是用来做什么的?Oracle select会写redo吗?

10.Oracle写入数据,讲一下数据落盘的过程。

11.RAC集群数据落盘的过程。

12.假如两个节点的RAC,比如一节点写了1,二节点会有什么操作?操作的顺序了解吗

13.介绍一下实习经历

14.OB三个节点如果宕机一个影响使用吗?宕机的过程中会有什么样的表现?

15.只有三个机器,一台宕机了,unit能迁移走吗?

16.现在正在往集群里面写入数据,宕机了一台,在业务端看来会有什么样的表现?



答案

1.Oracle高可用和ob高可用,和他们的实现方式?


 

数据库高可用方案实现原理
OracleRAC多节点共享存储,通过Cache Fusion同步内存数据。故障时秒级切换,应用透明。
OceanBase分布式Paxos协议数据分片(Partition)+三副本,基于Paxos协议实现多副本强一致,无共享架构。

2.ob的三副本了解吗,ob的三副本怎么保障强一致的?

每个数据分片(Partition)包含3个副本(Leader/Follower/Follower)。

写入流程:

强一致保证:仅当多数副本(≥2)持久化日志后,才向客户端返回成功。

3.三副本能实现强一致吗?

能,通过Paxos协议约束: 任何写入需多数副本确认(如3副本需≥2个确认)。网络分区时,少数派副本自动拒绝写入,避免脑裂。

4.了解ob的数据协调协议吗?说说原理

Multi-Paxos优化:

  • Leader选举: 通过Paxos协议选举唯一Leader处理写入。

  • 日志复制:Leader生成Redo日志并广播给Followers。

  • Followers持久化日志后返回ACK。

  • 收到多数ACK后,Leader提交并应用日志。

  • 日志回放: 所有副本按相同顺序应用日志,保障状态机一致性。

5.聊聊Oracle,讲一些SQL调优的实际案例?

SELECT * FROM sales WHERE TO_CHAR(sale_date,'YYYY-MM') = '2023-10'; -- 函数导致裁剪失效

优化:

SELECT * FROM sales WHERE sale_date BETWEEN DATE'2023-10-01' AND DATE'2023-10-31'; -- 直接范围查询

6.刚才聊到了分区表的分区裁剪,假如不调整谓词条件的情况下,有什么方法也能优化SQL?

  • 全局索引: 避免分区键限制。

  • 本地索引分区: 每个分区独立索引,加速扫描。

  • 统计信息更新: DBMS_STATS.GATHER_TABLE_STATS确保优化器准确选择分区。

  • SQL Profile: 使用SQL Tuning Advisor固定高效执行计划。

7.并行了解吗,说一下并行的机制,怎么使用的?

启用并行:

ALTER SESSION ENABLE PARALLEL DML;
SELECT /*+ PARALLEL(emp, 4) */ * FROM emp; -- 强制4个并行进程

资源控制:

PARALLEL_DEGREE_POLICY: 控制并行度策略(AUTO/MANUAL)。
PARALLEL_SERVERS_TARGET: 限制并行服务器数。

8.生产环境不推荐并行的原因

  • CPU: 并行进程争抢CPU,导致系统负载飙升。

  • I/O: 大量并行扫描引发存储吞吐瓶颈。

主要原因是CPU和IO,内存方面不是主要原因。

  • 内存: 每个并行进程消耗PGA内存,可能触发ORA-4030。

  • 锁竞争: 并行DML加剧锁冲突(如TX锁)。

9.redo是用来做什么的?Oracle select会写redo吗?

核心功能: 记录所有数据变更(DML/DDL),用于故障恢复。

SELECT语句不会直接生成redo日志,因为它们不修改数据库内容。但在维护读一致性、使用直接路径读取、执行递归SQL以及触发PL/SQL函数或数据库触发器时,可能会间接产生redo日志。

具体原因参考文章: select会写redo吗

10.Oracle写入数据,讲一下数据落盘的过程。

  1. 用户提交DML。

  2. 日志写入Log Buffer。

  3. LGWR将Log Buffer刷新到Redo Log文件(优先保证日志落盘)。

  4. DBWR将脏块从Buffer Cache写入数据文件(异步进行)。

11.RAC集群数据落盘的过程。

阶段关键组件工作流程设计目标设计目标设计目标
1. 数据块传递Cache Fusion1. 节点A修改数据块时,通过私网(Interconnect)将块副本传输给请求节点B2. GCS 跟踪块状态(CR/XD 模式)3. 块在内存间直接传递,避免磁盘 I/O减少共享存储访问提升并发性能
2. Redo 日志落盘ASM 存储1. 每个节点独立写入本地 Redo 日志线程2. 日志写入共享存储(ASM 磁盘组)3. 提交时强制刷盘(Commit = Log Written)确保事务持久性节点故障时恢复
3. 脏块写入DBWR 进程1. GCS 协调脏块刷盘顺序2. 持有最新版本的节点执行写盘3. 写入共享数据文件(ASM)保证数据一致性减少写冲突
4. 全局一致性GCS + GES1. GES 管理全局锁(如 TX 锁)2. GCS 协调块访问权3. 通过块版本号解决冲突跨节点读一致性 写操作串行化

12.假如两个节点的RAC,比如一节点写了1,二节点会有什么操作?操作的顺序了解吗


 

场景:节点1写入数据块A(值为1)

  1. 节点1持有A的Exclusive锁。

  2. 节点2请求修改A:

  3. 通过GCS向节点1请求块副本。

  4. 节点1将A的当前版本+锁信息传递给节点2。

  5. 节点2在本地缓存中修改A,生成Redo日志并落盘。

  6. 节点2通过GCS广播块变更信息。

13.介绍一下实习经历

省略

14.OB三个节点如果宕机一个影响使用吗?宕机的过程中会有什么样的表现?


 

  • 宕机一个节点:

无影响: 剩余2节点满足多数派(2/3),服务正常。

Leader切换: 宕机节点若含Leader副本,5秒内自动选举新Leader。

  • 宕机过程表现:

客户端连接该节点的会话断开(需重试)。 其他节点短暂写入延迟(Paxos重新协商)。

1.如果是三个单zone单observer是一份数据。如果某OBServer挂掉了,且超过 server_permanent_offline_time时间限制会永久下线,需要把这个单zone单observer下掉。重新部署上去。

2.如果是三个单zone多observer,且primary_zone 为 RANDOM 时,ob数据是以分布式存储的(以分区形式来的,按分区的粒度自动均衡到不同的OBServer节点,打散数据)

15.只有三个机器,一台宕机了,unit能迁移走吗?


 

  • 当某个OBServer节点挂掉时:

多副本机制:ob通常会在不同的OBServer上存储数据的多个副本(通常是3个副本)。这意味着即使一个节点失败,其他节点上仍然有数据的副本。

数据同步:在节点恢复后,ob会自动同步该节点上的数据,确保所有节点上的数据副本保持一致。

在官网论坛上找到的,所以结论应该是没有迁移走。。

16.现在正在往集群里面写入数据,宕机了一台,在业务端看来会有什么样的表现?


 

  • 客户端视角:

短时报错(如Connection reset),持续约1-5秒。

自动恢复: OBProxy 自动重试请求到新Leader。

  • 数据一致性:

已提交的数据不丢失(多数副本已持久化)。

未提交的事务自动回滚。

### OceanBase DBA 试常见问题及答案 #### 一、OceanBase 数据库基础 1. **OceanBase 的架构特点是什么?** OceanBase 是一个分布式关系型数据库,其核心架构包括 Paxos 协议实现的高可用性[^1]。它采用多副本机制,确保数据在多个节点间同步,从而提升系统的容错能力。此外,OceanBase 支持水平扩展,能够动态增加或减少节点以满足业务需求。 2. **OceanBase 中如何实现事务一致性?** OceanBase 使用两阶段提交协议(2PC)和 Paxos 协议来保证分布式事务的一致性[^2]。通过将事务日志复制到多个副本,并确保主副本与从副本之间的数据同步,OceanBase 能够在节点故障时恢复未完成的事务。 3. **OceanBase 的分区表设计原则是什么?** 分区表设计应考虑数据分布的均匀性和查询性能。通常使用 HASH 或 RANGE 分区方式,确保热点数据不会集中在单个分区或节点上[^3]。合理的分区策略可以显著提升查询效率并降低系统负载。 #### 二、性能优化与调优 1. **如何分析 OceanBase 的慢查询?** 慢查询可以通过 `gv$plan_cache_plan_stat` 和 `gv$sql_audit` 系统视图进行分析[^4]。重点关注 SQL 执行计划、扫描行数、I/O 开销等指标,结合 EXPLAIN 命令进一步定位瓶颈。 2. **OceanBase 的索引类型有哪些?** OceanBase 支持 B+ 树索引和全局/局部索引[^5]。B+ 树索引适用于范围查询和精确匹配场景,而全局索引跨所有分区存储,适合频繁跨分区查询的场景。 3. **OceanBase 的内存管理机制是怎样的?** OceanBase 使用内存池化技术管理资源,主要包括共享内存(Shared Memory)、用户态线程切换(User-level Thread Switching)以及动态调整的内存分配策略[^6]。合理配置 `memory_limit` 参数可以避免 OOM(Out of Memory)问题。 #### 三、运维与管理 1. **OceanBase 的备份与恢复机制是什么?** OceanBase 提供了基于 CLOG(Commit Log)的增量备份功能[^7]。通过定期生成快照并记录增量日志,可以在灾难发生时快速恢复到指定时间点。 2. **如何监控 OceanBase 的运行状态?** OceanBase 提供了丰富的监控指标,可通过 Prometheus 和 Grafana 实现可视化展示[^8]。关键指标包括 CPU 使用率、磁盘 I/O、网络延迟、SQL 执行耗时等。 3. **OceanBase 的升级流程是怎样的?** OceanBase 支持滚动升级(Rolling Upgrade),允许在不停机的情况下逐步更新集群版本[^9]。升级前需确保数据一致性检查通过,并备份重要数据以防万一。 #### 四、高级特性与应用 1. **OceanBase 的分片键选择原则是什么?** 分片键的选择直接影响数据分布和查询性能。通常建议选择高频访问且分布均匀的字段作为分片键[^10],例如用户 ID 或订单号。 2. **OceanBase 如何支持多租户模式?** OceanBase 通过资源隔离和权限控制实现多租户支持[^11]。每个租户拥有独立的计算资源和存储配额,确保不同业务之间的互不干扰。 3. **OceanBase 的高可用方案有哪些?** OceanBase 的高可用性主要依赖于 Paxos 协议和多副本机制[^12]。通过设置主备副本数量和仲裁策略,可以有效应对单点故障或区域性灾难。 ```python # 示例代码:创建分区表 CREATE TABLE sales ( order_id BIGINT NOT NULL, customer_id BIGINT NOT NULL, amount DECIMAL(10, 2), order_date DATE, PRIMARY KEY (order_id, customer_id) ) PARTITION BY HASH(customer_id) PARTITIONS 16; ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值