本文大意：
     全篇主要讲硬件选择和服务器成本的考虑，包括内存的开销，cpu开销，以及sql server的收费方式。
本文大意：
     存储在sql server中占了很重要的角色，存储子系统配置的不对就会让server性能很烂。
     磁盘比较多的性能往往比磁盘少的性能好，因为磁盘多吞吐量大。
     关于容量的评估，可以更具，评估文件大小，tempdb大小，备份大小
     关于性能的评估，可以评估，顺序，随机的读写性能
性能测试工具：CrystalDiskMark
本文大意：
     关于SSD磁盘的使用，首先要看传统的磁盘和SSD的区别，通过测试传统的磁盘，顺序读写性能远远高于随机读写。而SSD除了顺序读写性能不俗之外，随机读写性能远远的提升。那么很显然了，如果传统的磁盘为了适应服务器性能需求，花费比使用SSD要大的时候，那么就可以考虑使用SSD来代替。一般适用的场景：1.单实例多数据库，随机io过大，可以考虑把log放入ssd中，2.tempdb io过大可以考虑把tempdb放ssd中。
本文大意：
     sql server的安装配置最佳实践从还未装之前就已经开始，在决定要cpu，服务器，io子系统之后，
     1.先保持bios，os版本最新。配置专用的域账号。
     2.在bios的电源控制中是否选择了关闭或者OS控制。windows上的电源控制是否选择了高性能。
     3.是否开启超线程，是否经过了测试。
     4.raid级别，需要的空间，是否需要多个逻辑盘，使用CrystalDiskMark,SQLIO测试性能，raid的cache大小，cache策略是否设置成需要的
     5.启动Windows instant File Initialization和Page Lock
     6.把sql server更新到最新版本
     7.设置最大服务内存
     8.Optimize for ad hoc workloads是否配置
     9.tempdb多文件考虑
     10.启动T3226关闭，当备份成功后往errorlog写入信息
额外阅读：

Provisioning a New SQL Server Instance – Part Two

Provisioning a New SQL Server Instance – Part Three

本文大意：
     使用虚拟化的原因：因为虚拟化便宜
     缺点：1.io达不到要求。2.VMWare下，VM会过渡使用内存。3.过渡使用cpu问题
     IO达不到要求：
          作者使用6个1T的7200-RPM在NetApp SAN的磁盘和5400-RPM的usb2.0的磁盘做了性能对比：
          
     发现2个性能差不多，对于SQL Server来所这样的io性能是不够的，并且如果出现io size的问题SAM并没有好的解决方案，SQL Server对磁盘的要求不单单是空间，还有性能
     内存问题：
     内存大了可以减少io，VMWare和hyper-v内存的分配方式不同，VMWare默认可以超过设置的内存，但是hyper-v启动时会检查可以使用的内存数量，不会超过这个数量，但是当有压力时，有一个最小可用内存保证了内存的需求。VMware也可以静态的保留内存以免VM过渡的使用内存。
     
     CPU问题：
     VM是通过共享cpu片段来实现并发问题，当一个host分配为一个宽VM一个窄VM就很容易出现调度的问题。对于4个虚拟处理器的VM，当其他VM发生并发时，可以调用的cpu时间片并不是4个cpu。为了解决这个问题引入了协作调度（co-schedule）
     在虚拟环境下经常会碰到特殊的workload导致cpu性能问题，表现在VM的cpu利用率高，增加vcpu反而加重问题。减少vcpu反而性能编号。说明协同调度有问题，要不是过度的提交，要不就是宽，窄混合，导致调度问题。
 

The Accidental DBA (Day 6 of 30): Backups: Understanding RTO and RPO

本文大意：
     RTO：恢复时间需求，RPO：允许丢失的数据
本文大意：
     不管对数据库做了什么修改都会产生日志，日志的去向就2中1.提交，2.回滚。
     管理事务日志，不能让日志文件过大，妨碍数据库正常使用。
     恢复模式：
     完全：日志全部记录，在日志备份时被截断
     大容量日志：某些日志被最小化记录，在日志备份时截断
     简单：某些日志最小化记录，checkpoint被截断
     备份类型：
     全备，日志备份，差异备份，文件组备份，文件备份，文件差异备份，文件组差异备份
     全备：备份所有数据和一部分日志，允许一致性事务点，全备不会截断日志，全备的备份日志量：从备份读取数据时最早的活动日志到，备份读取结束的日志
     事务日志：备份所有日志，要在全备之后才能使用，第一次全备之后，全备和日志备份将不再有任何关系
     差异备份：从你上次全备后的所有修改，差异备份是累计的，不是递增的
本文大意：
     还原最主要的2个问题：1.要多久，2.可以接受多少数据的丢失
     根据以上的2个点来设置还原策略，进而设计备份策略
     比如，如果数据丢失可以接受在15分钟，那么就日志的备份至少是15分钟一次，若无法承受，那么最后还要恢复尾日志。当然还可以使用同步进制如镜像
     恢复时间，需要同个各种恢复策略的测试，保证恢复时间在指定时间内。
笔者意见：
     用备份来做灾难性恢复，随着数据库越来越大，已经有点不太现实了，一般的做法还是使用数据库冗余，镜像，故障转移等手段。备份如果只是用来做容灾，那么已经有点落伍了。
本文大意：
     压缩：可以让备份更快，更小，但是费cpu
     Copy_only：只复制，对日志备份中，不会对日志链产生影响
     Description和File Names：加入一些描述性的东西到备份文件中。
     Checksum:1.验证从数据文件中过来的page，如果checksum对不上，默认备份失败，并且报出现数据页错误。2.对整个备份计算checksum并放入备份文件头
     Status：用来表示backup的进度
本文大意：
     验证备份，不单单是验证备份的文件是否可用，而且还要验证是不是在备份恢复的时间内，DBA不单单要保证备份的正确性，而且要验证备份。保证随着时间的推移不会造成备份文件错误，备份验证比较简单只需要做恢复就可以了。如果要验证备份内容的正确性，那么在备份的时候使用checksum，在恢复的时候也使用checksum，用来验证存在备份头里面的checksum是否正确。同时需要考虑备份保存的问题，保存在哪里，保存时间多长。
本文大意：
     关于备份的保存有2个重大问题：1.不要保存在和数据库同一个io子系统下，2.只保留一份最新的backup
     如果数据库突然crash，那么在异地有一份就可以迅速还原上来，但是 往往是本地的一台机器crash，其他机器没事儿，所以不但要在异地保留一份，要在本地异机也保留一份。
     如果只保留一份最新的备份，如果刚好，全备出错，那么就无法恢复了。所以，备份的保留时间也是一个问题。本地至少要保留一个月的备份，异地至少3个月。除非没周都测试。可以适当减少。
本文大意：
     关于VM快照的备份，作者说了很多，但是关键点是，VM快照备份有些地方不给力，如不能根据日志链恢复，只能恢复到快照的点。好处，可以恢复到某个文件，甚至是某一个对象。还可以帮忙截断事务日志。
本文大意：
     DBCC checkdb，如果要检查整个库需要执行DBCC CHECKALLOC,  DBCC CHECKCATALOG,  DBCC CHECKTABLE and  DBCC CHECKFILEGROUP是不正确的。
     对于大的数据库，可以先运行checkfilegroup，然后执行checkcatlog来分解。checkdb，检查尽早的排除数据错误的问题。如果出现问题，可以使用错误日志发现问题。发现问题后需要恢复，就要考虑2个问题：1.可以丢失多少数据，2.会宕机多久。可以先通过备份简历测试，通过测试发现是否在可以接受的范围，然后再处理。当dbcc checkdb恢复后，是不管约束的，所以之后要使用dbcc checkident和dbcc checkconstraints善后。
额外阅读：
本文大意：
     所以维护主要是维护索引碎片的问题。定期重建或者重组。碎片2个坏处：1.造成io量大，2.造成内存，空间浪费。
     对于脚本维护有一下建议1.少于1000页不用处理，2.碎片少于10%不用处理，3.10-30%重组，4.30%以上重建。
     Ola Hallengren’s Maintenance Solution是很牛b的脚本，可以阅读一下然后使用。
