标签: process

将数据库更改从开发环境迁移到 QA 到生产环境的好方法是什么？目前我们：

1. 在 SQL 文件中编写更改脚本并将其附加到 TFS 工作项。
2. 工作经过同行评审
3. 当工作准备好进行测试时，SQL 在 QA 上运行。
4. 作品经过 QA 测试
5. 当工作准备好进行生产时，SQL 将在生产数据库上运行。

问题在于它非常手动。如果开发人员忘记了，它依赖于开发人员记得附加 sql 或同行评审员捕获它。有时，最终发现问题的是测试人员或 QA 部署人员。

第二个问题是，如果两个单独的任务更改同一个数据库对象，您有时最终需要手动协调更改。这可能只是它的方式，但似乎仍然应该有一些“标记”这些问题或其他东西的自动方式。

我们的设置：我们的开发商店充满了具有丰富数据库经验的开发人员。我们的项目非常面向数据库。我们主要是一家 .NET 和 MS SQL 商店。目前我们正在使用 MS TFS 工作项来跟踪我们的工作。这对于代码更改非常方便，因为它将更改集链接到工作项，因此我可以准确地找出在迁移到 QA 和生产环境时需要包含哪些更改。我们目前没有使用 DB 项目，但将来可能会切换到该项目（也许这是答案的一部分）。

我非常习惯于我的源代码控制系统为我处理这样的事情，并希望我的 SQL 也有同样的事情。

我们有一台专用的 SQL Server 2008 R2 机器，它遇到了一些奇怪的内存问题。机器本身有很多资源，包括两个四核处理器、16GB 内存和 64 位 Windows Server 2008 R2 Enterprise（它是戴尔 PowerEdge 2950） .

奇怪的问题是系统报告 82% 的内存在使用中，而 sqlservr.exe 仅报告 155mb 正在使用中。我怀疑 SQL Server 是问题的原因是，如果我重新启动 sqlservr.exe 进程，内存消耗会在一段时间内恢复正常。

有没有人对我如何开始追踪这个问题有任何想法？

谢谢，杰森

我有一个奇怪的情况。使用sp_whoisactive我可以看到：

好的，通过这个查询，我可以看到是什么触发了（这个词在英语中存在吗？）它：

SELECT c.session_id, c.properties, c.creation_time, c.is_open, t.text
FROM sys.dm_exec_cursors (SPID) c --0 for all cursors running
CROSS APPLY sys.dm_exec_sql_text (c.sql_handle) t

结果：

这是一个简单的select. 为什么要使用 f etch_cursor？

另外，我也看到了很多“空白”的 sql_texts。这与这个“光标”有关系吗？

DBCC INPUTBUFFER (spid) 给我看这个：

有这个问题 在这里（我做的），但我不知道这是否是同样的事情。

编辑1：

使用 kin 提供的查询，我看到了这一点：

编辑2：

使用活动监视器，我可以看到：

这是最昂贵的查询（第一个是故意的，我们知道）。

再一次，我想知道，为什么这select * from...是FETCH CURSOR……的原因。

编辑3：

这个“ select * from...”是从另一台服务器（通过linked server）运行的。

好吧，现在我无法理解@kin 所说的内容。

这是execution plan查询的（在数据库的同一服务器中运行）：

这是现在，通过链接服务器在另一台服务器上运行的执行计划：

好的，也不是问题。现在！执行计划，通过**activity monitor**（相同select * from）：

就像之前在这里发布的关于“开发人员应该能够查询生产数据库吗？ ”的问题的脉络一样，我想了解您对另一个特别烦人的话题的看法！

许多公司阻止开发人员在开发机器上安装 SQL Server Express 等，而是提倡使用集中式开发 SQL Server。

具体来说，这样做是为了确保：

• 开发服务器和生产之间的补丁级别一致性
  
• 能够证明和验证上述任何补丁
  
• 数据安全; 只有开发服务器上的数据才能用于开发
  
• 可恢复性；数据可恢复且仍在备份
  
• 转移到生产时可能导致问题的排序规则差异

对我来说，所有这些论点都特别无效，也许修补程序除外。但是如果本地机器上的数据库纯粹用于开发活动，而不是测试，那么当应用程序通过测试/UAT 等进入生产时，补丁将被证明。

排序规则似乎不是一个有效的理由，好像这是数据库的一个问题，它应该在创建时设置。据我所知，只有 SharePoint 和 SCCM 有这方面的问题；)

现在，假设它仅用于开发，并且数据库不会“移动”到生产中，唯一的移动是：

• 创建用于部署到生产的数据库的脚本
• 来自“生产”第三方系统的备份在适合验证和开发的情况下被恢复和截断

任何人都可以看到任何问题吗？我错过了什么吗？

我想最大的问题之一是本地数据库实例过时的能力，但那是软件管理问题，而不是 DBA 的 IMO。

我复制了一个大表的结构（顺便说一句，它是一个InnoDB表）

CREATE TABLE tempTbl LIKE realTbl 

