Oracle数据库数据恢复、性能优化

找回密码
注册
搜索
热搜: 活动 交友 discuz
Oracle数据库数据恢复、性能优化»论坛 › Oracle › Oracle数据库管理 › 请教11g dg下磁盘io 100%还有没优化的空间？ ...
发新帖
lxhbww

164

积分

0

好友

16

主题

[备份恢复] 请教11g dg下磁盘io 100%还有没优化的空间？

1#
发表于 2013-8-15 09:09:55 | 查看: 4425| 回复: 10
oel5.5+11.2.0.2.0 rac+dg，dg上iostat -dmx 3 数据那块盘%util都为100%
Linux 2.6.18-194.el5 (datadg1)  08/15/2013

Device:         rrqm/s   wrqm/s   r/s   w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await  svctm  %util
sda               0.59     0.74  2.09  0.77     0.24     0.01   174.42     0.02    7.08   2.45   0.70
sda1              0.58     0.74  2.09  0.77     0.24     0.01   174.44     0.02    7.08   2.45   0.70
sda2              0.01     0.00  0.00  0.00     0.00     0.00    36.84     0.00    4.34   3.34   0.00
sdb               0.06   490.28  2.99 17.99     0.05     1.99   198.72    13.22  629.70  44.01  92.35
sdb1              0.06   490.28  2.99 17.99     0.05     1.99   198.72    13.22  629.71  44.01  92.35
sdc               0.00    13.69  0.00  0.17     0.00     0.05   644.53     0.01   49.78   1.32   0.02
sdc1              0.00    13.69  0.00  0.17     0.00     0.05   645.44     0.01   49.85   1.32   0.02

Device:         rrqm/s   wrqm/s   r/s   w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await  svctm  %util
sda               0.00    11.63  0.00  1.99     0.00     0.05    54.67     0.03   12.67   6.00   1.20
sda1              0.00    11.63  0.00  1.99     0.00     0.05    54.67     0.03   12.67   6.00   1.20
sda2              0.00     0.00  0.00  0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
sdb               0.00     0.00  0.00  0.00     0.00     0.00     0.00    13.96    0.00   0.00  99.70
sdb1              0.00     0.00  0.00  0.00     0.00     0.00     0.00    13.96    0.00   0.00  99.70
sdc               0.00     0.00  0.00  0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
sdc1              0.00     0.00  0.00  0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00

Device:         rrqm/s   wrqm/s   r/s   w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await  svctm  %util
sda               0.00     4.67  0.00 10.33     0.00     0.06    11.61     0.41   39.74   1.90   1.97
sda1              0.00     4.67  0.00 10.33     0.00     0.06    11.61     0.41   39.74   1.90   1.97
sda2              0.00     0.00  0.00  0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
sdb               0.00     0.00  0.00  0.00     0.00     0.00     0.00    14.00    0.00   0.00 100.03
sdb1              0.00     0.00  0.00  0.00     0.00     0.00     0.00    14.01    0.00   0.00 100.07
sdc               0.00     0.00  0.00  0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
sdc1              0.00     0.00  0.00  0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
sdb1是接的盘阵用光纤卡4gb 盘为15k转速而主库rac是8gb光纤卡接盘阵，盘为10k转速，二个盘阵不一样
为什么同步还是无法实时同步完，一天产生归档也就4G左右.昨天看同步到前天晚上8点多，
现在看只同步到昨天晚上6点,dg同步还有没什么优化的地方能让备库快速和主库进行同步？
主库log_archive_dest_2                   string      SERVICE=standby LGWR ASYNC VAL
                                                 ID_FOR=(ONLINE_LOGFILES,PRIMAR
                                                 Y_ROLE) DB_UNIQUE_NAME=dg1