本文大意：
     对于统计信息维护，sql server会自动维护的规则：若 <500，累计500行更新，重新统计，>500则500+20%更新。
     统计信息是以BLOB方式存放在数据库中，一般自己不维护，而是更具优化器的需要自动创建，一般只有大的表需要做手动的统计信息维护。统计信息主要是包含了key的数据分布。统计信息分为3个部分：1.头，2.密度向量，3.直方图。
     统计信息的准确性，有很多因素，其中比较重要的是：表的大小，表是否频繁被修改。注意：索引重建会更改统计信息，但是索引重组不会。
      Ola Hallengren’s Maintenance Solution也可以用来维护统计信息
额外阅读：
本文大意：
     使用Agent alert可以用来反映严重错误的信息。通过配置agent alert 和操作员来完成。
     并且作者分享了一段代码
本文大意：
     谈到基线，就有4个问题：1.为什么要有基线，2.怎么获取基线，3.什么时候抓数据，4.怎么分析
     为什么要有基线：在出问题之间，提前发现问题；可以主动去调整；通过直方图发现其中变法，排查问题；数据和环境的变化；制定资源和能力计划
     怎么获取基线：通过抓取DMV，性能计数器
     什么时候抓数据：有些可以一天一次，比如可用空间，有些需要间隔几分钟一次比如性能指标。
     怎么分析：通过分析数据的变化来预测未来将要发生的情况
本文大意：
     主要介绍一些用来做监控的工具：
     1.性能计数器，比较全面，系统自带兼容性好。
     2.PAL，也是收集性能指标的，有统一的套件，不需要再自己配置了
     3.cleartrace，RML是用来分析sql trace的工具，有被扩展事件代替的趋势
     4.SQL Nexus是用来分析，SQLDiag和PSSDiag的结果
     5.DMV监控
我觉得在使用工具之前必须要了解是干什么用的，怎么分析的，才能用的得心应手
本文大意：
     索引是个很头痛的问题，如果不合适造成性能问题，如果没有select有性能问题。如果太多更改有性能问题。空间又浪费
     没有用的索引需要删除：
            1.完全重复的索引，可以使用通过DMV找出完全一样的索引干掉
            2.超出没用的索引，通过sys.dm_db_indes_usage_stats超出，干掉，注意，视图中的user_update是以语句个数来计算的
            3.相似的索引，索引相似一般分为几种情况，1.key相似 2.key的左边相似。 如果合并，会让io变大，可能会造成另外一个语句变烂，但是减少了空间，减少了维护成本，如果不合并浪费空间，浪费内存，更改性能可能会有潜在变化，并且便随死锁的出现。这些还是要看语句是否需要窄的索引。
     检查已存在的索引：
          1.主要是碎片的维护，2.填充因子的设置
     添加新的索引：
          添加新的索引是比较有难度的，因为需要分析已经存在的索引，如果只是单纯的添加索引，那么只会让索引越来越多，越来越臃肿，可以以miss index为指导创建索引。如果有miss index提示，那么把语句放到DTA上面，分析这样会比miss index更为全面，miss index 是为每个索引找最合适的索引，所以有时候需要考虑索引合并问题
额外阅读：
     讨论常用的一些性能指标的意义，性能计数器可以通过PAL进行统计，好处可以减少配置的时间，坏处是阀值是被写死的。
     CPU相关统计信息：
    • Processor
      • %Processor Time
      • %Privileged Time
    • Process (sqlservr.exe)
      • %Processor Time
      • %Privileged Time
     处理器有多少cpu时钟被使用，有多少被用在内核模式，程序占用了多少cpu，有多少使用与内核模式
     内存相关统计信息：
    • Memory
      • Available Mbytes    可用内存
    • SQL Server:Buffer Manager
      • Lazy writes/sec             Lazy write 次数
      • Page life expectancy    页生命周期
      • Page reads/sec             每秒页读取次数
      • Page writes/sec            每秒页写入次数
    • SQL Server:Memory Manager
      • Total Server Memory (KB)            总共服务内存
      • Target Server Memory (KB)          目标服务内存
    磁盘相关统计信息：
    • Physical Disk
      • Avg. Disk sec/Read                   读取延迟
      • Avg. Disk Bytes/Read               读取字节数
      • Avg. Disk sec/Write                   写入延迟
      • Avg. Disk Bytes/Write               写入字节数
    • Paging File
      • %Usage                                         page file使用率
    • SQL Server:Access Methods
      • Forwarded Records/sec              顺序记录数
      • Full Scans/sec                              扫描次数
      • Index Searches/sec                      查询次数
       对读取和写入延迟有一个推荐值来确定io是否正常：
        < 8ms: excellent