然后我更改了一个索引，并填充它以便我可以运行一些测试。使用以下方法填充它：

INSERT INTO  `tmpTbl` 
SELECT *
FROM `realTbl`

这花了太长时间，所以我想停止这个测试。¹

我在处于“发送数据”状态时终止了该进程：它现在已“终止”，并且仍处于“正在发送数据”状态。

我知道一些被杀死的进程需要恢复更改，因此与它们运行的​​时间相比可能需要（同样？）很长时间才能杀死，但我无法想象为什么现在会出现这种情况：需要清空整个表。

我很好奇正在发生的事情需要停止/终止这样一个简单的查询很长时间。给你一些数字：插入运行了一个小时或 3 个小时，现在杀死接近5 7。看起来它几乎DELETE每次都运行一次INSERT，并且删除比插入花费的时间更长？这甚至合乎逻辑吗？

（如果有人知道如何将我的测试服务器恢复原状也很好，因为它正在消耗一些资源，但目前这并不重要:)）

1） 我还不知道为什么（它是一个大表，10M 行，但它应该需要那么长时间？），但这是另一件事/不是这个问题的一部分:)。可能是我的测试本可以更聪明或更快速，但这也不是现在的问题：D

在测试 Oracle XE 连接建立机制时，我遇到了以下问题。虽然连接在每次迭代时关闭，但在 50-100 个连接后 Oracle 开始间歇性地抛出以下异常：

java.sql.SQLException: Listener refused the connection with the following error:
ORA-12516, TNS:listener could not find available handler with matching protocol stack
 
    at oracle.jdbc.driver.T4CConnection.logon(T4CConnection.java:489) ~[ojdbc6-11.2.0.4.jar:11.2.0.4.0]
    at oracle.jdbc.driver.PhysicalConnection.<init>(PhysicalConnection.java:553) ~[ojdbc6-11.2.0.4.jar:11.2.0.4.0]
    at oracle.jdbc.driver.T4CConnection.<init>(T4CConnection.java:254) ~[ojdbc6-11.2.0.4.jar:11.2.0.4.0]
    at oracle.jdbc.driver.T4CDriverExtension.getConnection(T4CDriverExtension.java:32) ~[ojdbc6-11.2.0.4.jar:11.2.0.4.0]
    at oracle.jdbc.driver.OracleDriver.connect(OracleDriver.java:528) ~[ojdbc6-11.2.0.4.jar:11.2.0.4.0]
    at oracle.jdbc.pool.OracleDataSource.getPhysicalConnection(OracleDataSource.java:280) ~[ojdbc6-11.2.0.4.jar:11.2.0.4.0]
    at oracle.jdbc.pool.OracleDataSource.getConnection(OracleDataSource.java:207) ~[ojdbc6-11.2.0.4.jar:11.2.0.4.0]
    at oracle.jdbc.pool.OracleDataSource.getConnection(OracleDataSource.java:157) ~[ojdbc6-11.2.0.4.jar:11.2.0.4.0]
    at com.vladmihalcea.book.high_performance_java_persistence.jdbc.connection.OracleConnectionCallTest.test(OracleConnectionCallTest.java:57) [test-classes/:na]

测试可以在 GitHub 上找到：

for (int i = 0; i < callCount; i++) {
    try {
        long startNanos = System.nanoTime();
        try (Connection connection = …

我有一个带有 SP4 的 SQL Server 2005 Std (x64)，它有一个我似乎无法杀死的过程。如果我查看 sys.dm_exec_requests，我会看到 SPID 103，wait_type 为 LCK_M_SCH_M，状态为 SUSPENDED，命令为 KILLED/ROLLBACK。然而，SPID 并没有消失。我什至可以执行 sp_who 103 并且我看到带有 KILLED/ROLLBACK 的 SPID。自从我杀死 SPID 以来，它的当前等待时间接近 20 小时。

此外，运行KILL 103 WITH STATUS ONLY返回 0% 已完成

我应该为自己感到羞耻，因为我知道。

查看附件中的此屏幕截图。

我的服务器确实没有看到大量的流量，不应该超载。Mysql 正在举办一个派对，邀请了所有人。问题是我不喜欢这种狂野的派对。

我怎么杀这个东西？我如何对其进行监管以使其不会继续发生？很快，我的主人就会报警，所有人的聚会都将结束。

我尝试通过WHM重新启动MySQL，现在重新启动时间太长，进度条仍然显示。

我能做些什么？

我仍然可以通过 SSH 访问服务器，但无法连接到 MySQL。这很紧急，因为我的在线商店现在已关闭。

重新启动 HTTP 服务器 (Apache) 会有帮助吗？

如果我运行mysqld，即直接在命令行上调用它，它会在外壳关闭或点击 时幸存下来ctrl-c。

有没有办法“交互式”运行它，即如果发生这些事情中的任何一个，它就会关闭？

（我发现这在开发过程中很有用，因为我有一个 tmux 脚本可以快速启动和关闭各种服务器。）