标签: sql-server-2008

在 SQL Server 2008 R2 中，我收到了几个死锁报告，输入缓冲区中有“*password------------”。看起来像是攻击，但在那种情况下，我不知道攻击的原因或类型。

（日志是由一位经验丰富的 DBA 专家生成的，并告诉我，不是我）

有谁知道它是什么？谢谢！

例子：

<?xml version="1.0"?>
<blocked-process>
  <process id="process879948" taskpriority="0" logused="0" waitresource="KEY: 5:72057602473263104 (1d69201d0ba6)" waittime="5185" ownerId="88389135" transactionname="SELECT" lasttranstarted="2012-09-25T18:11:02.507" XDES="0x1f7d2a590" lockMode="S" schedulerid="2" kpid="4552" status="suspended" spid="86" sbid="2" ecid="0" priority="0" trancount="0" lastbatchstarted="2012-09-25T18:11:02.507" lastbatchcompleted="2012-09-25T18:11:02.507" lastattention="2012-09-25T18:07:35.740" clientapp=".Net SqlClient Data Provider" hostname="IP-xxxxxxxx" hostpid="4868" loginname="sa" isolationlevel="read committed (2)" xactid="88389135" currentdb="1" lockTimeout="4294967295" clientoption1="671088672" clientoption2="128056">
    <executionStack>
      <frame line="14" stmtstart="374" stmtend="764" sqlhandle="0x03000500dac2967f208e4000a19d00000000000000000000"/>
      <frame line="1" stmtstart="44" sqlhandle="0x02000000632f7e131f79ec7312284505961e537a61b81be7"/>
      <frame line="1" sqlhandle="0x000000000000000000000000000000000000000000000000"/>
    </executionStack>
    <inputbuf>

*password---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------   </inputbuf>
  </process>
</blocked-process>

我有一个指向链接服务器的存储过程。在整个过程中的几个地方，我得到了如下内容：

INSERT INTO [TableName]
(...Columns...)
SELECT ...Columns...
FROM [ServerName\InstanceName].[Catalogue].[dbo].[TableName]
WHERE TableNameID = @TableNameID

这个过程存在于我的开发环境、测试环境和实时环境中。

问题是该过程的每个副本都略有不同，因为每个环境的服务器名称都不同。这使得管理脚本更新的部署变得很麻烦。

有没有办法使程序可移植，以便每个环境都可以运行相同版本的程序？

如果没有，我可以做些什么来使脚本部署更不容易出错/错误？

我计划对我的数据库（数据仓库）中的一些大表应用 PAGE 压缩。这些表相当大，有超过 150 亿行。

当我在测试环境中应用压缩时，整个过程大约需要 22 个小时。这些表每天都会通过运行很长时间的查询进行访问。

1. 在应用压缩时，是否会对正在运行的查询产生任何影响？任何锁等我应该知道？
2. 是否有交错的方法来应用压缩？
3. 您可能有任何其他输入/反馈？

我在尝试对从客户那里收到的备份文件使用 restore 命令进行恢复时遇到以下错误。

从磁盘恢复数据库 SFDB = N'C:\Backup\Backup.bak'

关于我可以做些什么来纠正这个问题的任何想法？它正在寻找 mdf，所以我可以假设我拥有的备份文件是增量备份而不是完整备份，这就是它寻找 mdf 的原因吗？

我不确定 1) 他们是否提供了所有数据（整个数据库）或 2) 我有正确的数据 - 我可以使用正确的 T-SQL 命令进行恢复 - 我只是不知道如何。

帮助表示赞赏。

Msg 5133, Level 16, State 1, Line 2
Directory lookup for the file "D:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA\Db.mdf" failed with the operating system error 21(failed to retrieve text for this error. Reason: 15105).
Msg 3156, Level 16, State 3, Line 2
File 'Db' cannot be restored to 'D:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA\Db.mdf'. Use WITH MOVE to identify a valid …

我有一个能够删除任何数据库的 sql server 用户。我一直在运行下面的代码来检查用户在 SQL Server 中拥有的权限，但无法确定用户如何能够删除数据库。是否有 sql 脚本可以帮助我确定此用户如何删除 dbs？是否有命令拒绝他们删除任何数据库？（SSMS 未将用户显示为 dbcreator 角色的一部分）

