oracle分页查询的效率分析

Oracle 前端之家
前端之家收集整理的这篇文章主要介绍了oracle分页查询的效率分析，前端之家小编觉得挺不错的，现在分享给大家，也给大家做个参考。


ROWNUM

@H_301_11@
可能都知道ROWNUM只适用于小于或小于等于，如果进行等于判断，那么只能等于1，不能进行大于的比较。
@H_301_11@ROWNUM是oracle系统顺序分配为从查询返回的行的编号，返回的第一行分配的是1，第二行是2，依此类推。
ROWNUM@H_301_11@总是从1@H_301_11@开始，不管当前的记录是否满足查询结果，ROWNUM@H_301_11@返回的值都是1@H_301_11@，如果这条记录的值最终满足所有的条件，那么ROWNUM@H_301_11@会递加，下一条记录的ROWNUM@H_301_11@会返回2@H_301_11@，否则下一条记录的ROWNUM@H_301_11@仍然返回1@H_301_11@。
@H_301_11@理解了这一点，就清楚为什么一般的ROWNUM@H_301_11@大于某个值或等于某个不为1@H_301_11@的值是无法返回结果的，因此对于每条记录的ROWNUM@H_301_11@都是1@H_301_11@，而ROWNUM@H_301_11@为1@H_301_11@不满足查询的结果，所以下一条记录的ROWNUM@H_301_11@不会递增，仍然是1@H_301_11@，因此所有的记录都不满足条件。


分页查询格式1
在查询的最外层控制分页的最小值和最大值。查询语句如下：

[sql] view plain copy
  1. SELECT*FROM
  2. (
  3. SELECTA.*,ROWNUMRN
  4. FROM(FROMTABLE_NAME)A
  5. )
  6. WHERERNBETWEEN21AND40


分页查询格式2

copy
    WHEREROWNUM<=40
  1. )
  2. WHERERN>=21


分页查询格式3
考虑到多表联合的情况，如果不介意在系统中使用HINT的话，可以将分页的查询语句改写为：

copy
    SELECT/*+FIRST_ROWS*/*WHERERN>=21


效率问题
对比这两种写法，绝大多数的情况下，第2个查询的效率比第1个高得多。
这是由于CBO优化模式下，Oracle可以将外层的查询条件推到内层查询中，以提高内层查询的执行效率。对于第2个查询语句，第二层的查询条件WHERE ROWNUM <= 40就可以被Oracle推入到内层查询中，这样Oracle查询的结果一旦超过了ROWNUM限制条件，就终止查询将结果返回了。
而第1个查询语句，由于查询条件BETWEEN 21 AND 40是存在于查询的第三层，而Oracle无法将第三层的查询条件推到最内层（即使推到最内层也没有意义，因为最内层查询不知道RN代表什么）。因此，对于第1个查询语句，Oracle最内层返回给中间层的是所有满足条件的数据，而中间层返回给最外层的也是所有数据。数据的过滤在最外层完成，显然这个效率要比第一个查询低得多。
上面分析的查询不仅仅是针对单表的简单查询，对于最内层查询是复杂的多表联合查询或最内层查询包含排序的情况一样有效。

观察上面格式1和格式2二者的执行计划可以发现，两个执行计划唯一的区别就是格式2的查询在COUNT这步使用了STOPKEY，也就是说，Oracle将ROWNUM <= 20推入到查询内层，当符合查询的条件的记录达到STOPKEY的值，则Oracle结束查询。因此，可以预见，采用第二种方式，在翻页的开始部分查询速度很快，越到后面，效率越低，当翻到最后一页，效率应该和第一种方式接近。

分页查询语句之所以可以很快的返回结果，是因为它的目标是最快的返回第一条结果。如果每页有20条记录，目前翻到第5页，那么只需要返回前100条记录都可以满足查询的要求了，也许还有几万条记录也符合查询的条件，但是由于分页的限制，在当前的查询中可以忽略这些数据，而只需尽快的返回前100条数据。这也是为什么在标准分页查询语句中经常会使用FIRST_ROWS提示的原因。
对于行操作，可以在得到结果的同时将结果直接返回给上一层调用。但是对于结果集操作，Oracle必须得到结果集中所有的数据，因此分页查询中所带的ROWNUM信息不起左右。如果最内层的子查询中包含了下面这些操作中的一个以上，则分页查询语句无法体现出任何的性能优势：UNION、UNION ALL、MINUS、INTERSECT、GROUP BY、DISTINCT、UNIQUE以及聚集函数如MAX、MIN和分析函数等。