主库iostat都小于10%，为什么在备库同步这么慢？有打开实时同步，主备库都有standby logfile
备库alert
Thu Aug 15 08:46:11 2013
Primary database is in MAXIMUM PERFORMANCE mode
Thu Aug 15 08:48:41 2013
RFS[373]: Assigned to RFS process 16636
RFS[373]: Selected log 22 for thread 2 sequence 730 dbid 1735692056 branch 823075992
Thu Aug 15 08:48:41 2013
RFS[374]: Assigned to RFS process 16638
RFS[374]: Selected log 23 for thread 2 sequence 729 dbid 1735692056 branch 823075992
Thu Aug 15 08:48:41 2013
RFS[375]: Assigned to RFS process 16640
RFS[375]: Selected log 11 for thread 1 sequence 772 dbid 1735692056 branch 823075992
Thu Aug 15 08:48:41 2013
RFS[376]: Assigned to RFS process 16642
RFS[376]: Selected log 13 for thread 1 sequence 771 dbid 1735692056 branch 823075992
Thu Aug 15 08:48:41 2013
Media Recovery Log /oraarch/testdb/1_732_823075992.arc
Thu Aug 15 08:48:44 2013
RFS[371]: Possible network disconnect with primary database
Thu Aug 15 08:49:41 2013
RFS[377]: Assigned to RFS process 16626
RFS[377]: Possible network disconnect with primary database
Thu Aug 15 08:51:29 2013
Archived Log entry 200 added for thread 2 sequence 729 ID 0x67753a18 dest 1:
Thu Aug 15 08:51:29 2013
RFS[372]: Possible network disconnect with primary database
Thu Aug 15 08:51:29 2013
RFS[374]: Selected log 21 for thread 2 sequence 728 dbid 1735692056 branch 823075992
Thu Aug 15 08:57:34 2013
RFS[378]: Assigned to RFS process 16665
RFS[378]: Selected log 12 for thread 1 sequence 770 dbid 1735692056 branch 823075992
Thu Aug 15 09:00:04 2013
RFS[374]: Possible network disconnect with primary database
Thu Aug 15 09:02:34 2013
Media Recovery Log /oraarch/testdb/2_692_823075992.arc

备库一些查询结果
SELECT MESSAGE FROM V$DATAGUARD_STATUS;
MESSAGE
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
ARC0: Completed archiving thread 2 sequence 726 (0-0)
ARC1: Beginning to archive thread 2 sequence 727 (36829114-37130856)
Primary database is in MAXIMUM PERFORMANCE mode
Re-archiving standby log 23 thread 2 sequence 727
RFS[371]: Assigned to RFS process 16558
ARC1: Completed archiving thread 2 sequence 727 (0-0)
Media Recovery Log /oraarch/testdb/1_731_823075992.arc
ARC0: Beginning to archive thread 1 sequence 769 (36613789-36935204)
Primary database is in MAXIMUM PERFORMANCE mode
Re-archiving standby log 11 thread 1 sequence 769
RFS[372]: Assigned to RFS process 16560

MESSAGE
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
ARC0: Completed archiving thread 1 sequence 769 (0-0)
Primary database is in MAXIMUM PERFORMANCE mode
Primary database is in MAXIMUM PERFORMANCE mode

已选择256行。


NAME      OPEN_MODE            PROTECTION_MODE      DATABASE_ROLE
--------- -------------------- -------------------- ----------------
testdb     MOUNTED              MAXIMUM PERFORMANCE  PHYSICAL STANDBY


   THREAD# NO_APPLIED_MIN NO_APPLIED_MAX NO_APPLIED_ALL
---------- -------------- -------------- --------------
         1            731            769             39
         2            691            727             37


   THREAD# APPLIED_MAX FIRST_TIME          NEXT_TIME      COMPLETION_TIME
---------- ----------- ------------------- -------------- -------------------
         1         729 2013-08-14 17:12:18 08-14 17:36:09 2013-08-14 17:59:06
         2         690 2013-08-14 17:28:36 08-14 18:15:01 2013-08-14 18:24:06


   THREAD#  SEQUENCE# APPLIED   NAME
---------- ---------- --------- ------------------------------------------------------------
         1        730 IN-MEMORY /oraarch/testdb/1_730_823075992
2#
发表于 2013-8-15 09:15:37
先查一下：

Set Linesize 400
Col Values For A65
Col Recover_start For A21
SELECT TO_CHAR (START_TIME, 'Dd.Mm.Yyyy Hh24:Mi:ss') "Recover_start",
          TO_CHAR (Item)
       || ' = '
       || TO_CHAR (Sofar)
       || ' '
       || TO_CHAR (Units)
       || ' '
       || TO_CHAR (TIMESTAMP, 'Dd.Mm.Yyyy Hh24:Mi')
          "Values"
  FROM V$Recovery_progress
WHERE Start_time = (SELECT MAX (Start_time) FROM V$Recovery_progress);


并上传完整的  standby alert.log 和mrp进程的trace

回复 只看该作者 道具 举报

