标签: upgrade

自 SQL Server 6.5 以来，我一直在使用 SQL Server，但仍然萦绕在我脑海中的旧建议是永远不要进行就地升级。

我目前正在将我的 2008 R2 DEV 和 TEST 系统升级到 SQL Server 2012，并且需要使用相同的硬件。不必恢复我的报告服务配置的想法非常有吸引力，我真的很聪明。不涉及分析服务或任何不寻常或非标准的东西——只安装了数据库引擎和报告服务。

有没有人遇到过就地升级的严重问题？或者我应该重新评估我对就地升级的立场？

由于自 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 Server执行大规模升级，并注意到分布式可用性组的一些异常行为，我正试图在继续之前解决这些问题。

上个月，我将远程辅助服务器从 SQL Server 2016 升级到 SQL Server 2017。该服务器是多个分布式可用性组 (DAG)和一个单独的可用性组 (AG) 的一部分。当我们升级这台服务器时，我们没有意识到它会进入一个不可读的状态，所以在过去的一个月里，我们一直完全依赖于主服务器。

作为即将进行的升级的一部分，我将CU 4补丁应用到服务器并重新启动它。当服务器重新上线时，刚刚打补丁的辅助服务器显示所有 DAG/AG 都在同步，没有任何问题。

然而，初选展示了一个非常不同的故事。报道称

• 单独的 AG 同步没有任何问题
• 但 DAG 处于不同步/不健康状态

在最初感到恐慌之后，我尝试了以下方法来使 DAG 中的事物再次同步：

• 从主数据库中，我停止并恢复了数据移动。这并没有开始同步数据。
• 在二级（我刚刚修补的那个）上我跑了ALTER DATABASE [<database] SET HADR RESUME;- 执行没有错误，但没有恢复任何同步

我最后一次再次同步数据的尝试是登录到辅助服务器，然后手动重新启动 SQL Server 服务。手动重新启动服务似乎有点极端，因为我希望重新启动服务器就足够了。

有没有人遇到过重启后 DAG 没有开始同步到辅助节点的问题？如果有，是如何解决的？

我检查了 SQL Server 错误日志和辅助服务器上的事件查看器，没有发现任何异常。

我想将我的 PostgreSQL 从版本8.4升级到9.4。

该文件是不是很清楚，我。

1. 如果进行升级，我会丢失旧数据库吗？
2. 如果升级后丢失旧数据库，如何备份它们？
3. 如何升级我的 psql？

我的 PostgreSQL 在CentOS 6.6服务器上运行。

我正在尝试使用此命令作为 postgres 用户在 Fedora 18 中将 Postgresql 从 9.2 升级到 9.3

$ pg_upgrade -b /bin -B /usr/pgsql-9.3/bin -d /var/lib/pgsql/data -D /var/lib/pgsql/9.3/data/ -j 2 -u postgres

日志中的错误

命令："/bin/pg_ctl" -w -l "pg_upgrade_server.log" -D "/var/lib/pgsql/data" -o "-p 50432 -b -c listen_addresses='' -c unix_socket_permissions=0700 -c unix_socket_directory='/var/lib/pgsql'" start >> "pg_upgrade_server.log" 2>&1 等待服务器启动......致命：无法识别的配置参数“unix_socket_directory”......停止等待 pg_ctl：无法启动服务器

正如a_horse在评论中指出的那样，参数unix_socket_directories在 9.3 中被(plural)替换。但是正在启动的服务器版本是旧的9.2：

$ /bin/pg_ctl --version
pg_ctl (PostgreSQL) 9.2.4

有任何想法吗？

今天早些时候，我注意到我所有的 Azure SQL 数据库服务器都从 v11 更新到了 v12。我是公司中唯一应该接触这些拨号的人，但不是我公司中唯一可以访问的人。由于这次升级不是我发起的，我想知道是谁发起的，以及这个计划外的更新是什么时候发生的。

我知道我可以写一封电子邮件给我公司的每个人，并礼貌地向WTF询问信息，但我宁愿用尽可能多的事实开始对话。另外，我倾向于认为这是 Microsoft/Azure SNAFU，因为升级所有服务器感觉太刻意了。

我目前在生产环境中运行 PostgreSQL 9.4，但我们正在服务器上进行操作系统升级，因此我认为可能是时候将 PostgreSQL 版本升级到最新版本 (12)，以便我可以利用一些可用的新功能。然而，各个数据库中的一些表是很久以前构建的（例如，2008 年之前，至少在某些情况下很可能是 2000 年之前）。这些数据库包含许多使用 OID 的表（WITH OIDS=TRUE在定义中）。