Oracle10g的新功能GROUP BY STOPKEY，使得Oracle10g解决了GROUP BY操作分页效率低的问题。在10g以前，Oracle的GROUP BY操作必须完全执行完，才能将结果返回给用户。但是Oracle10g增加了GROUP BY STOPKEY执行路径，使得用户在执行GROUP BY操作时，可以根据STOPKEY随时中止正在运行的操作。这使得标准分页函数对于GROUP BY操作重新发挥了作用。

除了这些操作以外，分页查询还有一个很明显的特点，就是处理的页数越小，效率就越高，越到后面，查询速度越慢。
分页查询用来提高返回速度的方法都是针对数据量较小的前N条记录而言。无论是索引扫描，NESTED LOOP连接，还是ORDER BY STOPKEY，这些方法带来性能提升的前提都是数据量比较小，一旦分页到了最后几页，会发现这些方法不但没有办法带来性能的提升，而且性能比普通查询还要低得多。这一点，在使用分页查询的时候，一定要心里有数。
分页查询一般情况下，很少会翻到最后一篇，如果只是偶尔碰到这种情况，对系统性能不会有很大的影响，但是如果经常碰到这种情况，在设计分页查询时应该给予足够的考虑。

多表联合
下面简单讨论一下多表联合的情况。对于最常见的等值表连接查询，CBO一般可能会采用两种连接方式NESTED LOOP和HASH JOIN（MERGE JOIN效率比HASH JOIN效率低，一般CBO不会考虑）。
一般对于大表查询情况下，HASH JOIN的效率要比NESTED LOOP高很多，所以CBO一般默认会选择HASH JOIN.

但是如果分页查询的内层是这种连接查询的话，使用NESTED LOOP可以更快的得到前N条记录。
在这里，由于使用了分页，因此指定了一个返回的最大记录数，NESTED LOOP在返回记录数超过最大值时可以马上停止并将结果返回给中间层，而HASH JOIN必须处理完所有结果集（MERGE JOIN也是）。那么在大部分的情况下，对于分页查询选择NESTED LOOP作为查询的连接方法具有较高的效率（分页查询的时候绝大部分的情况是查询前几页的数据，越靠后面的页数访问几率越小）。

HASH JOIN中第一步也就是第一张表的全表扫描是无法应用STOPKEY的，这就是NESTED LOOP比HASH JOIN优势的地方。
但是，如果恰好第一张表很小，对这张表的全扫描的代价极低，会显得HASH JOIN效率更高。
如果两张表的大小相近，或者Oracle错误的选择了先扫描大表，则使用HASH JOIN的效率就会低得多。

因此对于表连接来说，在写分页查询的时候，可以考虑增加FIRST_ROWS提示，它会导致CBO选择NESTED LOOP，有助于更快的将查询结果返回。
其实，不光是表连接，对于所有的分页查询都可以加上FIRST_ROWS提示。
不过需要注意的时，分页查询的目标是尽快的返回前N条记录，因此，无论是ROWNUM还是FIRST_ROWS机制都是提高前几页的查询速度，
对于分页查询的最后几页，采用HASH JOIN的方式，执行效率几乎没有任何改变，而采用NESTED LOOP方式，则效率严重下降，而且远远低于HASH JOIN的方式。

排序列不唯一所带来的问题
如果用来排序的列不唯一，也就是存在值相等的行，可能会造成第一次在前10条返回记录中，某行数据出现了，而第二次在11到第20条记录中，某行数据又出现了。一条数据重复出现两次，就必然意味着有数据在两次查询中都不会出现。
其实造成这个问题的原因很简单，是由于排序列不唯一造成的。Oracle这里使用的排序算法不具有稳定性，也就是说，对于键值相等的数据，这种算法完成排序后，不保证这些键值相等的数据保持排序前的顺序。
解决这个问题其实也很简单。有两种方法可以考虑。
1）在使用不唯一的字段排序时，后面跟一个唯一的字段。
一般在排序字段后面跟一个主键就可以了，如果表不存在主键，跟ROWID也可以。这种方法最简单，且对性能的影响最小。
2）另一种方法就是使用前面给出过多次的BETWEEN AND的方法。
这种方式由于采用表数据的全排序，每次只取全排序中的某一部分数据，因此不会出现上面提到的重复数据问题。
但是正是由于使用了全排序，而且ROWNUM信息无法推到查询内部，导致这种写法的执行效率很低