3#
发表于 2013-8-15 09:20:37
SQL> Set Linesize 400
Col Values For A65
Col Recover_start For A21
SELECT TO_CHAR (START_TIME, 'Dd.Mm.Yyyy Hh24:Mi:ss') "Recover_start",
          TO_CHAR (Item)
       || ' = '
       || TO_CHAR (Sofar)
       || ' '
       || TO_CHAR (Units)
       || ' '
       || TO_CHAR (TIMESTAMP, 'Dd.Mm.Yyyy Hh24:Mi')
          "Values"
  FROM V$Recovery_progress
WHERE Start_time = (SELECT MAX (Start_time) FROM V$Recovery_progress);
SQL> SQL> SQL>   2    3    4    5    6    7    8    9   10   11  
Recover_start         Values
--------------------- -----------------------------------------------------------------
13.08.2013 20:51:32   Log Files = 127 Files
13.08.2013 20:51:32   Active Apply Rate = 53 KB/sec
13.08.2013 20:51:32   Average Apply Rate = 53 KB/sec
13.08.2013 20:51:32   Maximum Apply Rate = 53 KB/sec
13.08.2013 20:51:32   Redo Applied = 6881 Megabytes
13.08.2013 20:51:32   Last Applied Redo = 0 SCN+Time 14.08.2013 19:37
13.08.2013 20:51:32   Active Time = 130234 Seconds
13.08.2013 20:51:32   Apply Time per Log = 158 Seconds
13.08.2013 20:51:32   Checkpoint Time per Log = 866 Seconds
13.08.2013 20:51:32   Elapsed Time = 131083 Seconds

已选择10行。

SQL>

alert_testdb.rar

17.5 KB, 下载次数: 930

回复 只看该作者 道具 举报

4#
发表于 2013-8-15 09:27:21
mrp进程的trace

mrptrace.rar

2.15 KB, 下载次数: 957

回复 只看该作者 道具 举报

5#
发表于 2013-8-15 10:41:22


