标签: sql-server

服务器 (SQL Server 2008) 的 tempdb 每月数次增加到 500GB+。是否可以找出导致此问题的 SQL 语句？问题通常不是由create table #temp...; insert into #temp...或select ... into #temp...复杂的连接引起的。

某些 tempdb 文件的初始大小每次也会自动设置为更大的值。如何预防？

有时缓存的计划会阻止调整/缩小文件的大小。如何找到哪一个持有tempdb？

我有一个 MS SQL Server 2008 R2 DB 服务器，目前正在与生产应用程序一起使用。

该应用程序的新增强功能现在需要varchar(100)增加表格中的列长度​​。

能否在不影响当前数据的情况下增加 prod DB 中此现有列的长度？

是否必须在非工作时间完成此更改以避免服务中断？

题：

我有一个脚本，其中包含来自 select 语句的大约 45,000 个插入。当我尝试运行它时，我收到一条错误消息，指出我的内存不足。我怎样才能运行这个脚本？

语境：

1. 添加了一些新的数据字段，使应用程序与客户端使用的另一个应用程序配合得很好。
2. 从客户端获得了一份数据电子表格，其中包含将当前数据项映射到这些新字段的值的数据。
3. 将电子表格转换为插入语句。
4. 如果我只运行一些语句，它会起作用，但整个脚本不会。
5. 没有。没有错别字。

如果有不同的方式我应该加载这些数据，请随时批评我并让我知道。

我已经四处搜索了，但没有找到这个问题的最终答案。

我需要一个可以为关联角色授予所有权限的脚本。

有什么想法，或者甚至可能吗？

这让我关闭 - 但我似乎无法翻转它并提供角色而不是用户的摘要。

http://consultingblogs.emc.com/jamiethomson/archive/2007/02/09/SQL-Server-2005_3A00_-View-all-permissions--_2800_2_2900_.aspx

 WITH    perms_cte as
(
        select USER_NAME(p.grantee_principal_id) AS principal_name,
                dp.principal_id,
                dp.type_desc AS principal_type_desc,
                p.class_desc,
                OBJECT_NAME(p.major_id) AS object_name,
                p.permission_name,
                p.state_desc AS permission_state_desc
        from    sys.database_permissions p
        inner   JOIN sys.database_principals dp
        on     p.grantee_principal_id = dp.principal_id
)
--role members
SELECT rm.member_principal_name, rm.principal_type_desc, p.class_desc, 
    p.object_name, p.permission_name, p.permission_state_desc,rm.role_name
FROM    perms_cte p
right outer JOIN (
    select role_principal_id, dp.type_desc as principal_type_desc, 
   member_principal_id,user_name(member_principal_id) as member_principal_name,
   user_name(role_principal_id) as role_name--,*
    from    sys.database_role_members rm
    INNER   JOIN sys.database_principals dp
    ON     rm.member_principal_id = dp.principal_id
) rm
ON …

将该UNPIVOT函数应用于未规范化的数据时，SQL Server 要求数据类型和长度相同。我明白为什么数据类型必须相同，但为什么 UNPIVOT 要求长度相同？

假设我有以下需要逆透视的示例数据：

CREATE TABLE People
(
    PersonId int, 
    Firstname varchar(50), 
    Lastname varchar(25)
)

INSERT INTO People VALUES (1, 'Jim', 'Smith');
INSERT INTO People VALUES (2, 'Jane', 'Jones');
INSERT INTO People VALUES (3, 'Bob', 'Unicorn');

如果我尝试 UNPIVOTFirstname和Lastname列类似于：

select PersonId, ColumnName, Value  
from People
unpivot
(
  Value 
  FOR ColumnName in (FirstName, LastName)
) unpiv;

SQL Server 生成错误：

Msg 8167, Level 16, State 1, Line 6

“姓氏”列的类型与 UNPIVOT 列表中指定的其他列的类型冲突。

为了解决错误，我们必须使用子查询首先将Lastname列强制转换为与以下相同的长度Firstname …

由于自 SQL Server 2005 或 2008 年以来，Microsoft 使 SQL Server 版本升级更加频繁，因此许多公司发现很难确定何时升级是“必须的”！当升级是“很高兴”时

