标签: sql-server-2008

是否有 T-SQL 查询显示某个数据库的上次还原日期时间？

我想知道如何识别实际填充 TEMPDB 数据库事务日志的确切查询或存储过程。

我正在尝试强制删除数据库，但是在删除数据库后，当我尝试重新创建数据库时，出现错误

无法创建文件 C:\Program Files.....[databasename].mdf 因为它已经存在

这是我强制删除数据库的查询

Use master;
ALTER database [databasename] set offline with ROLLBACK IMMEDIATE;
DROP database [databasename];

我明白，上面的查询正在删除数据库，但它没有删除.ldf和.mdf文件。如何彻底删除数据库？

正常查询

Drop database [databasename] ; //deletes the database completely, including the ldf and mdf's.

如何强制删除数据库，同时删除.mdf和.ldf文件？

我正在为一个简单的银行数据库编写架构。以下是基本规格：

• 数据库将存储针对用户和货币的交易。
• 每个用户每种货币都有一个余额，因此每个余额只是针对给定用户和货币的所有交易的总和。
• 余额不能为负。

银行应用程序将专门通过存储过程与其数据库通信。

我希望这个数据库每天接受数十万个新事务，以及更高数量级的平衡查询。为了非常快速地提供余额，我需要预先汇总它们。同时，我需要保证余额永远不会与其交易历史相矛盾。

我的选择是：

1. 有一个单独的balances表并执行以下操作之一：

   1. 将事务应用于transactions和balances表。TRANSACTION在我的存储过程层使用逻辑来确保余额和交易始终同步。（由杰克支持。）

   2. 将交易应用到transactions表并有一个触发器，balances用交易金额为我更新表。

   3. 将交易应用到balances表中，并有一个触发器transactions为我在表中添加一个新条目，其中包含交易金额。

   我必须依靠基于安全的方法来确保在存储过程之外不能进行任何更改。否则，例如，某些进程可以直接将事务插入transactions表中，并且在该方案1.3下相关余额将不同步。

2. 有一个balances索引视图，可以适当地聚合事务。存储引擎保证余额与其交易保持同步，因此我不需要依赖基于安全的方法来保证这一点。另一方面，我不能再强制余额为非负数，因为视图——甚至索引视图——不能有CHECK约束。（由丹尼支持。）

3. 只有一个transactions表，但有一个额外的列来存储该交易执行后立即生效的余额。因此，用户和货币的最新交易记录也包含其当前余额。（下面由Andrew建议；由garik提出的变体。）

当我第一次解决这个问题时，我阅读了这 两个讨论并决定了 option 2。作为参考，您可以在此处查看它的基本实现。

• 您是否设计或管理过这样的具有高负载配置文件的数据库？你对这个问题的解决方案是什么？

• 你认为我做出了正确的设计选择吗？有什么我应该记住的吗？

  例如，我知道对transactions表的架构更改需要我重建balances视图。即使我正在归档事务以保持数据库较小（例如，将它们移到其他地方并用摘要事务替换它们），每次架构更新时都必须重建数千万个事务的视图，这可能意味着每次部署的停机时间会显着增加。

• 如果索引视图是要走的路，我如何保证没有余额为负？

归档交易：

让我详细说明一下存档交易和我上面提到的“摘要交易”。首先，在像这样的高负载系统中，定期存档将是必要的。我想保持余额与其交易历史之间的一致性，同时允许将旧交易转移到其他地方。为此，我将用每个用户和货币的金额摘要替换每批存档交易。

因此，例如，此交易列表：

user_id    currency_id      amount    is_summary
------------------------------------------------
      3              1       10.60 …

我有一个进程可以抓取一堆记录（1000 条）并对它们进行操作，当我完成后，我需要将其中的大量记录标记为已处理。我可以用一个大的 ID 列表来表明这一点。我试图避免“循环更新”模式，所以我想找到一种更有效的方法来将这个 ID 包发送到 MS SQL Server 2008 存储过程中。

提案#1 - 表值参数。我可以定义一个只有一个 ID 字段的表类型，然后发送一个包含要更新的 ID 的表。

建议 #2 - XML 参数 (varchar) 和 OPENXML() 在 proc 主体中。

建议 #3 - 列表解析。如果可能的话，我宁愿避免这种情况，因为它看起来笨拙且容易出错。

其中有什么偏好，或者我错过了什么想法？

最近我们的一个 ASP.NET 应用程序显示了一个数据库死锁错误，我被要求检查并修复该错误。我设法找到死锁的原因是一个存储过程，它严格更新游标内的表。

这是我第一次看到这个错误，不知道如何有效地跟踪和修复它。我尝试了我知道的所有可能的方法，最后发现正在更新的表没有主键！幸运的是，这是一个身份栏。

后来我发现为部署编写数据库脚本的开发人员搞砸了。我添加了一个主键，问题就解决了。

我感到很高兴并回到我的项目中，并做了一些研究以找出导致僵局的原因......

显然，这是导致死锁的循环等待条件。没有主键的更新显然比有主键需要更长的时间。

我知道这不是一个明确定义的结论，这就是我在这里发布的原因......

• 缺少主键是问题吗？
• 除了（互斥、保持等待、无抢占和循环等待）之外，是否还有其他条件会导致死锁？
• 如何防止和跟踪死锁？

今天在对服务代理问题进行故障排除时，我发现数据库所有者是离开公司的员工的 Windows 登录名。他的登录名已被删除，因此查询通知失败。

据说处理这个问题的最佳实践是让“sa”成为数据库所有者。我们更改了它并清除了队列。

我的（非常基本的）问题：数据库所有者是什么，其目的是什么？

我已经设置了一台运行 Windows Server 2008 的服务器，并安装了 SQL Server 2008 Express。

我可以通过以下方式连接到机器的 SQL Server Express 数据库 MACHINENAME/SQLEXPRESS.

但是，当我们使用IP 地址通过任何软件或脚本进行连接时连接时，它将不允许连接。