select USER_NAME(p.grantee_principal_id) AS principal_name,
    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
order by principal_name

如果有帮助，上面查询的输出为用户提供了以下三个记录

class_desc object_name permission_name permission_state_desc OBJECT_OR_COLUMN xp_cmdshell EXECUTE GRANT DATABASE NULL CONNECT GRANT
DATABASE NULL CREATE DATABASE GRANT

我们正在使用 CDC 来捕获对生产表所做的更改。更改的行正在导出到数据仓库 (informatica)。我知道 __$update_mask 列存储了以 varbinary 形式更新的列。我也知道我可以使用各种 CDC 函数从该掩码中找出这些列是什么。

我的问题是这个。任何人都可以为我定义该掩码背后的逻辑，以便我们可以识别仓库中已更改的列吗？由于我们在服务器外部进行处理，因此我们无法轻松访问那些 MSSQL CDC 函数。我宁愿自己在代码中分解面具。SQL 端的 cdc 函数的性能对于此解决方案是有问题的。

简而言之，我想从 __$update_mask 字段中手动识别更改的列。

更新：

作为替代方案，也可以将已更改列的人类可读列表发送到仓库。我们发现这可以以远高于我们原始方法的性能来执行。

以下 CLR 对此问题的回答符合此备选方案，并包括为未来访问者解释掩码的详细信息。然而，对于相同的最终结果，使用 XML PATH 接受的答案是最快的。

我正在尝试为我们的报告开发人员设置一个沙箱以进行他们的工作。我目前的计划是每天晚上“重置”数据库，但我不确定如何去做。我所说的重置是指我想从服务器上的一个数据库之外的所有数据库中删除任何用户表、视图、存储过程等。我想另一种选择是删除并重新创建数据库，但我很确定这也意味着重新授予对所有适当 AD 组/人员的访问权限。

我真的不知道这样做的最佳方法是什么，所以我希望你们中的一些人能够提供一些好的想法/建议。谢谢。

为清楚起见，我们基本上想用我们的数据库来做这个：http : //try.discourse.org/t/this-site-is-a-sandbox-it-is-reset-every-day/57。唯一的区别是我们不想每天都重新创建我们的用户。

版本： SQL Server 2008
版：开发人员和企业

我们有一个 SQL Server 2008 数据库服务器（它恰好在 MS 故障转移群集下运行，但我认为这与此处无关）。

我们的应用程序运行 Hibernate 以进行数据库访问，自从我们最近从 v3.1 升级到 3.6 以来，我们经常遇到 SQL Server 崩溃（每 24-48 小时，但有时更频繁）。

有问题的具体问题似乎与内存有关。就在服务器崩溃之前（然后似乎由故障转移集群管理器自动重新启动），我们收到了这些错误的负载：

Error: 701, Severity: 17, State: 130.
There is insufficient system memory in resource pool 'internal' to run this query.

也偶尔（但定期）的消息

Error: 17300, Severity: 16, State: 1. (Params:). The error is printed in terse mode because there was error during formatting. Tracing, ETW, notifications etc are skipped.

错误：17312，严重性：16，状态：1。（参数：）。错误以简洁模式打印，因为格式化过程中出现错误。跟踪、ETW、通知等被跳过。

我还收到一些应用程序级别的错误，例如

java.sql.SQLException: A time out occurred while waiting to optimize the query. Rerun …

我LCK_M_S在使用 RCSI时看到等待共享锁 ( )。我的理解是这不应该发生，因为SELECTs在使用 RCSI 时不需要共享锁。

我怎样才能看到共享锁？是因为外键吗？

我正在尝试缩小数据库文件，但遇到了错误。

使用sys.database_files作品中的 file_id ，但使用逻辑文件名会产生错误。

两个语句中的逻辑文件名相同，所以这不是问题。此外，正在连接的数据库是相同的。以下按预期工作：

declare @fileId as int = (select file_id from sys.database_files where name = 'XY')
DBCC SHRINKFILE (@fileId, 0, TRUNCATEONLY)

然而以下...

DBCC SHRINKFILE ('XY' , 0, TRUNCATEONLY)

...将导致错误 8985：

消息 8985，级别 16，状态 1，第 1 行
无法在 sys.database_files 中找到数据库“<我的数据库>”的文件“XY”。该文件要么不存在，要么已被删除。