小编Zer*_*ity的帖子

我有一个带有聚集索引和 2 个非聚集索引的表。现在，在我看来，我正在从我的表中选择所有内容

create view dbo.MyView
as 
Select * from MyTable

现在，当我在查询中使用这个视图时，我可以假设这个视图将利用在表上创建的索引。（即与Select * from MyTable 的工作方式相同）？或者我应该使用索引视图

补充问题

如果视图可以利用表索引，那么使用SELECT * FROM MyView Where SomeColumn = @someValue可能会严重影响性能（如果视图有大量数据，那么它在没有索引时会表现得像堆）。如何克服这个问题？除了使用 NOEXPAND（因为我使用的是企业版）

在我的开发环境中，我正在处理查询。为此，我需要重置 SQL Server 内存、计划等，这可以确保我的查询是所有值重置的服务器上唯一的压力/工作过程

我正在做的事情很少

• 射击检查点
• DBCC 删除缓冲区；
• DBCC FREEPROCCACHE;
• DBCC FLUSHPROCINDB
• DBCC 自由会话缓存
• DBCC SQLPERF("sys.dm_os_wait_stats",CLEAR);

我做得对吗？或者我需要更多的东西来清除或查看新的统计数据？

我有一个 SSAS Cube，有 35 个维度和 10 个度量。

• 一些尺寸的尺寸相当大。
• 在几乎所有维度中，数据都会被更新和插入。
• 度量具有大量数据。

当我从SSMS运行（通过右键单击 SSAS 数据库）在数据库上“进程已满”时，大约需要 1 小时 30 分钟。

当我通过 XMLA 脚本从 SQL 代理作业处理多维数据集（进程已满）时，大约需要 1 小时 20 分钟。

当我通过 SSMS 分别处理维度和度量（过程完整）时，需要 1 小时 50 分钟。

但是，当我从 SSIS（通过 XMLA 的 DML 任务）处理维度和度量时，它需要 5 个多小时。[内存消耗几乎达到 100%]

所以我的问题是：

1. 来自 SSIS 的处理维度和度量会花费那么多吗？
2. 我应该选择什么样的处理来进行快速立方体处理。我正在做完整的过程。
3. 当我从前两个选项处理多维数据集时，大部分时间多维数据集都会因为“未找到属性键”而失败，但是当我分别处理维度和测量时，它运行良好。不处理完整的多维数据集确保正确处理维度和度量？

我在生产中有一个数据库，它不断地填充日志文件，它是一个数据仓库，并且有许多作业/查询正在运行。下面是我得到的错误

Msg 9002, Level 17, State 4, Line 7
The transaction log for database  is full due to 'ACTIVE_TRANSACTION'. 

现在这是有道理的，我明白 SQL 无法执行操作，因为它的日志文件已满。我有两个日志文件

• 启用无限制增长和自动增长的 D 盘 [D 盘大小 180 GB]
• E盘静态大小[E盘120GB，日志文件大小：20GB]

我对这个问题做了一些研究，并找到了可能的解决方案：来源

• 备份日志。
• 释放磁盘空间，以便日志可以自动增长。
• 将日志文件移动到具有足够空间的磁盘驱动器。
• 增加日志文件的大小。
• 在不同的磁盘上添加日志文件。
• 完成或终止长时间运行的事务。

现在，假设我的空间有限（即 180 GB + 20 GB），我认为这对于 SIMPLE RECOVERY MODE 中的数据库来说已经足够了。我怎么可能发现这个问题并在它发生之前进行纠正？

复制：

我试图通过使用以下设置创建新的示例数据库来复制此场景

和下面的查询以获取百万行并将它们插入表中

SET NOCOUNT ON;
DECLARE @SET_SIZE INT = 500000000;

CREATE TABLE dbo.Test500Million (N INT  PRIMARY KEY CLUSTERED NOT NULL);

