标签: storage

很多时候，我们都听到了同样的事情。关于在哪里放置 OLAP/OLTP 数据库、在哪里放置tempdb、在哪里放置事务日志等的建议。

但是假设您处于存储的物理定义对您来说是个谜的环境中。换句话说，确保您可以看到逻辑驱动器，并且您可以给系统管理员打电话并要求提供更多空间，但您永远不知道什么是不同的物理驱动器（假设在幕后有 SAN 或 NAS）。如果您实际上不知道这一点，那么您如何通过将受到重创的tempdb数据库放在不同的物理驱动器上来遵循最佳实践？

这方面的最佳做法是什么？

首先，让我先说我确实注意到有多个类似的问题，但它们都不是我想要问的，而且没有一个有明确的答案。

其次，让我确认我确实理解，即使在 SAN/虚拟化环境中，也建议对日志/数据使用不同的 LUN/spindle。

现在的问题是：

如果只有一个 LUN 分配给 SQL Server 虚拟机，以下配置之间是否存在性能（不是管理、安全或任何其他）差异：

1. 一个虚拟磁盘文件（vhd、vmdk 等），一个虚拟控制器，虚拟操作系统中的一个逻辑分区，以及该分区中的 tempdb/data/log
2. 一个虚拟磁盘文件，一个虚拟控制器，但多个逻辑分区/驱动器号用于 tempdb/data/log
3. 多个虚拟磁盘文件 一个单独的虚拟控制器，为 tempdb/data/log提供单独的分区

到目前为止，我听到了以下答案：

1. 有没有或可忽略不计的性能差异，至于到底，它与同一个IO能力仍然只是同一主轴
2. 有是在性能差一些场景因为虚拟控制器必须在单独的（虚拟）IO队列和调度访客OS

如果重要的话，让我们假设工作负载是非常多的线程和非常小的请求（如此深的小队列）。

我想一劳永逸地解决这个问题，所以我想请教一个 LUN的性能问题，不要提出优化布局的建议。

有很多关于 sql server 应该使用多大的存储块大小的文章，例如SQL Server 的磁盘分区对齐最佳实践。正确的块大小应该可以提高 sql server 数据库的性能。我正在寻找建议和方法来确定适合数据库的存储块大小。是否有关于如何确定合适的块大小的指南？

在 VM 上配置新的 SQL Server 时，最好将数据库、TempDB、日志和备份放在单独的逻辑驱动器上，即使底层存储相同？我知道这在物理服务器上是一个很好的做法；这种分离实际上帮助我们减少了并发 I/O 带来的痛苦。

我试图了解拥有 3 个驱动器而不是 5 个驱动器是否有意义。有人可以提供他们对这个想法的看法/建议吗？

过去几周，我们一直在努力找出导致这些 I/O 问题和检查点变慢的可能原因的根本原因。

乍一看，这显然是 I/O 子系统错误，应该归咎于 SAN 管理员。但最近我们将 SAN 更改为使用全闪存，但截至今天，错误仍然弹出，我不知道为什么，因为我运行的每个指标，无论是等待统计数据还是任何其他指标，都是为了检查 SQL 服务器是否可行罪魁祸首似乎恢复正常。

它并没有真正加起来。也很可能是其他东西正在咀嚼磁盘并且 SQL Server 在这里成为受害者......但我无法找出什么？

数据库位于可用性组中，当这些事件发生时，我们确实会看到角色更改和翻转以及超时发生。

任何帮助解决这个问题将不胜感激。如果需要任何进一步的细节，请告诉我。

错误消息。以下

SQL Server 在数据库 [ABC] (7) 中的文件 [E:\MSSQL\DATA\ABC.mdf] 上遇到了 14212 次 I/O 请求需要超过 15 秒才能完成。操作系统文件句柄是 0x0000000000000D64。最新的long I/O的偏移量为：0x0000641262c000

SQL Server 在数据库 [XYZ] (7) 中的文件 [E:\MSSQL\DATA\XYZ.mdf] 上遇到了 5347 次 I/O 请求需要超过 15 秒才能完成。操作系统文件句柄是 0x0000000000000D64。最新的long I/O的偏移量为：0x0000506c060000

