SQL Server 表触发器每秒可以处理多少事务?如果我有一个每秒插入 1,000 次的高度事务性表,该表上的插入触发器是否可靠地每次触发?
我有一个几乎 2 TB 大小的 SQL Server 数据库,它有带有图像数据类型的表。现在差异备份的大小与完整备份的大小相同。图像数据类型对此有什么影响吗?或者我错过了什么。
我们已经在生产中遇到了几次问题,它看起来像一个存储过程获得了一个新的、糟糕的计划并开始造成严重破坏。不幸的是,在执行 dbcc freeproccache 之前,我们无法捕获之前和之后的计划以查看不良计划的情况,我们也没有设置查询存储。
我的问题是,什么会导致 sql server 为存储过程生成新计划?特别是对于一直运行的 sp。我知道的一些是:
我正在使用许多严重缺乏备份的不同服务器。
我想使用简单模式实施备份计划,每周进行一次完整备份,然后在一周内进行一系列差异备份。
通过覆盖同一文件来执行完整备份和差异备份是否可行?我再次尝试限制使用的存储量,根据我的理解,如果我在某个时间间隔进行差异备份,则数据是累积的,因此只需要最新的 .dif 文件和完整的 .bak 文件。因此,每次执行差异备份时,它都会覆盖之前的备份。这是安全的还是我误解了一些重要的东西?
我必须对数据库进行未加密的完整备份,以便将其发送给其他团队,然后他们可以在自己的环境中恢复它。另一个团队有不同的环境和不同的 SQL Server 证书。
我的完整备份服务器设置是进行AES 128加密备份。而且我不打算与其他团队共享解密密钥和证书。我的 SQL Server 版本是 Standard 2014 SP2。
我见过加密备份,但我还没有遇到过这种情况。有没有人遇到过这种类型的场景。任何帮助将不胜感激。
编辑 -
就我而言,所有 SQL Server 数据库备份都使用自签名证书进行加密。此证书安装在所有服务器上,因此只需管理一个证书。如果证书过期,则需要续订,因为备份将不会使用过期的证书运行。此外,需要加载证书和私钥以恢复使用密钥对创建的备份。
这是我不打算与其他团队共享的证书和私钥。因此,需要可以绕过证书加密的仅复制完整备份。有什么办法,我可以通过创建一个不需要加载证书和私钥的备份来解决上述情况。
按照learning-dbadmin 的要求添加查询的输出-
我们正在尝试定义备份策略。我们打算申请以下内容:
但我们也在探索其他选项 - 事务日志备份和 Azure 备份(默认为 2 小时)
我是否正确地说差异备份会让我们到达上次差异备份,然后我们可以使用日志备份来接近我们想要恢复的位置?
因此,备份将如下所示:
自星期三以来每 2 小时 Inc - 日志备份。
让我们说灾难在周三中午来袭!
恢复差异,让我们在星期三凌晨 1 点...然后我们使用日志备份让我们在灾难发生之前到达。
这是类型之间的正确区分吗?
目标:想要创建一个所谓的“SQL 语句层”来检查/过滤所有传入的查询。如果传入的查询无效,则应拒绝。
用例:限制数据库访问并避免不可恢复的查询。在多个应用程序中没有关于相同“触发器或过程”(集中式)的重复代码。
迄今为止的研究:
描述:我站在一个新项目前,我们想限制和最小化对数据库的访问。例如:开发者可以DROP在应用层内部创建一个查询,但是数据库会拒绝这个查询,因为DROP查询是不允许的。
几年前我与 Laravel 一起工作,并在应用程序层内完成了大部分“程序和触发器”工作,例如控制器,而不是使用 Mutator 或 Accessor。现在我们希望将其减少到尽可能低的级别,以避免在不同的应用程序中出现像 Mutator 和 Accessor 这样的重复代码。
问题:Grants 和存储过程是唯一的方法吗?如果不是,是哪些?
我有一个特殊的情况让我使用SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED. (我sp_getapplock用来确保单个进程访问给定的行。)
我正在尽力避免任何类型的锁定升级。我清楚地知道ISOLATION LEVEL READ UNCOMMITTED读取有什么作用,但我不确定删除。
我看到用做删除一些示例代码ROWLOCK和READPAST,连同ISOLATION LEVEL READ UNCOMMITTED但我是没有什么,会做明确的,所以我也没有一直在使用它了。
这是否需要防止我的删除锁定升级或就ISOLATION LEVEL READ UNCOMMITTED足够了?
就像我想问的那样,假设我们使用 GUI 或 T-SQL 运行完整备份,SQL Server 会备份哪个文件,即仅备份数据文件或日志文件。
我已经读过它也需要 SQL Server 的活动事务部分(日志文件)。请确认。
如果是,那么当时正在运行并随后提交的事务会发生什么,该事务的日志是否会在备份时出现。
如果数据库失败,sql server 将如何恢复到它。
我的集群的两个节点中都运行着 Windows Server 2019 和 SQL Server 2019。在我的情况下,没有证人一切正常。我需要 Windows Server 故障转移群集 (WSFC) 用于我用作 DR 解决方案的可用性组。
当两个节点都运行时,我将关闭一个节点(它具有我的 AG 的主数据库)并从另一个节点执行可用性组的故障转移,反之亦然。有人可以解释为什么我们需要在两个节点故障转移集群中的见证,或者我如何重新创建我们需要见证的场景。