测试结果
下面做一些测试，按照如下步骤准备数据：

copy
    CREATETABLETASFROMDBA_USERS;
  1. TABLET1FROMDBA_SOURCE;
  2. ALTERADDCONSTRAINTPK_TPRIMARYKEY(USERNAME);
  3. CONSTRAINTFK_T1_OWNERFOREIGNKEY(OWNER)REFERENCEST(USERNAME);
  4. INDEXIND_T1_OWNERONT1(OWNER);
  5. EXECDBMS_STATS.GATHER_TABLE_STATS(USER,'T')
  6. 'T1')
  7. setautotracetraceonly
  8. settimingon


现在表格T中有37行数据，表格T1中有623K行数据。

比较格式1和格式2的查询计划

copy
    --查询语句1
  1. FROM
  2. (
  3. FROMT1)A
  4. AND40;
  5. --查询语句2
  6. FROMT1)A
  7. WHERERN>=21;


执行计划 执行时间 统计信息
查询语句1

----------------------------------------------------------
Plan hash value: 3921461035

----------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%cpu)| Time |
----------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 623K| 1231M| 2879 (1)| 00:00:35 |
|* 1 | VIEW | | 623K| 1231M| 2879 (1)| 00:00:35 |
| 2 | COUNT | | | | | |
| 3 | TABLE ACCESS FULL| T1 | 623K| 59M| 2879 (1)| 00:00:35 |
----------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

1 - filter("RN"<=40 AND "RN">=21)

 00: 00: 02.40 1 recursive calls
0 db block gets
10441 consistent gets
10435 physical reads
0 redo size
1720 bytes sent via sql*Net to client
431 bytes received via sql*Net from client
3 sql*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
20 rows processed
查询语句2

----------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%cpu)| Time |
----------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 40 | 82800 | 2 (0)| 00:00:01 |
|* 1 | VIEW | | 40 | 82800 | 2 (0)| 00:00:01 |
|* 2 | COUNT STOPKEY | | | | | |
| 3 | TABLE ACCESS FULL| T1 | 40 | 4000 | 2 (0)| 00:00:01 |
----------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

1 - filter("RN">=21)
2 - filter(ROWNUM<=40)

 00: 00: 00.03 0 recursive calls
0 db block gets
6 consistent gets
20 physical reads
0 redo size
1720 bytes sent via sql*Net to client
431 bytes received via sql*Net from client
3 sql*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
20 rows processed

关联查询
copy
    FROMT,T1WHERET.USERNAME=T1.OWNER)A
  1. WHEREROWNUM<=40
  2. WHERERN>=21;
  3. --查询语句2
  4. --或者
  5. SELECT/*+USE_NL(TT1)*/*WHERERN>=21;

可以看到默认是采用hash join,改用nested loop join方式似乎效率并没有明显提高，但是这是由于表T比较小只有34行，所以hash join的第一步即使对T进行全表扫描而无法应用stopkey，效率也很高。

执行计划 执行时间 统计信息
查询语句1

-----------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%cpu)| Time |
-----------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 40 | 165K| 6 (17)| 00:00:01 |
|* 1 | VIEW | | 40 | 165K| 6 (17)| 00:00:01 |
|* 2 | COUNT STOPKEY | | | | | |
|* 3 | HASH JOIN | | 40 | 12400 | 6 (17)| 00:00:01 |
| 4 | TABLE ACCESS FULL| T | 34 | 3740 | 3 (0)| 00:00:01 |
| 5 | TABLE ACCESS FULL| T1 | 40 | 4000 | 2 (0)| 00:00:01 |
-----------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

