none
帮忙看下这个性能监视器的结果,是不是I/O有点问题? RRS feed

  • 问题

  • Time LogicalDisk(_Total)\Avg. Disk sec/Transfer Memory\Available MBytes Memory\Pages/sec PhysicalDisk(_Total)\% Disk Time PhysicalDisk(_Total)\Avg. Disk Queue Length Processor(_Total)\% Processor Time SQLServer:Access Methods\Page Splits/sec SQLServer:Buffer Manager\Buffer cache hit ratio SQLServer:Buffer Manager\Free pages SQLServer:Buffer Manager\Page life expectancy System\Processor Queue Length
    06/07/2011 09:27:41.224 0.004539482 780 0.141680059 5.006930824 0.200277233 3.465032239 4.042048743 99.99749084 5602 1333 0
    06/07/2011 09:29:41.226 0.00179073 777 0 1.027896931 0.041115877 4.678750751 4.324832039 100 1481 1333 0
    06/07/2011 09:31:41.228 0.001744488 774 0.141658808 0.80921363 0.032368545 3.099191246 2.441531217 99.99656652 5384 1333 0
    06/07/2011 09:33:41.231 0.001227834 772 0 1.469680115 0.058787205 2.501871964 1.475134802 100 4450 1333 0
    06/07/2011 09:35:41.233 0.022423518 767 62.07207331 9.539316845 0.381572674 4.462283574 2.583211535 99.99743977 3652 1333 0
    06/07/2011 09:37:41.235 0.001515625 762 0 0.418283636 0.016731345 3.142321834 2.566566811 100 5266 1333 0
    06/07/2011 09:39:41.237 0.001497604 761 1.341614407 1.892217282 0.075698547 4.143279282 4.683150911 100 1607 1333 0
    06/07/2011 09:41:41.240 0.065673068 757 0.533381954 68.22713645 2.728730108 5.617860304 3.216959907 100 6660 1333 0
    06/07/2011 09:43:41.242 0.001717269 754 0 0.724590255 0.02898361 3.471905423 3.124878074 100 4745 1386 0
    06/07/2011 09:45:41.244 0.001164479 748 0.566644561 1.439639026 0.057585561 4.389856548 3.34153631 100 3448 1506 0
    06/07/2011 09:47:41.247 0.020934803 746 0.099996091 19.87572255 0.795028902 5.796893366 2.766558521 100 9510 1509 0
    06/07/2011 09:49:41.249 0.05345471 742 0.183348573 21.00255508 0.840102203 3.500387959 2.966913278 99.990006 6266 1509 1
    06/07/2011 09:51:41.251 0.000911441 738 0 0.841296347 0.033651854 4.338587949 3.45819853 100 5205 1509 0
    06/07/2011 09:53:41.254 0.001111099 735 0.024999025 0.482074078 0.019282963 4.45414573 3.574860599 99.97462144 4345 1509 0
    06/07/2011 09:55:41.256 0.000850984 732 52.4626921 0.921044816 0.036841793 3.326237636 3.850319897 100 5421 1509 0
    06/07/2011 09:57:41.258 0.002526376 732 0 2.006232314 0.080249293 4.71130221 2.774891846 100 8709 1509 0
    06/07/2011 09:59:41.261 0.067877196 729 0.099996093 111.9491631 4.477966523 4.424035559 2.399906226 99.95837236 4572 1509 0
    06/07/2011 10:01:41.263 0.002360799 726 67.66402261 2.2482485 0.08992994 3.96424622 2.341575167 100 9332 1509 0
    06/07/2011 10:03:41.265 0.001826729 727 0 0.896524453 0.035860978 4.482628184 2.558546245 100 8233 1509 0
    06/07/2011 10:05:41.267 0.001767293 727 69.38118896 1.019042934 0.040761717 3.738013647 3.374895692 100 4800 1509 0
    06/07/2011 10:07:41.270 0.21025218 727 0.399984418 370.7461108 14.82984443 4.151417126 7.666368004 100 4087 1509 0
    06/07/2011 10:09:41.272 0.000920627 725 1.199953306 1.316266394 0.052650656 4.524945038 3.141544419 100 3080 1509 0
    06/07/2011 10:11:41.274 0.00267613 722 0.016668187 0.787172386 0.031486895 3.710344845 2.716914509 100 5441 1557 0
    06/07/2011 10:13:41.277 0.001275841 723 0.091663101 0.550135271 0.022005411 3.200100808 2.374907607 100 6583 1677 0
    06/07/2011 10:15:41.279 0.016624404 723 0.658296971 6.901055 0.2760422 4.393111652 2.383201691 99.97530864 8709 1796 0
    06/07/2011 10:17:41.281 0.004154718 723 0 4.183157 0.16734262 3.745337673 2.333242637 100 4406 1917 0
    06/07/2011 10:19:41.284 0.00622664 737 539.1741456 34.60094387 1.383902596 9.581000378 48.14605517 99.99592568 866 1985 0
    06/07/2011 10:21:41.286 0.012837256 731 5.233130329 64.49301173 2.579720469 8.842082232 3.908181726 99.86130374 6985 118 0
    06/07/2011 10:23:41.288 0.002620808 728 0.199993835 1.39116079 0.055646432 3.497946589 2.616586009 99.90947495 6947 238 0
    06/07/2011 10:25:41.290 0.002183402 725 62.5892301 1.179331524 0.047173261 3.068267339 3.133211359 100 5208 358 0
    06/07/2011 10:27:41.293 0.008960032 721 0.225020553 17.53160089 0.701264036 7.158358143 3.158621837 99.99953655 6747 478 0
    2011年6月7日 3:26