本着一些较早的问题的精神，询问为什么更喜欢各种较新版本的 SQL Server 而不是以前的版本，公司可能会考虑将 SQL Server 2016 升级到较早版本甚至更高版本的客观技术或业务原因是什么？发布如 SQL Server 2014？

（这个关于 SQL Server 2012 与 SQL Server 2008 相比的问题，或者这个关于 SQL Server 2012 与 SQL Server 2005 相比的问题，作为这个问题精神的例子浮现在脑海中。他们的答案还扩展了这里的一些原因从 SQL Server 2008 或 SQL Server 2005 开始的公司）

作为开发人员，我经常使用 SQL Profiler。这是一个很好的调试工具，既可以跟踪我的代码在做什么，也可以分析性能问题。

但是我一直在我的开发环境中使用它，并且以一种非常可控的方式使用它。

• 启动我的应用程序，并使其进入特定状态
• 在探查器上开始跟踪
• 对我的应用程序执行特定的操作序列
• 停止跟踪并检查结果。

SQL Profiler 能否在生产环境中实际使用？

我首先担心的是它会降低性能。

我的第二个担忧是，因为它正在生产中，您不会触发有趣的操作本身。您必须让分析器长时间运行，然后分析结果。结果集会变得太笨拙吗？（占用太多磁盘空间，查询太难）。

有人在生产中使用 SQL Profiler 吗？

我正在尝试提高以下查询的性能：

        UPDATE  [#TempTable]
        SET     Received = r.Number
        FROM    [#TempTable] 
        INNER JOIN (SELECT  AgentID,
                            RuleID,
                            COUNT(DISTINCT (GroupId)) Number
                    FROM    [#TempTable]
                    WHERE   Passed = 1
                    GROUP BY AgentID,
                            RuleID
                   ) r ON r.RuleID = [#TempTable].RuleID AND
                          r.AgentID = [#TempTable].AgentID                            

目前我的测试数据大约需要一分钟。我对这个查询所在的整个存储过程的更改的输入量有限，但我可能会让他们修改这个查询。或者添加索引。我尝试添加以下索引：

CREATE CLUSTERED INDEX ix_test ON #TempTable(AgentID, RuleId, GroupId, Passed)

它实际上使查询所需的时间增加了一倍。我用非聚集索引得到了同样的效果。

我尝试按如下方式重新编写它，但没有任何效果。

        WITH r AS (SELECT  AgentID,
                            RuleID,
                            COUNT(DISTINCT (GroupId)) Number
                    FROM    [#TempTable]
                    WHERE   Passed = 1
                    GROUP BY AgentID,
                            RuleID
            ) 
        UPDATE  [#TempTable]
        SET     Received = r.Number
        FROM    [#TempTable] 
        INNER JOIN r …

根据官方 Microsoft BOL DENSE_RANK 是不确定的（RANK()）。但根据Itzik Ben-Gan 的排名函数 “...... RANK() 和 DENSE_RANK() 函数总是确定性的”。谁是对的？

到目前为止我发现： 微软的定义“确定性函数在任何时候使用一组特定的输入值调用它们时总是返回相同的结果，并给出相同的数据库状态。”

所以在集合理论表雇员

Employee            Salary
Sue Right            1.00
Robin Page           1.00
Phil Factor          1.00

和员工2

Employee            Salary
Phil Factor          1.00
Sue Right            1.00
Robin Page           1.00

是相同的。但是排名函数返回不同的值：

    CREATE TABLE [dbo].[Employees](
    --[ID] [int] IDENTITY(1,1) NOT NULL,
    [Employee] [varchar](150) NOT NULL,
    [Salary] [smallmoney] NULL,
) ON [PRIMARY]

GO
CREATE TABLE [dbo].[Employees2](
    --[ID] [int] IDENTITY(1,1) NOT NULL,
    [Employee] [varchar](150) NOT NULL,
    [Salary] [smallmoney] NULL,
) ON …

在 PostgreSQL 和 SQL Server 中，默认页面大小为 8 KB，在 MySQL 中为 16 KB，在 IBM DB2 和 Oracle 中仅为 4 KB。

为什么这些页面尺寸如此之小？

是否有历史或内存使用原因？