1 - filter("RN">=21)
2 - filter(ROWNUM<=40)
3 - access("T"."USERNAME"="T1"."OWNER")

 00: 00: 00.04 0recursive calls
0 db block gets
9 consistent gets
20 physical reads
0 redo size
2927 bytes sent via sql*Net to client
431 bytes received via sql*Net from client
3 sql*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
20 rows processed
查询语句2

-----------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%cpu)| Time |
-----------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 40 | 165K| 13627 (1)| 00:02:44 |
|* 1 | VIEW | | 40 | 165K| 13627 (1)| 00:02:44 |
|* 2 | COUNT STOPKEY | | | | | |
| 3 | NESTED LOOPS | | | | | |
| 4 | NESTED LOOPS | | 623K| 124M| 13627 (1)| 00:02:44 |
| 5 | TABLE ACCESS FULL | T | 34 | 3740 | 3 (0)| 00:00:01 |
|* 6 | INDEX RANGE SCAN | IND_T1_OWNER | 36684 | | 91 (0)| 00:00:02 |
| 7 | TABLE ACCESS BY INDEX ROWID| T1 | 18342 | 1791K| 710 (1)| 00:00:09 |
-----------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

1 - filter("RN">=21)
2 - filter(ROWNUM<=40)
6 - access("T"."USERNAME"="T1"."OWNER")

 00: 00: 00.01 1recursive calls
0 db block gets
14consistent gets
0physical reads
0 redo size
2927bytes sent via sql*Net to client
431 bytes received via sql*Net from client
3 sql*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
20 rows processed

现在增大表T，
copy
    MODIFY(USER_IDNULL,ACCOUNT_STATUS TEMPORARY_TABLESPACENULL);
  1. INSERTINTOT(USERNAME)SELECT('USER'||LEVEL)FROMDUALCONNECTBYLEVEL<100000;
  2. COMMIT;
  3. 'T')

然后重新测试语句1，会发现现在oracle已经改成用nested loop join了。
因此现在语句1和语句2的效果等同了。可以使用 USE_HASH(T T1) HINT强制使用hash join，结果做下对比，会发现hash join的效率低于nested loop join，读数据发生的IO（consistent gets+physical reads）大大增加了.
可以看到CBO是相当智能了。

含排序的查询
含排序操作的分页查询。可以简单的将查询分为两种不同情况，第一种排序列就是索引列，这种可以利用索引读取，第二种排序列没有索引。
第一种情况又可以细分为：完全索引扫描和通过索引扫描定位到表记录两种情况。无论是那种情况，都可以通过索引的全扫描来避免排序的产生。
第二种情况下，排序不可避免，但是利用给出分页格式，Oracle不会对所有数据进行排序，而是只排序前N条记录。

copy
    --查询语句1，排序列就是索引列.注意这里需要加上OWNERISNOTNULL,否则由于OWNER列不是NOTNULL,会导致索引无法使用。
  1. FROMT1WHEREOWNERISNOTNULLORDERBYOWNER)A
  3. --查询语句2，排序列没有索引
  4. NAME)A
  5. WHERERN>=21;
  7. --查询语句3，排序列没有索引
  8. AND40;

执行计划 执行时间 统计信息
查询语句1

-----------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%cpu)| Time |
-----------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 40 | 82800 | 4 (0)| 00:00:01 |
|* 1 | VIEW | | 40 | 82800 | 4 (0)| 00:00:01 |
|* 2 | COUNT STOPKEY | | | | | |
| 3 | VIEW | | 40 | 82280 | 4 (0)| 00:00:01 |
| 4 | TABLE ACCESS BY INDEX ROWID| T1 | 646K| 62M| 4 (0)| 00:00:01 |
|* 5 | INDEX FULL SCAN | IND_T1_OWNER | 40 | | 3 (0)| 00:00:01 |
-----------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

1 - filter("RN">=21)
2 - filter(ROWNUM<=40)
5 - filter("OWNER" IS NOT NULL)

*排序列就是索引列，可以看到通过索引的全扫描来避免了排序的产生。		 00: 00: 00.01 1recursive calls
0 db block gets
8consistent gets
1physical reads
0 redo size
1682bytes sent via sql*Net to client
427 bytes received via sql*Net from client
3 sql*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
20 rows processed
查询语句2

