XACT_ABORT_ON 的代码示例:
SET XACT_ABORT_ON;
BEGIN TRY
BEGIN TRANSACTION
//do multiple lines of sql here
COMMIT TRANSACTION
END TRY
BEGIN CATCH
IF (@@TRANCOUNT > 0) ROLLBACK;
//may be print/log/throw error
END CATCH
Run Code Online (Sandbox Code Playgroud)
由于 XACT ABORT 为 ON,任何错误都会自动回滚事务。那么 TRY CATCH 块有什么作用呢?
我知道 varchar(max) 和 nvarchar(max) 允许保存最多 2GB 的数据,但这与这个问题无关。
一个页面 8KB = 8192 字节
在 varchar 中,1 个字符就是 1 个字节。而在 nvarchar 中,1 个字符是 2 个字节。
varchar 允许有 8000 个字符(8000 字节)。而 nvarchar 允许有 4000 个字符(8000 字节)。
这是因为页面大小是 8192 字节吗?
假设应用程序已与 SQL\xc2\xa0Server 建立了两个连接。
\n通过任务管理器终止此应用程序是否会终止两个 SQL 连接?
\n我对 SQL Server Always On 的理解有些担忧。请您在需要时纠正我(概念上):
Always On 集群和 Always On 可用性组是 2 个独立的概念。集群是一种 HA 解决方案,而 AG 是一种 DR 解决方案。Always On 群集是否与 Windows 服务器群集相同?
要创建 Always On 群集 - 我们必须启动安装程序并选择“新 SQL Server 故障转移群集安装”,然后在每个新节点上我们需要启动安装程序并选择“添加节点”。集群(有多个节点)在IP地址方面作为一个单元运行,因此应用程序只指向一个IP,如果发生实例崩溃,则故障转移由集群技术处理,不需要更改应用程序IP。此外,用户/登录名是同步的,并且在故障转移的情况下将继续工作。这不能防止磁盘故障,因为所有节点共享同一个磁盘。
假设我们已经有一个 SQL Server 实例(比如服务器 A),那么要为此创建 Always On Clustering,我们需要执行与上述相同的步骤(创建新的故障转移集群安装),然后将服务器 A 添加为节点。对?
假设我们有一个新的 SQL Server 实例(没有 HA/DR)并且计划只配置 AG,那么我们首先需要确保在每个参与节点上启用“故障转移群集”窗口功能。然后右键单击 SQL Server 服务并启用“Always on Availability Groups”。然后在服务器实例上,我们创建 AG 并将数据库配置到组中。这确保了数据库级别的可用性,但是如果发生故障转移,则登录将不再起作用(孤立)。没有共享磁盘,因此主服务器的磁盘崩溃不会导致辅助服务器数据库出现任何问题。此外,客户端应用程序将指向侦听器 IP,侦听器将确保应用程序使用适当的工作服务器。对?
在上述场景中,启用了“故障转移群集”窗口功能,因此群集是 AG 的先决条件吗?Point 2 和 Point 4 中聚类的概念是否相同。
如果我希望使用 Always On (AG) 和故障转移群集配置 HA/DR,那么最佳做法是遵循第 2 点然后是第 4 点还是相反的方式?另外,我们是否应该同时使用虚拟集群名称和监听器,或者如果足够,我们应该使用其中之一吗?
“SQL Server 故障转移群集安装”和 Windows …
我正在研究使用 NOLOCK SQL 从一个活跃使用的数据库加载数据到报告数据库中的危害。我知道使用 NOLOCK 存在问题,但我正在考虑使用下面解释的策略来应对这些问题。
我知道有更好的方法,如日志传送、复制、镜像、AG、集群来拥有副本数据库,但这些不是这个问题的重点。
目标数据库有一个保存 LoadDate 的历史表。每 10 分钟,调度程序根据时间戳运行带有 WHERE 子句的 SELECT 查询(使用 NOLOCK)来获取数据,将其转储到临时表中,删除重复项(如果有)(保持最新)并将其合并到目标表中。
当 SELECT 查询运行时,SELECT 查询中使用的两个表可能会同时修改,但联接条件的列值不会更改。
伪代码示例:
DECLARE @LASTLOADDATE=SELECT MAX(LOADDATE) FROM HISTORYTABLE;
DECLARE @CURRENTDATE=GETDATE();
SELECT C1,C2,C3
FROM TBL1 T1 WITH(NOLOCK)
JOIN TBL2 T2 WITH(NOLOCK) ON T1.ID=T2.T1_ID
WHERE T1_TIMESTAMP>@LASTLOADDATE AND T1_TIMESTAMP<=@CURRENTDATE
//There is no index on timestamp column but an index may be added in the future
INSERT THE ABOVE RECORDS INTO STAGING TABLE
REMOVE DUPLICATES
MERGE DATA FROM STAGING TABLE INTO TARGET TABLE
INSERT INTO …Run Code Online (Sandbox Code Playgroud) 假设执行多表连接的 SELECT 查询,结果选择了 100000 行。连接操作将在内存中执行,结果也将保存在内存中,直到客户端(例如 - ssms)消耗整个结果?
一旦客户端使用了结果,SQL Server 是否会从内存中清除查询结果?
当执行查询时,SQL Server将产生一个查询计划列表,并启发式地选择成本较低的计划。
所选择的计划将存储在计划缓存中,以供后续看到相同查询时使用。
当表的某些属性发生变化或者重建索引时,它会再次产生一个查询计划列表,并启发式地选择一个成本较低的查询计划,并将其存储在计划缓存中。
但是,MSDN 似乎表明估计计划存储在计划缓存中,请参见下面的屏幕截图。那是对的吗?
我有一个新的 SQL Server 2019 本地实例。假设客户端是 SQL Server Management Studio 或任何其他应用程序:
Active Directory 身份验证被认为更安全,因为 SQL Server 身份验证允许在通过网络传递时以纯文本形式查看登录信息。
据我所知,索引查找允许服务器通过查找索引快速转到所需的页面,因此无需将查询表的所有页面从磁盘读取到内存中即可获得好处。
这个问题假设:
rate>100rate)。在这种情况下,我的问题是,对于使用相同 WHERE 子句 ( rate>50) 对该表进行的后续查询,SQL 引擎将对已驻留在内存中的页面执行表扫描。rate当整个表位于内存中并且不需要访问磁盘时,列上是否有索引对第二个查询有任何好处吗?
我们配置了完整备份和日志备份。
在恢复过程中,我们应用完整备份和后续日志备份。
我知道,如果我进行手动完整备份(非仅复制模式),那么它将破坏差异链。但在本例中没有差异备份。然而,存在事务日志链。由于仅非复制完整备份,该链是否会受到负面影响?
sql-server ×10
backup ×1
clustering ×1
concurrency ×1
failover ×1
index ×1
nolock ×1
plan-cache ×1
restore ×1
security ×1
t-sql ×1
transaction ×1