FlushCache：在 925084 毫秒内清理了 111476 个 buf，其中 62224 次写入（避免了 19 个新的脏 buf），用于 db 7:0 平均吞吐量：0.94 MB/秒，I/O 饱和度：55144，上下文切换 98407 最后一个未完成的目标：101241077 次写入FlushCache：在 248687 毫秒内清理了 5616 个 buf，其中 3126 个写入（避免了 3626 个新的脏 buf），用于 …

我们正在为一家希望能够将旅客信息输入在线数据库的旅游公司开发旅行/旅游应用程序。

在数据库中存储护照号码是否有任何安全最佳实践？应该加密吗？

我正在使用 sqlalchemy 将对象存储在数据库中。我正在创建的对象类型在运行时之前是未知的。我可以存储像字符串一样简单的东西。我可以存储一个jpg。我可能会创建自己的文件格式并存储它。重点是它很灵活。

我设想的表格至少包含两列。一个描述文件类型（.jpg、.txt、.py 等），另一个是包含文件数据的 blob。我想知道的是我在创建表时是否需要定义 blob 大小。是否可以让mysql动态设置blob的大小？这将很好地简化我的设计。

我知道还有其他方法可以做到这一点，但我有充分的理由这样做。如果它变成死胡同，我不介意沿着这条路走下去，然后再翻倍。

TLDR；如果我将电话号码存储在 MySQL（或任何具有等效约束的数据库）中，正确的格式是将 E.164 值放入 VARCHAR(32) 字段吗？

一直在阅读国际电话号码的格式/存储。过去由于各种原因，建议将其存储为字符串，因为此数据是标识符而不是实际数字（以及诸如前导 0 之类的问题）。我知道我不应该尝试通过正则表达式解析/验证电话号码，并且通常建议使用 Google 开发的 libphonenumber 来处理此问题并生成 E.164 格式的值。

我假设可以肯定地说 E.164 是当今最适合电话号码的存储格式。由于前导 + 似乎不需要并且前导 0 不会以这种格式出现？我已经看到 BIGINT(15) 建议将其存储在 MySQL 数据库中。这将需要一个额外的字段（字符串？）来支持带有分机号码的电话号码。它没有在维基百科文章中说明，但我在博客文章中看到很多提到 E.164 格式通过附加“;ext=12345”来支持扩展，那么存储到 VARCHAR(32) 字段是否更可取？“+19995556789;ext=12345”，这种格式的最大长度应该是32，那么32的长度合适吗？<+><;ext=>

编辑：我不确定扩展值到底应该是什么，根据这个它是 11，但是链接到的文章已经修改并被 Apple 存档，那里没有关于扩展长度的明确信息。最好只是达到更高的限制，例如 VARCHAR(50)，还是使用 BIGINT(15) 和一个附加字段用于可空的扩展？

我有一个在 VM 上运行的数据库，该数据库在大负载期间受到重创，特别是我可以看到 WRITELOG 正在等待。我最初的想法是将文件拆分到它们自己的驱动器上，但后端存储与其他数据库文件所在的位置相同。

基本上，它是作为集群共享卷呈现给整个虚拟机主机的 SAN。

这样做会有性能优势吗？我大脑深处的一些记忆告诉我一些关于 IO 流数量可能会更好的信息？

为了更新这个，我现在已经分离出文件并正确调整事务日志的大小。我一直在收集信息，sys.dm_io_virtual_file_stats并且可以看到我现在拥有极高的 readIOstalls，但具有 13ms 的低延迟。我还收集了一些内存信息，PLE 平均数以千计，这是一个 32GB 的系统，我预计除了在 30 分钟内它下降到 30 之后再次急剧上升之外，此时懒惰写入/秒增加在减少到 0 之前也到 50。这段时间可能是我看到的大量读取停顿的原因吗？我会期望看到如此高的读取停顿和高延迟吗？

我们在 S3 层上运行 V12 Azure 数据库实例。数据库上仍有大约 100GB 的可用空间。当使用在不同的非 azure SQL 服务器上运行的 SSIS 加载 85MB XML 文件，并将其直接插入到 azure 数据库中时，插入会在目标数据库上崩溃，并出现以下错误。

数据库“tempdb”已达到其大小配额。对数据进行分区或删除、删除索引或查阅文档以获取可能的解决方案。

tempdb 是否有任何限制或者知道为什么这可能会崩溃？85MB 的文件不可能填满数据库的剩余空间。似乎tempdb隐藏起来了，我如何监控它的使用情况？