Practical Service Broker

SQLServerCentral is supported by Red Gate Software Ltd.

Popular Topics

Home

Members

Calendar

Who's On

Home » Career » Presentations and Speaking » Practical Service Broker

Practical Service Broker

Rate Topic

Display Mode

Topic Options

Author

Message

Chad Crawford

Posted Tuesday, July 24, 2012 4:55 PM

SSCrazy

Group: General Forum Members
Last Login: Today @ 3:52 PM
Points: 2,549, Visits: 17,363

I'm putting together a Service Broker presentation for the local users group and hoping to submit it to a SQL Saturday as well. I would appreciate any feedback on content, phrasing, or whatever else you see that might make it better. Thanks!

SQL Server Service Broker is a messaging framework built into the SQL Server engine. It enables SQL Server to handle messaging between servers and applications with light setup and overhead. The flexibility of the framework enables Service Broker to queue event notifications, task execution requests or other messages while leveraging the strength of SQL Server transaction management, reliability and recoverability. In this session we will see how Service Broker can be used to:
--Interact with an external 3rd party application asynchronously
--Implement a low-impact audit log solution
--Scale out a task to multiple servers
--Throttle large batch processes

Thanks,
Chad

Edited, incorporated suggested changes

Post #1334835

Evil Kraig F

Posted Tuesday, July 24, 2012 5:30 PM

SSCertifiable

Group: General Forum Members
Last Login: Today @ 5:44 PM
Points: 5,677, Visits: 6,124

Chad, you might want to include a piece on how limiting the # of activations can allow for lowering the impact of multiple high-impact bulk work simultaneously requested, so it can be spread out over a longer time when the changes are non-critical.

An example of this could be only loading 1000 rows from a mid-day production file load at a time so you don't completely lock the system down with computations and the like, especially when the first file isn't even completed before the second one comes in. Smile

It's probably one of the best features of the asynchronous queues I've found to help with load balancing.

- Craig Farrell

Never stop learning, even if it hurts. Ego bruises are practically mandatory as you learn unless you've never risked enough to make a mistake.

For better assistance in answering your questions | Forum Netiquette
For index/tuning help, follow these directions. |Tally Tables
Twitter: @AnyWayDBA

Post #1334842

Chad Crawford

Posted Wednesday, July 25, 2012 8:49 AM

SSCrazy

Group: General Forum Members
Last Login: Today @ 3:52 PM
Points: 2,549, Visits: 17,363

Oh yes, good call - that is an excellent business case to draw out. How does "Throttle large batch processes" sound as a short description?

I do love how SB will spin up new activations to handle larger loads, or by suppressing it you can reduce the task impact. I knew that if things ever got pushed to the wire during a particularly heavy load I could shut off activation until things calmed down and let it slowly catch back up later when the server cooled off.

Thanks Craig, anything else you would change?

Post #1335184

Evil Kraig F

Posted Tuesday, July 31, 2012 1:45 PM

SSCertifiable

Group: General Forum Members
Last Login: Today @ 5:44 PM
Points: 5,677, Visits: 6,124

Heya Chad.

Sorry, came down very sick for a week, haven't reviewed a thing for a while.

The other primary reason I like SB vs. other messaging apps is the fact that the queues (at least when kept to the same database) persist via the log. If you have to do a point in time restore, you don't end up desynced like you would from an external messaging queue, like MS Queue. I've used that to argue against external Queues before.

If you have to go cross database, however, it won't matter in the end, so then they can stick with what they've got if it already exists.

Otherwise, looks good. :)

Post #1338144

« Prev Topic | Next Topic »

Permissions