-----------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%cpu)| Time |
-----------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 40 | 82800 | | 18077 (1)| 00:03:37 |
|* 1 | VIEW | | 40 | 82800 | | 18077 (1)| 00:03:37 |
|* 2 | COUNT STOPKEY | | | | | | |
| 3 | VIEW | | 646K| 1268M| | 18077 (1)| 00:03:37 |
|* 4 | SORT ORDER BY STOPKEY| | 646K| 62M| 72M| 18077 (1)| 00:03:37 |
| 5 | TABLE ACCESS FULL | T1 | 646K| 62M| | 3023 (1)| 00:00:37 |
-----------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

1 - filter("RN">=21)
2 - filter(ROWNUM<=40)
4 - filter(ROWNUM<=40)

*排序列没有索引，排序不可避免。带STOPKEY的ORDER BY，排序操作放到了内存中，
在大数据量需要排序的情况下，要比不带STOPKEY排序的效率高得多。

 00: 00: 01.32 1 recursive calls
0 db block gets
10973 consistent gets
10969 physical reads
0 redo size
2529 bytes sent via sql*Net to client
427 bytes received via sql*Net from client
3 sql*Net roundtrips to/from client
1sorts (memory)
0 sorts (disk)
20 rows processed
查询语句3

--------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%cpu)| Time |
--------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 646K| 1276M| | 18077 (1)| 00:03:37 |
|* 1 | VIEW | | 646K| 1276M| | 18077 (1)| 00:03:37 |
| 2 | COUNT | | | | | | |
| 3 | VIEW | | 646K| 1268M| | 18077 (1)| 00:03:37 |
| 4 | SORT ORDER BY | | 646K| 62M| 72M| 18077 (1)| 00:03:37 |
| 5 | TABLE ACCESS FULL| T1 | 646K| 62M| | 3023 (1)| 00:00:37 |
--------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

1 - filter("RN"<=40 AND "RN">=21)

*排序列没有索引，排序不可避免，不带STOPKEY，
进行的数据的全排序，排序数据量大，排序操作不得不在磁盘上完成，因此耗时比较多。

 00: 00: 05.31 72recursive calls
26db block gets
10973 consistent gets
19933physical reads
0 redo size
6489bytes sent via sql*Net to client
427 bytes received via sql*Net from client
3 sql*Net roundtrips to/from client
0 sorts (memory)
1sorts (disk)
20 rows processed