< 12ms: good
< 20ms: fair
> 20ms: poor
本文大意：
     决定使用高可用的策略：
     1.确定会使用到什么技术，并且是否有某些高可用会对这些技术排斥
     2.选择高可用技术
     3.测试高可用性，是否能够达到高可用的需要，并且对性能造成的影响可以在接受的范围内
本文大意：
     最不想聊的，就是说一些高可用和灾难恢复的一些技术，而且很浅。新人可以以此为切入点深入
本文大意：
     当sql server执行一个task时，出现的等待都会被记录到sys.dm_os_wait_stats上面，在paul的博客上面：wait stats post介绍了有关这个DMV一些脚本。然后过滤掉不想管的wait stats。wait stats只能当做一个troubleshooting的方向和切入点，不能认为真的是这个问题。
额外阅读：
      wait stats post
本文大意：
      对于dba来说，不单单是存储空间，还有性能，吞吐量，sys.dm_io_vaitual_file_stats获取数据库io信息。里面的值都是累加的，只有重启时才会重置。这个dmv不但有io延迟，还有读写次数和读写的字节数，用来标记读写做多的文件。
     io的延迟使用avg disk sec/write 和 avg disk sec/read，磁盘缓存，控制卡，存储系统都会影响延迟。延迟不单单是和host和磁盘相关，是从host到磁盘的整个路径，如总线，交换机，SAN控制器，磁盘。一般资深的存储管理员都会知道这个路径。
     avg disk bytes/read和avg disk bytes/write用来表示吞吐量，要测试吞吐量的极限可以简单的创建索引，来增大io的量。
     对sys.dm_io_vaitual_file_stats建立极限可以有详细的信息，说服存储管理员给予性能上的支持。还可以帮助预测将要发生的问题。如果io是渐变的，那么考虑是否在预期的范围内。SAN是共享存储，所以也需要考虑是否有可能是这个原因造成io上升，可以在数据库性能恶化钱给SAN管理员一个参考值。
本文大意：
     tempdb冲突时一个典型的冲突，大量的查询使用tempdb，当创建时，要分配page，元数据，处理FPS，GAM，SGAM等，为了优化，sql server对做了一个cache，更多信息可以看tempdb的白皮书。
     根据以下sql可以查看sql server中所有的堵塞：
     SELECT
    [owt]. [session_id],
    [owt]. [exec_context_id],
    [owt]. [wait_duration_ms],
    [owt]. [wait_type],
    [owt]. [blocking_session_id],
    [owt]. [resource_description],
    CASE [owt].[wait_type]
        WHEN N'CXPACKET' THEN
                RIGHT ( [owt].[resource_description] ,
                CHARINDEX ( N'=', REVERSE ( [owt].[resource_description] )) - 1)
            ELSE NULL
        END AS [Node ID],
        [es].[program_name] ,
        [est].text ,
        [er].[database_id] ,
        [eqp].[query_plan] ,
        [er].[cpu_time]
     FROM sys .dm_os_waiting_tasks [owt]
     INNER JOIN sys. dm_exec_sessions [es] ON
        [owt].[session_id] = [es].[session_id]
     INNER JOIN sys. dm_exec_requests [er] ON
        [es].[session_id] = [er].[session_id]
     OUTER APPLY sys. dm_exec_sql_text ( [er].[sql_handle] ) [est]
     OUTER APPLY sys. dm_exec_query_plan ( [er].[plan_handle] ) [eqp]
     WHERE
        [es].[is_user_process] = 1
     ORDER BY
        [owt].[session_id] ,
        [owt].[exec_context_id] ;
     GO
