Questions tagged «disk-structures»

我将从头开始重建一台IBM 3400服务器。该服务器专用于在Windows 2008 R2上运行的SQL Server 2008实例。 我将进行新的RAID配置。我的机器内部有6个SCSI 73 GB驱动器和一个IBM ServerRAID 8K控制器。设置RAID级别的好方法是什么？我的控制器上应该有两个，三个还是一个字段？ 我正在考虑提出以下解决方案之一： 使用所有磁盘并创建RAID 10池。 将4个磁盘用于RAID 1e池，并将其用于存储数据库数据和OS，将其他2个磁盘用于RAID 0池，并将其用于存储数据库日志。 其他组合。 较大的条带单元尺寸更好吗？ 该服务器将成为复制数据库的订阅者。它的主要任务是报告和数据检索，仅复制代理进行写操作。数据库的大小约为90 GB。

11 sql-server  performance  best-practices  disk-structures 

我的问题针对Postgres，但从任何数据库背景来看，答案可能就足够好。 我的假设正确吗： 磁盘具有固定的块大小？ RAID控制器可以具有不同的块大小吗？是否将一个RAID块拆分为多个实际磁盘块？ 该文件系统还具有独立的块大小，该块大小又被拆分为RAID块大小吗？ Postgres适用于固定的8k块。到文件系统块大小的映射在这里如何发生？文件系统是否将Postgres 8k块批处理在一起？ 设置系统时，最好将所有块都设置为8k？还是设置不是很重要？我还想知道在崩溃时某些“错误”的块大小设置是否会危害数据完整性？也许Postgres 8k块必须拆分为多个磁盘块？ 还是什么都没有批处理在一起，因此我在定义的块大小之间的每一个不匹配都会丢失磁盘空间？

11 disk-space  disk-structures 

我们的公司标准之一是为用户表/索引提供单独的文件组/文件。这被设置为默认值，因此不需要限定CREATE TABLE语句。 所以看起来像这样 fileid 1 =系统表，MDF fileid 2 = t-log = LDF fileid 3 =用户资料= NDF 在座的任何人都可以帮助我理解为什么要这样做的原始理由吗？ 我会干净的说我是伏都教徒。上午我错了......？ 编辑：我知道如何使用文件组来分离索引/分区/档案，以及如何恢复零碎的文件。这个问题是关于在同一卷上仅对系统表使用单独的文件组。

11 sql-server  filegroups  disk-structures 

《SQL Server tempdb最佳实践提高性能》一文建议，我应该将tempdb文件分割成与内核数相等的数量。因此，对于4个内核，您将获得4个文件。 通过拥有更多的文件，可以增加SQL Server一次可以推送到磁盘的物理I / O操作的数量。SQL Server可以将其下推到磁盘级别的I / O越多，数据库将运行得越快。使用标准数据库，SQL Server可以将所需的大量数据缓存到内存中。由于tempdb具有高写入特性，因此需要先将数据写入磁盘，然后才能将其缓存回内存。 尽管从理论上讲听起来不错，但总体上来说它真的那么好吗？它仅适用于IO非常高的特定系统吗？

8 sql-server  sql-server-2008-r2  storage  tempdb  disk-structures 

假设恒定内存（32gb）和CPU（4），2个磁盘阵列，我有以下磁盘 2 x 150（10k） 6 x 150（15k） 它们都是本地磁盘。 我的要求 我的数据库是350gb，并设置为默认10％增长 我的OS和SQL Server是Server 2k8R2（C：驱动器OS +页面+应用程序= 55Gb） 日志要求约为70gb，默认设置为10％的增长，并且通常会被截断 我的TempDb当前约为12gb，默认设置为10％的增长 我的问题是我试图了解将TempDB和OS以及Log放在哪里的最佳方式。我的经验仅限于这两个的最佳配置 这不是一个在线交易系统。它具有大量的数据写入（新数据+索引重建/重组），然后具有大量的数据读取（我估计约为50/50），处理大约13个小时，然后安静下来。 我的理解是，与日志相比，TEMPDB在正常处理期间被大量使用。 我的想法是以下 适用于OS + TempDB的2 x 150g（15k）突袭1 = 150g 2 x 150g（10k）RAID 1 = 150g for LOG（请注意此处的磁盘较慢） 4 x 150g（15k）突袭5 = 150g用于数据 听起来像个好主意吗？然后，如果需要，我可以交换Log + TempDB。 我是否违反基本原则，例如由于分页问题而从不将TempDB放在OS磁盘上，或者也许从不将日志放在比数据慢的磁盘上？ 编辑： 我们的系统上也有一个SSAS，最终用户只能访问多维数据集。上面的50％是根据处理SSAS数据库所需的时间得出的。

8 sql-server-2008-r2  business-intelligence  disk-structures 

我们有一个非常活跃的数据库服务器，上面运行着各种应用程序。最繁忙的两个是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