停掉  standby 后测试：
hdparm -tT /dev/sdb
  1. hu Aug 15 07:51:28 2013
  2. RFS[358]: Assigned to RFS process 16318
  3. RFS[358]: Selected log 12 for thread 1 sequence 768 dbid 1735692056 branch 823075992
  4. Thu Aug 15 07:51:29 2013
  5. RFS[353]: Possible network disconnect with primary database
  6. Thu Aug 15 07:51:34 2013
  7. RFS[359]: Assigned to RFS process 16320
  8. RFS[359]: Selected log 11 for thread 1 sequence 767 dbid 1735692056 branch 823075992
  9. Thu Aug 15 07:56:04 2013
  10. WARN: ARC2: Terminating pid 16286 hung on an I/O operation
  11. Thu Aug 15 07:56:34 2013
  12. WARN: ARC2: Terminating pid 16320 hung on an I/O operation
  13. krsv_proc_kill: Killing 1 processes (Process by index)
  14. Thu Aug 15 07:57:35 2013
  15. krsv_proc_kill: Killing 1 processes (Process by index)
  16. Thu Aug 15 07:59:06 2013
  17. RFS[358]: Possible network disconnect with primary database
  18. Thu Aug 15 08:01:36 2013
  19. RFS[360]: Assigned to RFS process 16343
  20. RFS[360]: Selected log 11 for thread 1 sequence 767 dbid 1735692056 branch 823075992
  21. Thu Aug 15 08:01:38 2013
  22. Archived Log entry 194 added for thread 1 sequence 767 ID 0x67753a18 dest 1:
  23. Thu Aug 15 08:04:09 2013
  24. Primary database is in MAXIMUM PERFORMANCE mode
  25. Thu Aug 15 08:04:09 2013
  26. Primary database is in MAXIMUM PERFORMANCE mode
  27. RFS[361]: Assigned to RFS process 16458
  28. RFS[361]: Selected log 21 for thread 2 sequence 726 dbid 1735692056 branch 823075992
  29. RFS[362]: Assigned to RFS process 16460
  30. RFS[362]: Selected log 11 for thread 1 sequence 769 dbid 1735692056 branch 823075992
  31. Thu Aug 15 08:04:09 2013
  32. RFS[363]: Assigned to RFS process 16462
  33. RFS[363]: Selected log 12 for thread 1 sequence 768 dbid 1735692056 branch 823075992
  34. Thu Aug 15 08:04:09 2013
  35. RFS[364]: Assigned to RFS process 16464
  36. RFS[364]: Selected log 22 for thread 2 sequence 725 dbid 1735692056 branch 823075992
  37. Thu Aug 15 08:11:10 2013
  38. WARN: ARC2: Terminating pid 16462 hung on an I/O operation
  39. Thu Aug 15 08:11:40 2013
  40. krsv_proc_kill: Killing 1 processes (Process by index)
  41. Thu Aug 15 08:11:40 2013
  42. RFS[364]: Possible network disconnect with primary database
  43. Thu Aug 15 08:11:40 2013
  44. RFS[361]: Possible network disconnect with primary database
  45. Thu Aug 15 08:11:44 2013
  46. RFS[365]: Assigned to RFS process 16478
  47. RFS[365]: Selected log 22 for thread 2 sequence 725 dbid 1735692056 branch 823075992
  48. Thu Aug 15 08:11:44 2013
  49. RFS[366]: Assigned to RFS process 16480
  50. RFS[366]: Selected log 12 for thread 1 sequence 768 dbid 1735692056 branch 823075992
  51. Thu Aug 15 08:16:45 2013
  52. Primary database is in MAXIMUM PERFORMANCE mode
  53. RFS[367]: Assigned to RFS process 16509
  54. RFS[367]: Selected log 23 for thread 2 sequence 727 dbid 1735692056 branch 823075992
  55. Thu Aug 15 08:16:45 2013
  56. RFS[368]: Assigned to RFS process 16511
  57. RFS[368]: Selected log 21 for thread 2 sequence 726 dbid 1735692056 branch 823075992
  58. Thu Aug 15 08:19:15 2013
  59. RFS[365]: Possible network disconnect with primary database
  60. Thu Aug 15 08:21:28 2013
  61. RFS[369]: Assigned to RFS process 16520
  62. RFS[369]: Selected log 22 for thread 2 sequence 725 dbid 1735692056 branch 823075992
  63. Thu Aug 15 08:21:28 2013
  64. RFS[366]: Possible network disconnect with primary database
  65. Thu Aug 15 08:24:00 2013
  66. RFS[370]: Assigned to RFS process 16522
  67. RFS[370]: Selected log 12 for thread 1 sequence 768 dbid 1735692056 branch 823075992
  68. Thu Aug 15 08:26:33 2013
  69. Archived Log entry 195 added for thread 2 sequence 725 ID 0x67753a18 dest 1:
  70. Thu Aug 15 08:26:35 2013
  71. Archived Log entry 196 added for thread 1 sequence 768 ID 0x67753a18 dest 1:
  72. Thu Aug 15 08:26:40 2013
  73. Archived Log entry 197 added for thread 2 sequence 726 ID 0x67753a18 dest 1:
  74. Thu Aug 15 08:30:38 2013
  75. Primary database is in MAXIMUM PERFORMANCE mode
  76. Re-archiving standby log 23 thread 2 sequence 727
  77. RFS[371]: Assigned to RFS process 16558
  78. RFS[371]: Selected log 21 for thread 2 sequence 728 dbid 1735692056 branch 823075992
  79. Thu Aug 15 08:30:38 2013
  80. Archived Log entry 198 added for thread 2 sequence 727 ID 0x67753a18 dest 1:
  81. Thu Aug 15 08:30:38 2013
  82. Media Recovery Log /oraarch/testdb/1_731_823075992.arc
  83. Thu Aug 15 08:30:41 2013
  84. Primary database is in MAXIMUM PERFORMANCE mode
  85. Re-archiving standby log 11 thread 1 sequence 769
  86. RFS[372]: Assigned to RFS process 16560
  87. RFS[372]: Selected log 12 for thread 1 sequence 770 dbid 1735692056 branch 823075992
  88. Thu Aug 15 08:30:41 2013
  89. Archived Log entry 199 added for thread 1 sequence 769 ID 0x67753a18 dest 1:
  90. Thu Aug 15 08:43:45 2013
  91. Primary database is in MAXIMUM PERFORMANCE mode
  92. Thu Aug 15 08:46:11 2013
  93. Primary database is in MAXIMUM PERFORMANCE mode
  94. Thu Aug 15 08:48:41 2013
  95. RFS[373]: Assigned to RFS process 16636
  96. RFS[373]: Selected log 22 for thread 2 sequence 730 dbid 1735692056 branch 823075992
  97. Thu Aug 15 08:48:41 2013
  98. RFS[374]: Assigned to RFS process 16638
  99. RFS[374]: Selected log 23 for thread 2 sequence 729 dbid 1735692056 branch 823075992
  100. Thu Aug 15 08:48:41 2013
  101. RFS[375]: Assigned to RFS process 16640
  102. RFS[375]: Selected log 11 for thread 1 sequence 772 dbid 1735692056 branch 823075992
  103. Thu Aug 15 08:48:41 2013
  104. RFS[376]: Assigned to RFS process 16642
  105. RFS[376]: Selected log 13 for thread 1 sequence 771 dbid 1735692056 branch 823075992
  106. Thu Aug 15 08:48:41 2013
  107. Media Recovery Log /oraarch/testdb/1_732_823075992.arc
  108. Thu Aug 15 08:48:44 2013
  109. RFS[371]: Possible network disconnect with primary database
  110. Thu Aug 15 08:49:41 2013
  111. RFS[377]: Assigned to RFS process 16626
  112. RFS[377]: Possible network disconnect with primary database
  113. Thu Aug 15 08:51:29 2013
  114. Archived Log entry 200 added for thread 2 sequence 729 ID 0x67753a18 dest 1:
  115. Thu Aug 15 08:51:29 2013
  116. RFS[372]: Possible network disconnect with primary database
  117. Thu Aug 15 08:51:29 2013
  118. RFS[374]: Selected log 21 for thread 2 sequence 728 dbid 1735692056 branch 823075992
  119. Thu Aug 15 08:57:34 2013
  120. RFS[378]: Assigned to RFS process 16665
  121. RFS[378]: Selected log 12 for thread 1 sequence 770 dbid 1735692056 branch 823075992
  122. Thu Aug 15 09:00:04 2013
  123. RFS[374]: Possible network disconnect with primary database
  124. Thu Aug 15 09:02:34 2013
  125. Media Recovery Log /oraarch/testdb/2_692_823075992.arc
  126. Thu Aug 15 09:07:11 2013
  127. WARN: ARC2: Terminating pid 16665 hung on an I/O operation
  128. Thu Aug 15 09:07:36 2013
  129. Primary database is in MAXIMUM PERFORMANCE mode
  130. Thu Aug 15 09:07:37 2013
  131. krsv_proc_kill: Killing 1 processes (Process by index)
  132. RFS[379]: Assigned to RFS process 16723
  133. RFS[379]: Selected log 23 for thread 2 sequence 732 dbid 1735692056 branch 823075992
  134. Thu Aug 15 09:07:38 2013
  135. RFS[380]: Assigned to RFS process 16725
  136. RFS[380]: Selected log 24 for thread 2 sequence 731 dbid 1735692056 branch 823075992
  137. Thu Aug 15 09:07:39 2013
  138. RFS[381]: Assigned to RFS process 16721
  139. RFS[381]: Selected log 21 for thread 2 sequence 728 dbid 1735692056 branch 823075992
  140. Thu Aug 15 09:07:42 2013
  141. Media Recovery Log /oraarch/testdb/1_733_823075992.arc
  142. Thu Aug 15 09:12:53 2013
  143. Archived Log entry 201 added for thread 2 sequence 731 ID 0x67753a18 dest 1:
  144. Thu Aug 15 09:12:57 2013
  145. Archived Log entry 202 added for thread 1 sequence 771 ID 0x67753a18 dest 1:
  146. Thu Aug 15 09:13:03 2013
  147. Archived Log entry 203 added for thread 2 sequence 728 ID 0x67753a18 dest 1:
  148. Thu Aug 15 09:13:33 2013
  149. RFS[382]: Assigned to RFS process 16756
  150. RFS[382]: Selected log 13 for thread 1 sequence 773 dbid 1735692056 branch 823075992
  151. Thu Aug 15 09:16:14 2013
  152. RFS[383]: Assigned to RFS process 16758
  153. RFS[383]: Selected log 12 for thread 1 sequence 770 dbid 1735692056 branch 823075992
  154. Thu Aug 15 09:16:15 2013
  155. Media Recovery Log /oraarch/testdb/1_734_823075992.arc
