我正在为我公司的一个客户寻找一些关于我正在寻找的问题的额外帮助。基本上,关于在每个实例上2-node active/active cluster
托管一个实例,我有两个相关的问题2008 R2
。
通常在节点#2 上的实例之一位于 RTM。当故障转移到节点 #1 时,SQL Server 服务会超时,但是一旦超时,呃,“超时”,服务实际上可以手动上线。并查看日志有表单错误
'登录失败......原因:服务器处于脚本升级模式......'。
起初我认为这是安装 SP1 失败的结果,但现在我不太确定了。SP1 肯定已安装在两个节点上,而另一个实例(通常在节点 #1 上)位于 SP1。我认为这是遵循在“非活动”节点上安装服务包的建议,进行故障转移并重复该过程。但是,我很难解释安装日志以查看是否只更新了一个实例或两者都更新,其中一个失败。所以我希望有人可以帮助我解决我应该查看的日志文件。
另外,可能是什么意思'script upgrade mode' errors
?这确实听起来像是 SP1 升级失败还是另有原因?奇怪的是,问题只发生在一个方向 - 从节点 #2 到节点 #1。当故障恢复到节点 #2 时,SQL Server 服务重新上线,无需任何手动干预。
将数据库迁移到具有默认排序规则 Latin1_General_CI_AS 的新 2014 服务器后,但在大多数数据库的排序规则为 Latin1_General_BIN 的情况下,尝试导入 Excel 电子表格会引发以下错误:
我已经将 sysdac_instances 跟踪到 msdb,它是一个系统视图,直接查询它会给出相同的错误。我希望有人能够指出我对这个问题的直接解决方案的方向?
奇怪的是,通过 SSMS 2008 运行导入是有效的。
我试图了解跟踪标志 2861 以及它对琐碎查询的实际作用?
简介说:
SQL Server 通常不会缓存这些简单查询的计划,因为缓存计划的成本高于为此类简单查询生成新计划的成本。
这显然是不正确的,因为我运行的每个“琐碎”查询似乎都被缓存了。所以我想知道 2861 的意义是什么,除非我误解了一个微不足道的计划实际上是什么。当我查询缓存计划并且它说它是临时的和微不足道的时,我没有理由怀疑它。
希望有人能给我解惑。
sql-server ×2
clustering ×1
collation ×1
failover ×1
msdb ×1
plan-cache ×1
restore ×1
trace-flags ×1