若大量出现FPS，GAM，SGAM堵塞，一般是2:1:1，2:1:2，2:1:3（fps间隔8088个页，GAM/SGAM间隔 7988*8页，页可以使用dbcc page 查看pagetype确定是否是GAM/SGAM/FPS）。
若出现冲突解决方法：1.减少临时表的使用，2.开启1118,3.创建多个数据文件。方法1比较简单，只要减少tempdb的使用就可以了，方法2：如果还出现冲突，启动1118，当表一上来就直接在专用区分配，而不是在混合区，这个trace是全局的，不单单是tempdb生效。方法3：也是现在用的比较多的方法，被认为是最佳实践，创建多个文件，文件个数=min(8，逻辑内核)+4*N
本文大意：
     一般导致锁堵塞的情况：1.无效的更新字段，2.update 没有相关index帮助，3.事务存在用户交互问题。
     通过对wait stats建立等待baseline，可以及时的发现问题。也可以使用sys.dm_os_waiting_tasks监控堵塞问题。
      A DMV A Day – Day 27 可以更具获取堵塞头，如果已经获取了堵塞链源头的spid，那么就可以根据以下几个方法获取到底是如何发送堵塞的：
     1.使用sp_blocker_pss08，2.使用SQLDiag，3.使用 Adam Machanic’s sp_WhoIsActive（但是我觉得，这3种我都觉得怎么样，更倾向于直接使用dmv获取堵塞链）
     解决方法：1.是否可以通过调整索引解决，2.是否考虑使用行版本
   
额外阅读：
     死锁的信息可以通过1222,1204,1205trace flag，写入到错误日志中。
     除了以上的方法，还可以使用SQL Trace，消息通知，WMI和扩展事件收集消息。
     Graphically Viewing Extended Events Deadlock Graphs 介绍了把deadlock graph重命名为.xdl然后可以在2012 ssms中打开，显示可视化界面。
     然后通过等待和已获得的资源的信息，分析死锁，调整死锁。可能的解决方案：1.创建索引。2.使用行版本
额外阅读：
本文大意：
     对于新手来说，往往会出现日志文件很大，但是数据文件相对来说很小。造成这个问题一般，除了程序bug之外，1.使用了完全恢复模式，但是没有日志备份，2.全备后被手动切换到完全模式，但是没有日志备份。
     SELECT [log_reuse_wait_desc] FROM sys.databases;
     使用这个sql查看到底是什么原因造成的如果是LOG_BACKUP那么就是日志没有备份的问题。
     每次日志增长都会带来一些问题：
     1.日志文件初始化，让写入操作暂停
     2.日志增长，日志块页会增长（应该指的是虚拟日志文件），会对性能造成影响（特别是olap负荷）
     3.日志大，恢复时间长
额外阅读：

The Accidental DBA的更多相关文章

  1. 【译】The Accidental DBA：Troubleshooting

    最近重新翻看The Accidental DBA,将Troubleshooting部分稍作整理,方便以后查阅.此篇是Part 3Part 1:The Accidental DBA:SQL Server ...

  2. 【译】The Accidental DBA：SQL Server Backup

    最近重新翻看The Accidental DBA,将SQL Server Backup部分稍作整理,方便以后查阅.此篇是Part 1Part 2:The Accidental DBA:Troubles ...

  3. 【译】The Accidental DBA：Troubleshooting Performance

    最近重新翻看The Accidental DBA,将Troubleshooting Performance部分稍作整理,方便以后查阅.此篇是Part 2Part 1:The Accidental DB ...

  4. brent ozar的sqlserver dba训练课程翻译——第二章：手动恢复数据库

    备份的唯一原因 备份的唯一原因是我们可以还原   当我第一次成为sqlserver数据库管理员,只要备份工作都能成功运行,我就会觉得一切都很好.我会查看sqlserver代理,保证那些作业都在运行,然 ...

  5. 2年SQL Server DBA调优方面总结

    原文:2年SQL Server DBA调优方面总结 2年SQL Server DBA调优方面总结 当2年dba 我觉得,有些东西需要和大家分享探讨,先书单. 书单 1.<深入解析SQL Serv ...

  6. [转]2年SQL Server DBA调优方面总结

      2年SQL Server DBA调优方面总结 当2年dba 我觉得,有些东西需要和大家分享探讨,先书单. 书单 1.<深入解析SQL Server 2008 系列> 这个就是mssql ...

  7. SQL调优日志--内存问题

    SQL调优日志--内存问题排查入门篇   概述 很多系统的性能问题,是由内存导致的.内存不够会导致页面频繁换入换出,IO队列高,进而影响数据库整体性能. 排查 内存对数据库性能非常重要.那么我当出现问 ...

  8. SQL调优日志--内存问题排查入门篇

    概述 很多系统的性能问题,是由内存导致的.内存不够会导致页面频繁换入换出,IO队列高,进而影响数据库整体性能. 排查 内存对数据库性能非常重要.那么我当出现问题的时候,我们怎么排查性能问题呢? 存在问 ...

  9. Github上的1000多本免费电子书重磅来袭！

    Github上的1000多本免费电子书重磅来袭!   以前 StackOverFlow 也给出了一个免费电子书列表,现在在Github上可以看到时刻保持更新的列表了. 瞥一眼下面的书籍分类目录,你就能 ...