复制代码

回复 只看该作者 道具 举报

6#
发表于 2013-8-15 10:43:52
检查一下存储设备。看一下存储设备的性能。
看iostat的数据，存储性能还不如我家一块15K的sas盘。

回复 只看该作者 道具 举报

7#
发表于 2013-8-15 12:58:17
[root@datadg1 ~]# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1             101G   37G   60G  38% /
tmpfs                  63G     0   63G   0% /dev/shm
/dev/sdb1             788G  158G  590G  22% /orasjrz
/dev/sdc1             296G   11G  270G   4% /oraarch
[root@datadg1 ~]#
[root@datadg1 ~]# hdparm -tT /dev/sdb

/dev/sdb:
Timing cached reads:   21768 MB in  2.00 seconds = 10908.09 MB/sec
Timing buffered disk reads:    2 MB in  5.99 seconds = 341.65 kB/sec
[root@datadg1 ~]#
[root@datadg1 ~]# hdparm -tT /dev/sdb

/dev/sdb:
Timing cached reads:   21576 MB in  2.00 seconds = 10810.32 MB/sec
Timing buffered disk reads:  266 MB in  3.01 seconds =  88.25 MB/sec
[root@datadg1 ~]#
[root@datadg1 ~]# hdparm -tT /dev/sdb

