标签: disk-structures

我们的企业标准之一是为用户表/索引使用单独的文件组/文件。这被设置为默认值，因此无需限定 CREATE TABLE 语句。

所以它看起来像这样

• fileid 1 = 系统表，MDF
• 文件 ID 2 = t-log = LDF
• fileid 3 = 用户资料 = NDF

这里的任何人都可以帮助我理解为什么强制执行此操作的原始理由吗？

我会坦白说我认为这是巫毒教。上午我错了......？

编辑：我知道如何使用文件组来分离索引/分区/存档，以及如何逐步恢复。这个问题是关于在同一卷上为系统表使用单独的文件组。

我将从头开始重建一台 IBM 3400 服务器。此服务器专用于在 Windows 2008 R2 上运行的 SQL Server 2008 实例。

我将进行新的 RAID 配置。我在机器内部有 6 个 SCSI 73 GB 驱动器和一个 IBM ServerRAID 8K 控制器。什么是设置 RAID 级别的好方法？我的控制器上应该有两个、三个还是一个字段？

我正在考虑制定以下解决方案之一：

1. 使用所有磁盘并制作 RAID 10 池。
2. 将 4 个磁盘用于 RAID 1e 池并使用它来存储数据库数据和操作系统，并使用 RAID 0 池中的其他 2 个磁盘并使用它来存储数据库日志。
3. 其他一些组合。

条带单元尺寸越大越好吗？

该服务器将成为复制数据库的订阅者。它的主要任务是报告和数据检索，只有复制代理进行写入。数据库的大小约为 90 GB。

我的问题针对 Postgres，但来自任何数据库背景的答案可能就足够了。

我的假设是否正确：

• 磁盘有固定的块大小吗？
• RAID 控制器可以有不同的块大小？是否将一个 RAID 块拆分为多个实际磁盘块？
• 文件系统也有一个独立的块大小，它再次被拆分为 RAID 块大小？
• Postgres 使用固定的 8k 块。这里是如何映射到文件系统块大小的？Postgres 8k 块是否由文件系统批量处理？

设置系统时最好将所有块都设置为 8k？还是设置不重要？我还想知道某些“错误”的块大小设置是否会在崩溃时危及数据完整性？也许如果必须将 Postgres 8k 块拆分为多个磁盘块？

或者没有任何东西一起批处理，因此我会因定义的块大小之间的每一次不匹配而丢失磁盘空间？

我们有一个非常活跃的数据库服务器，上面运行着不拘一格的应用程序集合。其中最繁忙的两个是全天进行文档扫描和工作流处理的 Laserfiche 数据库（平均约 2800 批请求/秒）和路由电子邮件的黑莓服务器应用程序。还有大约 25 个其他的小型应用程序数据库。

我们是政府机构，所以我们只获得了单个数据库服务器许可证的预算。

最近，我们获得了一个 SAN 来解决磁盘争用问题。

因此，目前我们在其自己的磁盘（raid 1 镜像对）上运行 TempDB，并且我们已将事务日志和数据文件移至 SAN。事务日志放在一个逻辑位置，数据文件放在另一个位置。从物理上讲，它是同一个阵列，但它是一个由 14 个轴（磁盘）组成的阵列，采用 RAID 1+0 配置。

一个非常强大的 SAN - 事情运行得更好。队列长度减半。

就在今天，我们还获得了另一种选择。如果我们当前在文件服务器上需要它，我们也可以有一个 4 磁盘阵列。我知道通常建议在两个单独的阵列上使用 MDF 和 LDF，但在我们的情况下，唯一的方法是将数据或事务日志从 SAN 移到配置为 Raid 5 的 4 磁盘阵列上。请记住它们是当前位于不同的逻辑卷中，但共享相同的物理阵列。

从臀部拍摄我觉得将 MDF 和 LDF 放在 14 轴 raid 1+0 阵列上可能与将它们与 4 轴 raid 5 阵列上的一个分开一样好。但是，我不会在这里问我是否是磁盘逻辑专家。两个选项都使用基本相同的 15k SAS 磁盘 - 即每个主轴基本上是相同的。

所以，本质上问题是。通过将数据或日志移动到它自己的 4 轴 raid 5 阵列，在配置为 RAID 1+0 的单个 14 轴阵列上的 MDF/LDF 是否会得到任何显着的改善（或根本没有）？

想法？

更新信息：

我还将注意到，当前日志卷上的平均队列长度始终保持在 0.55 左右。Data volume 上的平均队列长度很少超过 0.01（通常为 0.00） …

假设恒定内存 (32gb) 和 CPU (4)，2 x 磁盘阵列，我有以下磁盘

• 2 x 150 (10k)
• 6 x 150 (15k)

它们都是本地磁盘。

我的要求

• 我的数据库是 350gb 并设置为默认的 10% 增长
• 我的操作系统和 SQL Server 是 Server 2k8R2（C：驱动器操作系统 + 页面 + 应用程序 = 55Gb）
• 日志要求约为 70gb，并设置为默认 10% 的增长，并定期被截断
• 我的 TempDb 目前约为 12GB，并设置为默认 10% 的增长

我的问题是我试图了解最好将 TempDB 和操作系统以及日志放在哪里。我的经验仅限于这两个的最佳配置

这不是一个在线交易系统。它有大量数据写入（新数据 + 索引重建/重组），然后大量数据读取（我估计约为 50/50）处理了大约 13 个小时，然后就安静了。

我的理解是，与日志相比，在正常处理期间大量使用 TEMPDB。

我的想法如下

• 2 x 150g (15k) Raid 1 = 150g for OS + TempDB
• 2 x 150g (10k) Raid 1 = 150g for LOG（注意这里的磁盘较慢）
• 4 x …

这篇文章的SQL Server的tempdb最佳实践提高性能建议我应该拆分tempdb成若干文件等于内核的数量。因此，对于 4 个内核，您将获得 4 个文件。

通过拥有更多数量的文件，您可以增加 SQL Server 可以随时推送到磁盘的物理 I/O 操作的数量。SQL Server 可以下推到磁盘级别的 I/O 越多，数据库运行的速度就越快。使用标准数据库，SQL Server 可以将其需要的大量数据缓存到内存中。由于 tempdb 的高写入特性，数据需要先写入磁盘，然后才能缓存到内存中。

虽然理论上听起来不错，但它真的像一般优化一样好吗？它是否可能仅适用于 IO 非常高的特定系统？

请帮助解决以下情况：

存储消息历史记录的 API 有两种，它们是Zopim和Chat2Desc（导入到 Postman 中）。而这两个却可以接着其他的出现。

我的数据库与users表：

Table users
id , email, phone, ...

在Zopim 中，用户通过电子邮件进行识别，在Chat2Desc 中通过电话进行识别。对我来说，这两个领域很重要，无论聊天是什么，有多少不是。

也就是说，如果我在消息中收到电子邮件或用户的电话，我会向我的数据库 ( table users)发出请求以识别我的用户。

而且原则上，即使聊天室的结构也不重要。我会以某种方式选择它们。以下是如何正确保存它们的方法，以至于我为每个人提供了一个结构。

这就是我想出的（我不喜欢的东西，尤其是chat_clients桌子）：

解释：

表chats（聊天数据）：

1. client_id -表示的IDchat_clients表
2. duration - 聊天时长（120 秒）
3. system_type- 存储聊天的名称（Zopim、Chat2Desc等）
4. created_at - 创立日期

表格 chat_clients（聊天中的用户信息）：

1. is_agent - 0 | 1: 1 => 我的用户，0 => 不是我的
2. user_id - 是用户 ID。包含用户表中的 id …

通常 RDBMS（我是 MySQL 用户）性能的瓶颈是磁盘访问。与传统的主轴驱动器相比，SSD 提供了出色的性能。

问题：是否可以通过连接多个空间减少的驱动器来提高性能，因为这样可以有更多的磁头可用于读取数据？

喜欢用 4 个 500GB 7.2k RPM 驱动器替换 2TB 7.2k RPM 驱动器？

一个客户给了我他想要在我的项目中可视化的数据 - 但我不知道它是什么数据库格式。他也很不清楚......
我可以访问表结构，但不知道如何阅读它在。它绝对不是一个平面文件。

每个数据集有几个文件：

• file.dat（迄今为止最大的）
• file.id（小）
• file.ind（*.dat 大小的一半）

*.dat 文件中的前几个字节是03 6E 02 14 14 15 19 00（以防使用幻数）。

这些扩展是否敲响了警钟？有什么软件可以确定格式吗？

我们正在尝试评估通过将现有应用程序 .mdf 文件切换到 RAID10 LUN 与他们目前使用的现有 RAID5 LUN 可以获得的潜在性能改进。事务日志已经存在于 RAID10 LUN 上。

所以问题是，如果我们将数据文件移动到 RAID10，最终用户会在 GUI 中看到性能改进吗？或者当检查点发生并且更改被写入数据文件时写入数据文件会更快，但在最终用户级别不会看到任何改进？