ms sql数据库周期性写入时间戳的实现
任务：
每秒将时间戳写入 MS SQL 数据库表。
解决方案：
- 按计划写入时间戳的外部应用程序（例如 Sql 代理）。
- 存储过程，在无限循环中写入时间戳。
问题。
- 哪种解决方案最好？
- 在存储过程中运行无限循环有什么缺点吗？
- 服务器重启后如何启动存储过程？
- 还有其他解决方案吗？
Task:
Write timestamps into MS SQL database table every second.
Solutions:
- External application which writes timestamps by schedule (Sql agent for example).
- Stored procedure, which writes timestamps in infinite loop.
Questions.
- Which of the solutions is best?
- Is there any drawbacks of running infinite loop in stored procedure?
- How to start stored procedure after server reboot?
- Any other solutions?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
WAITFOR DELAY的存储过程路由，WAITFOR DELAY1、两者各有优缺点。根据您的环境进行评估和选择
程序优点：
- 没有 SQL 代理每秒处理一次的开销。 （事实上，我不认为你可以让 SQL Agent 持续每秒启动一次相同的作业。）
- 我不认为 WAITFOR 模式下的过程正在使用资源 - 但您想检查
过程缺点：
- 如果程序失败（以某种方式停止），它将不会启动。 （除非您正在运行 SQL 代理作业来检查过程是否已停止，在这种情况下不妨继续该过程）
- 可能比您想象的更容易停止/中断（并发/死锁、分离的数据库、维护期间手动停止然后忘记重新启动）
工作优势：
- 如果作业失败（可能数据库不可用），下一个作业仍将启动
作业缺点：
- 看起来很笨拙，让 SQL 代理每秒运行一次。如果执行此操作，请测量所需的服务器开销。
- 如果 SQL 代理失败或停止，作业将不会运行
建议：必须是每秒一次吗？可以是每 5、10、15 或 30 次吗？
2、除了上面提到的以外，不应该有。确保您不会遇到锁定、阻塞或死锁情况！
3，就像@gbn所说，sp_procoption
4，没有什么不涉及基于悲观锁定技术的繁琐技巧，或基于时间戳（不是日期时间）数据类型的拜占庭逻辑。最好的解决方案似乎是将这两个数据库合并为一个的长期解决方案，但这不是一个短期选择。
出于纯粹的偏执，我将两者结合起来，如下所示：
1, Both have advantages and disadvantages. Evaluate and choose based on your environment
Procedure Advantages:
- Don’t have overhead of SQL Agent processing once per second. (In fact, I don't think you can get SQL Agent to consistantly launch the same job once per second.)
- I don’t think a procedure in WAITFOR mode is using resources – but you’d want to check
Procedure Disads:
- If procedure fails (gets stopped somehow), it won’t start up. (Unless you have a SQL Agent job running to check if the procedure has stopped, in which case might as well go with the procedure)
- Might be easier to stop/break than you’d think (concurrency/deadlocks, detached DBs, manually stop during maintenance then forget to restart)
Job Advantages:
- If job fails (perhaps db is unavailable), next job will still get launched
Job Disads:
- Seems very kludgy, having SQL agent run every second. Measure required server overhead if you do this.
- If SQL Agent fails or is stopped, job won’t run
A suggestion: must it be once per second? Can it be once per 5, 10, 15, or 30?
2, Shouldn’t be any, barring what’s mentioned above. Make darn sure you can’t hit locking, blocking, or deadlock situations!
3, Like @gbn says, sp_procoption
4, Nothing that doesn’t involve cumbersome tricks based on pessimistic locking techniques, or byzantine logic based on the timestamp (not datetime) datatype. The best fix would seem to be the long-term one of combining those two databases into one, but that’s not a short-term option.
Out of sheer paranoia, I'd combine the two like so:
尝试使用 SQL Service Broker 异步执行此操作，即使必须重新启动 SQL Server 服务，它的队列系统也允许您不会错过任何数据。我曾经在这种轮询场景中使用过它。
http://msdn.microsoft.com/en -us/library/ms345108(SQL.90).aspx#sqlsvcbr_topic2
这可能会有所帮助，
http://msdn.microsoft.com/en-us/library/bb839488。 ASPX
Try using SQL Service broker to do this asynchronously and its queue system allows you to not miss any data even if the SQL Server service would have to be restarted. I ve used this once sometime back for this kind of polling scenario.
http://msdn.microsoft.com/en-us/library/ms345108(SQL.90).aspx#sqlsvcbr_topic2
This might help,
http://msdn.microsoft.com/en-us/library/bb839488.aspx