/dev/sdb:
Timing cached reads:   21924 MB in  2.00 seconds = 10985.86 MB/sec
Timing buffered disk reads:  432 MB in  3.02 seconds = 143.20 MB/sec
[root@datadg1 ~]#
[root@datadg1 ~]# hdparm -tT /dev/sdb

/dev/sdb:
Timing cached reads:   21592 MB in  2.00 seconds = 10819.41 MB/sec
Timing buffered disk reads:  534 MB in  3.00 seconds = 177.86 MB/sec
[root@datadg1 ~]# hdparm -tT /dev/sdb

/dev/sdb:
Timing cached reads:   21556 MB in  2.00 seconds = 10799.84 MB/sec
Timing buffered disk reads:  598 MB in  3.00 seconds = 199.08 MB/sec
[root@datadg1 ~]# hdparm -tT /dev/sdb

/dev/sdb:
Timing cached reads:   21756 MB in  2.00 seconds = 10902.08 MB/sec
Timing buffered disk reads:  646 MB in  3.02 seconds = 214.23 MB/sec
[root@datadg1 ~]# hdparm -tT /dev/sdb

/dev/sdb:
Timing cached reads:   21288 MB in  2.00 seconds = 10667.04 MB/sec
Timing buffered disk reads:  672 MB in  3.01 seconds = 223.16 MB/sec
[root@datadg1 ~]# hdparm -tT /dev/sdc

/dev/sdc:
Timing cached reads:   21320 MB in  2.00 seconds = 10682.70 MB/sec
Timing buffered disk reads:  264 MB in  3.02 seconds =  87.49 MB/sec
[root@datadg1 ~]# hdparm -tT /dev/sdc

/dev/sdc:
Timing cached reads:   21096 MB in  2.00 seconds = 10570.45 MB/sec
Timing buffered disk reads:  436 MB in  3.00 seconds = 145.17 MB/sec
[root@datadg1 ~]# hdparm -tT /dev/sdc

/dev/sdc:
Timing cached reads:   21472 MB in  2.00 seconds = 10758.59 MB/sec
Timing buffered disk reads:  534 MB in  3.01 seconds = 177.30 MB/sec

回复 只看该作者 道具 举报

