小编Ron*_*ldo的帖子

当我使用 MySQL 时，我可以运行一个命令，将 SSH 连接到我的服务器并将数据库复制到我的本地机器上。

ssh -t remoteserver 'mysqldump --compress -u dbuser --password="password" db_name' | /usr/local/mysql/bin/mysql -u root --password="password" local_db_name

我如何用 PostgreSQL 做同样的事情？

我的问题与以下两个实例的实验有关：

SQL Server 2017 Express 实例 (Microsoft SQL Server 2017 (RTM-CU16))
SQL Server 2014 Express 实例 (Microsoft SQL Server 2014 (SP2-CU18))

我使用函数ENCRYPTBYPASSPHRASE来加密文本并将结果用作 DECRYPTBYPASSPHRASE 的@ciphertext。我的测试结果如下：

根据这个微软修复，

[...] SQL Server 2017 使用 SHA2 散列算法来散列密码。SQL Server 2016 和更早版本的 SQL Server 使用不再被视为安全的 SHA1 算法。

但是，如果函数 DECRYPTBYPASSPHRASE 上没有与此相关的参数，它如何知道用于加密数据的算法是什么？它是加密数据的一部分吗？

根据我的测试结果，我猜 SQL Server 总是使用实例上可用的较新版本的算法来加密数据，但会尝试所有算法来解密数据，直到找到适合的算法或在找不到相应算法时返回 NULL . 这只是一个猜测，因为我找不到任何方法来检查 SQL Server 用于解密加密数据的散列算法。

查询优化器创建多个可能的执行计划。如何查看在选择执行的计划之前生成的所有计划？

微软说：

查询优化器必须分析可能的计划并选择估计成本最低的计划。

请注意，我不是在谈论执行计划缓存和重用，我在谈论候选执行计划，即生成但未选择执行的执行计划。

根据 Benjamin Nevarez 的文章SQL Server 查询优化器：

候选执行计划的生成在查询优化器内部使用转换规则执行，启发式的使用限制了考虑的选择数量，以保持优化时间合理。候选计划在优化期间存储在内存中，称为备忘录的组件中。

是否有可能以显示实际执行计划的方式呈现候选计划？

这个问题带来了查询优化器在简单查询的现有谓词中选择不好的搜索谓词的情况。运行一些测试后，我得出的结论是，糟糕的决定是由于使用了本地临时表而不是全局临时表或常规表。

db fiddle：本地临时表、全局临时表、常规表。

我在临时表文档中找不到任何可以解释我们在使用本地临时表而不是全局临时表或常规表时看到的不同行为的特征。这有合乎逻辑的原因还是可能是错误？

愿意解决这个问题涉及到一个错误的值对is_media_read_only数据库属性我做了一些研究和试验，但最终我不能梳理一下究竟触发列的更新is_media_read_only上sys.database_files。

根据sys.database_files文档，该列is_media_read_only应具有以下两个可能值之一：

1 = 文件位于只读媒体上。

0 = 文件在读写介质上。

有了这些信息，我对两个不同版本的 SQL Server 进行了以下实验：

Microsoft SQL Server 2014 (SP3-GDR) (KB4505218) - 12.0.6108.1 (X64)
Microsoft SQL Server 2017 (RTM-CU16) (KB4508218) - 14.0.3223.3 (X64)

在我的笔记本（驱动器 E:) 中插入一个笔式驱动器并创建一个数据库，如下所示：

CREATE DATABASE [MyDB]
 ON  PRIMARY 
( NAME = N'MyDB_01', FILENAME = N'D:\DataBases\MyDB_01.mdf'), 
 FILEGROUP [SECONDARY] 
( NAME = N'MyDB_02', FILENAME = N'E:\DataBasesPendrive\MyDB_02.ndf')
 LOG ON 
( NAME = N'MyDB_log', FILENAME = N'D:\DataBases\MyDB_log.ldf')
GO

查询 sys.database_files： …

据我所知，SQL Server系统数据库总是具有相同的 ID，而且我在 Internet 上看到许多维护脚本依赖谓词WHERE database_id > 4将它们从脚本的操作中排除。

另外，如果我SELECT name, schema_id FROM sys.schemas;在新的用户数据库上运行，我会得到：

name                 schema_id
dbo                  1
guest                2
INFORMATION_SCHEMA   3
sys                  4
db_owner             16384
db_accessadmin       16385
db_securityadmin     16386
db_ddladmin          16387
db_backupoperator    16389
db_datareader        16390
db_datawriter        16391
db_denydatareader    16392
db_denydatawriter    16393

我在两个不同的实例上运行了该查询，一个是 SQL Server 2016，另一个是 SQL Server 2005，并且都返回了相同的结果。

问题：

1. 是否有任何情况（或 sql server 版本）系统数据库 master、tempdb、model 和 msdb 的 database_id 分别不是 1、2、3、4？
2. 我真的可以相信我列出的架构在任何 SQL Server 实例上都具有相同的 ID，以便我可以根据这些 ID 编写维护脚本吗？

在阅读了一篇日期为2012年的关于未记录的函数fn_dblog 和 fn_dump_dblog的文章后，我想知道如果它们已经存在很长时间并且非常有用，为什么它们仍然未记录且不受支持。与这篇2004 年的sp_msforeachtable 和 sp_msforeachdb文章相同。