答案

  • It depends on network speed, you can set dedicated network for backup if possible. By the way, sql2k8 comes backup compression, much less network traffic for backup.

    Regarding db file placement, each sql server should have at lest 3 arrays for dbs. One for user dbs' data files, one for system dbs' data files and one for log files. Backup should always on its location. If you eye on performance, should go right way at very beginning.

    2011年6月8日 13:35

全部回复

  • 06/07/2011 10:29:41.295 0.00796613 719 0.274989301 3.581139575 0.143245583 9.560655685 2.933219213 99.99976356 5535 598 0
    06/07/2011 10:31:41.297 0.097432799 715 0.133328147 77.3177655 3.09271062 9.06994244 2.124917342 99.99976421 5170 718 0
    06/07/2011 10:33:41.300 0.001244908 712 0.066664073 1.504991937 0.060199677 5.986505642 2.916553208 99.97333333 3676 838 0
    06/07/2011 10:35:41.302 0.036859015 709 59.59662744 16.14427336 0.645770935 6.763671638 2.308525493 100 12872 855 1
    06/07/2011 10:37:41.304 0.00529004 707 0 1.726987675 0.069079507 10.2133124 3.05821425 99.99976773 10098 855 0
    06/07/2011 10:39:41.307 0.001561392 703 0 1.873672359 0.074946894 8.883585352 3.358202436 100 10774 855 1
    06/07/2011 10:41:41.309 0.003921598 701 0 1.487472011 0.059504691 3.248927954 2.733226828 99.91714996 7016 855 1
    06/07/2011 10:43:41.311 0.029654508 699 0 12.00852549 0.480294112 4.270229928 2.675244371 99.91311903 3709 855 0
    06/07/2011 10:45:41.314 0.003355486 691 0.216658186 3.426288382 0.137051535 5.290718168 2.324909 99.89102797 4364 855 0
    06/07/2011 10:47:41.316 0.002137761 684 0 1.268121485 0.050724859 4.53226923 3.249874581 99.94837377 7284 855 0
    06/07/2011 10:49:41.318 0.043306837 683 0 71.98965947 2.879586379 5.452661642 3.574860832 99.94173173 5713 943 0
    06/07/2011 10:51:41.320 0.002519121 684 0 1.304433288 0.052177332 3.472719157 2.275208185 99.97937223 6616 1063 0
    06/07/2011 10:53:41.323 0.003608167 684 0 2.609908223 0.104396329 3.273341569 2.341575745 100 4671 1183 0
    06/07/2011 10:55:41.325 0.001572301 683 56.59780537 2.010378067 0.080415123 4.743853668 2.983217656 100 3018 1303 0
    06/07/2011 10:57:41.327 0.001581703 683 0.066664079 1.086812467 0.043472499 3.437726412 2.691562199 99.95877988 9060 1423 0
    06/07/2011 10:59:41.330 0.001524401 679 0 0.738131661 0.029525266 3.17812848 2.725271331 100 6375 1542 0
    06/07/2011 11:01:41.332 0.001367725 674 0.17499321 1.825652447 0.073026098 5.814796606 3.55819527 100 4924 1663 0
    06/07/2011 11:03:41.334 0.068817268 674 0.133328166 48.97712214 1.959084886 3.259507167 2.733227401 100 5484 1746 0
    06/07/2011 11:05:41.337 0.016893941 672 61.18929371 18.78718095 0.751487238 3.190335329 2.766559378 99.79879276 6058 1746 0
    06/07/2011 11:07:41.339 0.008013434 673 0.18334859 8.277486906 0.331099476 5.127960876 3.450287111 99.95568779 3747 1746 0
    06/07/2011 11:09:41.341 0.015367885 671 0.149994164 6.737870633 0.269514825 3.335189298 2.691561936 99.99184472 6172 1746 0
    06/07/2011 11:11:41.343 0.027258797 671 0.066664097 8.857038278 0.354281531 2.8290141 2.141584113 99.91868974 6786 1746 0

    If you haven't all the things you want,be grateful for the things you don't have that you didn't want.
    2011年6月7日 3:29
  • 这是第一次使用性能计数器来进行监控。所以不太熟悉。

    从这个结果看:CPU和Memory应该没问题,I/O感觉有点问题,正确吗?


    If you haven't all the things you want,be grateful for the things you don't have that you didn't want.
    2011年6月7日 3:30
  • What makes you feel there's i/o issue?
    2011年6月7日 3:40
  • What makes you feel there's i/o issue?


    我从网上看LogicalDisk(_Total)\Avg. Disk sec/Transfer这个值的参考值是0.02.

    PhysicalDisk(_Total)\Avg. Disk Queue Length这个值在我的结果集中有些时候会大于2.

    而且有些时候%Disk Time也会很大,超过90.

    不知道这个是否正确?


    If you haven't all the things you want,be grateful for the things you don't have that you didn't want.
    2011年6月7日 3:43
  • What makes you feel there's i/o issue?


    我从网上看LogicalDisk(_Total)\Avg. Disk sec/Transfer这个值的参考值是0.02.

    PhysicalDisk(_Total)\Avg. Disk Queue Length这个值在我的结果集中有些时候会大于2.

    而且有些时候%Disk Time也会很大,超过90.

    不知道这个是否正确?


    If you haven't all the things you want,be grateful for the things you don't have that you didn't want.


    disk queue length不能直接反映出是否有瓶颈,这个计数器要结合磁盘的个数,raid级别和条带大小来综合考虑

    可以使用下面这两个

    Avg. Disk Sec/Read
    Avg. Disk Sec/Write

    • Less than 10 ms - very good
    • Between 10 - 20 ms - okay
    • Between 20 - 50 ms - slow, needs attention
    • Greater than 50 ms – Serious I/O bottleneck


    有dba的职位吗(北京的),请联系我 stswordman#hotmail.com
    2011年6月7日 4:06
    版主
  • 这是否说明IO 有点问题呢?

    我是将tempdb和数据文件放置在RAID1上的。将用户数据库的日志文件放置在RAID10上的。并且备份文件也是和用户数据库的日志文件放置在同一个RAID中


    If you haven't all the things you want,be grateful for the things you don't have that you didn't want.

    2011年6月7日 6:40
  • PhysicalDisk(_Total)\% Disk Time PhysicalDisk(_Total)\Avg. Disk Queue Length PhysicalDisk(_Total)\Avg. Disk sec/Read PhysicalDisk(_Total)\Avg. Disk sec/Write
           
    16.6075353 0.664301412 0.052081373 0.000689456
    0.807026172 0.032281047 0.003568589 0.000485054
    212.1331354 8.485325415 0.268484377 0.019330067
    1.324578735 0.052983149 0.00563474 0.000600478
    2.077710108 0.083108404 0.006113514 0.001046613
    2.251831765 0.090073271 0.004981684 0.000746473
    531.5478776 21.2619151 0.270424488 0.028181211
    2.491264668 0.099650587 0.003723086 0.000586701
    110.8754129 4.435016514 0.042718651 0.004443693
    1.333224402 0.053328976 0.006620943 0.0005875
    4.035464186 0.161418567 0.022599505 0.000756783
    2.658157297 0.106326292 0.012117076 0.000603119
    27.79773712 1.111909485 0.105927443 0.000693587
    223.8212235 8.952848939 0.0115186 0.229757558
    4.349062331 0.173962493 0.006740985 0.001275013
    409.9961489 16.39984596 0.008083431 0.437441566
    12753.4554 510.1382162 1.069520854 0.562685362
    15802.51478 632.1005912 1.101655433 0.153270203
    70.21227692 2.808491077 0.029343014 0.001093204
    111.3262167 4.453048668 0.109899357 0.052456777
    1.539116282 0.061564651 0.007853686 0.000660531
    1.362911332 0.054516453 0.003356642 0.000919782
    5.662266284 0.226490651 0.004670833 0.005031988
    1.401348094 0.056053924 0.004767047 0.001308253
    0.937822141 0.037512886 0.003219325 0.00106434

     

    上面的那一份是上午生产的时候抓取的数据。

    下面的这一份是下午专门抓取的Physical Disk部分的监控。

    看起来不太理想~

    2011年6月7日 6:48
  • 不要选择_total,分开计算.这样合起来没什么意义

    log决定了事物的提交速度.

    将备份文件和log放在一起会影响事物的吞吐. 尽量把log放在独立的存储上.

     

    你给出的监控数据中的第17,18行影响了整体结果,那是后服务器在进行什么操作?

     


    有dba的职位吗(北京的),请联系我 stswordman#hotmail.com
    2011年6月7日 7:14
    版主
  • 不要选择_total,分开计算.这样合起来没什么意义

    log决定了事物的提交速度.

    将备份文件和log放在一起会影响事物的吞吐. 尽量把log放在独立的存储上.

     

    你给出的监控数据中的第17,18行影响了整体结果,那是后服务器在进行什么操作?

     


    有dba的职位吗(北京的),请联系我 stswordman#hotmail.com

    但是存储上只做了两个RAID。一个RAID1,上面放置了数据文件,tempdb和划分一块作为仲裁。

    另外一个RAID10,上面存放了日志文件和备份文件。

    因为没有多余的Raid了,所以就这样放置了。


    If you haven't all the things you want,be grateful for the things you don't have that you didn't want.
    2011年6月7日 7:30
  • 不要选择_total,分开计算.这样合起来没什么意义

    log决定了事物的提交速度.

    将备份文件和log放在一起会影响事物的吞吐. 尽量把log放在独立的存储上.

     

    你给出的监控数据中的第17,18行影响了整体结果,那是后服务器在进行什么操作?

     


    有dba的职位吗(北京的),请联系我 stswordman#hotmail.com

    我有分开去monitor硬盘的情况。

    发现R盘的情况是OK的,该盘是存放DB Log和做备份的。

    另外一个S盘是做TEMpDB和存放数据库数据文件的。

    PhysicalDisk(3 S:)\% Disk Time PhysicalDisk(3 S:)\Avg. Disk Read Queue Length PhysicalDisk(3 S:)\Avg. Disk sec/Read PhysicalDisk(3 S:)\Avg. Disk sec/Write PhysicalDisk(3 S:)\Current Disk Queue Length
    39.01641755 0.217101665 0.008530681 0.006901928 0
    36.16205569 0.357368139 0.024962165 0.001673114 0
    31.76822338 0.1753408 0.013028669 0.004190702 0
    1664.430043 16.54366736 0.069079585 0.019764648 16
    8364.298489 83.30436972 0.352059035 0.037416759 0
    12.06135176 0.104469661 0.009973429 0.000597748 0
    5.316897916 0.052194831 0.007257822 0.000501717 0
    15.75611415 0.155522847 0.01792805 0.00078147 0
    9.30640465 0.073386091 0.00963512 0.000698846 0
    21.74033259 0.207744345 0.012738784 0.002080969 0
    3.446683824 0.033471857 0.006762121 0.000579612 0
    6858.092241 67.55584959 0.082637869 0.02868729 128
    5123.223051 50.77442346 0.122473323 0.054719024 0
    50.48836396 0.49688796 0.027440267 0.002054604 1
    3332.629597 32.44810783 0.188408947 0.021216952 28
    3337.800331 32.76915917 0.186324312 0.053486603 0
    7638.265512 74.42313608 0.145673449 0.098470184 75
    3407.483076 33.50798331 0.060361403 0.014372068 0
    147.0484267 1.458892823 0.045179484 0.006100877 0
    3818.299105 37.83644854 0.286247699 0.010506796 0
    11.1423694 0.110542878 0.013147076 0.000583978 0
    35.11915905 0.35052577 0.048854704 0.000508918 0
    8.016762745 0.061235491 0.008821608 0.000681025 0
    6.660955443 0.0659604 0.005504451 0.000477915 0
    16.84517657 0.167766779 0.027169231 0.000477906 0
    644.6224566 5.814867521 0.182956869 0.014844103 2
    13.4650748 0.122870974 0.005169986 0.002287379 1
    67.51287042 0.672474588 0.060858597 0.00139083 0
    119.046131 1.171804168 0.073545607 0.000675588 0
    190.0928502 1.899511029 0.134322746 0.000988953 0
    754.6830934 7.46304671 0.036033749 0.006881793 72
    4773.102356 47.05497071 0.149498422 0.015802084 0
    1270.639604 12.6629852 0.038218999 0.007126402 0
    8.77899811 0.04807491 0.003436033 0.001228008 0
    45.97586726 0.458886189 0.044625121 0.000623214 0
    13.86931704 0.07692519 0.006631609 0.002044208 0
    4495.342689 42.5310434 0.17209506 0.119233634 0
    22.50448458 0.207445184 0.010376782 0.002613861 0
    15.19195831 0.102881358 0.006166833 0.001403793 0
    912.1088208 8.896694183 0.056577838 0.012841106 0
    20.2393614 0.173363338 0.00687963 0.00245331 0
    13.59307235 0.066223729 0.006711993 0.001999761 0
    77.45951278 0.748018971 0.029305909 0.002837367 0
    9.31648779 0.055251439 0.003155783 0.003287356 0
    47.17434425 0.396104895 0.004309474 0.001482653 0
    4176.834805 40.90513795 0.087154412 0.032564351 0
    1580.816982 15.72255229 0.099255221 0.013699067 0
    2660.003511 25.66220562 0.111848465 0.028477151 0
    5336.126713 51.64007268 0.162269965 0.101397791 34
    6174.590531 60.16878309 0.186848656 0.041089514 0
    56.17525477 0.535352221 0.019785494 0.002299056 0
    770.6597867 7.612201346 0.228370425 0.057501523 0
    21.39825582 0.196294564 0.017119041 0.000605074 0
    93.12796194 0.91978734 0.037352487 0.002582585 0
    6.040134029 0.056888074 0.007627598 0.001297231 0
    11.95743708 0.084085886 0.007091005 0.000948063 0

     


    If you haven't all the things you want,be grateful for the things you don't have that you didn't want.
    2011年6月7日 10:03
  • 不要选择_total,分开计算.这样合起来没什么意义

    log决定了事物的提交速度.

    将备份文件和log放在一起会影响事物的吞吐. 尽量把log放在独立的存储上.

     

    你给出的监控数据中的第17,18行影响了整体结果,那是后服务器在进行什么操作?

     


    有dba的职位吗(北京的),请联系我 stswordman#hotmail.com

    但是存储上只做了两个RAID。一个RAID1,上面放置了数据文件,tempdb和划分一块作为仲裁。

    另外一个RAID10,上面存放了日志文件和备份文件。

    因为没有多余的Raid了,所以就这样放置了。


    If you haven't all the things you want,be grateful for the things you don't have that you didn't want.
    How can you put tempdb on quorum disk? Backup files should be on remote location, you lose all backups if server or disk goes wrong. I rather put log files on raid1 and data files on raid10.
    2011年6月7日 13:25
  • 不要选择_total,分开计算.这样合起来没什么意义

    log决定了事物的提交速度.

    将备份文件和log放在一起会影响事物的吞吐. 尽量把log放在独立的存储上.

     

    你给出的监控数据中的第17,18行影响了整体结果,那是后服务器在进行什么操作?

     


    有dba的职位吗(北京的),请联系我 stswordman#hotmail.com

    但是存储上只做了两个RAID。一个RAID1,上面放置了数据文件,tempdb和划分一块作为仲裁。

    另外一个RAID10,上面存放了日志文件和备份文件。

    因为没有多余的Raid了,所以就这样放置了。


    If you haven't all the things you want,be grateful for the things you don't have that you didn't want.
    How can you put tempdb on quorum disk? Backup files should be on remote location, you lose all backups if server or disk goes wrong. I rather put log files on raid1 and data files on raid10.

    我的意思是仲裁和TEMPDB都是在一个物理RAID上,只是逻辑上分区不一样。

    你所谓的备份文件存放到remote location是指?

    因为RAID1上的磁盘空间比RAID10小,所以我就将RAID1上存放DATA,而在RAID10上存放的备份文件和日志文件。

    其实我也知道日志文件应该放置在RAID1上。而数据文件应该存放到RAID10上。只是考虑到磁盘空间问题,所以才这样划分的。


    If you haven't all the things you want,be grateful for the things you don't have that you didn't want.
    2011年6月8日 0:34
  • Remote location is storage on another server.

    2011年6月8日 3:35
  • Remote location is storage on another server.


    在cluster中也可以这样使用吗?
    If you haven't all the things you want,be grateful for the things you don't have that you didn't want.
    2011年6月8日 3:36
  • Sql can backup db to anywhere on your network (NAS, SAN and so), no matter if clustered or not.
    2011年6月8日 3:40
  • 现在RAID10的性能看起来是正常的。上面存放的是DB的备份文件和DB的日志文件。

    另外个RAID1上面存放的是DB的数据文件和TEMPDB文件。IO性能看起来有很大的问题。

    是不是因为我将数据文件和日志文件放错位置,导致IO异常?

    RAID1的写入速度很慢。


    If you haven't all the things you want,be grateful for the things you don't have that you didn't want.
    2011年6月8日 3:43
  • You answered your own question.
    2011年6月8日 3:46
  • You answered your own question.


    那我如果将之前的换一下:

    RAID10存放DB的备份文件和DB的数据文件和TEMPDB文件。

    RAID1上面存放DB的日志文件.

    这样是否会好点?如果将TEMPDB和日志文件放置在一起的话,IO应该也会有竞争的吧?

     另外因为我担心备份文件的问题,所以上面将备份文件也放置到RAID10.这样是否合理?也请帮忙评估下。因为RAID10的空间大一倍。


    If you haven't all the things you want,be grateful for the things you don't have that you didn't want.

    2011年6月8日 3:50
  • 磁盘性能算不上好,但是也不是很坏.磁盘偶尔的繁忙是正常的.

    你先select * from sys.dm_os_wait_stats order by wait_time_ms desc,看看瓶颈是什么。

    如果是log_waiter,那么说明日志磁盘有问题。如果是page_latch_xx,说明数据磁盘有问题。


    想不想时已是想,不如不想都不想。
    2011年6月8日 3:51
    版主
  • 磁盘性能算不上好,但是也不是很坏.磁盘偶尔的繁忙是正常的.

    你先select * from sys.dm_os_wait_stats order by wait_time_ms desc,看看瓶颈是什么。

    如果是log_waiter,那么说明日志磁盘有问题。如果是page_latch_xx,说明数据磁盘有问题。


    想不想时已是想,不如不想都不想。

    Waittype waiting_tasks_count waiting_time_ms max_waiting_time_ms signal_waiting_time_ms
    XE_TIMER_EVENT 5840 175140132 30031 175140037
    REQUEST_FOR_DEADLOCK_SEARCH 35031 175137644 5028 175137644
    LAZYWRITER_SLEEP 192408 175118859 1476 4562
    LOGMGR_QUEUE 367670 175116285 564745 24404
    SQLTRACE_INCREMENTAL_FLUSH_SLEEP 43711 174840297 4048 0
    ONDEMAND_TASK_QUEUE 2085 174711725 76791751 109
    CHECKPOINT_QUEUE 39902 174608800 14999332 2499
    XE_DISPATCHER_WAIT 17 173700132 61980034 0
    FT_IFTS_SCHEDULER_IDLE_WAIT 2895 173642842 60007 20
    CXPACKET 20520054 154722319 96538 2944455
    SLEEP_TASK 2527028 88286294 1037 83152
    BROKER_TO_FLUSH 85469 87572042 2595 1077
    PAGEIOLATCH_SH 1803346 48505125 2911 89658
    LATCH_EX 28372866 20653431 2827 1356239
    IO_COMPLETION 213570 2490176 2796 1833
    PAGEIOLATCH_EX 111838 2089694 2616 3326
    CMEMTHREAD 20880878 2038033 242 1654363
    ASYNC_NETWORK_IO 972261 1118290 2000 28533
    SQLTRACE_FILE_BUFFER 2184 962541 1006 239
    PAGELATCH_UP 1421746 903551 31 67863
    ASYNC_IO_COMPLETION 24 618262 237116 0
    SOS_SCHEDULER_YIELD 5782644 441517 53 437510
    OLEDB 243513 420120 594 0
    BACKUPBUFFER 184576 417372 595 2857
    WRITELOG 374897 368847 2266 15534
    BACKUPIO 125823 368325 603 292
    CXROWSET_SYNC 649035 149925 35 25222
    SLEEP_BPOOL_FLUSH 48555 145868 39 388
    LCK_M_S 217 130136 8117 12
    PAGELATCH_SH 538211 125607 1222 27759
    PREEMPTIVE_OS_WAITFORSINGLEOBJECT 34874 86330 1283 0
    BROKER_TASK_STOP 8 70119 10000 0
    EXECSYNC 111244 43844 8191 2934
    LATCH_SH 48949 43280 237 8316
    DTC 1910 40102 262 96
    MSQL_XP 13660 30481 921 0
    PREEMPTIVE_OS_GETPROCADDRESS 13660 30352 920 0
    PAGEIOLATCH_UP 1518 27487 1286 24
    LCK_M_SCH_M 54 24374 1955 8
    DTC_ABORT_REQUEST 8 24004 3000 0
    PREEMPTIVE_OS_FILEOPS 4256 19232 2722 0
    PREEMPTIVE_OS_WRITEFILEGATHER 83 17935 3088 0
    LCK_M_IX 38 15724 5001 1
    LCK_M_U 16 15323 10813 0
    PREEMPTIVE_OS_AUTHENTICATIONOPS 70927 15212 20 0
    PAGELATCH_EX 446652 14560 160 12900
    BACKUPTHREAD 3188 8458 5467 100
    PREEMPTIVE_OS_LOOKUPACCOUNTSID 6791 4314 165 0
    LCK_M_X 43 3731 533 0
    PREEMPTIVE_OS_SETFILEVALIDDATA 3187 2699 429 0
    PREEMPTIVE_OS_CRYPTACQUIRECONTEXT 10718 2214 8 0
    PREEMPTIVE_OS_FLUSHFILEBUFFERS 3276 1957 453 0
    PREEMPTIVE_OS_PIPEOPS 121 1852 127 0
    PREEMPTIVE_OS_DELETESECURITYCONTEXT 16924 1792 11 0
    WRITE_COMPLETION 475 1354 174 0
    PREEMPTIVE_OS_AUTHORIZATIONOPS 16996 1318 8 0
    PREEMPTIVE_OS_DTCOPS 1 1258 1258 0
    LCK_M_IU 1 1137 1137 0
    PREEMPTIVE_DTC_BEGINTRANSACTION 1993 1078 18 0

    If you haven't all the things you want,be grateful for the things you don't have that you didn't want.
    2011年6月8日 3:58
  • 磁盘性能算不上好,但是也不是很坏.磁盘偶尔的繁忙是正常的.

    你先select * from sys.dm_os_wait_stats order by wait_time_ms desc,看看瓶颈是什么。

    如果是log_waiter,那么说明日志磁盘有问题。如果是page_latch_xx,说明数据磁盘有问题。


    想不想时已是想,不如不想都不想。

    而且 我查看,发现是一直都这样的。。。。
    If you haven't all the things you want,be grateful for the things you don't have that you didn't want.
    2011年6月8日 3:58
  • 直接备份到远程吧,

    你的tempdb使用频繁吗?通过sys.dm_io_virtual_file_stats看一下各个文件的io比例.

    尽量调整吧...

     

    你遇到什么性能问题了吗?


    有dba的职位吗(北京的),请联系我 stswordman#hotmail.com
    2011年6月8日 4:01
    版主
  • 直接备份到远程吧,

    你的tempdb使用频繁吗?通过sys.dm_io_virtual_file_stats看一下各个文件的io比例.

    尽量调整吧...

     

    你遇到什么性能问题了吗?


    有dba的职位吗(北京的),请联系我 stswordman#hotmail.com

    现在还没遇到什么性能问题。只是说监控的结果是这样的。
    If you haven't all the things you want,be grateful for the things you don't have that you didn't want.
    2011年6月8日 4:04
  • 直接备份到远程吧,

    你的tempdb使用频繁吗?通过sys.dm_io_virtual_file_stats看一下各个文件的io比例.

    尽量调整吧...

    你遇到什么性能问题了吗?

    这是查看那个磁盘上的IO比例结果。

      num_of_reads 
    num_of_bytes_read
    io_stall_read_ms  num_of_writes  num_of_bytes_written io_stall_write_ms io_stall
    USERDB_DATA 80.10% 92.30% 97.70% 33.70% 24.50% 25.80% 95.40%
    TEMPDBDATA 7.40% 4.90% 0.73% 61.80% 60.50% 65.30% 2.80%
    2011年6月8日 5:58
  • 看起来 USERDATABASE的数据文件的读取蛮多的。

    但是TEMPDB的写入蛮多的。


    If you haven't all the things you want,be grateful for the things you don't have that you didn't want.
    2011年6月8日 6:01
  • Sql can backup db to anywhere on your network (NAS, SAN and so), no matter if clustered or not.


    恩,明白你的意思了。

    对了 如果数据库有三十多G,那么采用异地备份这种方式,是否比备份到本地更慢?

    而且网络流量方面是否也会比较大?


    If you haven't all the things you want,be grateful for the things you don't have that you didn't want.
    2011年6月8日 9:34
  • It depends on network speed, you can set dedicated network for backup if possible. By the way, sql2k8 comes backup compression, much less network traffic for backup.

    Regarding db file placement, each sql server should have at lest 3 arrays for dbs. One for user dbs' data files, one for system dbs' data files and one for log files. Backup should always on its location. If you eye on performance, should go right way at very beginning.

    2011年6月8日 13:35
  • It depends on network speed, you can set dedicated network for backup if possible. By the way, sql2k8 comes backup compression, much less network traffic for backup.

    Regarding db file placement, each sql server should have at lest 3 arrays for dbs. One for user dbs' data files, one for system dbs' data files and one for log files. Backup should always on its location. If you eye on performance, should go right way at very beginning.


    因为我来之前磁盘柜的RAID已经做好了.他们不想换了.

    而且我当时也有要求换,但是我们老大讲,我刚来 先低调点......

    当时为了这个RAID的配置 我还专门在网上查询过资料.记得当时还有问过你们..


    If you haven't all the things you want,be grateful for the things you don't have that you didn't want.
    2011年6月8日 14:29
  • 请问楼主怎样查出这些信息?是从SQL Server中,还是通过性能监视器?
    2013年1月17日 12:10
  • 性能监视器

    If you haven't all the things you want,be grateful for the things you don't have that you didn't want.

    2013年1月18日 10:47