8#
发表于 2013-8-15 13:03:05
结果怎么越测越大？数据库再开启来同步时一会会很快一直同步，但过了几分钟开始又慢下来了，这是为什么？
dg alert
Thu Aug 15 12:50:03 2013
Managed Standby Recovery starting Real Time Apply
Parallel Media Recovery started with 16 slaves
Waiting for all non-current ORLs to be archived...
All non-current ORLs have been archived.
Media Recovery Log /oraarch/hisdb/2_707_823075992.arc
Media Recovery Log /oraarch/hisdb/1_747_823075992.arc
Media Recovery Log /oraarch/hisdb/1_748_823075992.arc
Completed: alter database recover managed standby database using current logfile disconnect
Media Recovery Log /oraarch/hisdb/1_749_823075992.arc
Thu Aug 15 12:50:15 2013
Media Recovery Log /oraarch/hisdb/2_708_823075992.arc
Media Recovery Log /oraarch/hisdb/2_709_823075992.arc
Thu Aug 15 12:50:32 2013
Media Recovery Log /oraarch/hisdb/2_710_823075992.arc
Media Recovery Log /oraarch/hisdb/1_750_823075992.arc
Media Recovery Log /oraarch/hisdb/2_711_823075992.arc
Thu Aug 15 12:50:54 2013
Media Recovery Log /oraarch/hisdb/1_751_823075992.arc
Media Recovery Log /oraarch/hisdb/2_712_823075992.arc
Media Recovery Log /oraarch/hisdb/1_752_823075992.arc
Thu Aug 15 12:51:05 2013
Media Recovery Log /oraarch/hisdb/1_753_823075992.arc
Media Recovery Log /oraarch/hisdb/2_713_823075992.arc
Media Recovery Log /oraarch/hisdb/1_754_823075992.arc
Thu Aug 15 12:51:17 2013
Media Recovery Log /oraarch/hisdb/2_714_823075992.arc
Media Recovery Log /oraarch/hisdb/1_755_823075992.arc
Media Recovery Log /oraarch/hisdb/2_715_823075992.arc
Thu Aug 15 12:51:29 2013
Media Recovery Log /oraarch/hisdb/1_756_823075992.arc
Media Recovery Log /oraarch/hisdb/1_757_823075992.arc
Media Recovery Log /oraarch/hisdb/2_716_823075992.arc
Media Recovery Log /oraarch/hisdb/1_758_823075992.arc
Media Recovery Log /oraarch/hisdb/2_717_823075992.arc
Media Recovery Log /oraarch/hisdb/1_759_823075992.arc
Media Recovery Log /oraarch/hisdb/1_760_823075992.arc
Thu Aug 15 12:51:45 2013
Media Recovery Log /oraarch/hisdb/2_718_823075992.arc
Media Recovery Log /oraarch/hisdb/2_719_823075992.arc
Media Recovery Log /oraarch/hisdb/1_761_823075992.arc
Media Recovery Log /oraarch/hisdb/2_720_823075992.arc
Thu Aug 15 12:51:57 2013
Media Recovery Log /oraarch/hisdb/1_762_823075992.arc
Media Recovery Log /oraarch/hisdb/2_721_823075992.arc
Media Recovery Log /oraarch/hisdb/1_763_823075992.arc
Media Recovery Log /oraarch/hisdb/1_764_823075992.arc
Thu Aug 15 12:52:08 2013
Media Recovery Log /oraarch/hisdb/1_765_823075992.arc
Media Recovery Log /oraarch/hisdb/2_722_823075992.arc
Media Recovery Log /oraarch/hisdb/1_766_823075992.arc
Media Recovery Log /oraarch/hisdb/2_723_823075992.arc
Media Recovery Log /oraarch/hisdb/1_767_823075992.arc
Thu Aug 15 12:52:18 2013
Media Recovery Log /oraarch/hisdb/2_724_823075992.arc
Media Recovery Log /oraarch/hisdb/2_725_823075992.arc
Media Recovery Log /oraarch/hisdb/1_768_823075992.arc
Media Recovery Log /oraarch/hisdb/2_726_823075992.arc
Media Recovery Log /oraarch/hisdb/1_769_823075992.arc
Thu Aug 15 12:52:35 2013
Media Recovery Log /oraarch/hisdb/2_727_823075992.arc
又卡在这下不去了，io一直100%
开始同步时io
Device:         rrqm/s   wrqm/s   r/s   w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await  svctm  %util
sda               0.00     0.00  0.00  0.33     0.00     0.00     8.00     0.00   10.00  10.00   0.33
sda1              0.00     0.00  0.00  0.33     0.00     0.00     8.00     0.00   10.00  10.00   0.33
sda2              0.00     0.00  0.00  0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
sdb               2.67   749.33 278.67 207.33     5.23     3.74    37.77    10.36   21.51   2.06 100.03
sdb1              2.67   749.33 278.67 207.33     5.23     3.74    37.77    10.36   21.51   2.06 100.03
sdc               0.00     0.00  0.00  0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
sdc1              0.00     0.00  0.00  0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00

