我曾经在一家拥有第三方数据仓库解决方案的公司工作。显然所有的对象和表都隐藏在支持数据库中,所以我不清楚某些存储过程中究竟发生了什么。我在那里看到了这个有趣的存储过程,并想在我自己的解决方案中复制它,但我无法理解它是如何工作的。我正在描述下面的存储过程,如果有人能给我一些关于如何实现这一点的想法,这将非常有帮助。如果你能建议我如何使这更好,那就更好了。
存储过程被称为进程日志。它有 DBID、ObjectId、Step、Status、Remarks、Reads、Inserts、Updates、Delete 等参数
我们要做的是,在每个存储过程中,我们必须执行这个存储过程,状态为 2(进行中)在增加值后,在每个步骤或部分结束时可以多次执行这个存储过程的过程的可变步长。根据插入更新选择和删除语句的行数,我们应该在各自的存储过程参数变量中记录值。最后,您可以执行状态为 3(已完成)的相同存储过程,或者如果该过程在 catch 块中结束,状态将为 4(失败)在备注部分,我们可以复制 SQL 的错误消息。
为了查看所有这些信息,我们获得了一份报告的访问权限,显然我没有源代码,但报告显示了存储过程完成的时间,状态是多少插入更新删除和读取它做过。如果失败,错误信息是什么?
我已经有一些改进存储的想法,谁开始的?,参数的值是多少?对于谁开始存储过程部分,我有一个困惑。大多数这些存储过程作为不同作业的一部分运行。我们所有的作业都以服务帐户用户身份运行,但作业由不同的用户手动启动。我需要找出哪个用户启动了它,作为内部存储过程,作为当前用户,它将始终显示服务帐户。同样对于参数值,是否有更好的动态方法来找出这一点?而不是手动设置变量的值。我想使用 INPUTBUFFER 的输出,但它只显示参数的名称而不是值。
如果有人可以指导我有关此审计 SP 的后端表结构和脚本,那将非常有帮助。也欢迎任何更多的改进想法。
我的主要困惑:我相信他们有一些存储这些存储过程值的表,如果 SP 已经在运行,他们会在记录中进行更新,然后进行插入,但是他们如何识别在场景中进行插入而不是更新其中存储过程严重失败并且未执行 catch 块。
audit stored-procedures architecture sql-server-2014 logging