Questions tagged «san»

通常，我们每周的完整备份大约需要35分钟，而每天的差异备份大约需要5分钟。自星期二以来，每天花了将近4个小时才能完成工作，远远超出了要求。巧合的是，这在我们有了新的SAN /磁盘配置后就开始发生。 请注意，该服务器正在生产中运行，我们没有任何总体问题，它运行平稳-除了IO问题主要体现在备份性能方面。 在备份期间查看dm_exec_requests时，备份一直在等待ASYNC_IO_COMPLETION。啊哈，所以我们有磁盘争用！ 但是，MDF（日志存储在本地磁盘上）和备份驱动器都没有任何活动（IOPS〜= 0-我们有足够的内存）。磁盘队列长度也约为0。CPU徘徊在2-3％左右，也没有问题。 SAN是Dell MD3220i，该LUN由6x10k SAS驱动器组成。服务器通过两条物理路径连接到SAN，每条物理路径通过一个单独的交换机，并具有到SAN的冗余连接-共有4条路径，其中两条在任何时间都处于活动状态。我可以通过任务管理器验证两个连接均处于活动状态-完美地平均分配负载。两种连接都运行1G全双工。 我们曾经使用巨型帧，但是我已禁用它们以排除此处的任何问题-无需更改。我们有另一台服务器（相同的OS + config，2008 R2）已连接到其他LUN，并且没有任何问题。但是，它不运行SQL Server，而只是在它们之上共享CIFS。但是，它的LUN首选路径之一与麻烦的LUN在同一SAN控制器上-因此我也排除了这一点。 尽管存在以下问题，但运行几个SQLIO测试（10G测试文件）似乎表明IO很不错： sqlio -kR -t8 -o8 -s30 -frandom -b8 -BN -LS -Fparam.txt IOs/sec: 3582.20 MBs/sec: 27.98 Min_Latency(ms): 0 Avg_Latency(ms): 3 Max_Latency(ms): 98 histogram: ms: 0 1 2 3 4 5 6 7 8 9 10 11 12 …

31 sql-server-2008-r2  backup  network  san 

我们的SQL服务器位于SAN上。它包含数十个OLTP数据库，其中一些数据库包含100万条以上的记录。 我们每周运行Ola Hallengren的索引维护脚本，并且每次运行几个小时。根据碎片阈值，脚本将重新组织索引或为索引重新编制索引。我们已经观察到，在重新索引期间，日志文件会变得很大，这会导致日志传送过程中带宽的过度消耗。 然后是Brent Ozar的一篇文章，他说不再停止担心SQL索引： 您的硬盘驱动器与其他同时共享驱动器请求的服务器共享，因此驱动器将始终在各处跳跃以获取数据。整理索引碎片只是毫无意义的繁忙工作。 谷歌搜索这个问题会导致意见分歧，其中大多数观点似乎太简短或太弱。我们的暂定计划是调整维护脚本中的碎片阈值，以使其重新组织的频率比重新编制索引的频率高得多。 最终裁决是什么？考虑到每周运行维护工作所带来的负担，是否值得对SAN上的SQL索引进行碎片整理？

16 sql-server  sql-server-2008-r2  index  database-recommendation  san 

我有一个连接到SAN的SQL Server。我们的新存储供应商建议所有LUN跨越整个磁盘阵列，即RAID5。我通常会向SAN管理员请求3个单独的LUN（数据，日志和TempDB），但是鉴于新供应商的建议，创建单独的LUN有什么意义吗？还是如果所有内容都在一个LUN中，因为它仍然可以覆盖所有磁盘，我是否会看到相同的性能？ 很棒的文章在这里，但是并不能完全解决我的确切情况：http : //www.brentozar.com/archive/2008/08/sql-server-on-a-san-dedicated-or-shared-drives/

8 sql-server  performance  storage  san 

我们有一个非常活跃的数据库服务器，上面运行着各种应用程序。最繁忙的两个是Laserfiche数据库，该数据库全天进行文档扫描和工作流处理（平均大约每秒2800个批处理请求），还有一个黑莓服务器应用程序可路由电子邮件。还有大约25个其他小型应用程序数据库。 我们是政府机构，因此仅获得单个DB服务器许可证的预算。 最近，我们获得了SAN，以解决磁盘争用问题。 因此，当前，我们在其自己的磁盘（raid 1镜像对）上运行了TempDB，并且已将事务日志和数据文件移至SAN。事务日志放在一个逻辑位置，数据文件放在另一个逻辑位置。从物理上讲，它是相同的阵列，但它是由RAID 1 + 0配置中的总共14个主轴（磁盘）组成的阵列。 一个非常强大的SAN-并且运行情况要好得多。队列长度减半。 就在今天，我们还获得了另一种选择。如果我们当前在文件服务器上需要它，我们也可以有一个4磁盘阵列。我知道通常建议在两个单独的阵列上使用MDF和LDF，但是在我们这种情况下，唯一的方法是将数据或事务日志从SAN移到配置为Raid 5的4磁盘阵列上。请记住，它们是当前位于单独的逻辑卷中，但共享相同的物理阵列。 从臀部射击我觉得将MDF和LDF组合在一起放在14主轴突袭1 + 0阵列上可能和将它们与4主轴突袭5阵列中的一个分开一样好。但是，我不会在这里问我是否是磁盘逻辑专家。两种选择都使用基本相同的15k SAS磁盘-即每个主轴基本相同。 因此，本质上，问题是。通过将数据或日志移动到它自己的4轴raid 5阵列上，在配置为raid 1 + 0的单个14主轴阵列上具有MDF / LDF是否会得到任何显着的改善（或根本没有改善）？ 有什么想法吗？ 更新信息： 我还将注意到，当前“日志”卷上的平均队列长度始终保持在0.55左右。数据量的平均队列长度很少超过0.01（通常为0.00） sys.dm_io_virtual_file_stats查询结果： <table> <tr> <td>database id</td> <td>Volume</td> <td>io_stall_read_ms</td> <td>num_of_reads</td> <td>avg_read_stall_ms</td> <td>io_stall_write_ms</td> <td>num_of_writes</td> <td>avg_write_stall_ms</td> <td>io_stalls</td> <td>total_io</td> <td>avg_io_stall_ms</td> </tr> <tr> <td>25</td> <td>h</td> <td>175086</td> <td>1411</td> <td>124</td> <td>69</td> <td>41</td> <td>1.6</td> …

8 sql-server-2008  disk-structures  san