Device:         rrqm/s   wrqm/s   r/s   w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await  svctm  %util
sda               0.00     0.00  0.00  0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
sda1              0.00     0.00  0.00  0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
sda2              0.00     0.00  0.00  0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
sdb               0.67  2194.67 90.33 539.00     1.58    10.68    39.90     4.98    8.16   1.59 100.00
sdb1              0.67  2194.67 90.33 539.00     1.58    10.68    39.90     4.98    8.16   1.59 100.00
sdc               0.00     0.33  0.00  0.67     0.00     0.00    12.00     0.00    0.50   0.50   0.03
sdc1              0.00     0.33  0.00  0.67     0.00     0.00    12.00     0.00    0.50   0.50   0.03


现在io

Device:         rrqm/s   wrqm/s   r/s   w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await  svctm  %util
sda               0.00     0.00  0.00  0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
sda1              0.00     0.00  0.00  0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
sda2              0.00     0.00  0.00  0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
sdb               0.00     0.00  0.00  0.00     0.00     0.00     0.00     3.00    0.00   0.00 100.00
sdb1              0.00     0.00  0.00  0.00     0.00     0.00     0.00     3.00    0.00   0.00 100.00
sdc               0.00     0.00  0.00  0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
sdc1              0.00     0.00  0.00  0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00

Device:         rrqm/s   wrqm/s   r/s   w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await  svctm  %util
sda               0.00     0.00  0.00  0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
sda1              0.00     0.00  0.00  0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
sda2              0.00     0.00  0.00  0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
sdb               0.00     0.00  0.00  0.00     0.00     0.00     0.00     3.00    0.00   0.00 100.03
sdb1              0.00     0.00  0.00  0.00     0.00     0.00     0.00     3.00    0.00   0.00 100.03
sdc               0.00     0.00  0.00  0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
sdc1              0.00     0.00  0.00  0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00

回复 只看该作者 道具 举报

9#
发表于 2013-8-15 14:48:18
/dev/sdb:
Timing cached reads:   21768 MB in  2.00 seconds = 10908.09 MB/sec
Timing buffered disk reads:    2 MB in  5.99 seconds = 341.65 kB/sec
[root@datadg1 ~]#

这个很说明问题了吧

回复 只看该作者 道具 举报

10#
发表于 2013-8-15 15:05:45
给出下面的 输出：


set serveroutput on;
DECLARE
lat INTEGER;
iops INTEGER;
mbps INTEGER;
BEGIN
DBMS_RESOURCE_MANAGER.CALIBRATE_IO(20, 15, iops, mbps, lat);
DBMS_OUTPUT.PUT_LINE ('max_iops = ' || iops);
DBMS_OUTPUT.PUT_LINE ('latency = ' || lat);
dbms_output.put_line('max_mbps = ' || mbps);
end;
/

回复 只看该作者 道具 举报

11#
发表于 2013-8-15 15:47:34
SQL> select name,open_mode,PROTECTION_MODE,DATABASE_ROLE from v$database;

NAME      OPEN_MODE            PROTECTION_MODE      DATABASE_ROLE
--------- -------------------- -------------------- ----------------
TESTDB     READ ONLY WITH APPLY MAXIMUM PERFORMANCE  PHYSICAL STANDBY

SQL> set serveroutput on;
DECLARE
lat INTEGER;
iops INTEGER;
mbps INTEGER;
BEGIN
DBMS_RESOURCE_MANAGER.CALIBRATE_IO(20, 15, iops, mbps, lat);
DBMS_OUTPUT.PUT_LINE ('max_iops = ' || iops);
DBMS_OUTPUT.PUT_LINE ('latency = ' || lat);
dbms_output.put_line('max_mbps = ' || mbps);
end;
/SQL>   2    3    4    5    6    7    8    9   10   11  
DECLARE
*
第 1 行出现错误:
ORA-56708: 找不到任何具有异步 I/O 功能的数据文件
ORA-06512: 在 "SYS.DBMS_RMIN", line 463
ORA-06512: 在 "SYS.DBMS_RESOURCE_MANAGER", line 1296
ORA-06512: 在 line 6


SQL>

回复 只看该作者 道具 举报

返回列表
高级模式
B Color Image Link Quote Code Smilies
您需要登录后才可以回帖 登录 | 注册

QQ|手机版|Archiver|Oracle数据库数据恢复、性能优化

GMT+8, 2025-1-1 10:59 , Processed in 0.053676 second(s), 24 queries .

Powered by Discuz! X2.5

© 2001-2012 Comsenz Inc.

回顶部
TEL/電話+86 13764045638
Email service@parnassusdata.com
QQ 47079569