排序列不唯一所带来的问题
copy
    tony@ORCL1>TABLETESTSELECTROWNUMID,A.*FROMDBA_OBJECTSA;
  1. Tablecreated.
  2. tony@ORCL1>'TEST');
  3. PL/sqlproceduresuccessfullycompleted.
  4. tony@ORCL1>COLUMNOBJECT_NAMEFORMATA30
  5. 2(
  6. 3 4SELECTID,OWNER,OBJECT_NAMEFROMTEST 5WHEREROWNUM<=10
  7. 6)
  8. 7WHERERN>=1;
  9. IDOWNEROBJECT_NAMERN
  10. --------------------------------------------------------------------------------
  11. 69170APEX_030200WWV_FLOW_INIT_HTP_BUFFER1
  12. 69179APEX_030200WWV_HTF2
  13. 69178APEX_030200WWV_FLOW_LANG3
  14. 69177APEX_030200WWV_FLOW_UTILITIES4
  15. 69176APEX_030200VC4000ARRAY5
  16. 69175APEX_030200WWV_FLOW_SECURITY6
  17. 69174APEX_030200WWV_FLOW7
  18. 69173APEX_030200HTMLDB_ITEM8
  19. 69172APEX_030200WWV_FLOW_GLOBAL9
  20. 69171APEX_030200WWV_FLOW_IMAGE_PREFIX10
  21. 10rowsselected.
  22. 2(
  23. 3 4BYOWNER)A
  24. 5WHEREROWNUM<=20
  25. 6)
  26. 7WHERERN>=11;
  27. IDOWNEROBJECT_NAMERN
  28. --------------------------------------------------------------------------------
  29. 69180APEX_030200WWV_HTP11
  30. 69179APEX_030200WWV_HTF12
  31. 69178APEX_030200WWV_FLOW_LANG13
  32. 69177APEX_030200WWV_FLOW_UTILITIES14
  33. 69176APEX_030200VC4000ARRAY15
  34. 69175APEX_030200WWV_FLOW_SECURITY16
  35. 69174APEX_030200WWV_FLOW17
  36. 69173APEX_030200HTMLDB_ITEM18
  37. 69172APEX_030200WWV_FLOW_GLOBAL19
  38. 69171APEX_030200WWV_FLOW_IMAGE_PREFIX20
  39. 10rowsselected.
  40. --可以看到，有多个ID在两次查询中都出现了。
  41. --通过加上ID作为排序列解决这个问题。
  42. BYOWNER,ID)A
  43. 69171APEX_030200WWV_FLOW_IMAGE_PREFIX2
  44. 69172APEX_030200WWV_FLOW_GLOBAL3
  45. 69173APEX_030200HTMLDB_ITEM4
  46. 69174APEX_030200WWV_FLOW5
  47. 69176APEX_030200VC4000ARRAY7
  48. 69177APEX_030200WWV_FLOW_UTILITIES8
  49. 69178APEX_030200WWV_FLOW_LANG9
  50. 69179APEX_030200WWV_HTF10
  51. 69181APEX_030200ESCAPE_SC12
  52. 69182APEX_030200WWV_FLOW_Meta_DATA13
  53. 69183APEX_030200WWV_FLOW_TEMPLATES_UTIL14
  54. 69184APEX_030200WWV_RENDER_CALENDAR215
  55. 69185APEX_030200WWV_RENDER_CHART216
  56. 69186APEX_030200WWV_FLOW_CHECK17
  57. 69187APEX_030200WWV_RENDER_REPORT318
  58. 69188APEX_030200WWV_FLOW_PAGE_CACHE_API19
  59. 69189APEX_030200WWV_FLOW_RENDER_QUERY20
  60. rowsselected.

猜你在找的Oracle相关文章

[Oracle]记一次由sequence引发的enq sv-contention等待事件
数据库版本：11.2.0.4 RAC(1)问题现象从EM里面可以看到，在23号早上8：45~8：55时，数据库...
oracle统计信息的锁定与解锁
（一）问题背景最近在对一个大约200万行数据的表查看执行计划时，发现存在异常，理论上应该...
【转】RMAN删除过期备份或非过期备份
（一）删除备份--DELETE命令用于删除RMAN备份记录及相应的物理文件。当使用RMAN执行备份操...
数据恢复顾问（DRA）
（1）DRA介绍 数据恢复顾问（Data Recovery Advise）是一个诊断和修复数据库的工具，DRA能...
RMAN备份与恢复（一）--认识RMAN
RMAN（Recovery Manager）是Oracle恢复管理器的简称，是集数据库备份（backup）、修复（re...
RMAN备份与恢复（二）--RMAN常用操作学习
（1）连接目标数据库 在RMAN中可以建立与目标数据库或恢复目录数据库的连接。与目标数据库...
ORA-00245问题总结
（1）问题描述 在进行数据库归档备份时（备份归档日志文件和控制文件），有时成功，有时失...
使用RMAN对数据文件进行恢复
（1）备份数据库 在使用RMAN进行数据库恢复之前，先用RMAN进行全库备份 （2）删除数据文件...
Oracle使用fy_recover_data恢复truncate删除的数据
(一)truncate操作概述在生产中，truncate是使用较多的命令，在使用不当的情况下，往往会造...
备份与恢复（四）--RMAN使用恢复目录catalog来保存档案资料库
（一）恢复目录概述RMAN档案资料库用于存储数据库备份、修复以及恢复所需的信息。这些信息...
MySQLMsSQLOracleSqlitePostgre SQLMariadbMongoDBNoSQLHBaseJDBC
undo日志persistent-cmysql-error-postal-codesql-match-almysql-5.6mysql-8.0database-tri安装路径系统错误data_dir丢失文件主从同步sql_mode数据库目录匿名用户character_seID归零数据库位置查询表重复字段查询字段截断日志SUSPECT7391Remote ServeLinked Serve玄学问题登录不上开启远程访问