Oracle 解析
1、union \ union all \ Intersect \ Minus内部处理机制（优化）
当查询语句中的where子句中使用到or时，可以用union all来代替。因为使用or查询语句的时候，引起全表扫描，并走索引查询
特别：当对方表中没有灭有我方表中的字段时，需要将我方表中的字段放空
# 用union all替代union
Union因为要进行去除重复值的处理，所以效率要低
适用场合：1-如果合并两个select结果集，没有刻意要去除重复行
2-如果union的各个select结果集，不存在交集
# Oracle的内部处理过程：
union操作：先执行union all操作获取所有数据合集，再执行去除重复行操作。所以如果没有重复的，不要用union，效率低
# 总结：对两个结果集的union，union all，intersect，minus操作耗时：
Union all：3ms
# 1.两个结果集的全表扫描获取2.获取所有展现数据
Union：6ms
# 1.两个结果集的全表扫描获取2.去除重复操作3.获取所有展现数据
Intersect：7ms
# 1.两个结果集的全表扫描获取2.两个结果集的唯一性排序3.获取交集4.获取所有展现数据
Minus：7ms
# 1. 两个结果集的全表扫描获取2.两个结果集的唯一性排序3.获取差集4.获取所有展现数据Intersect和minus的获取交集和差集如执行计划图，没有耗费时间，这个内部机制没有研究，不过由于之前是唯一性排序，所以即使耗时也很少，就当做不耗时了
2、SQL的执行过程
-
select
select a from table where b = ''/ order by a-
第一步：首先会计算出一个Hash值，判断当前hash值在数据库中是否存在，如果存在相同的值，参照其执行过程进行执行，如果不存在，则进入第二部
-
第二步：语法分析（如果是DCL语句，只要语法没有错，那么就会隐式的有一个commit操作，但如果语义错误，那么就会抛出）
判断当前的SQL语法是否存在错误的地方，如果存在，则返回报错，如果不存在，那么进入第三步进行语义分析
-
第三步：语义分析（如果语义没有错，DCL成功执行，还会有一个隐式的commit动作）
首先判断当前session是哪个用户的，然后再判断数据字典中当前用户是否存在查阅当前表的权限（这里会进行俩步操作：第一：查询当前用户的相关定义，第二：查询当前表的相关定义），不通过则返回报错，通过则进入下一步进行编译
-
第四步：编译（将文本转换成二进制）
首先查看编译条件，其次再进行改写，如：where sal a between and b，那么这个时候就会改写成 ‘ 范围<= a <= 范围 ’，编译通过后，进行下一步执行
- 编译顺序（当前例子限于上面的select）
- ① from：找到表，查询其中定义等
- ② where：需要表中的数据满足哪些条件，解析where子句时，并没有解析select子句中列的别名，所以在where条件中不能写列的别名，但可以写from中的别名
- ③ select：满足条件中的数据，你想要哪些列
- ④ order by：进行排序
- 编译顺序（当前例子限于上面的select）
-
第五步：执行
生成数据库的执行计划，执行计划中会存在几种选择，如：索引查询、全表扫描还是其它方式等，然后进入下一步 替换
-
第六步：替换变量
如果当前语句中存在查询变量，那么进行变量替换，如果没有则通过该步骤，进入下一步 最终执行
-
第七步：最终执行，得到对应的数据
-
第八步：返回相关值
# 当前操作中对于性能和执行速度主要集中 第三、四、五步，而优化则在此体现 # 对于相同功能，类似需求存有偏差，如需要不同的id，那么这个时候就可以使用同一变量进行替代，达到一次编译多次使用的结果，节省数据库的性能 # 例如：# 一次编译多次使用 select * from emp where emp_id = 10625; select * from emp where emp_id = 10627; # 改写 select * from emp where emp_id = （变量）; <--可以达到一次编译多次使用 -
-
a
3、DB参数
-
cursor_sharing：如果当前SQL写死，不存在变量赋值，那么可以修改DB中的参数设置
sql>show parameter cursor NAME TYPE VALUE ------------------------------------ ----------- --------------------- cursor_bind_capture_destination string memory+disk cursor_sharing string EXACT cursor_space_for_time boolean FALSE open_cursors integer 600 session_cached_cursors integer 500cursor_sharing：用来判断当前的DB中的SQL语句能不能共用一个编译计划、执行计划。取决于其值，
参数默认值：EXACT，代表着只有SQL语句是精确匹配的，才能共用一个编译计划或者执行计划，否则将不适用。当前参数还存另外俩个值，Force、similar
Force：代表着无论你的SQL语句如何，他们都共用一个执行计划或者编译计划
similar：代表着无论你的SQL语句相似时，才共用一个执行计划或者编译计划，那么就存在一个相似度的判断
-
show all（parameter）
autocommit = off：① 仅在当前整体会话有效，如果使用exit退出当前整体会话，那么之前所作的事务都会默认提交 ②如果将 off 改为 ON 或者 IMM ，那么当前会话所作的任何DML操作，只要DML语句被执行，那么事务将会自动提交
-
recyclebin
重点：回收站对象所关联的约束、过程等如何恢复
show parameter recyclebin; # 默认是打开的，如果将其关闭，那么DDL后想要找回之前的数据，就找不回了，该参数就类似回收找的操作 NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ recyclebin string on ############################################################################### # 删除某个表 drop table 【表名】; # 闪回到该表删除前的时间，并且会自动提交表被删除前的所有数据信息 flashback table 【表名】 to before drop; # 查询即可 select * from 【表名】; # 查看回收站中是否存在数据 show recyclebin-
记录所有被删除表的历史信息，如：表名、删除时间、类型
-
指向回收站的数据只能看，不能改
-
回收站默认保存时长为15分钟，当undo空间不够时，会自动回收早期的文件信息
# undo_retention interger 900(秒) -
删除原表之后，其名字在数据库回收站中被修改，找不到原始数据表的名字
-
如果关闭了回收站，此时删除表，那么DB就会直接释放空间，该表就无法找回
-
如果回收站没有关闭，并且在删除语句后添加 purge，那么该表也无法进入回收站，要想再次恢复，只能使用备份恢复
drop table t01 purge; -
回收站的数据被标识为不可用，可回收，一旦清除掉回收站中某一个对象，如果再想恢复，就无法恢复了，只能通过备份来进行恢复了，因为回收站中已经不存在该对象了
# 清除某一对象 purge table "BIN$/G4SX5kUPd7gVQAAAAAAAQ==$0"; -
使用flashback table时，如果当前数据库中已经存在（被某个用户创建了同名表）需要恢复的同名的表时，这个时候需要对回收站的表进行改名，在恢复到数据表中
flashback table 【表名】 to before drop rename to [非重复的表名]; -
清空回收站
# 当前命令，无论是什么账户，都只能清理自己账户下的回收站，无法清理别的账户下的回收站 PURGE RECYCLEBIN; # 当前命令，清空所有用户回收站的数据 PURGE DBA_RECYCLEBIN;
-
-
timing
- 用来记录对数据库的发生的任何操作所花的时间
show timing # 默认是关闭的 NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ timing string off -
unused：只有物理备份可恢复原来的数据，逻辑备份不可恢复
alter table [表名] set unused （[列名]） <--- # 一旦对某列执行此操作，那么就没有后悔的机会，不可逆的操作 # 1、该列将被隐藏，不可见，但依然存在，此操作针对于需要回收的列 # 2、可追加同名的列在表中 # 释放空间 alter table [表名] drop unused columns; <-- # 释放隐藏的列，腾出空间注意：在释放不可用的列的时候，只能释放当前表所有的不可用的列，不能指定某一个列进行释放，因为当前操作时不可逆的
-
autotrace(执行计划)
- 在终端中用于查看SQL语句的执行计划，其有五个参数 ” off、on、traceonly（进查看当前语句的执行计划，不查看其操作的内容）、trace explain（省略掉Statistics后面的参数）、trace statistics（只看当前statistics部分，其余省略）
set autotrace off # 不看执行计划 <--- 默认 set autotrace on # 查看执行计划 <--- 默认所有都看 set autotrace traceonly # 仅看执行计划，不查看SQL操作内容 set autotrace trace explain # 仅看 Execution plan 这一栏 set autotrace trace statistics; # 仅看 statistics 这一栏 SELECT se.username,se.status, se.sql_address,st.event, si.block_changes FROM v$session se,v$session_wait st, v$sess_io si,v$process pr WHERE st.sid=se.sid AND st. sid=si.sid AND se.PADDR=pr.ADDR AND se.sid>6 AND st. wait_time=0 AND st.event NOT LIKE '%SQL%' ORDER BY physical_reads DESC ; -
db_writer_process
- DB将脏数据写入到底层系统文件上的进程，启动 DB 实例，如果没有指定当前进程数，那么Oracle会根据CPU的数量决定参数的设置，默认 DB 实例启动时，参数为 1
SQL> show parameter db_writer NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ db_writer_processes integer 1
audi（审计：默认打开)
用来存放数据库中其它信息，默认存放空间是在系统表空间中，但系统表空间默认几百兆，但有时候需要防止其它用户在系统表空间下乱写数据，导致空间变小，这时候需要设置上限对于普通用户
SQL> show parameter audi
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
audit_file_dest string /12C_DB/db/admin/orcl/adump
audit_sys_operations boolean TRUE
audit_syslog_level string
audit_trail string DB
unified_audit_sga_queue_size integer 1048576
##################################################################
audit_trail --> 当前参数可以更改为 OS 、NONE(关闭)
2.审计文件存储路径 – audit_file_dest （当前参数所指路径）
当前文件是根据会话来生成的，每次登录数据库，就产生一个文件，并且默认只会记录管理员的登录日志，如果使用 exit 退出DB会话，那么当前会话就结束，若重新登录，那么又会产生一个新的文件
3.审计方式
- Mandatory auditing
- Standard database auditing
- Value-based auditing
- Fine-grained auditing（FGA）：粒度小，可以针对到表中的某列。其中 DBMS_FGA 专门的审计系统包
-
commit
- 向数据表中插入数据时，没有 commit 的时候，数据存储在底层数据文件（磁盘）上，只不过 commit 时，只是提醒 redo 日志将数据写入磁盘，当出现报错时，redo 不会重现报错的语句
- 不会触发 DBWR 操作（将数据写到文件系统），只触发日志写的操作
- 当一定量的数据插入表中时，再次插入数据超过表空间容量的数据，commit 当前数据时，报错，当查询数据时，只能查到第一次插入成功时的数据，第二次插入的数据存在底层数据文件上，但会成为垃圾数据
-
system
在DB中想要修改参数，其中一种方法，其范围是全局的
alter system set [参数] = [值]; <--- 当前修改范围是全局的，所有使用一台数据库的用户其参数值都会被修改 -
session（会话）
在DB中想要修改参数，其中第二种方法，其范围是当前会话
alter session set [参数] = [值]; <--- 当前修改范围是当前会话的，只有自己的参数会被改变
-
recover（快速恢复区）
SQL> show parameter recover # 指定路径：alter system set db_recovery_file_dest='' scope=spfile(在DB参数中生效); # 设置存储大小：alter system set db_recovery_file_dest_size=[存储空间] scope=spfile(在DB参数中生效); NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ db_recovery_file_dest string /12C_DB/db/fast_recovery_area db_recovery_file_dest_size big integer 4560M db_unrecoverable_scn_tracking boolean TRUE recovery_parallelism integer 01、存放备份的默认区域，如：
- 归档日志，如果没有指定存放路径，默认在此
- 日志、控制文件多路复用
- 闪回日志
2、自定义保存路径
- 该路径需要具备当前 DB 所属账户组的写权限
3、设置完快速恢复区之后，需要重启 DB 实例，才能生效
-
sec_case_sensitive_logon（密码控制）
SQL> show parameter sec_case_sensitive_logon NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ sec_case_sensitive_logon boolean TRUE- 如果当前参数值为 TRUE ，DB是严格区分大小写的，参数值为 False 则不区分
-
enable_ddl_logging（记录DDL操作）
SQL> show parameter enable_ddl_logging NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ enable_ddl_logging boolean TRUE- 当前参数用来记录数据库中DDL操作，保存位置参考：$ORACLE_BASE/diag/rdbms/orcl/orcl/log/ddl/
- 当前参数的默认值为 FALSE ，也就是不记录，如果需要记录则需要手动设置为 TRUE
-
db_block_checking（块检查）
SQL> show parameter db_block_checking NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ db_block_checking string FALSE- 当前参数默认为 FALSE，如果设置为 TRUE 将会对所有的数据块进行检查。DB通过对数据块信息的读取，用来确认块的自我一致性，根据DB的工作负载，会产生一定的开销（1~10%）
- 当前参数有多个值可以设置
- off：除system表空间之外，任何表空间中都不执行块检查
- low：在内存中的块的内容发生变化之后，进行块检查（速度快，负载低）
- medium：执行所有low的检查，除索引组织表不检查外，所有的表都检查
- full：检查任何一切以及索引块（负载高-- 不建议使用）
-
instance_type
instance_type string RDBMS- 实例类型：Relational database manager（关系型数据库管理器 — RDBMS）
-
statistics_level（统计信息）
SQL> show parameter statistics_level NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ statistics_level string TYPICAL-
默认值为 typical ，只收集特定的一些数据信息
-
值二 ：ALL ，收集DB产生的所有信息，包括底层调用产生的IO开销。这样会造成DB内耗过大，负载极高，一般DB做压力测试的时候才设置该值
-
值三：BASIC，不收集任何统计信息，对于自动化极高的18、19C来说，是毁灭性的，这样DB就无法自动修复。ASMM自动共享内存就没办法自动分配内存空间
-
4、SQL
1、数据存储位置
临时表上不存在ROWID，但是存在ROWNUM
5、SQLPUS解析
1、sqlplus /nolog登录
-
使用该方式进入的意义 --> sqlplus /nolog
防止输入的登录用户名和密码的明文进入到操作系统的history记录中，使得其它用户使用当前DB操作系统时，通过history查看到对应的用户名和密码登录DB，造成DB数据丢失，却无法定责，并且有效防止删库跑路现象
-
全称
# sqlplus /nolog --> sqlplus /no login
2、sqlplus使用管理员登录
-
服务端登录 — 连接sqlplus只有sysdba用户不会校验，一般账户都会校验用户名和密码
# 使用 sys 账户登录，服务端默认是不校验用户名和密码，只要指定身份 -- sysdba 登录就不会校验 # 不管前置使用哪个账户或者DB系统中不存在用户名或密码，只要指定 sysdba ，就不会校验 sqlplus / as sysdba <--- 当前方式直接登录 -
客户端登录
# 客户端要想登录 sysdba 账户，必须指定用户名和密码，服务端会校验
6、事务
1、事务定义
-
事务开始
- 当执行第一条DML操作语句时，事务自动开启
-
事务结束
-
正常结束
-
显示结束：手动提交 Commit 或者回滚 Rollback
-
隐式结束：①使用了DCL（授权）语句
② 在命令窗口中，如果使用 exit 命令退出了当前数据库会话，那么数据库会默认将之前所作的所有操作进行提交
-
-
异常中了
- 显示结束：手动关闭或者重启了服务器，没有保存之前的操作 <----Oracle默认回滚
- 隐式结束：电源突然断掉、网络断了，没有保存之前的操作 <----Oracle默认回滚
-
7、语义
1、DML语句
Oracle中执行DML语句之后，不做任何的提交或者回滚操作，后面执行DCL操作，那么当前DCL操作会自动提交，其上次执行的DML语句也会被提交，因为DCL语句Oracle默认是隐式提交事务
-
delete
delete语句删除的数据，并不会释放表空间，只是标明当前被删除的数据不可用，只有当空闲空间不够用时，才会回收delete的空间，如果想立即回收不可用的数据的空间，使用回收空间语句即可
-
insert
-
使用append方式，快速批量插入数据，减少IO时间，因为 append 方式是直接在表的最后面添加数据，不会去寻找表中的空位进行插入
# 1、查看用户下对应的表是否是 logging 模式，其值如果显示为 logging，那么将其改成 NOlogging select table_name,logging from user_tables; <-- 查看当前用户下的所有表（对象级别） alter table [表名] NOlogging; # 2、插入数据，使用 append 方式进行插入 insert /* append */ into 【表名】
-
2、DML操作对undo表空间的影响
- 当对某一个数据进行修改时，修改和被修改数据都会先存放到undo表空间中，当事务提交后，undo表空间更新的数据才会放到内存中去，当事务未提交，需要还原数据时，使用rollback，undo表空间中的原始值会重新覆盖到内存中
- 在rollback之前，undo段的数据被标识为：当前数据是有效的历史数据
- 当commit之后，undo段的数据被标识为：当前数据无效但未过期，因为DB中有一个参数规定历史数据过期的时间。在规定时间内，可以调用具体的事务还原当前值
- 当时间超过过期时间时，undo段的数据被标识为：过期，当undo的可用空闲空间不足时，会自动覆盖过期的历史数据
3、DDL语句
-
truncate
truncate操作只是截断数据与定义之间的关系，将定义改变了，truncate之后的数据表会还原成初始状态
注意：truncate 之后的数据只能通过备份去恢复
-
drop
drop操作只是更改对象名和指向位置（指向回收站），如果要查看，可以回到回收站中查看，但注意：如果回收站中是表的话，那么查看的时候需要对表名加双引号，因为回收站中存在非法字符
SQL> show recycle
ORIGINAL NAME(原名) RECYCLEBIN NAME(回收站的名字) OBJECT TYPE DROP TIME
---------------- ------------------------------ ------------ -------------------
TESTABCDEFG BIN$/G01bMFH1IbgVQAAAAAAAQ==$0 TABLE 2023-05-24:16:23:34
SQL> select * from "BIN$/G01bMFH1IbgVQAAAAAAAQ==$0";
no rows selected
SQL> desc "BIN$/G01bMFH1IbgVQAAAAAAAQ==$0";
8、SQL脚本
1、脚本书写
# 1、创建文件，以 .sql 结尾，代表着当前文件是一个SQL文件，文件中写入你需要的命令或者SQL语句，授予执行权限
# 2、DB系统中引用 @+文件名即可
9、权限管理
1、创建用户并授予基本权限
# 1、创建用户
create user 【用户名】 identified by 【密码】
# 2、授权
grant create table to 【用户名】 # 授予用户创建表的权限
grant create session to 【用户名】 # 授予用户连接数据库的权限
alter user 【用户名】 quota 1m【可以是 unlimited（没有限制）】 on users;#授予用户存储空间的大小
# 注意：unlimited 受限于硬盘容量
系统权限：
- 能够对数据库结构造成改变的权限，对数据库进行操作的权限：如：建表、连接等 100多种
- 带 any 的权限，一般不会给普通用户
对象权限
- 关联对象当中存在的数据，对数据进行增删改查的权限
2、查询权限的分类授予
1、授予某普通用户只能查询另一用户的某一张表
grant select on Albert.sp to apps;
3、DBA 权限
- DBA 权限并不是值 具有任何权限，而是相比较普通用户它的权限相对较多，例如：创建、删除用户。普通用户则不具有该权限
10、索引
1、索引解析
1、组成
由 rowid 和 索引字段组成
2、索引查询数据的原理
通过select定位数据时，首先需要找到索引字段的值，再通过索引字段值找到rowid，通过rowid去定位数据块中所存在的数据物理位置，然后直接调用数据即可。
2、索引丢失（失效）
重点：何为索引失效？
使用索引查找数据，必先拿到对应数据的rowid值，而rowid值具有俩份，在索引和表中各一份，当调用对应的数据时，DB会对比这俩个值是否一致，来判断索引是否有效。如果俩个值不一致，那么索引就失效 <–逻辑错误
1、如果当前表被移动，那么当前表上的索引都会失效
alter table [表名] move; <--- 当前表上的所有索引会失效，但数据依然还在
2、如果索引失效，俩个解决办法
-
重新创建索引
create index [索引名] on table[表名][索引字段] -
重建索引（将原来表中的rowid重新更新一份）
alter index [索引名] rebuild;
3、索引进行运算的时候，索引失效，则该如何？
解决办法：将整体进行运算或者判断的值建立索引
select * from emp where emp_id+1=10217+1; <-- 索引失效
create index ind_emp_id_temp on emp(emp_id+1); <-- 即可快速查询
4、
11、备份
重点：备份时，如不指定保存路径，那么备份片默认保存再快速恢复区路径下的实例名中的备份文件夹中
备份相关表
# V$ARCHIVED_LOG <-- 查看归档日志相关情况
# V$BACKUP_CORRUPTION
# V$BACKUP_DEVICE
# V$BACKUP_FILES
# V$BACKUP_PIECE
# V$BACKUP_REDOLOG
# V$BACKUP_SET
# V$BACKUP_SPFILE
# V$COPY_CORRUPTION
# V$RMAN_CONFIGURATION
# V$SESSION_LONGOPS
1、逻辑备份（日志与其没有关系）
定义：将DB中的data定义导出，生成dmp文件，恢复时，数据（表、对象等）定义可以恢复，其中索引备份需要进行重建
- 是否可用于生产环境？
- 备份时，生产环境的DB已经停掉，没有进行业务操作，那么备份出来的数据可继续在生产环境中使用
- 如果备份时，生产环境DB依然进行业务操作，那么备份出来的数据不可恢复到生产环境中去使用，只能用作测试环境
2、物理备份
- 冷备份
- 停掉DB，将相关文件全部Copy ----> 缺点：备份期间任何业务不能做，效率低
- 热备份（常用）
- 不停DB，将相关文件全部Copy，Copy中，DB还在工作，仍在产生数据，当我们备份完所有关键文件时，仍需要拷贝备份时间段所产生的增量数据的日志或者文件
- 对于热备份，备份的数据能达到什么程度，取决于增量数据的日志或者文件是否有备份
- 缺点：数据库负载会非常高
3、增量备份
- 全备份（默认 level = 0 单个文件全部拿走）
- 当个文件的全备
- 增量备份（默认 level = 1 差异增量备份）
- 差异增量
- 只跟上一次的备份作比较，备份被修改过的文件
- 累计增量
- 如果语句中加上 cumulative 只跟全备（level 0）作比较
- 不加 cumulative ，只跟上一次的备份作比较 <— 默认Differential（无论上一次做的是那种备份）
- 差异增量
4、镜像拷贝
注意：镜像拷贝的文件大小和源文件一模一样
-
镜像拷贝恢复速度是所有备份文件中速度最快的，其备份文件和源文件一模一样，某个源文件出错，拷贝与那文件的镜像备份到源文件位置，且将名字改成源文件名，即可直接启动DB
-
镜像拷贝复制期间，如果源文件数据量大，那么耗时也相对较多，如果出现错误突然中断，那么当前镜像拷贝文件就没有用了，需要重新备份
-
备份命令
backup as copy [备份类型：tablespace、datafile、user等] [文件号 tag:可自行修改] format;
5、查看备份文件
select count(*) from v$backup_set; --> 查看存在多少份备份文件
6、优化备份速度
-
增加通道（Channel）
-
拆分备份文件大小，给产生的备份文件指定容量
backup datafile [文件号#file （v$datafile即可查看）] section size = 25M tag '[取名]' list backup datafile 1[文件号]; <-- 指定查看备份的文件，其中文件号指的是前面备份的文件的文件号 -
压缩备份文件
# 1、会自动过滤掉没有分配数据的数据块（高水位线上 - HWM） # 2、未使用的数据块也会被过滤掉 参数设置：High、Medium、Low 和 Basic
# 备份时进行压缩文件 backup as (compressed backupset)[压缩的意思] database plus archivelog; # 压缩参数 、 取消压缩就将 compression 去掉即可 configure compression algorithm 'Basic' as of release 'Defult' optimize for load true; <--- 默认为 Basic 形式进行压缩
7、备份快速恢复区
-
备份快速恢复区中的所有文件
Rman> backup recovery area to destination '【文件存放路径（可直接指定路径，也可在DB参数设置中更改备份文件存放路径 ）】'; -
备份所有恢复文件
Rman> backup revocery files; <-- 并不是所有的备份文件都放在快速恢复区
8、备份归档日志
-
使用 镜像拷贝 方式进行备份
# 规范命令 backup as copy [备份类型：tablespace、datafile、user等] [文件号 tag:可自行修改] format; # 命令 backup as copy archivelog like '【文件路径】' format '【保存路径及格式】' # 热备包括数据文件和归档日志 keep [forever | until time [=] '存储时间（多久失效）'] nokeep [restore point rsname](还原点) # 显示出所有具有还原点的Rman备份集 list restore point all; # 显示指定的还原点 list restore point 'rsname'; -
备份归档文件，选定sequence【文件号】号
注意：当前 sequence【文件号】 可以在 v$archived_log 表中查到对应的归档文件，从选定的归档文件号开始备份，备份完之后删除从开始文件号后面的所有归档文件，除了当前正在使用的归档文件
backup as backupset format '【文件保存格式】' archivelog from sequence=[文件号] delete input; -
在恢复目录数据库中设置归档日志状态
RMAN> connect catalog 恢复用户名/密码@SID <--- 连接恢复目录 RMAN> change backup tag '备份日志的名称' keep forever; <--- 代表永久有效，当前日志
9、删除归档日志
# 1、RMAN 进入，检查是否存在过期日志
Rman> crosscheck archivelog all;
# 2、删除所有过期归档日志
Rman> delete expired archivelog all;
# 3、from代表：从当前时间开始，删除多少天的归档日志
RMAN> delete archivelog from time 'sysdate-1';
# BEFORE代表：删除距今多少天前的归档日志
RMAN> DELETE ARCHIVELOG ALL COMPLETED BEFORE 'SYSDATE-7';
10、建立备份周期思路
重点：至少保存一套完整的备份（风险较大）,最好保留当前备份周期俩份完整的备份。如：当前备份周期七天，要想保留俩份完整的备份，就必须保证上一份全备不能过期，那么就需要修改保留时长为14天。防止突发问题，DB需要恢复到上一个周期的某一天而没有备份可用，这样就是最保险的。 ---- 保留时长是备份周期的二倍，并且空间需要保留俩份完整备份的空间
注意：如果备份周期是七天的话，一定要考虑是否需要扩大控制文件中备份清单的保存时长以及备份空间是否足够
# 问题：
# 要求备份周期七天，七天后做一次全备，如不考虑控制文件中备份清单保存时长和剩余空间是否足够，会出现哪些问题？
① 当前库存在七天前的一次全备，并且也存在近七天内的累计或者差异备份。当你进行备份时，正好到第八天，这个时候当前控制文件中的上一份备份清单信息就已经过期，正常情况都会在当前备份脚本的最后写上，删除过期的备份片。一但备份过程中DB出现错误或者空间不足引发错误，并且执行了删除过期备份的语句。当你使用上一次的全备来进行恢复数据库时，上一份已经被删除了，只剩下还没过期的累计或者差异备份，但这俩份备份文件需要在全备的基础上才可以使用。这就造成了无法估量的损失。
# 总结：在备份开始时，一定要查看控制文件中 保存备份清单的时长 以及 空间状况
1、传统备份理念 — 小时级别
注意：生产库的相关数据文件一般都很大，恢复都是，RTO（时间损耗）
1. 生成备份集或者压缩备份集
2. 下线（offline）丢失或者报错的文件
3. restore相关备份集或者直接拷贝到指定位置
4. 应用日志（恢复到指定时间点时使用）
5. 上线（online）
2、秒级恢复 — 实时数据同步（成本高，RTO最低）
- 通过归档或者redo日志实时重现生产库的操作
- 如果生产库的文件发生损坏，直接将损坏的文件指向容灾库的文件即可，因为数据间隔时间都是秒级的
3、挂载磁盘方式恢复
注意：此种方式和将备份文件直接放生产库存在相似之处，但该方式最大程度上避免了整个系统的损坏导致数据全部丢失的情况
优点：
- 将备份服务器分出一块磁盘空间。挂载到生产服务器下，将生产服务器的所有备份文件都拷贝到当前磁盘上，备份完成之后，下架磁盘，防止生产库的损坏导致备份集也损坏，依次循环
- 当生产库发生某个文件发生错误时，如果备份磁盘存在镜像拷贝，将磁盘挂载到生产库上，然后将出错的文件指向备份磁盘上的文件即可，否则解压相关文件，恢复数据库即可
- 当前方式最耗时的地方是：磁盘挂载的时间以及文件指向的时间，不存在cp的动作，同样也是分钟级的
缺点：
- 没有冗余，如果备份磁盘上的文件发生错误，那么数据可能真无法恢复
- 如何将备份磁盘上的文件放到生产库的磁盘阵列上？
- 直接拷贝过去
- 对备份磁盘上的备份文件再做一次备份，并指向生产库的磁盘阵列路径
11、删除备份
注意：因为Rman工具是交互式，当你删除某个备份的时候，Rman会询问是否删除，如果你不回应它，那么它将一直处于等待的状态，导致无法进入下一步。但是，也可以使用 noprompt 参数，不询问直接删除
# 交互式正常删除
delete backupset 【文档编号】; 需要输入 YES | NO ,才能正确删除
# 直接删除
delete noprompt backupset 【文档编号】; 不用输入 YES | NO
# 也可以使用删除标签的方式进行删除备份
delete backupset tag=[编号]； 同样是交互式的，需要输入 YES | NO ,才能正确删除
12、备份切片
注意：备份片的大小需要在通道上指定，当满足条件后，该备份片自动关闭备份，开启新的备份片续上，可以使用脚本也可以单行命令显示
run{
allocate channel [通道编号] type disk<-- [通道类型] maxpiecesize [每份备份片大小];
backup as backupset [备份类型,也可省略，直接备份全库] fromat '存储位置及文件名' [database 代表全备];
}
12、自动诊断工具（ADRCI）(深度学习)
- 优势
# 1、无需数据库实例开启，不影响实例运行。
# 2、统一管理多个产品和实例，无需反复切换环境变量。
# 3、记录数据库发生的严重错误，方便DBA在ADR中跟踪问题。 每个问题都有一个问题键和一个唯一的问题 ID。可通过命令 show problem 来查看错误。
# 4、每个问题根据发生的次数记录为一个个事件。当DBA在ADR中跟踪事件，每个事件都由一个数字事件 ID 标识，该 ID 在 ADR 中是唯一的。可通过命令 show incident -all 来查看错误。
# 5、可以快速将事件和问题信息打包到一个 zip 文件中，以便传输给 Oracle 支持。
# 6、可以快速清理大日志文件。
13、数据库启动时查找实例
1、通过环境变量和数据库SID所生成的hash值（存放在共享内存中）与将来启动SQL plus连接时所得到的环境变量所生成的Hash（key）值与共享内存中的值进行比对，一致则连，不一致则不连
ORACLE_HOME ORACLE_SID
14、保持数据库不宕机
- 控制文件不丢失
- system数据文件和undo表空间数据文件不丢失
- redo日志组有效
15、日志记录模式
1、Oracle数据库、表空间和表具有三个级别的日志记录模式，分别是 logging、nologging 和 force logging，当创建一个数据库对象时将记录日志信息到重做日志文件
- logging：在创建对象或者DML操作时，将相关的日志信息记录到重做日志文件中
- force logging：它只能在数据库和表空间级别设置，无法对某一个表做强制设置，只要在当前俩个级别设置过，对数据库或者表空间做的所有的操作都会产生日志信息，并且写入到重做日志文件中，重点是，该命令无视你在任何层面设置的 nologging 模式，每个操作都将记录到重做日志文件中
- nologging：尽可能最少记录相关操作产生的日志信息写到重做日志文件中，减少IO消耗时间，在批量插入数据时，可用。其它情况，尽可能的不用
2、三个级别对象
注意：当数据库或表空间使用非强制模式时，日志记录优先级别由低到高：数据库 --> 表空间 --> 数据表
- 数据库级别
- 当数据库级别使用FORCE LOGGING时，具有最高优先级别，其它俩个级别使用的任何一种模式的优先级都将低于当前级别，如果数据表级别存在使用 nologging 模式，则该模式没有作用，除非数据库级别改变日志模式
- 表空间级别
- 当表空间级别使用FORCE LOGGING时，数据表的任何模式优先级都将低于当前级别，如果数据表级别存在使用 nologging 模式，则该模式没有作用，除非表空间级别改变日志模式
- 数据表级别
- 一旦上述俩种模式使用 force logging 模式，其优先级低于以上俩个日志级别
3、归档与非归档之间又存在不同的联系
- 在归档模式下，logging 和 force logging 支持介质恢复，而 nologging 则不支持介质恢复，当redo切换日志组时，并且会将相关日志一同记录到归档日志中
- 在非归档模式下，日志信息记录到日志文件，不产生归档文件，一旦丢失日志文件，数据库出现错误无法恢复
4、相关命令
# 查看数据库级别日志记录模式
select log_mode,force_logging from v$database;
# 查看表空间级别的日志记录模式
select tablespace_name,logging,force_logging from dba_tablespaces;
# 查看对象级别的日志记录模式
select table_name,logging from user_tables;
# 数据库级别切换到强制或者非强制日志模式
alter database force\noforce logging;
# 表空间级别切换到强制日志模式
alter tablespace tablespace_name [force\noforce] logging;
# 数据表级别
alter table 【表名】 nologging; <-- 最少化记录日志
alter table 【表名】 logging; <-- 正常记录日志
16、表空间
1、表空间如何组成
组成方式：块（存取数据的数据单位），多个块组成区，多个区组成段，多个段组成表空间
2、系统表空间
重点：系统表空间一定不要随意删除数据或者因为空间占用大而删除表空间再重建，那样的话，整个DB就宕机了
# 系统表空间
system
sysaux(AWR)：系统负载的信息绝大部分都会存在当前表空间下，而ASMM操作的前提就是根据当前负载信息做调整，影响着整个DB
3、表空间如何存取数据
注意：在 Oracle 8i 9i 的时候，表空建的扩展都是手动控制，而在10G过后，表空间的扩展方式默认改成auto模式，除非手动更改为manage，否则当表空间存储空间不足时，自动扩展空间，回收亦是如此
重点：建表的时候，数据库会在表空间下映射出跟表同名的段（segment） ，而段当中存取数据是通过区来进行，（区是表空间的扩展单位）而区则由多个数据块（一个块大小8k）组成
4、非/系统默认临时表空间损坏处理流程
注意：非系统默认临时表空间损坏也不影响数据库正常运行，可能存在多个用户共用一个临时表空间，那么需要将所有使用该临时表空间的用户指向别的临时表空间，然后再进行修改
# 1、查看告警日志
参照路径：$ORACLE_BASE($ORACLE_HOME)/diag/rdbms/[SID]/orcl/trace/alert_[SID].log
# 2、查看哪些用户正在使用当前临时表空间，为不影响其它用户的操作，先将
select USERNAME,TEMPORARY_TABLESPACE from dba_users;
# 2、删除掉损坏的临时表空间
drop tablespace 【临时表空间】 including contents and datafiles cascade constraints;
# 3、创建一个新的临时表空间或者使用源库中的表空间
create temporary tablespace 【表空间名称】 tempfile '表空间所对应的文件保存路径，包括文件名'
size 50m autoextend on next 50m maxsize 20480m extent management local;
# 4、将原来损坏的表空间用新的替换
alter user 【用户名】TEMPORARY TABLESPACE 【临时表空间名】;
5、非系统表空间损坏处理
注意：当前操作具有苛刻的条件（没有备份），如果归档日志不连续，那么当前恢复方式无法恢复
- 损坏的表空间从开始创建到结束，整个生命周期必须处于归档模式下
处理流程：
# 1、当插入数据报错时
insert into apps.a select * from apps.testc
ERROR at line 1:
ORA-01116: error in opening database file 2
ORA-01110: data file 2: '/12C_DB/db/oradata/orcl/test_space.dbf'
ORA-27041: unable to open file
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3
# 2、查询表空间是否存在，从给出的路径中寻找
# 3、下线表空间文件
alter database datafile '对应表空间保存路径' offline;
# 4、从新创建一个新的同名表空间
alter database create datafile '保存路径和原来的路径一致';
# 5、查询新建的数据文件编号
select file#,name from v$datafile;
# 6、恢复数据文件
recover automatic datafile 【上面查询出来的编号】;
# 7、上线对应表空间，查询即可
alter database datafile 【编号】 online;
6、Undo表空间
- undo表空间规划
- 存放当前事务的有效数据
- 存放当前事务无效，但未过期的数据
- 存放过期数据
- 空闲空间
- 当插入的数据过大时
- undo表空间首先会使用空闲空间来存储数据，当空闲空间不足以支撑后续数据时，会把过期的数据清理掉，还不够时，会将无效但未过期的数据清理掉，用来存放新进事务的数据，当还不足够时，就会报错，当前事务操作失败
- 当前事务操作失败会产生一个问题
- 第一是把过期和没过期的数据都清理掉了，无法调用事务回退到原来的历史数据
- 当前事务操作失败会产生一个问题
- undo表空间首先会使用空闲空间来存储数据，当空闲空间不足以支撑后续数据时，会把过期的数据清理掉，还不够时，会将无效但未过期的数据清理掉，用来存放新进事务的数据，当还不足够时，就会报错，当前事务操作失败
- 当检索数据undo中不存在时，报错ORA-01555
- 问题
- 可能是过期时间到了，数据库自动回收了当前空间
- 用户执行了DML操作，导致undo表空间爆了
- 解决
- 扩大undo表空间，如果是自动扩展，最好给一个上限值，防止误操作，导致undo无限扩展，将磁盘空间挤满
- 问题
- 强制保存900秒以内的数据，防止被覆盖
- 语法：ALTER TABLESPACE 【undo表空间名】 RETENTION GUARANTEE; ----- 打开之后便根据保存时间来强制保存
- alter tablespace undotbs2 retention noguarantee; ----- 关闭强制保存
- 多租户架构下的undo表空间
- 从12C R1就开引入多租户架构模式，但12C R1仅支持Global Shared Undo（全局共享）模式，也就是说，当前模式下所有PDB只能使用一个Undo表空间，而当前Undo表空间仅存在根容器下
- 从12C R2之后引入了 PDB Local UNDO模式，当前模式支持所有的PDB都有自己的UNDO表空间。每个容器下都有自己的undo表空间。好处是：
- 减少各PDB之间争用Undo表空间，同时方便拔插
- 只有使用Local模式，才支持新特性：Refresh PDB，Flashback PDB
17、日志挖掘
注意：日志挖掘能够精确的确定DB灾难产生的时间点，更清晰的知道恢复数据到哪个点，但相对来说，如果归档日志较多的话，那么也是一项巨耗时的工程
# 查看DB是否开启归档
# 创建字典保存路径，一般指临时文件保存的地方，可以不更改路径
alter system set utl_file_dir = '保存路径' scope=spfile；
# 开启补充日志，NO为关闭，YES开启（
select supplemental_log_data_pk,supplemental_log_data_ui from v$database; -- 查询
alter database add supplemental log data (primary key, unique index) columns; -- 开启
# 创建字典
exec dbms_logmnr_d.build('dictionary.ora[字典名称]','[先前创建的保存路径]');
# 查询归档日志保存路径
select name from v$archived_log；
# 查询redo路径
select * from v$logfile;
# 添加解析的归档日志
exec dbms_logmnr.add_logfile(LogFileName=>'【上面查询出来的归档日志保存路径】',Options=>dbms_logmnr.addfile);
# 使用字典对归档日志进行挖掘
exec dbms_logmnr.start_logmnr(dictfilename=>'【上面创建的保存路径下的字典文件】');
# 查询
select scn,sql_redo from v$logmnr_contents where lower(sql_redo) like '【相关操作的关键字】' and seg_owner='【表的所属用户】';
18、隐藏参数强行起库
注意：当控制文件损坏，无法启动DB时，可以使用以下参数
# 意思是：不进行数据库一致性检查
_allow_resetlogs_corruption=true
_corrupted_rollback_segments=true
_offline_rollback_segments=true
二、DB架构
一、简介
1、DB定义
Oracle Database 8i、9i等之前的版本 <-----> 基于Intenet
Oracle Database 10G <-----> 基于Grid（网格），对于局域网内部的资源可以共享使用
Oracle Database 12C <-----> 基于Cloud（云架构）
2、文件系统
简介：Oracle (Automatic Storage Management)
Physical Volume 物理卷
Logical Volume 逻辑卷
Linux中文件后缀名没有意义
Linux中LVM分区：当某个分区磁盘容量不够时，其可以动态调整逻辑分区大小
物理硬盘融合成大的逻辑硬盘，在从逻辑硬盘中做拆分 <-----条带化技术（标准化分区）
条带化的粒度、冗余度取决于：
LVM空间管理指导 ----> 落地：RAID技术 （只要规划好了磁盘空间，就不能再重新进行规划，如果要改，那必须得格式化磁盘）
流程：①条带化处理，将所有时间LVM空间管理的磁盘进行融合，然后根据具体情况进行调配
-
有条带化但没有冗余：在RAID技术中称为 ---- > RAID0
解释：但LVM根据实际情况分配磁盘空间之后，没有设置冗余空间用于对应突发情况的磁盘爆满（坏），那么这个时候，爆满的磁盘（坏）可能就会坏掉，造成数据丢失，可能也会造成使用后LVM技术的所有磁盘都坏掉
-
有条带化、有镜像无冗余：RAID1
解释：最简单的就是，俩个盘，一块存放源文件，第二块盘就是源文件的镜像
-
有条带化、有镜像、有冗余：RAID5 <------ 基于空间的考虑（安全系数高） 衍生出来的 RAID6 存放俩块校验盘
流程：三块盘（基础）
①条带化处理，将所有时间LVM空间管理的磁盘进行融合，然后根据具体情况进行调配（三块盘）
第一块盘：存放数据
第二块盘：存放数据
第三块盘：存放校验信息，如果数据块损坏，就通过校验信息进行数据恢复
错误：
如果前俩块盘都出现错误，仅剩校验盘，该如何解决错误
-
Oracle中 使用软件模拟 RAID 的实现功能 ----> ASM技术（针对DB：实现存储和空间动态管理）
-
高可用（HA high aviable）—>Oracle （Real Application Clusters）
- 故障转移
- 负载均衡
实现方式一：主备 —> 读写分离
- 实时同步
- 当主节点DB出现故障时，是否会实时体现在备用节点DB上
- 当主节点出现故障，备用节点立马顶上，就不会出现数据丢失的情况
- 异步同步
- 当主节点DB出现故障时，过一会（间隔五分钟）再体现在备用节点DB上
- 当主节点出现故障，备用节点可能需要等待一段时间，那么这段时间内可能会造成数据丢失的情况，如：银行数据肯定不能支持
- 一般情况下的主备
- 都只有主节点在工作，只有当主节点出故障的时候，备用节点再启动（主 – 活 备 — 死）
- 这就造成了资源利用不充分，并且负载均衡可能效果不好，也可能不存在
- 读写分离：确保备用节点也在工作，不会造成资源浪费
- 弊端：负载均衡效果不理想，大部分情况下读的操作相对较多，那么承受读操作的节点配置相对来说较备用节点的配置高，寿命相对较短暂
实现方式二
- 主主 — > 集群（RAC）或者 单节点
- 多个节点数据实时共享，但内部数据互相交互会造成一定的资源消耗，如：内存、CPU消耗越多，服务器的性能越差，效率就越低
-
Oracle Streams（流复制）
- 针对DB对象、表少的时候用，如果对象多、表与表之间的关联关系多，那这个时候流复制技术就失去优势
- 衍生出数据同步工具 —> OGG：同平台、跨平台、跨DB版本等等同步都可，相对来说成本较高
-
Oracle Enterprise Manager Grid Control（企业管理工具）
- 单机版DB，自带网页管理工具，其中10G、11G可以达到百分百的对数据库进行管理，而12C往上，相对而言就很少，只能做基础架构的调整
二、 DB管理
一、DB进程
2、归档模式
注意：归档模式 —> 手动设置 —> 归档日志的视图 —> v$archived_log
-
必须先在DB中手动设置成归档模式，如果DB中没有设置该模式，那么只能恢复近100M的日志文件
-
归档模式：发生redo日志切换时，被切换的日志会进行归档，比如：当前在使用联机重做日志1，当1写满的时候，发生日志切换，开始写联机重做日志2，这时联机重做日志1的内容会被拷贝到另外一个指定的目录下。这个目录叫做归档目录，拷贝的文件叫归档重做日志
-
非归档模式：只能做冷备处理，不能进行热备，并且在恢复时，只能做完全恢复，最近一次的完全备份到系统出错期间的数据无法恢复
-
当归档模式对redo log文件进行复制时，当三个日志文件都写满了，Redo切换回第一个日志文件时，这时候还没有备份完，Log Writer（LWGR）就会等待你的日志归档完成，再覆盖，这个时候，日志无法写入，Redo log 无法清空，新的日志无法写入缓存，用户层面一直在等待，DB就会处于等待
-
文件大小：# 10G 默认：2G # 11G 默认：4G # 12C 默认 4G
-
查询存放归档文件信息的表
select * from v$archived_log; -
12C中DB默认是可以同时生成31份归档文件，冗余，防止文件丢失，造成数据库无法挽回，同时也可以更改存放路径，只需要更改其中一个路径变量，即可修改归档日志存放路径
SQL> show parameter archive NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ log_archive_dest_1 string log_archive_dest_10 string log_archive_dest_11 string log_archive_dest_12 string -
可以切换归档文件
SQL> show parameter db_recovery_file_dest_size; NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ db_recovery_file_dest string /12C_DB/db/fast_recovery_area db_recovery_file_dest_size big integer 0 ################################################################### SQL> archive log list <--- 查看归档模式是否开启，默认是 没有开启 Database log mode No Archive Mode Automatic archival Disabled Archive destination /u01/ebs/db/data Oldest online log sequence 721 Current log sequence 723 ################################################################### # 启动归档日志 0 sqlplus / as sysdba - dba身份进入 1 shutdown immediate; –关闭数据库 2 startup mount; – 打开数据库 3 alter database archivelog;—开启归档日志 4 alter database open;–开启数据库 5 archive log list; – 查看归档日志是否开启 # 开启状态： # 数据库日志模式 存档模式 # 自动存档 启用 # 存档终点 USE_DB_RECOVERY_FILE_DEST # 最早的联机日志序列 49 # 下一个存档日志序列 51 # 当前日志序列 51 ################################################################### # 关闭归档日志 1 shutdown immediate; 2 startup mount; 3 alter database noarchivelog; 4 alter database open; 5 archive log list ;–查看归档日志是否关闭 # 状态： # 数据库日志模式 非存档模式 # 自动存档 禁用 # 存档终点 USE_DB_RECOVERY_FILE_DEST # 最早的联机日志序列 49 # 当前日志序列 51 ############################################################################# # 查询归档模式是否开启 select name,dbid,log_mode,flashback_on,open_mode from v$database;解决方式：
- 默认单线程写日志。可设置为并发
- 增加 LWGR 轮询时长
- 调大 Redo 成员的空间大小 50M ----> 500M
- 增加 Redo 成员数量
出现问题：如果某个 Redo log 文件被删除，那么DB是否会崩
- 当前 LGWR（专门的写进程） 是否用到该文件，如果没有，那么重新在DB中创建该文件，反正轮询回来该文件还是要被清空
- 当 LGWR 正在用该文件，当前文件被删除，不一定会崩，取决于当前操作系统的缓存设置以及文件设置，但一定不要重启，重启之后当前进程就断了，就无法找到该文件，那么数据库就Down了
-
归档模式下的不完全恢复（只能在mount状态下）
-
Rman中支持的方式
-
基于时间的不完全恢复，所谓时间就是将scn号转换成时间
recover database until time '[转换的时间] -
基于SCN号的不完全恢复
recover database until scn [号]; -
基于sequence的不完全恢复
-
-
SQL底下支持四种 时间、scn、sequence 和 cancel
-
3、检查点进程
-
同时写俩种文件
- 控制文件
- 数据文件 <---- Database Writer（DBW）也会写入数据到该文件，写数据的时候会锁定当前文件，DBA 想要在该文件种注入检查点，这个时候就会返回错误
-
用处
- 当检查点生效时，会自动同时更新控制文件和数据文件的头的时间信息（更新定义）
- 时间信息（System Change Number 系统变更号 SCN）与 DB 中的时间戳一 一对应关系
-
缺点
- 检查点的时间可以手动设置，但不可设置的过于短暂，当检查点的时间间隔过于短暂，虽然保证了 DB 短时间内的宕机不会造成较多的数据丢失，但是会出现 控制文件和数据文件的频繁上锁，导致业务进展缓慢，效率低下。当 控制文件和数据文件 被上锁时，其它的任何操作只能等待当前操作完成，释放资源才可进行下一步操作
-
设置检查点
- Redo log日志在切换日志文件的时候
- 手动打印检查点
- 设置定时
-
为什么会更新文件的时间信息
- 防止文件被错误删除，导致DB不可用
- 当DB在某个时间点Down掉时，重启DB时，DB会根据Down的时间点往前找到最近的检查点进行启动，同时会在控制文件和数据文件头上写入时间，表明这俩文件的时间点一致，当数据库启动到Open时，DB会判断当前的俩个文件时间是否一致，如果一致则正常启动实例，如果不一致，则需要实例恢复。如果 DB 异常宕机，并且正在进行 DML 操作，如果 DML 操作提交了，检查点文件会在这个时候添加上检查点时间，后续做的所有 DML 操作如果没有进行 Commit ，那么 DB 都会默认进行回滚。重启之后，这个时候的DB不可用的，因为 Redo log中的日志记录了最新的 DB Down的时间，DB 重启之后，DB 会自动把最后commit时间点到 Redo log中记录的 DB Down 的时间中间做的任何操作都会重做一遍，没有 commit 的事务都会进行回滚，DB 恢复到最后一次提交时的状态，DB 这时候转变为 读写模式 ，应用才可以启动，当DB中控制文件和数据文件最后一次检查点的时间一致时，DB会自动恢复
-
查询控制文件头和数据文件头的检查点
- 谁的检查点大谁的数据就是最新的
# 查询控制文件头的检查点 select file#,checkpoint_change# from v$datafile; <-- 直接读取控制文件 # 查询数据文件头的检查点 select file#,checkpoint_change# from v$datafile_header; <-- 直接读取数据文件
4、在线添加日志文件
-
创建组并设置存储路径及文件大小
alter database add logfile group [组号] ('[日志存储路径/文件名]') size [日志文件大小] -
将日志文件添加到组
alter database add logfile member ['日志文件路径/文件名'] to group [组号 group#] -
删除日志文件，同时还需要将物理文件删除
alter database drop logfile member ['日志文件路径/文件名']； -
删除日志组
alter database drop logfile group [组名]
二、DB文件
1、控制文件
重点：标准控制文件是俩个一模一样的文件
-
框架：DB 使用到的框架信息，如：DB名字、数据文件、日志文件等整体结构信息，这些文件存储位置、多大。控制文件中都会记录下来。但该文本是以二进制的形式记录的，需要通过 DB 的数据字典进行访问。
-
时间信息（System Change Number 系统变更号 SCN）：时间强一致性，如果日志文件中检查点的时间不一致，必须通过日志做实例恢复，才会让你启动。如：mysql、sqlserver可以从别的库中拷贝文件可能可以直接使用，Oracle则不可用，必须日志中记录的时间点一致才可
-
Catalog（恢复目录）：存储相关文件信息，如备份数据库信息，Catalog中则会保存相关的备份文件的目录信息，备份中都有啥，什么时间备份的等清单信息。当前记录下的信息会被保存到当前数据库的控制文件中，有效期七天（Range：0~365天），过期则不可用，保存时间可以进行修改。当设置的保存时间过长的时候，数据库的控制文件会逐渐变大，导致数据库运行效率缓慢
# 保存时间受当前参数控制，最大保存时间365天，如果设置为0，则永不过期 NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ control_file_record_keep_time integer 7 -
控制文件多路复用（control_files）
SQL> show parameter control_files NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ control_files string /12C_DB/db/oradata/orcl/contro l01.ctl, /12C_DB/db/fast_recov ery_area/orcl/control02.ctl ################################################################################# # 添加控制文件： alter system set control_files='/12C_DB/a/control001.ctl' scope=spfile; # 重启实例即可-
官方建议存储位置：ASM 和 文件系统上
-
应用：
-
备份原始的控制文件
-
原始文件pfile的所在位置，并使用其创建新的文件
# pfile 原始路径：/12C_DB/db/admin/orcl/pfile/ create pfile='[路径]' from spfile; -
加入到参数设置中
alter system set control_files='[原始文件]-后追加新的文件-->[路径]' -
重启实例
-
-
-
控制文件丢失
注意：涉及到控制文件的恢复都属于不完全恢复，因为其需要使用resetlogs来启动库，就导致上一阶段的归档的日志无法续写，只能从新开始，只要归档日志出现了不连续，那么前一阶段的归档日志将没有任何作用，需谨慎对待控制文件的丢失恢复
如果丢掉某一份文件，只需要将另一份文件更改成丢掉的文件的文件名称即可，或者将 DB 中需要的控制文件参数名更改即可（controlfile中更改失去的控制文件名即可）
-
DB 处于 OPEN 状态
当前状态复制一个好的控制文件到相应的位置下，那么其复制的控制文件只能是原始控制文件的镜像文件，并不是当前数据库所需的控制文件，当重新启动数据库时，俩者的检查点都不一样，所以无法启动数据库
-
DB 处于 SHUTDOWN 状态
当前状态复制控制文件到相应的路径下是可行的，因为已经停库，控制文件中的检查点已经生成，所以，复制当前状态的控制文件到丢失的控制文件的路径下，即可重启DB
-
控制文件的原始文件存放于 $ORACLE_HOME/dbs 路径
-
可以将控制文件备份成跟踪文件以文本文件的形式输出，其中包含重建控制文件脚本，到告警文件中查看当前备份的文件保存路径 （…/diag/rdbms/[实例名]/[实例名]/trace/alert-orcl.log）
alter database backup controfile to trace; select value from v$diag_info where name like 'Def%'; <-- 可以查询出生成控制文件的文件夹名称 -
如果控制文件全部丢失且没有备份，使用脚本重建控制文件，但同样会造成数据丢失
RMAN> STARTUP NOMOUNT <-- 启动到 RMAN> CREATE CONTROLFILE REUSE DATABASE "[实例名]" RESETLOGS NOARCHIVELOG MAXLOGFILES 16 MAXLOGMEMBERS 3 MAXDATAFILES 100 MAXINSTANCES 8 MAXLOGHISTORY 292 LOGFILE <-- 重做日志（联机日志） GROUP 1 '/12C_DB/db/oradata/orcl/redo01.log' SIZE 50M BLOCKSIZE 512, GROUP 2 '/12C_DB/db/oradata/orcl/redo02.log' SIZE 50M BLOCKSIZE 512, GROUP 3 '/12C_DB/db/oradata/orcl/redo03.log' SIZE 50M BLOCKSIZE 512 -- STANDBY LOGFILE DATAFILE <-- 系统数据文件 '/12C_DB/db/oradata/orcl/system01.dbf', '/12C_DB/db/oradata/orcl/sysaux01.dbf', '/12C_DB/db/oradata/orcl/undotbs01.dbf', '/12C_DB/db/oradata/orcl/users01.dbf' CHARACTER SET AL32UTF8; <-- 当前数据库的字符集 RMAN> alter database open resetlogs; <-- 最后打开数据库
-
-
自动备份控制文件
-
在Rman中开启自动备份控制文件选项，以下俩种不同情况，Rman是否自动备份控制文件以及参数文件
-
当开启自动备份时，什么节点会自动备份？
CONFIGURE CONTROLFILE AUTOBACKUP ON;- 当数据库框架结构改变时，会自动备份控制文件和参数文件
- 当对单个系统文件（system仅次于它）或者整个数据库进行备份时，会自动备份控制文件和参数文件
-
当关闭时，又如何自动备份？
CONFIGURE CONTROLFILE AUTOBACKUP OFF;- 当数据库框架结构改变时，不会自动备份控制文件和参数文件
- 当对单个系统文件（system仅次于它）或者整个数据库进行备份时，会自动备份控制文件和参数文件
-
-
2、数据文件
1、在 Noarchivelog 模式下出现数据文件丢失或错误，该如何：
- 关闭数据库 shutdown abort ，为什么不用 immediate 关闭呢，因为数据文件丢失，导致检查点打不上，所以只能强制关闭
- 从备份文件中还原数据库，包括所有的数据文件和控制文件
- 重做宕机之后那段时间的所有改变，因为没有开启归档，redo只能保存十五分钟
2、在 archivelog 模式下出现非关键数据文件（除了system和undo tablespace文件以外）丢失或错误，又该如何：
- 当数据库处于----open状态
- 下线出现问题的数据文件 ---- offline
- 从备份中还原 — restore
- 恢复数据库 — recover
- 上线 ---- online
- 当数据库处于----close状态 <---- 更倾向于该模式，防止出现关联数据，导致恢复出错
- 打开数据库处于 nomount状态
- 下线出现问题的数据文件 ---- offline
- 从备份中还原 — restore
- 恢复数据库 — recover
- 上线 ---- online
3、在 archivelog 模式下出现数据字典丢失或错误，并且该文件属于system或者undo，该如何：
- 停库 — shutdown immediate（一般是停不了） --> shutdown abort（停库）
- 打开数据库至 ---- mount 状态
- 从备份文件中还原和恢复数据库
- 打开数据库
3、重做日志文件：
特点：文件轮询覆盖
- 下辖三个日志文件，每个日志文件默认50M，轮流写入，当三个文件都写满了，那么就会覆盖掉第一个日志文件，如果想要恢复被覆盖的日志，那么就需要归档进程（ARC）
注意：做冗余，每个文件分开放，不至于出错的时候文件全部损坏（Redo log buffer）—> 表：v$log，v#logfile
1、查询日志所在位置
select group#,thread#,bytes,members from v$log; <-- 查询当前日志大小，多少组
select member from v$logfile; <--- 查询日志文件所在位置
select v1.group#,v1.status, member,sequence#,first_change#
from v$log v1,v$logfile v2
where v1.group#=v2.group#;
2、重做日志的四种状态
| unused | 未使用的redo日志文件 | 刚建立的DB或者使用resetlogs重做的DB会出现 |
|---|---|---|
| inactive | 已经归档（可任意删除） | 组成员丢失，复制一个重新添加即可，若当前组失效，重新添加组 |
| active | ① 归档状态 ② 事务正在进行 | 事务完成或者手动打检查点其状态会转变为 inacive |
| current | 当前正在写入的日志文件 | 若当前文件出现损坏，切换redo日志成员，将当前损坏的日志切换到另一个没有损坏的redo日志成员上，再停库复制一份redo文件，修改其名字即可重新使用，如果不能切换，DB损坏 |
3、redo日志发生损坏
情况一：如果被损坏的日志不是当前日志（current）状态，也不是活跃（active）状态，为 inactive 状态，修补方式为：
# 1、查看告警信息，查看哪个日志组损坏了
参照路径：$ORACLE_BASE($ORACLE_HOME)/diag/rdbms/[SID]/orcl/trace/alert_[SID].log
# 2、可能出现无法正常关机，需要强制关机
shutdown abort
# 3、启动到 mount 状态
startup mount
# 4、清除损坏的日志组
alter database clear logfile group [损坏的日志组的编号];
# 5、直接打开数据库即可
alter database open;
情况二：如果损坏的redo日志不是当前（current）日志，但是状态时active，并且事务没有提交，且当前没有sys用户连接着DB
注意：如果事务没有提交，重做redo之后，需要将所有未提交的事务重新再做一遍，并且一定要重新做一次大备份，因为重做了redo日志，代表着之前的所有归档日志已经无法和现在的归档接上，归档编号从 1 开始
# 1、查看告警信息，查看哪个日志组损坏了
参照路径：$ORACLE_BASE($ORACLE_HOME)/diag/rdbms/[SID]/orcl/trace/alert_[SID].log
# 2、可能出现无法正常关机，需要强制关机
shutdown abort
# 3、尝试清除掉损坏的日志组（可能无法清除）
alter database clear logfile group [损坏的日志组的编号];
# 4、启动到 mount 状态
startup mount;
# 5、添加参数 _allow_resetlogs_corruption=TRUE，如果没报错，重启DB，直接进入第八步
alter system set "_allow_resetlogs_corruption"=TRUE scope=spfile;
#################################这俩步是在第五步报错的情况下适用的############################
{
# 6、如果第五步方式报错，重新创建一个pfile文件，将参数直接添加进去*._allow_resetlogs_corruption=TRUE
create pfile='[保存路径]' from spfile; # 打开pfile，添加即可
# 7、以pfile启动数据库到 mount
startup pfile='[保存路径]' mount;
}
#########################################################################################
# 8、以resetlogs启动到 open（一定要先使用一遍）
alter database open resetlogs;
# 9、恢复数据库
recover database until cancel;
# 10、以resetlogs启动到 open（再次使用）
alter database open resetlogs;
**情况二之另外：**如果损坏的日志状态是 active 的话，并且当前会话没有退出数据库连接且有（sys权限），并且当前连接的状态是 open 状态，才可以添加检查点，否则无法使用当前修补方式
重点：添加检查点的目的是 --> 将 active 状态转变为 inactive ，不需要重建控制文件，意味着只是一个简单的添加删除动作，不是不完全恢复，并且之前的归档日志依然可以使用
# 1、查看告警信息，查看哪个日志组损坏了
参照路径：$ORACLE_BASE($ORACLE_HOME)/diag/rdbms/[SID]/orcl/trace/alert_[SID].log
# 2、查询当前是否有 sys 用户连着数据库,询问管理员，如果没有，则无法使用当前修复方式
# 2、sys用户 --> 添加检查点
alter system checkpoint;
# 3、查看损坏的日志是否变成 inactive 状态
select * from v$log;
# 4、尝试清除掉损坏的日志组
alter database clear logfile group [损坏的日志组的编号];
# 5、直接打开数据库即可
alter database open;
**情况三：**如果损坏的是当前（current）日志，并且事务正在进行，其修补方式为
重点：建议直接使用备份恢复，这样还可以使用归档日志重现失败前的相关操作，如果使用一下方式修补，那么就无法恢复失败前未提交的相关事务操作
# 1、查看告警信息，查看哪个日志组损坏了
参照路径：$ORACLE_BASE($ORACLE_HOME)/diag/rdbms/[SID]/orcl/trace/alert_[SID].log
# 2、可能出现无法正常关机，需要强制关机
shutdown abort
# 3、尝试重新启动DB，会报错显示redo文件丢失
startup
# 4、重新创建一个 pfile 文件,文件可以任意指定位置
create pfile='/tmp/pfile.txt' from spfile;
# 5、打开新的 pfile 文件，加入隐含参数
vim /tmp/pfile.txt
*._allow_resetlogs_corruption=TRUE
# 6、用新的 pfile 文件启动DB至mount状态
startup pfile='/tmp/pfile.txt' mount;
# 7、运行控制文件备份的跟踪命令，会产生一个文件，文件中会给你一个完整的创建控制文件的命令
alter database backup controlfile to trace; <-- 生成创建控制文件的命令
select value from v$diag_info where name like 'Def%'; <-- 可以查询出生成控制文件的文件夹名称
# 8、打开上述查询出来的文件夹，复制创建控制文件命令，并检查是否必要的数据文件和redo文件都包含在其中，如果有些数据文件或者redo文件不存在，一旦生成之后，前者的数据文件在新的控制文件中就没有记录，就无法使用
CREATE CONTROLFILE REUSE DATABASE "ORCL" RESETLOGS ARCHIVELOG
MAXLOGFILES 16
MAXLOGMEMBERS 3
MAXDATAFILES 100
MAXINSTANCES 8
MAXLOGHISTORY 292
LOGFILE
GROUP 1 '/12C_DB/db/oradata/orcl/redo01.log' SIZE 50M BLOCKSIZE 512,
GROUP 2 '/12C_DB/db/oradata/orcl/redo02.log' SIZE 50M BLOCKSIZE 512,
GROUP 3 '/12C_DB/db/oradata/orcl/redo03.log' SIZE 50M BLOCKSIZE 512
-- STANDBY LOGFILE
DATAFILE
'/12C_DB/db/oradata/orcl/system01.dbf',
'/12C_DB/db/oradata/orcl/sysaux01.dbf',
'/12C_DB/db/oradata/orcl/undotbs01.dbf',
'/12C_DB/db/oradata/orcl/apps.dbf',
'/12C_DB/db/oradata/orcl/users01.dbf'
CHARACTER SET AL32UTF8;
# 9、将DB重新启动到 nomount 状态，依然使用前者新的 pfile 文件启动
startup pfile='/tmp/pfile.txt' nomount;
# 10、运行第八步创建控制文件命令
# 11、新的控制文件创建完成之后，已 resetlogs 方式打开数据库，一旦打开，之前的所有归档日志都将失效，此时数据库非常脆弱，一旦出错，很难挽回，一定要做一个全库备份
alter database open resetlogs;
4、参数文件
- 文件类型的参数文件：文本编辑时，DB 不会做相关的检查，在重新启动的时候才会检查
- DB 中的参数：二进制，修改即生效，同时也会直接报错，从 9i 开始，DB 默认启动以二进制的方式，但同时也支持文本的启动方式
5、备份文件
- 逻辑备份：将表或者文件中的数据抽取出来，存放到另一个文件中。前提是：数据库处于Open状态
- 物理备份：上面有解释
6、归档文件
归档文件不小心删除了，可以考虑设置重做日志在每次轮询归档文件时，生成 2 个 或者 N个归档文件，用空间换安全
7、密码文件
更多的是存放系统管理员（DBA）的密码信息
8、告警和跟踪文件
经常查看，可删，会自动生成
- Alert.log：用来记录 DB 启动和关闭的相关信息，以及 DB 参数修改信息 <---- 文本类型的文件
- trace.log：记录后台运行的进程信息，如：恶意杀掉、DB运行效率不高或者bug出现，应对每一个进程都会产生一个跟踪文件 <---- 文本类型的文件
三、DB 逻辑架构和物理架构的区别
- 逻辑架构：
- 创建一个表，DB 会自动分配一个区，每个区中含有 8 个数据块，如果没有指定数据块大小，那么默认为 8K 一个
- 表空间：可以理解成一个项目的文件夹，每个项目拆分成多个单元，由多个成员或组来完成，但多个单元文件又存放在一个以项目名称而建立的文件夹下。表空间（文件夹）可以存放多少数据取决于表空间中包含的文件大小 ----> 实际就是给定的物理存储空间有多大。表空间由数据块组成（区下的数据块）
- 区（Extent）：空间扩展的最小单位，空间不够用时，是以区来扩展的.
- 数据块（Oracle data block）：数据库读写的最小单位
四、DB实例
1、启动过程：shutdown —> nomount （实例启动，未与DB连接）----> mount（实例启动，读取控制文件与DB关联，但还是处于关闭状态） —> open（实例启动，打开关联的数据库，数据文件根据授权被用户相应访问）
-
①mount 、②nomount
- ①当 DB 实例使用 startup mount 启动实例时 ，除了 与生俱来的 SYSDBA 用户以外，任何用户都不能连接 归档模式 的 DB
- ②当 DB 实例使用 startup nomount 启动实例时，用户可以正常连接进行操作
-
open_mode：read write
-
read：当管理员讲实例开启为 只读 模式时，其它用户只能读取数据，不能增、删、改数据
- 如何进入只读模式？
# 1、首先进入非归档模式（正常打开），启动实例 startup nomount; # 开启实例，但不加载、不打开数据库 # 2、打开数据库，加载数据库 alter database mount; # 3、设置只读模式 alter database open read only; -
write：如何进入只写模式？
-
2、什么是DB实例：实例 = 内存（SGA） + 进程（后台进程）
默认值：PGA和SGA ===> 1 : 4
# PGA和SGA默认值不适用的情况
OLTP\OLAP 业务
-
Oracle instance —> 分为俩部分
-
memory：内存
- PGA：当选用了专有服务器模式，PGA是独立的，与SGA没关系
- SGA（共享内存）：内存一般都指SGA，当DB架构选用了共享内存模式的时候，PGA才占用SGA的内存资源。用户发起的指令信息都会归集到SGA中
-
进程
-
用户进程
-
服务器进程
-
后台进程
用户进程：用户与DB建立连接，通过 IP+端口+DB服务名称 服务器进程：应用与DB建立连接时，生成的进程，应用如果断开，当前服务器进程就自然断开 后台进程：数据写进程、日志写进程、检查点进程、归档进程、redo进程等等 <-- 实例当中的进程
-
-
-
Oracle database —> DB文件
- 日志文件
- 数据文件
- 控制文件
- 参数文件
- 告警文件
-
解析实例图
-
应用与DB建立连接产生服务器进程，才能提交用户的增删改查命令，首先进入PGA当中，然后提交SGA统一进行编译、执行
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-BQmzzsN6-1687763866008)(C:\Users\admin\AppData\Roaming\Typora\typora-user-images\image-20230613113850386.png)]
-
-
全局数据库名和SID的区别
- 全局数据库名：对外提供服务的名称，外部应用想要连接DB，必须使用该名称才能访问。和Service 名称保持一致（Service名称指的是 listener 中的服务名称）
- SID：系统识别号，操作系统连接DB时使用的连接名。切换不同实例亦是如此。如：export ORACLE_SID=[SID]
五、DB 停库的方式
-
shutdown abort（不建议）
- 强行停库，会导致控制文件、数据文件的检查点时间不一致，也可能会导致数据文件丢失，得到的只能是脏数据，这个时候需要做实例恢复，重做日志 — > 归档日志 ，但如果这些日志有损坏，那么DB 可能就宕机了
- 不允许新的连接连 DB、不会等待会话结束、不会等待事务结束、也不会写入检查点和正常关闭文件
-
shutdown immediate（常用）
- 正常停机，会在控制文件、数据文件、日志文件等打上相同的检查点并且正常关闭文件，下次即可正常启动 数据库 ，不需要做额外的操作，得到的是 clean （干净的）数据
- 不允许新的连接连 DB、不会等待会话结束、不会等待事务结束、但会写入检查点和正常关闭
-
shutdown transactional（少用）
- 会等待数据库中事务结束，如果事务没结束，那么实例也不会中止，会一直等待下去，直到事务完成或者手动杀掉正在运行的事务，并且会在控制文件、数据文件、日志文件等打上相同的检查点并且正常关闭文件，得到的是 clean （干净的）数据
- 不允许新的连接连 DB、不会等待会话结束、会等待事务结束、也会写入检查点和正常关闭
-
shutdown normal（少用）
- 等待数据库中的会话结束、事务结束，才会在控制文件、数据文件、日志文件等打上相同的检查点并且正常关闭文件，如果中途有任何一个会话或者事务没有结束，就不会停库，这个时候就需要手动杀掉正在运行的会话或者是事务，才可停库
- 不允许新的连接连 DB、会等待会话结束、会等待事务结束、也会写入检查点和正常关闭
-
特例
普通用户提交的事务正在处理，这个时候 SYS 用户想要关闭实例，这个时候是g
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Nn2rCL1V-1687763866008)(C:\Users\admin\AppData\Roaming\Typora\typora-user-images\image-20230215114323472.png)]
六、表空间管理
-
碎片空间回收
# 查看表空间的初始化信息 select segment_name,blocks,initial_extent,next_extent from dba_segments where segment_name='APPS'; # 开启表的行移功能，不然数据是无法移动的 alter table [表] enable row movement; # 开始压缩表空间 alter table [表] shrink space cpmpact; # 清除垃圾数据，回收表空间 alter table [表] shrink space;注意：当表空间收缩并且回收空间后，其关联的触发器、存储过程和索引等可能会出现问题
-
表空间容量冗余
- 创建表空间时，12C 默认为100M ，每次追加 100M ，每次初始的数据块，都不会百分百的存满空间，而会存留（PCT_FREE）百分之十的容量，用来存放数据定义、事务等
-
表空间不足时
- 当表空间不足时，外部还有数据需要存储进来，DB 中可以设置相关参数，当空间不足时，处于等待状态，而不是立马报错，这样可以防止数据导入一半报错，出现垃圾数据的情况，损失时间
- DB 中默认的时间为 0 ，单位是 秒
SQL> show parameter resum NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ resumable_timeout integer 0 -
扩容表空间
- 查询当前表空间的编号和名称
- 扩容
- 还可以直接启用空间不足时，自动开始等待，默认为7200秒，也可以在开启时，追加参数设置时间
# 1、select FILE#,name from v$datafile; # 2、alter database datafile [FILE# (文件名)] resize [大小 单位：M]; # 3、alter session enable resumble [timeout 300]; <--- 如果不追加括号中的内容，那么默认为7200秒，追加之后就变成300秒 -
d
三、加密备份
1、TDE – Wallet(软件)
重点：如果当前系统使用钱包加密数据，一定要备份该文件。如果钱包丢失，后续数据就无法加密和解密，加密的数据就无法使用。如果钱包文件存在，但是主密钥忘了，后续数据就无法加密和解密。重建钱包加密文件，无法挽回上一个主密钥加密后的数据，因为二者调用的加密层级不是同一个，所以主密钥和钱包文件处于同一层级上，无法哪个丢失，之前被加密的数据就无法使用
-
特点：
- 可加密类型
- 数据文件（例如：表空间、索引等）
- Redo log and archivelog files
- 数据泵加密
- Memory(内存)
- File backups
- 自动管理
- 不需要更改程序
- 可加密类型
-
解析–Wallet工具
流程：Wallet中存储加密的主密钥 —> 调用 ESM (External Security Module)外部安全模块 —> 生成加密、解密密钥 —> 通过加密密钥把敏感信息加密（主要是表中的敏感列信息） —> 存到对应的加密数据中 —> 提取数据时，通过解密密钥释放加密数据即可正常使用
-
使用TDE进行加密需注意
-
表中每列的的加密算法都是唯一的，其它列不能使用相同的加密算法
-
可以在表中追加、修改加密列和加密方式（salt和普通加密）
alter table 【表名】 modify (column_name encrypt [NO] salt); -
可以更改加密算法
alter table 【表名】 rekey using '【算法】';
-
-
加密算法有
- 3DES168
- AES128
- AES192
- AES256
-
TDE加密例子
# 创建表，对字段进行加密 create table [表名]( [column name] [column type], [column name] [column type] encrypt using '[加密算法]', <-- 当前列指定加密算法 [column name] [column type] enerypt no salt, <--- 加密时不添加随机数 [column name] [column type] encrypt <--- 普通加密 ) ###################################################################################### # 解析 encrypt using '[加密算法]'：当前列指定加密算法，并且该表中不得出现第二列使用同样的加密方式 enerypt no salt：如果某列追加 no salt ，就代表着当前列只针对该列值加密，不进行深度加密。如果追加的是salt，那么就是深度加密，需要在当前值后面追加随机数再进行加密。 优点是：① 数据更加安全，密文不易破解 缺点是：如果当前列想要追加索引，因为进行了深度加密，你想使用索引查询，是无法查询到有效值，必须去掉 salt 加密方式才可以使用索引 ###################################################################################### ###################################################################################### -
手动创建钱包（加密）
-
创建钱包
# sqlnet.ora 文件中追加当前语句即可创建 Encryption_wallet_location= (source = (method = file method_data = (DIRCETORY = 默认路径是在DB文件夹下的admin/orcl/wallet中))) # 钱包存放路径 DIRCEORY：当前路径下自动生成 钱包文件 -
指定加密密码
alter system set encryption key identified by [passwd]; <--- 主密钥 -
关闭、打开钱包命令
alter system set encryption wallet close/open;
-
2、OSB加密备份
- 可针对于 Rman 备份文件加密（基于OSB客户端）
- 范围：全局或者本地
- 也可针对于文件系统加密（基于OSB客户端）
- 范围：全局、本地、备份集或者volume level
- 密钥管理
- OSB客户端进行管理
- 存储再管理服务器上加密密钥存储中
- 加密算法
- AES128（默认）、AES192和AES256
3、Rman加密备份(还需深度学习)
-
仅针对于 Rman 备份文件、集
- 范围：数据库和表空间层面
-
密钥管理
- 数据库管理
- 存储在数据库的安全钱包中（也就是安装存储机制SSL）
-
加密算法
- AES256-bit，可以更改加密算法
# 1、configure encryption algorithm '[算法名称]' # 2、CONFIGURE ENCRYPTION FOR DATABASE OFF; # default < Rman 备份时，切记更改当卡参数值 -
加密方式
-
透明模式（TDE）
前提是：存在钱包加密，如果没有钱包，那么就无法开启该模式。
对于备份和恢复是没有任何影响的，但是在备份的时候，切记打开钱包，并且修改Rman的参数，备份出来的数据就是加密的，恢复还原时，仍需打开钱包，否则无法解密数据
-
密码模式
- 注意：在 Rman 中开启密码模式时，在当前会话进行备份或者恢复时，不需要密码。当用户退出当前会话时，需要重新设置密码，该密码必须和首次输入的密码保持一致，否则无法进行备份或者恢复。如果关闭了密码模式，无论是当前会话还是新的会话，都不需要密码进行验证
- 设置参数 <== 默认为 ON
- 设置密码
# 1、CONFIGURE ENCRYPTION FOR DATABASE 【ON】; set encryption on identified by [password] only -
混合模式
set encryption on identidied by [password]
-
4、VPD加密方式 - 私有
特点：行级和列级（敏感列）加密
5、数据泵加密
8、调整算法
# V$RMAN_ENSRYPTION_ALGORITHMS <--- 当前视图包含了所有支持当前系统加密的算法，可切换
# 2、set encryption algorithm '[算法名称]'
四、Oralce Omf（文件管理）
https://blog.csdn.net/jetliu05/article/details/124712220 <--- 文章
ASM（独立于操作系统的）
五、Rman
注意：更改Rman中的参数值设置，只需要拷贝命令，更改其中的参数值即可，但当你不知道改写什么的时候，拷贝命令，删除参数值，然后运行命令，其后接命令会在下方显示
一、概念解释
1、备份策略
-
冗余度（可以更改成none（不要）, recovery（几天）, redundancy（几个））
Rman默认的冗余度是 1 ，当数据库对某个文件做多次备份时，备份恢复时，默认临近的那份备份文件有效，但之前备份的文件只要没有超过七天，都还是有效，只不过在备份恢复时，需要指定
-
部分备份（partial）
2、备份类型
-
全备（full）：每次都会把整个数据库都进行备份
-
增量备份（需要确认？）
注意：如果事先不存在 0 级增量备份，直接做 1 级增量备份的话，DB会默认直接做一份 0 级备份
-
累计增量（level 1），在上一次 0级 的基础上做新产生的数据进行备份，并且只能用在 0 级的备份片上
backup incremental level 1 cumulative [备份类型] -
差异增量，在level 1层级上比对，是否产生新的数据，不指定 1
backup incremental level cumulative [备份类型]
-
3、备份模式
- 离线（冷备）
- 非归档模式下，并且数据库需要启动到 mount 状态，才能使用 Rman 进行备份
- 在线（热备）
4、只读表空间的备份
-
在使用Rman进行备份时，如有只读表空间，那么就跳过当前表空间或者数据文件
-
注意：每次备份时，如果没有关掉控制文件自动备份的开关，默认备份时都会自动备份控制文件和参数文件
skip readonly CONFIGURE CONTROLFILE AUTOBACKUP ON;
5、备份方式
-
镜像备份：拷贝所有文件，无论当前文件或者数据块中是否有信息，不会被加密，文件只能存放在磁盘中，不能存放在库中
backup as copy datafile [数据文件编号/文件路径] format '【保存位置】' -
备份集：只拷贝带有数据的文件
backup as backupset format '存储位置' tablespace 【表空间名称】 # backup as backupset tablespace [表空间名称] # backup as backupset datafile [编号] --> 输入 report schema 即可查到
6、关于备份的动态性能视图
v$backup_set ---> 备份集有关
v$backup_piece ---> 备份文件存储有关
v$datafile_copy ---> 复制文件数据到磁盘上
v$backup_files
7、Rman参数设置
注意：Rman中的命令即可单条执行，也可以使用脚本执行
1、查看相关参数是否被修改
select * from v$rman_configuration;
2、重置修改过的参数设置
注意：只要重置了修改的参数，那么之前记录在 v$rman_configuration 表中的修改记录同时也会重置
CONFIGURE RETENTION POLICY clear; <-- 在更改参数的动词前使用 clear 即可重置回原来的参数值
3、单实例和集群切换日志
- 单实例切换日志，只是将当前号redo日志切换到另一给redo日志，同时产生一份归档文件
- 集群切换日志，无论在哪一个节点上切换日志，所有节点的redo日志都会切换到另一个日志文件中，并且将当前redo生成一份归档，目的是为了防止当前组redo上正在写的日志信息丢失
注意：如果将单实例切换日志命令在集群环境中运行，那么只会切换当前实例节点上的redo日志，不会切换所有节点的redo
# 单实例切换日志
alter system switch logfile;
# 集群切换日志
alter system archive log current;
4、相关配置参数
特别注意：在单实例下，控制文件存放路径可以任意指定，在集群环境下，控制文件一定要存放在共享目录下，不然在提起备份时，无法识别其它
# 冗余度： 【可选none，recovery，redundancy】，默认是 1
CONFIGURE RETENTION POLICY TO redundancy 1; # default
# 影响只读或者脱机表空间： 默认关闭，打开的话，只读和脱机表空间只会备份一次，之后就不会再备份，因为俩者不会产生数据改变
CONFIGURE BACKUP OPTIMIZATION OFF; # default
# 备份时生成的通道的类型，因为有三个通道，所以需要制定某一个，默认是磁盘，磁带的简称时sbt
CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
# 控制文件自动备份，默认是关闭的，打开之后，默认保存路径在快速恢复区
CONFIGURE CONTROLFILE AUTOBACKUP OFF; # default
# 控制文件自动备份使用的通道以及文件命名格式，默认通道是保存在磁盘，只有当控制文件自动备份开启的时候，该命令才生效
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; # default
# 通过磁盘通道做一个并行度为1的备份集
CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default
# 指生成的备份文件在磁盘上保存几份，默认是一份，可以保存多份，做冗余
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
# 指归档文件备份在磁盘上保存几份，默认是一份，可以保存多份，做冗余
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
# 指备份集的大小，默认是没有限制，但是备份出来的文件大小超过磁盘的上限，就可以设置其上限
CONFIGURE MAXSETSIZE TO UNLIMITED; # default
# 加密备份，退出当前会话就输入输入密码验证才能使用，默认关闭
CONFIGURE ENCRYPTION FOR DATABASE OFF; # default
# 默认加密算法
CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # default
# 压缩备份集，默认是5：1的压缩当量
CONFIGURE COMPRESSION ALGORITHM 'BASIC' AS OF RELEASE 'DEFAULT' OPTIMIZE FOR LOAD TRUE ; # default
# Rman备份的保存天数，最好是等于controfile文件中的保留天数，默认七天
CONFIGURE RMAN OUTPUT TO KEEP FOR 7 DAYS; # default
# 归档日志自动清理，默认关闭，一般在脚本先运行备份归档日志的命令，然后在删除，防止到期自动删除，不能恢复误删文件或者数据，一般不改
CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default
# 当前值得是控制文件得快照的信息，在备份控制文件信息时，并不是备份当前正在使用得控制文件，而是这个快照文件
CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/12C_DB/db/12.1.0/dbs/snapcf_orcl.f'; # default
9、名词解释
-
RESTORE
解释：从备份当中将所需文件找回，所需文件在控制文件中记录着相关信息，默认文件从哪来回哪去
-
RECOVER
是推动数据库往前走，比如：八点做了一次全备，到十点才备完，这个时候需要将数据库恢复到九点，这个时候需要用Rman将DB恢复到八点，然后再使用归档日志，恢复到九点
-
FLASHBACK
闪回可以推动数据库往后走，调用闪回日志，回到以前某个时间点，效率相对于Rman较快，但有条件限制，如：
- DB结构性变化，文件系统中加给文件或者删除给文件，就不能使用
- 闪回日志默认只保留24小时
- DB重做了resetlogs
10、Rman相关命令
1、查询命令
# 查询数据库是否存在备份集
list backup = list backup of database;
# 列出所有备份文件
list backup;
# 列出镜像拷贝文件
list copy;
2、删除备份
# 删除所有备份
delete backup;
# 删除失效备份
delete expired backup;
3、备份命令
# 数据库全备命令
backup as backupset format '[保存路径]/all_%u%r%s.bak' database plus archivelog;
# 备份单个数据文件命令
backup datafile [数据文件编号：FILE#]; v$datafile表中可以查询得到——》 FILE#
# 控制文件
backup current controlfile format '[保存路径/con_%u%s.bak]';
# 参数文件
backup spfile format '[保存路径/con_%u%s.bak]';
4、report命令
重点： AVAILABLE —> 可用，存在备份的保留策略中
absolute —> 过期，备份集存在，备份信息中标记为过期，如果按照备份数来做策略，默认保留俩份，当备份第三份时，第一份就会被标记为过期
EXPIRED —> 失效，备份信息中存在备份集，但备份集被删除
# 显示过期备份片
report obsolete;
# 显示不可恢复的备份文件
report unrecoverable;
# 报告三天内没有备份的文件
report need backup days=3；
# 报告冗余次数小于冗余策略的数据文件
report need backup redundancy [冗余策略数字];
# 显示数据库必须要备份的文件
report need backup;
# 查询数据库所有表空间
report schema;
5、删除备份片
# 删除备份片且不循问,通过编号删除
delete noprompt backupset\backup 【编号：备份片前面的数字】;
# 删除备份片，通过 tag 删除
delete backupset tag='【默认时年月日加时间，备份时生成的】';
# 删除失效的备份集
delete expired backup
6、检查命令
# 查询备份文件、备份集是否可用，可用：’AVAILABLE‘ ，不可用状态：’EXPIRED‘，过期状态’absolute‘
crosscheck backupset\backup;
# 检查归档日志是否可用
crosscheck archivelog all;
# 检查当前数据库包括控制文件以及归档文件
validate database include current controlfile plus archvielog;
# 检查逻辑坏块
validate check logical database include current controlfile plus archivelog;
# 检查PDB
validate pluggable database manager;
# 检查DB
list failure;
1、Rman中format参数
%a：Oracle数据库的activation ID即RESETLOG_ID。
%c：备份片段的复制数（从1开始编号，最大不超过256）。
%d：Oracle数据库名称。
%D：当前时间中的日，格式为DD。
%e：归档序号。
%f：绝对文件编号。
%F：基于"DBID+时间"确定的唯一名称，格式的形式为c-IIIIIIIIII-YYYYMMDD-QQ,其中IIIIIIIIII 为该数据库的DBID，YYYYMMDD为日期，QQ是一个1～256的序列。
%h：归档日志线程号。
%I：Oracle数据库的DBID。
%M：当前时间中的月，格式为MM。
%N：表空间名称。
%n：数据库名称，并且会在右侧用x字符进行填充，使其保持长度为8。
%p：备份集中备份片段的编号，从1开始。
%s：备份集号。
%t：备份集时间戳。
%T：当前时间的年月日格式（YYYYMMDD）。
%u：是一个由备份集编号和建立时间压缩后组成的8字符名称。利用%u可以为每个备份集生成一个唯一的名称。
%U：默认是%u_%p_%c的简写形式，利用它可以为每一个备份片段（即磁盘文件）生成一个唯一名称
11、Rman下支持的还原方式
二、Rman还原数据库
1、开启归档模式
2、登录Rman
rman target / nocatalog
3、备份数据文件、归档日志文件
注意：第三步和第四步后面追加的 %u%s%r 是为了保存文件时，文件名不会重复
Rman> backup as backupset format '[保存路径]/all_%u%r%s.bak' database plus archivelog;
4、备份参数文件和控制文件
# 控制文件
Rman> backup current controlfile format '[保存路径/con_%u%s.bak]';
# 参数文件
Rman> backup spfile format '[保存路径/con_%u%s.bak]';
5、进入目的库，创建相应的文件夹，文件夹必须和源库的文件夹保持一致
重点：保证文件夹和源库的文件夹目录一致，如：
$ORACLE_HOME/admin --> 下的所有文件夹都需要创建
$ORACLE_HOME/dbs ---> 当前文件夹中可能不存在实例名和数据库名的文件夹，一定要创建
6、传输压缩包
scp [压缩包] [目的库的地址]:[压缩包保存路径]
7、进入目的库的Rman
rman target / nocatalog
8、设置源库 dbid ， 强制启动数据库到 --> nomount 模式
SQL> select name,dbid from v$database; <-- 查询源库 ID
Rman> set dbid [源库ID]
Rman> startup nomount force
9、恢复参数文件
Rman> restore spfile from '【文件保存路径】';
10、关闭 强制启动的 nomount 模式，普通启动 nomount 模式
Rman> shutdown immediate
Rman> startup nomount
11、恢复控制文件
Rman> restore controlfile from '[文件保存路径]';
12、恢复数据库
Rman> alter database mount;
Rman> restore database;
Rman> recover database; <--- 使用后面命令时可能会报错,接下来恢复到它给出的 scn 即可，反之则无需使用下面的命令
Rman> recover database until scn 【scn编号】; <-- 上一步报错为 SCN 才用
13、查看文件日志路径和 临时文件路径是否和源库的路径一致，如不一致则修改为一致
SQL> select member from v$logfile; <-- 文件日志路径
SQL> select name from v$tempfile; <--- 临时文件路径
14、打开数据库，让其创建当前库相对应的 redo 文件和 temp文件等
SQL> alter database open resetlogs;
15、查看数据库基本信息
# 1、查看数据库实例名和状态
select instance_name, status from v$instance;
# 2、查看数据库唯一编号和模式
select dbid, open_mode from v$database;
# 3、查看数据文件
select file_name from dba_data_files;
# 4、查看临时文件
select file_name from dba_temp_files;
# 5、控制文件所在位置是否和源库一致
show parameter control
# 6、参数文件所在位置是否和源库一致，如果没有，则创建
show parameter pfile
15.1、创建参数文件，如果出现ORA-32001错误时，SPFILE is not，也可使用该方式（扩展）
# 1、管理员登录 <--- sqlplus / as sysdba
# 2、查看是否存在文件 <--- show parameter spfile;
# 3、从pfile创建spfile文件 <--- create spfile from pfile;
# 4、关闭数据库 <--- shutdown immediate;
# 5、开启数据库 <--- startup
# 6、查看是否生成文件 <--- show parameter spfile;
# 7、再次执行一下命令即可alter system set UTL_FILE_DIR='/home/oracle','/home/oracle/temp','/home/oracle/scripts' scope=spfile;
16、关闭数据库，启动监听，并重新打开数据库
SQL> shutdown immediate
lsnrctl start
SQL> startup
三、Rman还原控制文件
形式：如果某个控制文件被删除或者出错
重点：一定注意，记得备份，记得备份，记得备份
1、使用 Rman 进入，开启 nomount 模式
rman target / nocatalog
Rman> startup nomount
2、还原控制文件
Rman> restore controlfile from '[文件保存路径]';
3、恢复数据库
Rman> recover database;
4、打开数据库，可能会出现报错，提示你需要重建控制文件或者不重建
- 重建控制文件：会导致之前所有的数据文件丢失，整个系统恢复成全新的状态
Rman> alter database open;
####################################################################################
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of sql statement command at 03/18/2023 11:44:18
ORA-01589: must use RESETLOGS or NORESETLOGS option for database open
####################################################################################
Rman> alter database open RESETLOGS;
- 不重建控制文件：
5、数据库即可正常使用
四、Rman增量备份恢复
1、查看最近一次的增量备份的scn
Rman> list backup to database
2、恢复数据库
Rman> restore database
3、还原数据库
Rman> recover database until scn [增量备份的SCN号]
4、更新重做日志
Rman> alter database open resetlogs;
五、Rman校验DB并自动修复（少用）
前提：需要存在备份
1、Rman校验
前提条件：
- DB 必须开启归档模式
- 必须有一个 0 level 备份（全备）
- Rman使用归档日志进行恢复
- 损坏的数据块可以从闪回日志还原
2、查询 DB 中有哪些错误：
-
进入 RMAN 模式下，输入
list failure; <-- 显示出有哪些错误 advise failure; <--- 建议修复方式 repair failure preview; <--- 预先执行一遍，查看流程是否正确以及使用的备份文件是否正确。不会真正的修复 repair failure <--- 修复命令 change failure; <--- 消除错误（会报错，但是再次查询错误，错误消失） -
查询数据块是否存在坏块
recover corruption list; -
校验数据块（视图：v$database_block_corrupti）
- 指定数据块，校验文本，是否存在坏块
- 确定文件是否存在或者是否保存在正确的位置
- 检查单个备份集和数据块
- 跳过未使用的数据块
- 显示失败的日志
六、逻辑导出\导入
注意：
1、如果文件名重复，那么后来的文件就会将之前重复的文件进行覆盖，之前备份的文件就不在存在
2、exp无法备份无段的空表
重点：执行逻辑导入、导出时，一定要注意字符集的使用，最好先使用包含中文的小表进行测试，防止导出时中文乱码，就无法恢复数据，网阔必须流畅不能断
1、保证导出数据一致性
1、如果导出某个时间点之前的数据，如果持续时间一小时或者几小时不等，期间数据库有提交新的事务在操作，改变了之前的数据，并且900秒内并没有导出该表，其过期数据可能会被数据库回收，一段时间后，需要导出该表，那么必须去undo表空间查找其历史记录，这个时候，已经过了数据过期时间的规定点，undo中已经没有该历史数据了，那么导出就会报错，找不到数据
解决办法：
1、在导出命令中加上flashback_time，指定导出数据需要的某个时间点，但还需更改其它俩个参数
2、undo_rention：预估需要的时间，然后设置undo过期时间大于预估时间，保存历史数据，防止新的事务提交对原来数据的该变，而历史数据在过期之前还未执行导出而报错
3、undo_size：当过期时间扩大时，undo表空间也同样需要扩大，最起码需要保证导出这段时间内不能因为内存问题报错，防止过多的历史数据占据空闲空间，而新的数据无法进入，导致报错
# 导出
exp userid=username/passwd tables=[导出的表名] file=[导出文件的保存位置] buffer=[小推车读写的大小] log=[新的日志存储位置]
# 导入
imp userid=username/passwd tables=[导入的表名] file=[导出后文件的保存位置] buffer=[小推车读写的大小] log=[日志存储位置]
# 带查询导出数据 ---> \ 代表这转义，没有实际意义，但必须有，否则会报错
exp userid=username/passwd tables=[导出的表名] file=[导出文件的保存位置] query=\'where [条件]\' buffer=[小推车读写的大小] log=[新的日志存储位置]
# 导入查询出来的数据
imp userid=username/passwd tables=[导出的表名] file=[导出文件的保存位置] ignore=y buffer=[小推车读写的大小] log=[新的日志存储位置]
# 闪回导出数据 ---> 闪回导出必须要system用户，但 sysdba 用户不可
exp userid=username/passwd tables=[导出的表名] file=[导出文件的保存位置] buffer=10000 flashback_time=\"to_timestamp\(\'2023-03-23 14:35:00\',\'yyyy-mm-dd hh24:mi:ss\'\)\" log=[新的日志存储位置]
# 闪回导入数据 (有待考究) ---> 其中 full 代表着：可能是将所有的导出的闪回数据都重新导入回去
imp userid=username/passwd file=[导出文件的保存位置] full=y ignore=y
# 导出用户
exp userid=username/passwd owner=[用户名] file=[导出文件的保存位置] buffer=1048576 feedback=10000 log=[新的日志存储位置]
# 导入用户
imp userid=username/passwd full=y file=[导出文件的保存位置] buffer=1048576 feedback=10000 log=[新的日志存储位置]
# 跨用户导入数据：apps --> tom formuser：指的是从哪个用户将数据导出 touser：哪个用户接收数据
imp userid=username/passwd file=[导出文件的保存位置] formuser=[导出数据的用户名] touser=[接收数据的用户名] [tables <-- 可以指定，不指定就默认全部导入的对象的用户] buffer=1048576 log=[新的日志存储位置]
# 使用主机管道压缩备份文件
mknod 路径/执行程序名称(自己指定) p
exp userid=username/passwd owner=[用户名] file=[导出文件的保存位置] log=[新的日志存储位置] expbk/exp_pipe & gzip < mknod 定义的路径> [压缩名称.gz]
跨数据库传输表空间原理：
俩个库：都有控制文件、数据文件、系统表空间、其它的表
2、导出数据出现乱码的几种情况
- 源库和目的库的字符集编码不一样
- 应用与DB之间字符集编码不一样
- 数据加密
- 数据库内部加密会自动解密，不影响数据的正确使用
- 通过第三方加密的数据，并没有通过第三方工具进行解密，直接使用，就会乱码
七、不完全恢复
1、备份所有数据文件
2、确定灾难产生时间
exec dbms_logmnr.add_logfile('/12C_DB/db/fast_recovery_area/ORCL/archivelog/2023_05_23/o1_mf_1_17_l6r7rjmw_.arc',dbms_logmnr.new);
exec dbms_logmnr.start_logmnr(options=>dbms_logmnr.dict_from_online_catalog);
select scn,sql_redo from v$logmnr_contents where lower(sql_redo) like 'drop%' and seg_owner='SYS';
# 1、开始挖掘，首先当前组，查看当前组所在位置,然后查看当前组日志文件所在位置
select * from v$log; <--- 查询当前所在组的编号
select * from v$logfile; <---- 利用当前所在组的编号对应redo日志
# 2、一个一个查找，三个文件找到对应的scn号，将查找到的scn号转化为具体时间
select scn_to_timestamp(scn <-- 【就是上面sql语句查出来的scn号】) from dual;
# 3、将数据文件传输到备份数据库上
# 4、保证备份数据库上的 SID，唯一数据库名，归档日志路径，重做日志路径和正式数据库上的路径不一样
export SID = [不和源库的SID一致]
db_unique_name string orcl <-- show parameter name
instance_name string orcl <-- show parameter name
db_recovery_file_dest string /12C_DB/db/fast_recovery_area
v$logfile <-- 表中查看重做日志路径
# 4、重做控制文件
create controlfile reuse database orcl reserlogs archivelog
datafile
'[传输数据文件的保存路径，需要将所有传输过来的数据文件都此形式写出来]'，
'[传输数据文件的保存路径]'
logfile
group 1 '[写入想要保存的redo日志路径，必须和 DB 参数中的路径保持一致，但不得与源库的路径一样]' size 50m,
group 2 .......;
# 5、判断重做日志从归档日志哪个位置开始写入数据
recover database using backup controlfile until change [scn]； <-- 当前scn号是之前重数据库中挖掘出来的scn号，输入之后会显示出应该重哪个归档日志开始恢复，然后输入 <--- auto 即可恢复日志应用介质
# 6、使用 resetlogs 打开数据库即可
alter database open resetlogs;
# 7、然后逻辑导出当前误删除的表
exp <-- 导出 imp <-- 导入
![[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-zI8uLCpC-1687763866009)(C:\Users\admin\AppData\Roaming\Typora\typora-user-images\image-20230328171525130.png)]](https://i-blog.csdnimg.cn/blog_migrate/1c065ad4c471a9addfa34b3f5074e3f9.png)
八、删库跑路–恢复DB
背景：使用DBCA删除整个DB系统，元数据文件都不存在，但是存在元数据、控制文件、参数文件以及所有的归档日志的全备
1、恢复DB
# 1、进入DB中，尝试是否能启动DB，一般都是报错
startup
# 2、尝试还原参数文件，因为DB想要启动的第一件事就是获取参数文件
restore spfile from '保存位置';
# 3、创建一个 spfile 参数文件，然后重新启动到 nomount ，使其运用刚创建的 spfile 文件
create pfile from spfile;
shutdown immediate
startup nomount
# 4、参数文件还原之后可以使DB进入nomount状态，这个时候就可以进行控制文件还原，但注意：在进入nomount状态时，如果参数文件中相关参数值没有相应的实现，那么就会报错，这个时候就需要查看对应参数文件中参数值是否少了或者在相关目录下没有该文件
#################################### 情景再现 ###########################################
RMAN> startup nomount
connected to target database (not started)
RMAN-03002: failure of startup command at 05/23/2023 17:24:40
# 当前错误就是 --> 审计跟踪文件无法生成，是因为规定的参数值中，少了一个目录，所以无法创建相关文件
RMAN-04014: startup failed: ORA-09925: Unable to create audit trail file
Linux-x86_64 Error: 2: No such file or directory
Additional information: 9925
#########################################################################################
# 5、当一切准备就绪之后，并且DB也启动到nomount状态时，就可以还原控制文件
restore controlfile from '【保存路径】';
# 6、打开到mount状态，查看当前控制文件是否识别到目前所需的所有备份文件，如果没有，则使用扩展中的语句
alter database mount; -- 启动到 mount
list backup; -- 查看是否存在所需备份文件
#################################### 扩展 ############################################
# 如果存在多个控制文件，并且控制文件生成具有先后顺序的话，如果不使用最近的控制文件进行还原，可能存在控制文件清单中不存在后续的备份文件，也就无法识别到后续的备份文件，就无法还原控制文件中不存在的备份文件，那么就需要将相关备份文件添加到清单中，让其识别出后续的备份文件
# 添加备份文件信息到控制文件中
RMAN> catalog start with '【其它无法识别的备份文件路径】';
# 再次查看是否识别了
list backup
#########################################################################################
# 7、还原数据库
restore database;
# 8、恢复数据文件
# 当前命令执行完之后可能会保存，是因为当时做最后一个备份时，DB 会自动切换redo日志文件，这样不管当前redo在做什么，接下来的操作都不会影响，所以恢复完之后只需 resetlogs 打开就行
recover database; -- 会自动寻找相关的日志文件
# 9、打开数据库，使用当前方式打开数据库之后，立马要做一个全备，因为当你以该方式打开之后，数据库的归档日志文件序号和redo日志都将从 0 开始，也就是说和上面的备份已无任何关联，所有的日志都将从新开始编号，如果此时没有备份，DB 损坏了，那就无法使用之前的备份恢复数据库了
alter database open resetlogs;
# 10、备份数据库
Rman> backup as backupset format '[保存路径]/all_%u%r%s.bak' database plus archivelog;
# 11、如果当前DB无法登录，那么就需要重建密码文件
# 登录： sqlplus / as sysdba
# 重建密码文件： orapwd file=orapw[sid] password=[大小写、数字、字符]
2、DBCA识别实例
使用DBCA删库，备份恢复之后，再次查看DBCA中，删除选项变灰，无法再次进行删除，是因为 etc 文件夹下
oratab 无法识别实例，只需要添加一条命令即可识别
# 1、打开 oratab 文件
vim /etc/oratab
# 2、添加命令，识别当前库的实例
【SID】:【$ORACLE_HOME】:N
# 3、解析 oratab 文件
3、解析文件 – /etc/oratab
当前文件是在建库时，运行的root.sh脚本时产生的，目的就是用来识别实例，查询主机中存在多少个实例，可以手动修改
# 命令形式
【SID】:【$ORACLE_HOME】:AUTO
# 说明：
SID：指的是需要识别到的实例的唯一名称
ORACLE_HOME：实例安装时的主目录
AUTO：当前参数包含俩个值 --> Y | N
如果设置成 Y ：就代表当前实例可以自启动，同样可以使用脚本 dbstart和dbshut
如果设置成 N：表示不需要自启动，每次都需要手动开关库 <-- 建议使用
九、问题
提问：为什么不完全恢复需要resetlogs进行重做日志？
完全恢复不丢数据而不完全恢复就丢数据呢？
完全恢复和不完全恢复？
1、完全恢复
定义：完全恢复：控制文件、数据文件、联机（redo）日志、归档日志（联机日志的镜像备份，热备无法备份联机日志）
问：什么叫完全恢复？
答：① 联机（redo）日志最后一条 redo 的点和控制文件最后的一个点 cpods （checkpointondisk）进行比较 ，cpods跟随着日志写入的 scn 在变化（只要有日志写入，无论是哪个文件（控制、数据、归档等日志文件）），如果recover 做到联机（redo）日志的最后一条 redo ，并且当前 redo 的编号和控制文件中的 cpods 编号一致，那么Oracle认为当前的恢复已经把所有的日志做完了，才称之为—完全恢复
②所有文件头的时间向量（scn）都会在控制文件中存在一份，如果recover能够通过与控制文件中最新的时间向量校验，那么就叫完全恢复，否则不完全恢复
简单来说，就是将当前组最后一条 redo 的时间向量与控制文件的cpods相比较，如果相等 ---- 完全恢复
问：如果 recover 做到当前组（current）的最后一条 redo，是不是完全恢复？
答：不叫，有一个条件，cpods必须相等，如果超过 cpods （为什么能超过cpods），因为控制文件是早期备份的，当前日志中的cpods比早期控制文件中的cpods高，所有不叫完全恢复
2、不完全恢复
1、问：不完全恢复为什么要用resetlogs打开数据库，为什么不能直接开？（alter database open resetlogs）
因为需要拿到数据库宕机前的scn号，数据库宕机之后无法拿到上一刻的联机日志数据，就算当前联机日志没有丢失，都无法拿到，联机日志的时刻更新的，只能通过镜像文件进行恢复数据库，并且重做联机日志
2、二问：为什么通过控制文件recover数据库，Oracle依然认为是不完全恢复？
答：当前存在默认的联机日志，当前联机日志可能不是控制文件所需的联机日志，因为是不完全恢复，无法拿到联机日志中数据库所需的scn号，控制文件中所需的scn号在联机日志中已经成为历史的一点，因为联机日志时刻更新，导致数据库宕机时，无法重联机日志中拿到控制文件中所需的scn号，只能重做联机日志来启动数据库，重做联机日志时，其中sequence#号都是从1 开始，但是scn号永远都是上涨的，并且唯一
3、问：如果 recover 做到归档日志的某一个 scn 的位置，并且后续还有许多日志没有恢复，是否称之为完全恢复？
答：不完全恢复
十、数据迁移
一、架构
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-NaZRpXMn-1687763866010)(C:\Users\admin\AppData\Roaming\Typora\typora-user-images\image-20230412150157280.png)]
sysaux：属于工具表空间
二、数据泵
（无论在服务端还是客户端，导出的数据都会存放在服务器） —> 调用DBMS_DATAPUMP 包实现
1、方式
- expdp（导出）
- impdp（导入）
- 如果出现数据乱码，就需要删除刚才导入的所有数据，然后更改字符集编码参数，再次进行导入
- 提取数据文件的 1m~几m 数据来进行测试，查看字符集编码是否相同。可以使用 VI 打开数据泵备份的文件编码格式
2、作用
- 复制数据文件
- 重定向路径（不用过内存，效率高）
- 外接表
- 远程支持
-
在数据库内部生成一个进程且长期执行，该进程只能调用一次，用于监控数据泵的相关情况
-
优势
- 并发执行，不影响其它进程
- 监控空间消耗情况
- 重映射功能
- 数据采集和压缩源数据
- 导出时可压缩数据
- 加密
3、导入、出模式
重点：逻辑导入、出不能指定先哪个表后哪个表，而是系统先碰到哪个表就谁先，如果表中存在约束关系，导出可能会按照约束关系来，但导入的时候不会按照约束关系来，而是先碰到先导入，一旦先导入外键的数据，那么主键数据不存在，该数据就会报错，所以只能适用于测试环境，生产环境慎用
特别重点：一定要注意导入导出时的字符集编码，如果字符集编码不一样，无论是导入还是导出，文件都不可用
-
全部、单表、模式、表空间、传输表空间和传输数据库导出、入
-
传输表空间：将定义传输过去，复制数据文件到目标数据库，引用数据文件即可
-
同平台：Linux和windows属于同平台
-
跨平台：涉及到字节序不同，最后解析出来结果不一样，如：Linux和unixs字节序就不一样，需要进行转换，其中Oracle本身自带 Rman 工具即可转换，Rman 不止做备份
Rman > convert database [平台名称] '实例名称' -
数据库版本：因为数据泵只有在Oracle10G（10.2.0.1）上才有，如果俩个平台中有一个低于该版本，那么将无法使用数据泵，当然，可以更改其中参数，使其达到高版本
# 修改参数 show parameter compatible 12.1.0[默认跟随当前数据库版本]
-
-
4、使用数据泵刻制表到外部盘（取数）
解析：① 如果不看 organization external 这段，就是一个简单的刻制表结构与定义和数据的操作
② 从整体上看，首先对源表进行刻制，然后通过数据泵的形式将刻制表中的数据导入到中
# 1、创建目录
create directory [目录代称] as '【目录】';
# 2、授权给某个用户对该目录的读写权限
Grant read,write on directory 【定义的目录代称】 to 【用户】;
# 3、导出数据
create table [表名](字段名 类型 【约束，可写可不写】)
organization external
（type ORACLE_DATADUMP【加载方式】 DEFAULT DIRECTORY [填写文件所在目录]
location (【数据文件名称】）)
parallel 【并发个数】
as
select [与上诉需要刻制的字段保持一致] from [表名]
三、SQL*Loader
注意：什么工具做导入，就什么工作做导出，如果混淆使用，可能导致数据失效
1、主要用于导出操作系统上的文本数据（有一定格式）导入到数据库中
![[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-cMfEDJ0v-1687763866015)(C:\Users\admin\AppData\Roaming\Typora\typora-user-images\image-20230417171239742.png)]](https://i-blog.csdnimg.cn/blog_migrate/5eebd6578fd348d72e039ce907567db5.png)
-
Control file：用来管理数据如何导入、导入的格式问题，控制文件必须以 【.ctl】后缀结尾
-
①sqlldr会首先加载控制文件，选择符合控制文件要求的数据进入，②到条件判断阶段，判断是否符合条件要求，③ 接下来进入数据库中，同时还会再次判断是否符合相关要求，是否存在相关约束 ④ 插入到DB中
注意：② 、③步骤其实是一步，扩展开来
- 如果不符合①控制文件中的解析要求，就会进入到Bad file中
- 如果不符合②条件判断，当前数据就会进入到Discard file文件中
- 如果不符合③条件判断，同样进入到Bad file中
-
在这一期间，同时会写入相关日志，记录其中操作
-
加载数据基本命令
# 脚本填写 [ load data infile '[导入数据文件所在位置]' badfile '不符合第一和第三步要求的数据存放的位置' into table [导入数据的表名] fields terminated by '，' <-- 代表着字段使用逗号隔开 optionally enclosed by '"' <-- 代表着字符串使用双引号引起来 （column name） <--- 数据插入的数据表的字段名 ] # 用户加载脚本 sqlldr 用户名/密码 control=【控制文件脚本】
2、使用ORACLE_LOADER定义外部表（读）
-
将外部表的数据导入到新表中
create table [表名](字段名 类型 【约束，可写可不写】) organization external (type ORACLE_LOADER【加载方式】 DEFAULT DIRECTORY [填写文件所在目录] access parameters (records delimited by newline【代表隔行就是新的一行数据】 badfile extab_bad_dir:'[文件名字格式]' logfile extab_log_dir:'[文件名字格式]' fields terminated by ','【代表着字段使用逗号隔开 】 missing field values are null【代表缺省的字段值使用null表示】 (读取表的字段名，可能存在时间格式转换)) location (【数据文件名称】)) parallel 【并发执行个数，此处填数字】 reject limit【拒绝限制，当达到多少拒绝次数时，终止数据读取，也可不限制，但意义不大】 unlimited【不限制，慎重填，可不用这个】
十一、闪回
重点：① 闪回只能在当前DB上做，不能像Rman一样可以平移到另一个DB上做，然后再倒回想要的数据到生产库。闪回是不支持该方式的，所以风险很大，但效率相对于备份恢复高
② 闪回只针对逻辑上的错误，无法改变物理上的错误（如：错误删除某一文件，使用闪回日志回退，是无法回退回去的，只能备份恢复）
③闪回后的数据，其rowid会被更改
④ 要想开启闪回，必须先打开归档日志
⑤ 闪回日志和重做日志是俩套独立的日志，互不干扰
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-AQpsaoS6-1687763866015)(C:\Users\admin\AppData\Roaming\Typora\typora-user-images\image-20230626115455305.png)]
查看闪回日志信息
# 表：v$flashback_database_log
# 字段解析：
OLDEST_FLASHBACK_SCN：使用当前的闪回日志，能将数据库闪回到哪个SCN点
OLDEST_FLASHBACK_T：使用当前的闪回日志，能将数据库闪回到哪个时间点
RETENTION_TARGET：可完成多长时间内的闪回操作
FLASHBACK_SIZE：当前闪回日志所占字节数
ESTIMATED_FLASHBACK_SIZE：根据当前的业务负载量，为满足 RETENTION_TARGET 参数时间设置，需要多少字节的闪回日志空间
一、闪回表查询
声明：闪回查询无法跨越DDL操作语句，只能闪回到DDL操作语句后的时间，闪回空间大小和db_recovery_file_dest空间大小关联，当该空间满了时，闪回就会报错，这个时候需要扩大空间即可解决
1、数据库闪回默认保存时长（分钟）
# 误删数据，24小时内即可恢复
SQL> show parameter db_flashback_retention_target
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_flashback_retention_target integer 1440
2、恢复历史数据（flashback不支持sys用户）
**方法一：**当前操作是将某个表直接退回到某个时间点，而不是反向更新，直接退回到某个时间点，那么退回的时间点到当前时间点之间的所有操作都需要重新进行，风险相对较大
# 1、查询当前数据库的系统时间
select to_char(sysdate,'yyyy-mm-dd hh24:mi:ss')from dual;
# 2、查询删除数据时前十分钟的数据是否存在需要被恢复数据
select * from 【表名】 as of timestamp to_timestamp('2023-01-13 14:10:43','yyyy-mm-dd hh24:mi:ss');
# 3、开启表的行移功能，不开启则出现报错 ----- ORA-08189：未启用行移动功能，不能闪回表；
alter table 【表名】 enable row movement; -- 开启行移动功能
# 4、如果存在，则将时间复制到下面的语句 注意：执行当前语句时，如果没有开启当前表的行移功能，则会报错
flashback table 【表名】 to timestamp to_timestamp('2023-01-13 14:10:43','yyyy-mm-dd hh24:mi:ss');
# 5、 关闭行移动功能
alter table 【表名】 disable row movement;
注意：如果使用的是truncate 语句，则无法使用闪回查询进行数据恢复，
- 因为其将表的定义及结构都删除了，真正意义上的空表
- 无论是表定义还是结构被修改，都无法恢复到原来的数据结构，只能使用备份文件
**方法二：**反向更新数据，不用退回到历史某个点，而是根据历史点创建一个新的视图来接受历史时间点的数据，然后通过视图与原表的关联进行数据更新，这样就不需要重做历史时间点到当前时间点的所有操作，风险相对较小
# 1、查询当前数据库的系统时间
select to_char(sysdate,'yyyy-mm-dd hh24:mi:ss')from dual;
# 2、查询删除数据时前十分钟的数据是否存在需要被恢复数据
select * from 【表名】 as of timestamp to_timestamp('【上面查询的时间】','yyyy-mm-dd hh24:mi:ss');
# 3、创建一个视图接收未修改之前的数据
create view v01 as (select * from apps.trainee as of timestamp to_timestamp('【上面查询的时间】','yyyy-mm-dd hh24:mi:ss'));
# 4、对原表数据进行更新
update apps.trainee set tel=(select tel from v01 where apps.trainee.traineeid = v01.TRAINEEID);
# 5、查询数据是否正确
select * from 【原表】;
# 6、提交即可
commit;
3、flashback
定义：快速数据库数据恢复机制
优点：快速、在线恢复，无需关库、操作简单
缺点：
- 只是用于逻辑错误，例如：错误删除某些数据，对数据文件没有损坏等
- 受限于undo表空间的大小，空间不足的请款下，旧的undo空间的数据会被新的数据覆盖，适用于短时间的数据恢复
4、闪回后的对象其关联属性
-
drop某一个对象，其相关约束、索引、存储过程、触发器等属性，会一起删除，但是恢复之后需要重新编译，需要更改其名称，因为drop掉对象之后，相关属性的名称会自动根据回收站定义的形式来命名，所以需要更改名称
-
当同一对象经历多次drop时，回收站此时会存在多个名称一样的对象，此时如果不指定名称，默认恢复的对象时离当前时间最近的对象，只有指定恢复某一个对象时，才不会默认恢复
-
不指定对象闪回
# 1、查看回收站 SQL> show recyclebin; ORIGINAL NAME RECYCLEBIN NAME OBJECT TYPE DROP TIME ---------------- ------------------------------ ------------ ------------------- HKBN BIN$/G01bMFI1IbgVQAAAAAAAQ==$0 TABLE 2023-05-24:17:14:04 T01 BIN$/G4SX5kQPd7gVQAAAAAAAQ==$0 TABLE 2023-05-24:17:50:59 T01 BIN$/G4SX5kOPd7gVQAAAAAAAQ==$0 TABLE 2023-05-24:17:49:28 T01 BIN$/G4SX5kNPd7gVQAAAAAAAQ==$0 TABLE 2023-05-24:17:49:20 # 2、不指定闪回对象，默认闪回 SQL> flashback table t01 to before drop; Flashback complete. # 3、闪回后再次查看回收站，确定是离当前最近时间的对象被闪回 SQL> show recyclebin; ORIGINAL NAME RECYCLEBIN NAME OBJECT TYPE DROP TIME ---------------- ------------------------------ ------------ ------------------- HKBN BIN$/G01bMFI1IbgVQAAAAAAAQ==$0 TABLE 2023-05-24:17:14:04 T01 BIN$/G4SX5kOPd7gVQAAAAAAAQ==$0 TABLE 2023-05-24:17:49:28 T01 BIN$/G4SX5kNPd7gVQAAAAAAAQ==$0 TABLE 2023-05-24:17:49:20 -
指定对象闪回，可以进行任意恢复，但回收站的数据只能查（不能用于业务上），不能修改
# 1、查看回收站中的对象 SQL> show recyclebin; ORIGINAL NAME RECYCLEBIN NAME OBJECT TYPE DROP TIME ---------------- ------------------------------ ------------ ------------------- HKBN BIN$/G01bMFI1IbgVQAAAAAAAQ==$0 TABLE 2023-05-24:17:14:04 T01 BIN$/G4SX5kUPd7gVQAAAAAAAQ==$0 TABLE 2023-05-24:17:53:38 T01 BIN$/G4SX5kSPd7gVQAAAAAAAQ==$0 TABLE 2023-05-24:17:52:19 T01 BIN$/G4SX5kRPd7gVQAAAAAAAQ==$0 TABLE 2023-05-24:17:51:33 T01 BIN$/G4SX5kOPd7gVQAAAAAAAQ==$0 TABLE 2023-05-24:17:49:28 T01 BIN$/G4SX5kNPd7gVQAAAAAAAQ==$0 TABLE 2023-05-24:17:49:20 # 2、查询哪个对象是需要被闪回的，查询的时候，需要给回收站中的对象添加双引号，因为存在非法字符 SQL> select * from "BIN$/G4SX5kSPd7gVQAAAAAAAQ==$0"; ID ---------- 1028 # 3、指定当前闪回对象 SQL> flashback table "BIN$/G4SX5kSPd7gVQAAAAAAAQ==$0" to before drop;
-
二、闪回事务查询
1、查询俩个时间点之间做的所有事务操作，存在多少个版本
select versions_xid,tel from apps.trainee versions between timestamp to_timestamp('【某个事务开始时间点】','yyyy-mm-dd hh24:mi:ss')
and to_timestamp('【某个事务结束时间点】','yyyy-mm-dd hh24:mi:ss');
2、使用闪回事务查询，查询某一个版本对应的所有事务操作
select undo_sql from flashback_transaction_query where xid='【对应上面查询的 versions_xid】';
3、执行所有查询出来的 undo_sql ，才能保证事务的完整性
4、俩种情况
情况一：某一个事务将一个表中的某一列数据进行更改，用户只执行了某一条数据的undo_sql，对某一条数据进行恢复 <-- 不合理，影响当前版本的一致性，因为上一个事务是更改了整列的数据，而你只用了某一条数据的undo_sql进行修改，俩者版本已经不一致了，违反事务的一致性和完整性约束（是不被允许的）。如果想抵消事务，那必须抵消上一个事务对所有对象的事务操作，执行所有的undo_sql，回退所有事务，该事务才能被抵消，这样才能保证事务的一致性的完整性
例：取钱：当账户A减少100，账户B增加100，C用来记录交易，当我执行了账户B的undo_sql，抵消它单给账户的事务，其它俩个没有抵消，那么就会造成账户A少了100，而账户B并没有增加钱，显然是不对的。只有抵消转账操作，才能完成回退所有事务，将A账户添加100，B账户减少100，C 记录交易，这样才能保证事务的完整性和一致性
情况二：当前事务的步骤：① 在T01添加一条数据 ②在T02 更新一条数据 ③在T03表中删除一条数据 ④提交
当后台发邮件说，T03表中的一条数据被误删除，当管理员使用闪回查询，找到删除前的数据，并且闪回到当前T03表中，然后后台去使用，发现还是不对。这个时候管理员发现，T03表中的数据是需要T01表中添加一条数据，T02表中修改一条数据，才能在T03表中删除一条数据，经历了一个完整的事务，而管理员只是单纯的闪回了T03表中的数据，那这样就损坏了之前事务的完整性。要想找回该数据，只能调用闪回事务查询中的undo_sql，当你闪回事务查询时，之前数据版本涉及到多个事务的操作，所以必须执行所有undo_sql，才能抵消三个表中的事务修改
二、闪回开启
注意：开启闪回具有前置条件
# 1、回收站处于 open 状态
# 2、超过闪回时长，则无法使用闪回，默认24小时 <-- 不建议修改
# 3、归档是否开启
# 4、开启闪回
-
查询闪回是否开启
select flashback_on from v$database; -
查询闪回空间使用率
select * from v$flash_recovery_area_usage; -
开启 DB 归档功能（前提条件）
alter database archivelog/noarchivelog; #开启 or 关闭 -
开启闪回功能
1、开启闪回功能
会相应的打开闪回的进程，并且创建一个闪回文件，里面包含闪回日志 《=== 二进制的
2、关闭闪回功能
会相应的停止闪回的进程，并且自动删除闪回日志
alter database flashback ON/OFF; # 开启 or 关闭 -
闪回日志无法更改路径（默认在快速恢复区下的flashback路径下，当然也可以更改其快速恢复区路径）
# 存在 $ORACLE_BASE/flash_recovery_area/ORCL/flashback 路径下
三、数据迁移
- 定义：哪个表的数据需要迁移出来，那么 using 关键字后面就跟哪个表，merge into 后跟嵌入数据表
- matched 关键字：确认 on 后面跟的条件是否对的上，如果对的上，那么进入 matched 语句进行处理，反之进入 not matched语句
- 注意：merge只适合数据量小的时候，如果数据庞大，优先考虑俩条SQL进行处理
merge into fd f using zd z on (f.fs_id=z.s_id)
when matched then
update set f.fs_price=z.s_price
when not matched then
insert values(z.s_id,z.s_name,z.s_price);
四、闪回技术范围
1、表
情况一
错误的删除（drop）表，可以通过回收站找回，但是它受时间限制，默认900秒（15分钟内）可以找回，也受空间限制
情况二
数据库所有对象修改过的表的历史数据，都保存在 undo 表空间中，保存时长受表空间大小以及规定时间限制，如果保存的数据时间越长，可能当前对象的历史数据占空间越来越小，因为空间不足，导致历史数据虽然没过期，却查不到了 ，因为会有其它对象修改历史数据，如果他们数据量大，超过undo表空间大小，undo就会自动回收最开始的数据，直到新修改的数据全部存入为止，导致原来的历史数据无法找到。因为undo 时间和空间的限制，无法存放太长时间的历史数据，早期数据可能查不到，就会报错 ORA-01555（快照数据过旧，因为历史数据查不到了，数据已经被清理或者回收了）
11G时DB新特性：历史数据归档
① 新建永久表空间，大小受限于磁盘空间 ②将重要的表指向该空间，历史数据都指向该空间
情况三
错误的DML操作语句，可以通过查询历史数据是否存在undo表空间中，如果存在，则可以闪回到当前表
# 1、获取OCA证书（直接OCA OCP一起考）
# 2、有原厂或者WDP（授权培训机构）的培训记录
# 3、通过12C 063的考试
# 4、通过hands on的申请，72小时内发放证书
Create table apps.x
(
Devices_id NUMBER NOT NULL, -- 主键
HHT_NUMBER Number Not Null, -- 设备号
CYC_HEADER_ID NUMBER NOT NULL, -- 任务号
CREATED_BY Number Not Null,
CREATION_DATE Date Not Null, -- 创建时间
LAST_UPDATE_DATE Date Not Null, -- 最后更新 / 修改时间
LAST_UPDATED_BY Number Not Null,
LAST_UPDATE_LOGIN Number
);
-- 唯一索引
Create Unique Index apps.x_U1 On apps.x(Devices_id);
-- 序列
Create Sequence apps.x_S Start With 10001;
create table apps.trainee(
TraineeID number(6),
TraineeName varchar2(20),
Sex varchar2(4) default '男' check(Sex in ('男','女')),
identifiedly varchar2(12) default '全职员工'
check(identifiedly in ('全职员工','实习生')),
Address varchar2(100),
Tel number(11),
BankID number(21),
constraint pk_TraineeID primary key(TraineeID)
);
insert into apps.trainee(TraineeID) values(1);
五、闪回数据库
十二、处理数据库的故障
1、物理检查
1、检查数据坏块 - dbv
重点：当前检查是检查数据块物理上存在的错误，检查出来的错误是不能自动修复的，需要手动修复，并且一定存在备份，如果没有备份，那么就不能使用该方法修复
检查语句一：
# 检查语句一：
dbv file=【数据文件完整路径，包括数据文件名】 <-- 当前检查只能在数据文件好的时候可以用，一旦出现坏块就没有任何用处
# 如：系统数据文件检查
dbv file=/12C_DB/db/oradata/orcl/system01.dbf
DBVERIFY: Release 12.1.0.2.0 - Production on Fri May 26 11:48:05 2023
Copyright (c) 1982, 2014, Oracle and/or its affiliates. All rights reserved.
DBVERIFY - Verification starting : FILE = /12C_DB/db/oradata/orcl/system01.dbf
DBVERIFY - Verification complete
Total Pages Examined : 102400
Total Pages Processed (Data) : 67028
Total Pages Failing (Data) : 0
Total Pages Processed (Index): 13718
Total Pages Failing (Index): 0
Total Pages Processed (Other): 4786
Total Pages Processed (Seg) : 1
Total Pages Failing (Seg) : 0
Total Pages Empty : 16868
Total Pages Marked Corrupt : 0 --> 标记坏块的数量
Total Pages Influx : 0
Total Pages Encrypted : 0
Highest block SCN : 3256665 (0.3256665)
检查语句二：
# 可以使用检查语句，查询哪些数据文件存在坏块，在 Rman 下使用该命令
Rman> backup validate database; <-- 显示哪些数据文件存在坏块，不会显示坏块的编号
2、blockrecover（修复坏块）
存在问题：12C 当某一个数据文件出现数据坏块的时候，当前检查根本无法使用，并不能检查出来坏块的地方，只能通过手动查询当前数据文件存在的数据表查询出来，如果使用blockrecover来恢复DB，该方式只适用于12C以下的版本。
修复坏块：11G版本可以使用 blockrecover 来修复坏块 12C版本就不适用该方法
11G版本：
########################### 11G 坏块修复流程 #############################
# 知道坏块位置时，使用该方法。效率高，同时不用下线相关数据文件，不影响连接
Rman> blockrecover datafile [编号] block [编号];
12C以上版本
# 不知道坏块位置时，可以使用以下方式修复：
# 1、将坏块文件下线
alter database datafile [编号] offline;
select SEQUENCE#,NAME from v$archived_log order by SEQUENCE# asc;
# 2、进入 RMAN 还原坏块数据文件
restore datafile [编号];
# 3、恢复数据文件
recover datafile [编号];
# 4、上线数据文件
alter database datafile [编号] online;
2、exp（expdp）
重点：导出数据时，如果出现了坏块，那么整个导出的数据都将失效
2、逻辑检查
1、ANALYZE
重点：当前检查数据块上是否存在逻辑错误，检查出来的错误不能自动修复
比如说：物理上的数据存储位置发生变化，rowid改变了，而当前数据上的索引的位置没变，索引上的rowid没有及时更新（索引失效），导致使用索引进行查询数据的时候，出现逻辑坏块
2、闪回（可修复逻辑坏块）
3、DBMS_REPAIR
4、Block media Recovery（不检查）
重点：调用Rman中的备份进行修复，当前方式一定要存在备份，如果没有备份，那么将无法恢复
十三、监视和管理内存（15节）
十四、管理数据库相关模式下的对象
一、堆积表
特点：数据存储杂乱无章，先插入的数据rowid值由小变大，但也并不是一成不变的，如果先存储的某条数据被删除，那么其占有的rowid就会被释放
作用：
二、分区表
重点：可以以任何列做分区筛选条件，
1、作用：提高数据检索效率（应用对数据增删改查的效率，便于管理），每个分区都会拥有自己段
2、什么是分区表以及为什么使用它？
从哪几个方面去判断表大还是表小，以下可做参考：
- 数据量多或少：数据表的定义关乎数据量的多少。如果一个表中有十亿条数据，但只有俩到三个字段（可能只占2G空间），另外一个表中只有十万条数据，但是存在十到十五或者更多字段（可能占10G空间）
- 碎片空间：在操作中删除的数据或者表，它依然存在当前空间，只是名称定义被更改，普通用户无法查询，造成碎片冗余，增大空间
- 字段定义类型（如：可变长度（varchar）和定长（char））：可变长度和定长的根本区别在于：存储一个五个字符长度的数据，可变长度定义给10个字节，那么当前数据在可变长度中，只会占用5个字符空间。如果是定长，那么存储时，剩余的空间将用占位符代替，消耗空间 <-- 当前设想都是在英文字符集下
- 数据库建库的字符集编码（如：传统字符集（单字节存储），中文字符集（ZHS164GBK：14个字节存储），国家字符集（UTF8或者UTF16：39位））：对于不同字符集，针对单个字符的存储结构
特性：
- 具有相同的逻辑属性、约束和索引d等
- 降低IO开销，将数据分流到不同的表空间里去
- 应用程序上是透明的，感知不到数据存储在多个表空间中。如：将不同时间段的数据分开，昨天的数据存放到A 表空间中，今天的实时数据，存放到 B 表空间中，对应用程序的运行没有任何影响
- 缺点非常明显：
- 如果某一个表出现错误，对于数据恢复是否存在影响？
3、创建分区表的方式
# 创建分区表，处于同一表空间
create table pt_range_test1(
pid number(10),
pname varchar2(30)
) partition by range(【分区字段】)(
partition 【分区别名】 values 【分区条件】 tablespace 【表空间名称】,
partition 【分区别名】 values 【分区条件】 tablespace 【表空间名称】,
partition 【分区别名】 values 【分区条件】 tablespace 【表空间名称】
) enable row movement;
# 查询当前用户下的分区表情况
select * from user_tab_partitions t;
-
Range（范围）
-
重点：分区范围拼接起来要能够涵盖当前表中分区字段的所有可能出现的值，不能存在某一条数据没分区放
-
如：以 id 为单位，低于 1000 的，存放到 A 分区，低于 2000 的大于 1000 ，存放到 B 分区，其余存放到 C 分区
# 插入数据 insert into pt_range_test1 (pid, pname) values (1, '瑶瑶'); insert into pt_range_test1 (pid, pname) values (1500, '倩倩'); insert into pt_range_test1 (pid, pname) values (null, '优优'); commit; # 查看不同分区的数据。也可单独查看 select 'P1' 分区名, t.* from pt_range_test1 partition (p1) t union all select 'P2' 分区名, t.* from pt_range_test1 partition (p2) t union all select 'P3' 分区名, t.* from pt_range_test1 partition (p3) t
-
-
Hash分区（散列分区）
- 重点：把数据均匀分布
-
List分区（列表分区）
- 重点：当前分区是以值（表中字段值）来划分分区，当某一个字段分区的数据量过大时，
-
reference分区（引用分区）
- 重点：参照别的分区表进行分区
4、分区表索引创建
-
局部索引
提升当前局部分区检索效率，
-
全局索引
三、索引组织表
特点：基于索引架构的表，本身存在索引
问题：跟传统的索引表有什么区别？
① 索引组织表必须存在主键值，当前表所生成的数据必须基于主键生成。
②索引组织的叶子节点上存放的不单是索引值和rowid。
③索引组织表的叶子节点上存放的是 索引键值（通过主键约束生成）–> 即主键值、非主键值以及数据头的定义（即存放完整数据）
优势：①叶子节点上存放整条数据 ②rowid只存放一份 ③ 不在通过rowid来定位数据，而是通过主键值
缺点：① 主键不能是延迟类型的
1、创建索引组织表语句
# 建表
create table [表名]
(country_id char(2) constraint country_id_nn not null,
name varchar2(20),
symbol varchar2(25),
map BLOB,
flag BLOB,
constraint country_id_pk primary key (country_id))
ORGANIZATION INDEX TABLESPACE [表空间名称] PCTTHRESHOLD [0-100] OVERFLOW TABLESPACE [表空间名称];
# 解析
####################
ORGANIZATION INDEX --> 当前创建表的类型是索引组织表
####################
PCTTHRESHOLD [0-100] --> 存储数据的份额，DB默认是50%，当插入的一行数据，其值大于叶子节点存储空间50%，后续的值将不再存储到当前叶子节点上，而转存到其它指定表空间中去，不破坏二叉树的平衡性。叶子节点存储空间为8K，1K=1024字节，一个字节占8位，也就是说叶子节点最大存储数据为：8（K）x1024（字节）x8（位）=65536（位）。65536 x 50% = 32768（位），也就是说，当插入一行（这里的一行指的是，当前表所有字段为一行）数据超过32768位时，后续数据将不在进入叶子节点进行存储。当然，存储份额是可以改变的，0~100都可
####################
OVERFLOW TABLESPACE --> 超出数据进入的表空间，当插入一行的数据超过上述指定的份额，那么剩余的数据将进入到当前超出表空间中
四、触表
特点：存储在不同的数据块中
应用场景：① 表中数据很少更新，查询居多 ② 多表查询 ③ 数据量大（超过2G）
优点：① 冗余少，空间占用率低 ②提高多表查询效率
缺点：① 单表查询效率降低（针对非触表）
创建触表：
# 创建触结构
create cluster [触表名称](
[使用触表的字段] [字段类型]
)
HASHKEYS [自定义大小]
SINGLE TABLE HASH IS [触键值]
SIZE [自定义大小];
###########
# 建表
create table [表名]
([字段名称] [字段类型])
CLUSTER [引用定义好的触结构] （[触表字段]）;
##########
# 解析
① 创建触表时，需先存在触结构
② 触结构中的字段可以包含多个，但必须在表中存在当前字段，且数据类型必须保持一致，每个触结构都必须有一个触键值，其它的值可做排序或者分组值
③ HASHKEYS：触键值大小可以自由定义，但字段值不能超过该大小
④ SINGLE TABLE HASH IS：指定触键值，当前值不能超过上面的hash值大小
⑤ SIZE：触结构长度，一般不建议很长，因为表与表之间关联字段不会很多
五、作为DBA，如何管理表
- 如何预估新表的大小
- 分析表的增长趋势
- 管理表的优化统计信息
- 在线对数据库对象进行重组（效率低）
- 通过中间表进行数据转换
十五、自动存储管理（ASM）
# 需要懂得哪些
1、ASM发展史
2、ASM如何与DB参数文件和DB实例打交道
3、通过SQL命令调整ASM对应的参数、文件或者磁盘
4、开启和关闭ASM实例
5、管理ASM磁盘组
6、使用RMAN迁移DB到ASM（不是全部文件都可以放到ASM虚啊）
特点：绕过底层管理
没有应用ASM技术之前读取数据流程：应用产生的数据 --> DB --> OS file（操作系统对应的文件） --> 底层硬盘
应用ASM技术读取数据流程：应用产生的数据 --> DB --> 底层硬盘
什么是实例：内存 + 进程
1、ASM解析
ASM下存在三个进程：RBAL（经理）、ARB0~ARBA（进程数），Oracle10g默认进程数最多11个进程数，11g进程数最多1024个，而12C越多，进程数越多，负载越大，搬运数据效率也就越高
RBAL（经理）：发起重平衡任务的进程
ARB0~ARBA（进程数）：搬运数据块，默认干活进程数只有一个，如果当前进程数为0，那么重平衡也将关闭
2、如何创建ASM实例
-
俩种方式生成实例
- DBCA方式生成
- ASMC方式生成
-
设置初始化参数
-
开启ASM实例
# ASM下没有open阶段，只要开启到mount阶段就可以了 正常起停 # 开机 ---> 先启ASM，再启DB，否则就无法启动,如果不启动ASM，那么就无法调用底层数据文件，那么DB就无法启动 # 关机 ---> 先关DB，再关ASM，否则报错，先断掉DB与磁盘的读取数据，之后再关闭ASM -
ASM实例
重点：管理DB产生的数据文件
# 一个 ASM 实例可以管理多个 DB 实例，多个 DB 实例对应多个 ASM 实例也可以-
ASM 下不能指定文件存储路径
如果自定以文件存储路径，ASM则会将你自定义的路径以软连接的方式指向对应的ASM指定路径上去，就会造成重平衡失衡问题，当软连接失效，DB就无法访问到ASM中的文件，DB可能就会出现问题
-
-
关闭ASM实例
异常起停 # 如果某一个实例以 abort 方式关闭，那么另一个实例同样以该方式自动关闭，但会造成数据块丢失或者磁盘损坏
3、早期文件存储历程
-
文件系统
早期文件系统以ntfs结尾命名，
-
ASM技术（10G之后出现）
通过ASM技术，避免了DB直接与文件系统打交道，而是通过中间层ASM进行处理。替换了文件系统的一部分功能，又封装了裸设备的一些功能方法
-
裸设备（10G就没有该选项了）
维护难度高，当前方式直接将文件系统与磁盘进行关联
4、ASM发展史
-
10g
# 使用同一账户管理 DB实例和ASM实例，只需要在连接的时候更改SID即可 -
11g
# 分层 DB：使用Oracle账户进行管理，sysdba具有绝对权限对DB任意参数修改 ASM：使用Grid账户进行管理，sysdba对ASM还是具有一定的操作权限，比如：添加或者划分磁盘空间 ASM账户：sysams管理ASM磁盘及磁盘组 SYS或者SYSDBA：管理ASM当中的参数配置 -
12C
# 沿用 11g 的架构，但发生改变DB账户没有权限对ASM进行管理，独立分开
5、ASM逻辑架构图
-
ASM数据最小读写单位 – 分配单元
Allocation unit(AU) -- 默认大小 1M（针对不同文件，粒度不一样） # 针对数据、归档文件 ---> 1M 大小 # 针对控制、参数文件可能更小 ---> 128K -
ASM盘（ASM disk）
# 由一个或多个 AU 组成盘 其实就是外部重新添加的磁盘，而分配给ASM的空间，就称之为 ASM盘 -
ASM文件
# ASM 文件和 ASM 盘是多对多的关系，多个文件对应多个磁盘 -
ASM磁盘组
# 一个磁盘组下可以有多个 ASM 文件，而一个 ASM 文件不能对应多个组 ---> 一对多
6、ASM异常组
问题：当一个数据文件进入到 ASM 中，如果当前数据文件为 1G ，就会划分成多个 AU（au大小根据取决于参数设置大小） 打散单个或者多个磁盘上，如果某个磁盘上的某一个块损坏了，那么整个数据文件也就损坏了，如何修复？
修复：首先对磁盘进行区域划分，划分出存储数据区域和异常组区域，通过异常组进行数据文件镜像冗余，当数据文件某个块出错，将请求划分到当前数据块对应的异常组上，对应用是毫无感知的、透明的 — 类似于 RAID1的存储结构
7、ASM磁盘组冗余–（磁盘阵列）
注意：normal和high磁盘冗余要考虑磁盘格式化和损耗的问题，再进行空间判断
-
外部冗余
只是实现磁盘的条带化功能，没有冗余，不创建镜像文件，无法启到保护数据的作用
-
normal冗余（一份源文件+一份镜像文件+一份安全空间）— 三分法
- 将整个磁盘划分出三份相当量的磁盘空间，一份磁盘空间存放原始数据，一份磁盘空间存放原始数据的镜像文件，一份空出来，空出来的这份保证拥有足够的磁盘空间再生成一份原始数据的镜像文件。防止前俩份某一份出错之后没有空间再生成镜像文件，导致normal降级，如果normal降级，会导致镜像文件出错或者压根没有生成，无法恢复。一定要以三分法的划分方式进行存储数据
- 安全空间一定要留出三分之一
-
high冗余（一份源文件+俩份镜像文件）— 五分法
- 将整个磁盘划分出五份相当量的磁盘空间，一份磁盘空间存放原始数据，俩份磁盘空间存放原始数据的镜像文件，空出俩份，空出来的这俩份保证拥有足够的磁盘空间再生成俩份原始数据的镜像文件，防止前三份某一份或者俩份出错之后没有空间再生成镜像文件，导致high降级，如果high降级，会导致镜像文件出错或者压根没有生成，无法恢复。一定要以五分法的划分方式进行存储数据
- 安全空间一定要留出五分之二
-
举例
- 单实例下，所有文件更倾向于外部冗余
- 集群下，归档日志、redo日志、闪回日志、参数文件都使用外部冗余了，因为当前几种日志所占空间较大，不适合做磁盘组冗余，其中参数文件较小，如果损坏了也容易修复，也可以做磁盘冗余，但不建议。
- 集群环境下的表决文件和注册文件一定要做磁盘组冗余，最低都应该做normal冗余，如果当前俩份文件丢失，那么集群无法起来，导致ASM也无法起来，DB就无法起来，整个系统就宕机了。
8、磁盘组动态重平衡
**超重点：**重平衡的数据字典
select * from v$asm_operation;
# 解析
SOFAR：就是目前为止挪动的AU数量12276
EST_WORK：估计要挪动的AU总数量166087
AU：ASM在分配空间时,以AU为单位进行,AU即Allocation units,是组成ASM disk的基本单元。此处的1个AU大小是4M
1、重点
一定要考虑效率，但添加的磁盘空间足够大时，超越了当前磁盘空间，将新磁盘按照原来磁盘空间进行划分，然后添加到ASM中去，目的是为了保证ASM读写的均衡，提高效率
####################################################
asm_power_limit integer 1 <-- 重平衡工作进程，默认是一个进程
asm_diskgroups string <--- 磁盘分组，ASM分到的磁盘管理组
asm_diskstring string <--- 存储位置，一般位于Linux底下的DEV路径下，当前路径专门存放外接设备
- 重平衡参数：进程数越多，内耗越大，对外服务质量可能就会变差，应用运行不流畅。因为ASM作用在磁盘与DB系统之间，如果当前进程数过多，就会导致DB运行缓慢，最后使app运行缓慢，建议10~11个进程
- ASM：对应的命令必须去到对应的命令行，不能在操作系统下的命令行使用ASM命令，即便用了也看不到
- 添加磁盘时，应该考虑其大小、规格号和版本号，防止再添加新的磁盘时，因为算力不一样，导致多块盘之间无法进行重平衡，导致冗余降级
2、例题
举例：当ASM中存在俩块盘，并且空间所剩不足时，添加一个100G的盘，作何操作？
# 应当从三个方面去考虑
① 重平衡的问题 ② 数据导入导出的效率 ③ 磁盘读写的效率
方案一：首先查看原始磁盘空间大小，按照原来磁盘空间大小划分新的磁盘空间，然后依次添加到ASM中去。ASM会自动划分一部分进程到新的磁盘上，重新设定重平衡，减少原始磁盘的IO开销，提高效率。
#########################################################################################
方案二：不查看原始磁盘空间大小，直接将100G的盘添加到ASM中，这样虽然能降低原来磁盘的IO开销，但是一段时间过后，原来磁盘空间写满，那么所有的进程将会指到新的磁盘上，产生大量的数据，这个时候可能会造成读写效率低下，同时导入导出时效率低，增加导入导出的风险，重平衡也失去其意义
9、创建或者删除磁盘组
1、创建磁盘组语法
create diskgroup [磁盘组名称] [冗余级别] redundancy
failgroup [故障组名称] disk
'[存储位置]/[名称]' NAME [当前磁盘块的别名] SIZE 120G Force，
'[存储位置]/[名称]' ，
'[存储位置]/[名称]'
failgroup [故障组名称2] disk
'[存储位置]/[名称]' ，
'[存储位置]/[名称]' ，
'[存储位置]/[名称]' ;
# 例子
create diskgroup dgroup1 normal redundancy
failgroup controller1 disk
'/device/A1' name diskA1 size 120G [Force],
'/device/A2',
'/device/A1'
failgroup controller2 disk
'/device/B1',
'/device/B2',
'/device/B3';
# 解析
SIZE 120G：当前容量指的是添加的磁盘空间大于当前磁盘组的空间，然后指定使用多少空间，剩余的空间就是不使用
Force：指的是当调用一个磁盘时，当前磁盘存储过数据，磁盘头写入过数据，那么使用force参数，就强行抹去上一份的数据，重新写入新的数据，上一份数据就没办法再恢复了 ---- 慎重使用该参数
2、删除磁盘组和磁盘
注意：删除磁盘时，删除语法执行很快，因为它只是将定义删除了，ASM会自动重平衡数据到其它磁盘上，这个时候ASM的IO开销非常大，所需要的时间也根据数据量的多少确定，因为ASM默认是1个进程在工作。查看数据字典，确认当前被删除的磁盘上的数据重平衡到其它磁盘上去了，才能物理摘除磁盘
1、删除语法
# 当前磁盘组没有写入过数据，使用该命令即可删除
DROP DISKGROUP [磁盘组名称];
# 当前磁盘组写入过数据，使用该命令删除
DROP DISKGROUP [磁盘组名称] INCLUDING CONTENTS;
2、误删除还原语法
注意：① 当你误删除某一个磁盘时，被删除的磁盘需要将数据重平衡到其它磁盘上，这个过程需要时间，在这个时间内都可以取消删除，那么数据就会自然而然的重平衡回来。
② 但如果超过了重平衡时间，重平衡已经完成，那么就撤销删除的命令就无效了，只能手动添加磁盘回去，然后再次重平衡数据。
③ 该方式需要重平衡俩次，期间会浪费大量的时间和IO开销，并没有得到很好的效果
# 删除磁盘
alter diskgroup [磁盘组名称] drop disk [磁盘名称/别名];
# 撤销删除
alter diskgroup [磁盘组名称] undrop disk;
3、磁盘组添加磁盘
注意：添加磁盘后，ASM会自动重平衡数据到新的磁盘上，重平衡过程需要时间根据数据量的大小来确定
Alter diskgroup [磁盘组名称] add disk
'[存储路径]' NAME [别名]，
'[存储路径]' NAME [别名]; -- 可以添加多个
4、删除和添加同时进行
注意：当前方式只需要重平衡一次，大大减少了IO开销和时间花费
alter diskgroup [磁盘组名称] drop disk [需要删除的磁盘别名] add failgroup fred disk '[存储]' name [别名];
10、ASM创建表空间
1、创建表空间
注意：在指定ASM磁盘空间时一定要在前面添加一个 ’ + ’ ，代表ASM的根目录
create tablespace [表空间名称] datafile '+[磁盘组名称]' size [表空间大小];
2、ASM体现表空间
注意：ASM下，不同的数据文件会自动创建不同的数据文件名称作为对应的数据文件的文件夹，如：
数据文件 --> DATAFILE（文件夹名称） 控制文件 —> CONTROLFILE（文件夹名称）
-
ASM实例下的文件名
# 由三部分组成 [创建文件时对应的文件名].[文件号].[随机数 <-- 9位数组成] # 比如 create tablespace abcd datafile '+DGORUP1' size 100M; # ASM下存储应是 ABCD.1.235685964
3、连接ASM
# 设置需要连接的库
export ORACLE_SID=【名称】
# 输入对应的命令进入ASM
asmcmd
ASMCMD>ls -l [磁盘组名称]/[对应的数据库SID]/[DATAFILE]
sys
Y
# 其中 SYS 等于 Y 就代表着当前文件受 ASM 管理，如果 SYS 等于 N ，那么就是 DB 指定的存储路径，就不受 ASM 管理，是软连接的方式指向过来的
11、迁移DB到ASM中（学习）
十六、Catalog（备份恢复目录）
注意：如果使用catalog，一定要新开一个DB系统，将备份文件的数据库的备份清单信息和备份片存到当前catalog库上。备份清单在catatlogDB上以表的数据形式存在，不会存在过期的说法，只要DB不崩
1、控制文件保存的备份清单信息
-
备份文件过期，如何让DB重新识别？
# 识别过期备份文件 RMAN> catalog start with '【其它无法识别的备份文件路径】'; -
catalog指的是
用来存放备份文件数据的清单，备份了什么文件，文件存放在哪个路径下，类似于 x y 变量的区别，这份清单默认是存放在对应的数据库的控制文件中，默认保存七天，可以更改其保存失效，范围是（0~365天），改成0 就是永久保存
问题：如果设置为永久保存，那么控制文件长时间的积累清单数据，造成控制文件不断增大，导致数据库运行效率低下？
解决：将清单数据插入到恢复目录的一个表中，这样就不会存在过期问题，误删还容易找回，又不会增大控制文件，降低DB运行效率
问题：如果是集群环境，如何确认哪个清单属于哪个实例？
解决：将每个实例的DBID注册到恢复目录中，将各自清单数据文件存放到各自以DBID注册的路径下
注意：在备份数据库时，一定要连接恢复目录数据库，如果不连接，那么恢复清单数据就会存放到控制文件中
CONFIGURE RMAN OUTPUT TO KEEP FOR 7 DAYS; # default ############################################################## SQL> show parameter control NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ control_file_record_keep_time integer 7-
存放类型
不同的介质类型，开辟的通道也不一样，如：Disk（磁盘），快速恢复区和磁带。其实前俩个差不多，因为最底层介质都是磁盘，但还是有些许不同，因为快速恢复区容量小，且很多文件都默认存放在快速恢复区，所以更建议存放在另一个文件夹下或者放到本地系统中
-
![[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-jS2iX0jt-1687763866017)(C:\Users\admin\AppData\Roaming\Typora\typora-user-images\image-20230608164934748.png)]](https://i-blog.csdnimg.cn/blog_migrate/a0cafe987ccc331b995af15931b5307e.png)
十七、主动维护（监控DB）
1、检查哪些方面
- DB状态
- DB配置
- DB空间使用情况
- DB是否存在告警或者报错
- 下结论（诊断书很难写）
2、如何检查
-
使用DB的统计信息，解决DB慢操作（CRUD）---- 数据字典
- 数据字典更新统计信息不及时
-
收集DB负载信息（AWR）
-
脚本路径：
@ORACLE_HOME/rdbms/admin/awrrpt.sql; -
DB自动共享内存管理（ASMM） <— 根据AWR，自动调整内存资源分配
![[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ItsMJEaM-1687763866017)(C:\Users\admin\AppData\Roaming\Typora\typora-user-images\image-20230609171044956.png)]](https://i-blog.csdnimg.cn/blog_migrate/ad2f1fbe983f8d4d1a4fb5e38002944d.png)
-
属于 sysaux 表空间的数据，大部分都是AWR收集过来的负载数据
-
DB默认每小时（60min）收集一次，保留 8 天
# 查询AWR策略 select DBID,SNAP_INTERVAL,RETENTION,TOPNSQL from dba_hist_wr_control; DBID SNAP_INTERVAL RETENTION TOPNSQL ---------- --------------- --------------------- -------- ########## +00000 01:00:00.0 +00008 00:00:00.0 DEFAULT ############################################################################# SNAP_INTERVAL=+00000 01:00:00.0 表示采样间隔是1小时 RETENTION=+00008 00:00:00.0 表示采样数据保留期限是8天 # 如果做压力测试，就会更改采样时间间隔，一般情况下不做修改![[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-jCyaxBk1-1687763866017)(C:\Users\admin\AppData\Roaming\Typora\typora-user-images\image-20230609171134621.png)]](https://i-blog.csdnimg.cn/blog_migrate/40900ce72151e61e4752481a0e5a0f2e.png)
-
AWR收集SGA（内存）信息，由内存监视器（mmon）进程进行收集，收集对应的内存信息，存到AWR的快照中去，如：IO
-
AWR快照设置，指定某一个时间段平稳运行的状态做标准，用来判断DB负载情况。
# 手动生成快照语法 DBMS_WORKLOAD_REPOSITORY.CREATE_BASELINE( start_snap_id IN NUMBER, <--- 某阶段快照开始时间 end_snap_id IN NUMBER, <-- 某阶段快照结束时间 BASHLINE_NAME IN VARCHAR2 <--- 极限值 );![[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-6gRGyLQl-1687763866018)(C:\Users\admin\AppData\Roaming\Typora\typora-user-images\image-20230609170906853.png)]](https://i-blog.csdnimg.cn/blog_migrate/ab8c1bc43a289e893c729fd700e723ca.png)
-
-
DB自动诊断监视器（ADDM-诊断报告）
重点：会自动参照某一个时间段的情况来给定相关优化建议
注意： 11g 之前手动生成维护建议
-
脚本路径：
@ORACLE_HOME/rdbms/admin/ -
判断mmon收集的信息是否存在问题，调用ADDM进程进行判断，完成后会自动生成诊断报告或者建议
-
SQL Tuning Advisor（SQL优化器）：主要针对慢SQL，如TOP SQL，会给出相关建议，建议在某个字段创建索引、建议删除表中碎片或者重组表等
-
Memory（内存）：主要针对PGA和SGA，给定一个值，就不需要再管PGA和SGA它们如何分配。当Memory值为0时，就需要手动修改PGA和SGA的值，可以调用各自的优化器进程，自动生成需要多少值，再给定相关值
-
SQL Access Advisor（SQL访问优化器）：主要针对组SQL（多表），不再针对单条SQL（单表），组SQL每条拎出来可能查询效率高，但是组合在一起，可能效率就下降。这时调用访问优化器给出建议，进行修改
-
Space（空间）
- 区优化器（Segment Advisor）：针对表空间而言，当插入的数据量过大，而表空间自动扩展速度慢，就会造成DB负载高，调用 区优化器（Segment Advisor），增大每次扩展的空间值，如：未扩大区值，可能是每次扩展都是64K或者更小，那么就给它扩大
- Undo Advisor：根据undo保留时间，来确定undo空间的大小
![[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-T6NpfidC-1687763866019)(C:\Users\admin\AppData\Roaming\Typora\typora-user-images\image-20230609163453938.png)]](https://i-blog.csdnimg.cn/blog_migrate/21ee1c1e26b03c16033003b4ded16978.png)
-
-
设置告警阈值。如：当表空间超过设定的阈值，就告警
# 如：插入10亿条数据，某一个表空间的阈值设置为 80% 就告警，90% 严重告警，100% 就报错。如果这个时候我们将阈值临时更改为75% ，并且插入的数据已经超过临时更改的上限值，那么就不会告警，直到空间使用率为 0 ，这个时候就会报错
-
查看DB自动生成的告警日志
# 查看当前告警或者报错的数据字典 DBA_OUTSTANDING_ALERTS # 查看历史告警或者报错的数据字典 DBA_ALERT_HISTORY -
使用DB的自动维护任务
3、使用AWR
**注意：**AWR生成的报表存储位置是你进入SQLPLUS的当前目录下，同样可以指定对应的存储目录
**重点：**① 查看DB负载情况，快照之间的时间最好不要超过 俩小时 ，如果 DB 在某一刻运行缓慢或者断断续续运行卡壳，那么查看最近俩小时的负载情况即可，因为查看负载时间过长的话，那么曲线图可能会被平和掉。
② 如果 DB 长时间运行缓慢，那就需要查看长时间段的负载情况或者多时间段的情况
1、流程：
-
调用脚本
-
默认生成 HTML 报表
-
指定查看几天内的DB负载情况
-
指定AWR开始时间，其中只需要将 快照 的 id 输入即可
-
指定AWR结束时间，其中只需要将 快照 的 id 输入即可
-
指定报表名称
# 调用 AWR 脚本，生成分析报表
$ORACLE_HOME/12.1.0/rdbms/admin/awrrpt.sql;
# 指定报表类型
'html' HTML format (default)
'text' Text format
'active-html' Includes Performance Hub active report
# 指定时间
Snap
Instance DB Name Snap Id Snap Started Level
------------ ------------ --------- ------------------ -----
orcl ORCL 97 13 Jun 2023 09:37 1
98 13 Jun 2023 11:00 1
Specify the Begin and End Snapshot Ids
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Enter value for begin_snap: 97 <--- 开始的时间（快照ID[Snap Id]）
Begin Snapshot Id specified: 97
Enter value for end_snap: 98 <--- 结束的时间（快照ID[Snap Id]）
2、AWR报表参数解析
-
DB Time(s)：所有的sql加起来的时间消耗
SQL的运行时间是由 CPU 分配时间片决定的，如果CPU没有给当前的SQL分配时间片，那么当前SQL必须处于 wait 状态，那么 wait 状态也需要消耗时间。如果大部分时间体现在wait，① 代表着CPU性能不强（主频不高），时间片就很少 ② 负载高。 而 CPU 在运行 SQL 的时候也需要消耗时间，所以这俩部分时间加一起就决定着DB的运行效率 ----- DB Time(s) = DB CPU(time) + DB wait(times)
解决：开并发
# 查询当前 IO 读写进程 select x.inst_id, y.con_id, x.ksppinm name, <--- 名称 x.ksppdesc description, y.ksppstvl value, <--- 读写进程数 y.ksppstdf isdefault, decode(bitand(y.ksppstvf,7),1,'MODIFIED',4,'SYSTEM_MOD','FALSE') ismod, decode(bitand(y.ksppstvf,2),2,'TRUE','FALSE') isadj from sys.x$ksppi x, sys.x$ksppcv y where 1=1 and x.inst_id = y.inst_id and x.indx = y.indx and x.ksppinm in ( '_use_single_log_writer', '_max_outstanding_log_writes') order by translate(x.ksppinm, ' _', ' '),x.inst_id,y.con_id; ###################################################################################### # 更改读写进程数 SQL> alter system set "_max_outstanding_log_writes"=8 scope=spfile; ###################################################################################### # 查询进程数 ps -fu oracle |grep -i ora_lg |grep -v grepAWR报表解析：
Report Summary <-- #v第一部分 Load Profile Per Second Per Transaction Per Exec Per Call DB Time(s): 0.0 0.0 0.00 0.01 <-- # 当前时间指的是 CPU 运行sql命令的时间和 SQL 等待CPU分配时间片运行SQL的时间的总和 DB CPU(s): 0.0 0.0 0.00 0.01 Background CPU(s): 0.0 0.1 0.00 0.00 <-- 后台进程使用 CPU 的时间 Redo size (bytes): 780.5 20,986.6 <-- 每秒钟产生的redo数据量 Logical read (blocks): 25.7 690.5 Block changes: 3.7 98.4 <-- 一个小时内数据块的变化量 Physical read (blocks): 1.4 38.7 <-- 物理读块有多少（从底层文件将数据调到内存进行读） Physical write (blocks): 1.1 29.7 <-- 物理写块有多少（将内存中的数据写到底层文件） -
编译和执行效率（Execute to Parse）
执行到编译：占比高，决定着SQL编译次数多少或者说sql重复利用性低，都是硬编译 如：执行效率50%，编译效率80%，得出结果60%，代表着 CPU 大部分时间都在编译SQL，所以需要优化SQL
**计算公式：**执行效率 / 编译效率 * 100%
-
编译SQL和编译所占用的时间（Parse CPU to Parse Elapsd ）
如果占比高，因为SQL命中CPU几率低，可能是因为应用模块没有隔离或者说没有开并发
十八、多租户环境(单实例)
重点：① 共用一套内存实例、后台进程、元数据、redo日志、archive日志、控制文件和参数文件 ②当前PDB无法访问其它PDB，需要通过DB_link才可以访问
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-dgLD97qT-1687763866020)(C:\Users\admin\AppData\Roaming\Typora\typora-user-images\image-20230613161229598.png)]
1、容器DB解析
-
DB数量
容器数据库创建之后会存在 一个0级数据库，没有资源。一个根容器DB，一个种子库，其它的就是PDB库
注意：对内 0 号 和 1 号 都指一个容器，所有PDB可以共用一个undo文件，因为所有的undo都会写到根容器中的undo文件中
-
0 号 DB
# 0 号DB应该就是容器 0 JOS02CDB <--- 对外提供服务时使用的名称，如：打开监听，就是启用当前容器名称的监听才能够监听到容器中其它PDB的库 -
1 号 DB
重点：1 号容器存在的数据文件有：系统文件、undo文件、辅助文件（sysaux）、用户文件和临时文件。当前容器是不存储业务数据文件
# 1 号DB就是根容器 1 CDB$ROOT <--- -
2 号 DB
重点：种子库存在的数据文件有：系统文件、undo文件、辅助文件（sysaux）和临时文件。当前容器是不存储业务数据文件
# 2 号DB就是种子库 2 PDB$SEED <--- 建库的模板，创建新的PDB时用来参照的 -
其它DB
其他库存在的数据文件有：系统文件、undo文件、辅助文件（sysaux）、用户文件、临时文件和其它数据文件
# 其它的库就是PDB库（也就是对外或者对内（公司内部）提供服务的库）
-
-
DB的日志
- 容器和PDB所产生的redo信息，统一写到一套redo日志中去。一套redo日志会对应一套archive日志。
- 当前容器数据库知道所有PDB产生的历史数据、redo数据等。通过容器可以对每个PDB进行备份和恢复
- 容器和PDB共用一套redo日志、archive日志、控制文件和参数文件
-
DB对应的数据字典
-
传统数据库对应的数据字典
dba_[名称] <--- 针对所有对象相关的定义，查看所有 all_[名称] <--- 当前用户和具有查阅权限的数据 user_[名称] <--- 当前用户自己的，不能查看其它用户的数据 -
基于容器数据库对应的数据字典
cdb_[名称] <--- 针对所有对象相关的定义，查看所有 dba_[名称] <--- 只能看到当前CDB中的所有 all_[名称] <--- 当前用户和具有查阅权限的数据 user_[名称] <--- 当前用户自己的，不能查看其它用户的数据
-
2、创建用户
注意：每个PDB只能在自己的范围内创建用户，不得跨越用户。但是根容器下创建的用户可以实现多个PDB中切换
-
根容器下创建账户
重点：
c##：代表公有账户
# 如：根容器创建用户 create user c##[用户名] identified by [passwd]； <--- 只能在根容器下执行 -
操作根容器用户
无论对根容器用户作何操作，都需要在前面指定语法格式，才能使用根容器用户连接
# 授权 grant [权限] to c##[用户名]; # 使用根容器用户登录sqlplus sqlplus c##[用户名]/[密码]; -
dsa
3、DB迁移
-
DB之间互相迁移需注意的问题
# 1、源库与目的库须保持组件一致，无论是CDB还是PDB，单实例亦是如此，不能多出组件 # 2、字符集必须保持一致（国家字符集和国际字符集） # 3、undo表空间的模式是否相同，12.1仅支持共享模式，12.2开始支持本地模式 # 4、APEX是否安装 # 5、SGA和PGA参数值必须相同 # 6、CDB版本和参数（compatible）应保持一致，如：12.1.0和19.0.0就不一致，就需要更改 # 7、open_cursor参数值应保持一致 -
sda
4、多租户之间如何进行PDB连接
重点：① Sqlplus 想要连接DB中的实例，必须在tns中注册对应的实例，否则无法连接到对应的实例 — TNS文件
② 外部想要连接DB，必须通过listener文件，并且listener中还要注册对应的实例，否则外部无法访问DB ----Listener文件（对外提供服务的信息）
1、tns文件解析
重点：TNS文件用来识别DB中存在的实例，是否能够通过SQLPLUS连接DB，要想容器中的PDB可以被用户连接，需要在TNS中注册当前PDB实例
【对外服务名称】 =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = localhost)(PORT = 【端口号】))
(CONNECT_DATA =
(SERVICE_NAME = 【对外服务名称-小写】)
(INSTANCE_NAME = 【根容器名称】)
)
)
# 开放第二个实例，只需要追加即可，更改相应的端口和对外服务名称
【对外服务名称】 =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = localhost)(PORT = 【端口号】))
(CONNECT_DATA =
(SERVICE_NAME = 【对外服务名称-小写】)
(INSTANCE_NAME = 【根容器名称】)
)
)
# 【对外服务名称】：就是DBCA建库时指定的全局数据库名称
# 【端口号】：如果没有重新创建一个端口，那么就是原来的端口
# 【根容器名称】：CDB实例的名称，而不是PDB的实例名称
2、listener文件解析
重点：当前文件用来监听端口，第三方软件要想连接DB，必须通过监听才能访问
【CDB_SID】 =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = localhost)(PORT = 1521))
)
)
SID_LIST_TEST =
# SID_LIST ：当前段保持不变，指向对应的 CDB 的 ORACLE_HOME 路径和 CDB 的 SID
(SID_LIST =
(SID_DESC =
(ORACLE_HOME=【路径】)
(SID_NAME = 【CDB_SID】)
)
# 开放第一个实例
(SID_DESC =
(GLOBAL_DBNAME = 【填写你想要开放给第三方软件连接的PDB_SID】)
(SID_NAME = 【CDB_SID】)
)
# 开放第二个实例，当前位置追加即可
(SID_DESC =
(GLOBAL_DBNAME = 【填写你想要开放给第三方软件连接的PDB_SID】)
(SID_NAME = 【CDB_SID】)
)
)
# 如果想多开放几个实例供外部访问，只需要在 SID_LIST_TEST 后面追加 SID_DESC 即可，同时TNS也需要扫描到内部实例
5、多租户下系统参数修改
1、PDB参数修改
如果 ISPDB_MODIFIABLE 参数值是 true，那么就可以在PDB下更改当前参数值，如果是False就不能更改
select NAME,ISPDB_MODIFIABLE,con_id from v$parameter where name in ('undo_retention','processes','statistics_level');
6、查看容器历史操作
注意：当前表可以查看PDB是否被拔出还是被创建 —> OPERATION字段
SQL> select DB_NAME,CON_ID,PDB_NAME,OPERATION,OP_TIMESTAMP,CLONED_FROM_PDB_NAME from cdb_pdb_history where con_id >2 order by con_id;
DB_NAME CON_ID PDB_NAME OPERATION OP_TIMESTAMP CLONED_FRO
---------- ---------- ---------- ---------- ------------------ ----------
SEEDDATA 3 PDB$SEED UNPLUG 07-JUL-14
TEST 3 PDB$SEED PLUG 14-JUN-23 PDB$SEED
TEST 3 TESTS1 CREATE 14-JUN-23 PDB$SEED
TEST 3 TESTS1 UNPLUG 15-JUN-23
TEST 3 TESTS1 PLUG 15-JUN-23 TESTS1
7、容器开启并发
重点：开启的并发数是根据你虚拟机的CPU个数来决定的，如果你CPU个数不够，不支持开启多个并发数，即使修改了DB并发参数，那也无法更改其并发数可能还会影响效率，最好的并发数是几个CPU就开几个并发。更改并发参数的同时，也增加了系统的负载
-
增大并发数
注意：写进程数 12C 后默认是 俩个 ，LGWR 是专门的写进程
# 查询当前 IO 读写进程 select x.inst_id, y.con_id, x.ksppinm name, <--- 名称 x.ksppdesc description, y.ksppstvl value, <--- 读写进程数 y.ksppstdf isdefault, decode(bitand(y.ksppstvf,7),1,'MODIFIED',4,'SYSTEM_MOD','FALSE') ismod, decode(bitand(y.ksppstvf,2),2,'TRUE','FALSE') isadj from sys.x$ksppi x, sys.x$ksppcv y where 1=1 and x.inst_id = y.inst_id and x.indx = y.indx and x.ksppinm in ( '_use_single_log_writer', '_max_outstanding_log_writes') order by translate(x.ksppinm, ' _', ' '),x.inst_id,y.con_id; ###################################################################################### # 更改读写进程数 SQL> alter system set "_max_outstanding_log_writes"=8 scope=spfile; ###################################################################################### # 查询进程数 ps -fu oracle |grep -i ora_lg |grep -v grep
8、容器中连接PDB
重点：连接时指定PDB的 sid，但同时需要提供sys的账号和密码
-
Rman连接PDB的语法
重点：连接上以后，都可以按照单实例数据库的操作方式操作当前PDB
# 指定用户名密码和对应PDB的SID即可 rman target [username/passwd]@[PDBSID] -
PDB连接SQLPLUS
# 普通用户连接 PDB sqlplus [username/passwd]@[PDBSID] # 单独打开某一个PDB alter pluggable database [PDBSID] open; # 打开所有的PDB alter pluggable database ALL open; -
PDB备份恢复
# 备份数据库 backup database [PDB_SID]; # 恢复数据库 # 还原 restore databse [PDB_SID]; # 恢复 recover database [PDB_SID]; # 打开PDB alter pluggable database tests1 open; -
切换CDB和PDB
# PDB切换不同的容器 alter session set container = [PDB_SID]; # 切换到CDB容器 alter session set container = cdb$root;
9、集群架构
十九、字符集
1、字符集分类
注意：一个字节等于二进制的八位数（0101表示）
-
单字节字符
应用场景：西方国家
- 7位（标准Ascii编码）：2的7次方，存在128种编码格式，常用的如：字母大小写、数字、计算符以及标点符号等，还不到128种
- 8位：2的8次方256种
-
多字节字符编码
注意：2~4个字节表示一个字符，用于中方大国
- UTF8（DB的编码方式），UTF-8（应用程序的编码方式）：（2~4个字节表示一个字符）可变长的多字节，根据你存入的数据来设置当前几个字节来表示，节省空间
- UTF16（DB的编码方式），UTF-16（应用程序的编码方式）：（2个字节表示一个字符）定长的字节表示，无论什么字符，只要使用该字符编码方式，就算当前给定的空间没有使用完，也不会自动释放，造成空间损耗
- ZHS164GBK（中文简体）：都是 UTF8 的子集，字符编码只能向下兼容，不能同级字符编码转换
2、如何使用字符集
- 数据库存储字符时
- DB中存储字符，声明的变量类型是常用的中文编码方式，那么使用的是数据库的字符集。如果变量类型不是中文编码方式的，如：nvarchar、nchar。当前编码方式使用的是国家字符集。在使用DBCA建库的时候，就需要选择DB的编码方式和国家字符集的编码方式。有利于不同的语言文字存取，不会形成乱码
- DB更改字符集的方式
- 更改DB字符参数（不稳妥，可能会造成数据乱码）
- 字符参数：nls_lang=ZHS16GBK <-- 其中nls（国际语言支持）
- 重新建库
- 导出数据
- DBCA删掉源库
- 建立以UTF8编码格式的新库
- 导入数据，但是在导入的时候也可能出现问题。因为源库和新库的编码格式不一致，更换编码格式的时候会造成数据丢失
- 更改DB字符参数（不稳妥，可能会造成数据乱码）
- 字符集
- 数据库字符要 >= 操作系统字符集 >= 应用字符集 <== 最好保持一致
3、使用过程中规避哪些问题
4、字符集对于操作的影响
5、查询、排序和转换
二十、内存管理（PGA-SGA）
重点：实例 = 内存（SGA） + 进程（后台进程）
1、PGA
简介：PGA：当选用了专有服务器模式，PGA是独立的，与SGA没关系。但，PGA 的大小影响排序
2、SGA
简介：SGA（共享内存）：内存一般都指SGA，当DB架构选用了共享内存模式的时候，PGA才占用SGA的内存资源。用户发起的指令信息都会归集到SGA中
默认值：PGA和SGA ===> 1 : 4（五分） or 2 : 8（十分）
1、SGA组件
-
高速数据缓冲区（Database Buffer Cache）
-
缓冲池
缓冲区的集合，默认块大小是8k，缓存包含使用非标准块大小2k、4k和16k的表空间的单独池
-
默认池
默认缓存块的存储位置，除非手动配置单独的池，否则是唯一的缓冲池。其它池的配置不影响默认池
-
keep池
用于存放频繁访问但空间不足而在默认池中老化的块，保持缓冲池的目的是将对象保留在内存中，较少IO开销
-
Recycle池
当前池适用于不经常使用的块，可防止对象占用缓存中的空间
-
-
数据缓冲区-DBWn
-
Pinned：当进行 DML 操作修改、删除数据时，数据被上锁，即为当前状态（连接），当数据进行回滚时，DB 会从历史数据（undo空间）中找回之前被修改的原始数据重新修改到内存中去，这个时候，其状态又转变为 Clean（干净的）数据，并且会修改当前的数据状态为 Clean
-
Clean：当第一次执行查询时，从底层文件中读取的数据，存放到缓冲区中，那么缓冲区中的数据和底层文件中存放的数据一致时，并且俩方面没有进行任何的其它操作，即为当前状态（干净）
-
Free or unused：当第一次执行查询时，内存当中没有所需数据，当前进程从文件中查找数据存放到内存中，存储当前数据的缓冲区记录为空，当前状态即为此
-
Dirty：①当 DML操作进行时，并没有进行 commit 时，底层所记录保存的数据并未得到真正的修改，而内存中被修改之前的数据会被存放到历史数据中（undo）空间中去，这个时候，缓冲区和底层文件所保存的数据不一致时，称之为当前状态（脏数据）。
②当进行 Commit 时，内存当中被修改的数据就会触发 DBWR（DB写进程） 进程，会将Dirty（脏数据）写入到底层文件中，与内存中的数据一致，这个时候数据状态又会重新变成 Clean（干净的）状态
-
用户 如何将数据读取出来？
通过用户与DB建立的服务器进程（Server Process）进行读取数据，改数据也通过该进程。而写数据则通过 DBWR 进程
-
-
-
内存区（In-Memory Area）
-
重做日志缓存区（Redo Log Buffer）
- 记录DML或DDL操作对数据库所作更改的所需信息
-
共享池（Shared Pool）
缓存各种类型的程序数据，如：已解析的SQL、PL/SQL代码或者数据字典信息和系统参数。
- 库缓存（Library Cache）
- 数据字典缓存（Data Dictonary Cache）
- 服务器结果缓存（Server Result Cache）
- 预留池（Reserved Pool）
-
大池（Large Pool）
-
Java池
-
固定SGA（Fixed SGA）
生产环境的重点：
生产环境中部署软件时，整个过程当中不能存在告警和报错，一定要修复告警和报错才下一步，除非当前告警和错误不会影响到未来的业务，则可以忽略。不保证一定不要跳过或者忽略