随机推荐

  1. 通用easyui查询页面组件

    easyui查询页面组件使用指南 本组件开发需求:信息系统的查询页面基本是包括:搜索区域,列表显示区域,按钮条. 1.录入一个查询语句(如:select * from Strudents),录入列表显 ...

  2. 孙鑫MFC学习笔记10：画图/贴图

    1.SetPixel在指定点设置像素 2.虚线.点线宽度必须为1 3.CColorDialog创建颜色对话框 4.需要设置CC_RGBINIT标志才能设置颜色对话框的默认颜色 5.CC_FULLOPE ...

  3. SSH实例(6)

    在WebContent文件夹下新建query.jsp和save.jsp文件. query.jsp: <%@ page language="java" import=" ...

  4. MAC安裝CocoaPods

    前言,鑒於很多人都比較趕時間,有人是為了去應付工作,有人是為了去找妹子,總之,不管你懂不懂,如果你只是想安裝一下,那麼你只需要按照濤叔下面畫黃色的命令複製粘貼到終端順序執行就好了. 一.安裝 1.Ru ...

  5. Java的对象初始化过程

    成员变量(字段)初始化顺序 在一个类里初始化的顺序是由成员变量在类里面的定义的顺序来决定的.即使成员变量大量散布于类的各个方法定义的中间,那些成员变量仍会在调用任何方法之前得以初始化,甚至在构造函数调 ...

  6. GJM ： 基于Actor模式的c#网络游戏服务器的实现和Unity游戏客户端的连接 [转载]

    感谢您的阅读.喜欢的.有用的就请大哥大嫂们高抬贵手"推荐一下"吧!你的精神支持是博主强大的写作动力以及转载收藏动力.欢迎转载! 版权声明:本文原创发表于 [请点击连接前往] ,未经 ...

  7. jQuery Label Better – 友好的表单输入框提示插件

    jQuery Label Better 帮助你标记您的表单输入域,带有美丽的动画效果而且不占用空间.这个插件的独特之处在于所有你需要做的就是添加一个占位符文本,只有当用户需要它的时候才显示标签. 您可 ...

  8. Draggabilly – 轻松实现拖放功能（Drag & Drop）

    Draggabilly 是一个很小的 JavaScript 库,专注于拖放功能.只需要简单的设置参数就可以在你的网站用添加拖放功能.兼容 IE8+ 浏览器,支持多点触摸.可以灵活绑定事件,支持 Req ...

  9. 给你推荐10款优秀的 HTML5 动画工具

    HTML5 在过去三年快速增长,已经成为 Web 开发人员最喜欢的编程语言之一.强大的编程语言拥有开发更好的网页应用的能力. HTML5 中引入的新技术都非常好,像 Chrome.Firefox.Sa ...

  10. Matter.js – 你不能错过的 2D 物理引擎

    Matter.js 是一个 JavaScript 2D 刚体物理引擎的网页.Matter.Engine 模块包含用于创建和操作引擎的方法.这个引擎是一个管理更新和渲染世界的模拟控制器. Matter. ...