此外，我还对大部分代码库进行了搜索，以查找任何表中对 OID 列的引用，并发现了几个实例，其中存在显式调用 OID 列的查询。幸运的是，这样的情况并不多，而且大多数都是引用系统表（即，SELECT oid FROM pg_namespace，...FROM pg_class）。

对从 9.4 数据库转储的数据运行pg_upgrade该过程会在此时停止，并断然声明直到数据库中没有 OID 后才会继续。据我所知，他们在过去的几个版本中一直在慢慢地逐步淘汰这些内容，而 12 版本使它们基本上变得无关紧要，但建议是在pg_upgrade继续之前完全删除 OID 列。我认为这对于一个几乎不相关的专栏来说是“矫枉过正”。

此时 - 我承认我还没有完全考虑到这一点 - 我想知道简单地“翻转”WITH OIDS受影响的表定义中的开关是否FALSE足以继续升级？如果翻转的话，现有的 OID 列是否仍是数据库结构的一部分（我认为会，但自动升级可以做一些有趣的事情）？

我意识到，在理想情况下，我希望最终从数据库中完全消除 OID。然而，作为一个单人 IT 部门，这必须“列入清单”以供以后评估。目前，我只是想让数据库在最新的 PostgreSQL 版本上启动并运行，同时我有机会这样做而不会立即影响操作。

使用 Enterprise DB 构建的 Windows 安装程序从 PostgreSQL（例如 9.3.0 到 9.3.1）执行小升级的推荐方法是什么？我应该先卸载还是在现有安装上安装？

当前安装是使用 postgresql-9.3.0-1-windows-x64.exe 执行的。现在我想使用 postgresql-9.3.1-1-windows-x64.exe 进行升级。

在测试从 SQL Server 2014 SP1 (12.0.4422.0) 到 SQL Server 2016 CTP 3.2 (13.0.900.73) 的升级时，我遵循推荐的更新过程并遇到了一个问题，即故障转移后数据库无法在旧的主数据库上启动到更新的辅助。我们的设置是一个主副本和一个辅助副本，我完成的步骤是：

1. 删除同步提交辅助副本上的自动故障转移
2. 将辅助服务器实例升级到新版本
3. 手动故障转移到辅助副本
4. 验证数据库在新的主副本上是否在线
5. 将以前的主副本升级到新版本

升级辅助节点和故障转移使其成为主节点完全按预期工作。但是在升级以前的主副本后，我注意到其上的数据库在 SSMS 中列为Not Synchronizing / In Recovery。尝试访问它们也会生成错误消息：

数据库...无法访问。（对象浏览器）

通过我看到的 SQL Server 日志检查

无法打开数据库 '...' 版本 782。将数据库升级到最新版本。

查询master..sysdatabases表，确实是旧版本，升级过程中没有更新：

不幸的是，日志没有指出它为什么没有更新，并且可用性组仪表板只给出了一个通用警告，表明某些可用性数据库的数据同步状态不健康，没有任何原因。

我尝试使用 TSQL 分离数据库或将它们设置为离线以“踢”它进行更新，但由于它们是 SQL AG 的一部分，因此这些命令不起作用。

当数据库是 SQL AG 的一部分时，如何将数据库升级到最新版本？

我在官方 docker 镜像中运行 MySQL 5.7.11。

当我想升级时，出现以下错误：

mysql_upgrade -uroot -p
password:
Error occurred: Cannot setup server variables.

我四处寻找，没有找到任何提示。我试图运行--verbose，但没有运气。

作为参考，这里是我启动数据库时的日志：

db_1  | 2016-02-17T11:23:10.453190Z 0 [ERROR] Incorrect definition of table performance_schema.events_waits_current: expected column 'NESTING_EVENT_TYPE' at position 15 to have type enum('TRANSACTION','STATEMENT','STAGE','WAIT', found type enum('STATEMENT','STAGE','WAIT').
db_1  | 2016-02-17T11:23:10.453233Z 0 [ERROR] Incorrect definition of table performance_schema.events_waits_history: expected column 'NESTING_EVENT_TYPE' at position 15 to have type enum('TRANSACTION','STATEMENT','STAGE','WAIT', found type enum('STATEMENT','STAGE','WAIT').
db_1  | 2016-02-17T11:23:10.453275Z 0 [ERROR] Incorrect definition of table performance_schema.events_waits_history_long: expected column 'NESTING_EVENT_TYPE' at …