;WITH T(N) AS (SELECT N FROM (VALUES (NULL),(NULL),(NULL),(NULL),(NULL),(NULL),(NULL),(NULL),(NULL),(NULL)) AS …

我面临着与不断增长的日志文件相关的问题，因此我收到了错误。当我检查 SQL 日志时，我发现以下消息（错误日志中几乎 90% 都填充了这些消息）

SQL Server 遇到 1 次 I/O 请求需要超过 15 秒才能在文件中完成

几乎所有数据库都会发生这种情况，包括 temdb [.mdf 和 .ndf 文件] 以及我也收到以下消息

平均吞吐量：0.34 MB/秒 I/O 饱和度：196 次上下文切换 1210

最后一个未完成的目标：530 avgWriteLatency 2

FlushCache：在 142370 毫秒内清理了 6233 个 buf，384 次写入（避免了 99 个新的脏 buf），用于 db 6:0

我的 temdb 大小和其他数据库和日志文件大小足够大。

历史：

• 以前的开发人员已经多次进行数据库收缩和日志收缩。
• 所有数据库都处于压缩模式。

我的行动计划：

• 我发现日志文件的初始大小很小，增长了 10%。我计划将初始大小增加 512 MB，增加 512 MB 以获得合理数量的 VLF。

  问题 1：虽然我会在非高峰时段进行工作，但进行这些更改是否有可能损坏我的数据库或日志文件？

  问题二：数据库压缩方式会影响IO操作吗？如果是，我该如何解决？

• 我计划从防病毒检查中删除所有数据库和日志文件。

• 我计划将目标恢复时间更改为 < 1 分钟的数据库（特别是 tempdb 和我的数据库）

  问题 3：这会影响我的数据库吗？我的意思是刷新缓冲区和写入磁盘应该可以提高性能，对吗？

  问题 4：我有 3 个 tempdb …

我正在设计一个用于在线购物的网站，我有一个与此相关的问题。如您所知，购物网站可能有不同统计/规格的不同产品。设计数据库的最佳方法是什么？以下是我想到的想法

1. 为不同的产品类型创建不同的表。前任。电话、电视、电子游戏、手表、衣服、电脑等。

忧虑：

但是让我们说 a 来显示移动规范 [就像这样例子] 我需要大约 40-50 列来存储移动规范。假设明天一个新功能出现在移动设备上，那么我可能不得不再添加一列，该列将保存该特定模型的值，而对于其他所有移动设备，该列将为 NULL。

2：有主要产品表，例如。电子、服装及配饰、健康等。每张表都有单独的规格表。前任。Electronics 表将包含平板电脑、手机、固定线路等的主要详细信息，Electronics_Spec 将包含具有相关规范的列。

忧虑：

产品之间有许多与其他产品不匹配的特性。前任。固定电话将有关于电线长度的规范，而平板电脑则没有。

一般问题：

有些产品的规格相当少。例如：床、玩具、鞋类。

有没有其他更好的方法来设计一个数据库来保存与多个产品相关的大量规范？

我的意图是将数据库空间保存到最好。我真诚地为我糟糕的英语道歉。

我在服务器上有很多 SQL Server 作业。每当完成任何作业执行时，我都需要执行 SP。一种困难的方法是在每个调用该 SP 的作业上创建一个步骤。

有没有简单的方法可以做到这一点？作业完成后，SQL Server 是否执行任何 SP 或任何内容？

我有一个 55 GB 大小的立方体，需要大约 2 小时才能完成处理。因为我有过去 4 年的数据，但我们的业务只需要 2 年的数据。为此，我已将维度和事实视图更改为仅包含最近两年的数据。现在，我的立方体大小减少到 32 GB，但处理时间增加了 30 分钟（即 2 小时 30 分钟）。我期望它会更少，因为我限制了进入多维数据集的大量数据。为什么处理时间增加了而实际上应该减少？我现在怎样才能减少处理时间？

PS：我已经尝试过多维数据集分区，并且由于尺寸较大，它也增加了处理时间。

我正在使用通过 WHERE 子句限制数据的视图。

我的观点基本上是这样的：

SELECT V.Col1, V.Col2.... V.Col13 
FROM DimeTable V 
WHERE <my filter clause>

它从维度表中选择几乎所有列，因此我无法在所有这些列上创建非聚集索引，因为它可能会减慢插入操作并且对我没有太大帮助