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?
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: