数百个数据库 SQL Server 日志传送
SQL Server 2005 Standard 64x，目前有 300 多个微型数据库（每个 5MB），用户群根据需要添加数据库。想要为热备份实现日志传送，但不是通过向导，因为这看起来会为每个日志传送数据库添加 3 个作业（1 个在主数据库上，2 个在辅助数据库上）。
我是否尝试自己编写或使用 Quest 的 LiteSpeed 之类的东西？或者我是否对拥有数百个 SQL Server 代理作业并且所有这些作业都被解雇感到过于拘谨（或者更糟糕的是，我是否必须尝试对它们进行计时）？
欢迎所有建议。
SQL Server 2005 Standard 64x, with 300+ tiny databases currently (5MB each), user base adds databases as needed. Want to implement log shipping for warm standby, but not via the wizard, since that looks like it adds 3 jobs (1 on primary, 2 on secondary) for each log-shipped database.
Do I try to write my own or use something like Quest's LiteSpeed? Or am I being too squeamish about having hundreds of SQL Server Agent jobs and all of them firing off (or worse, would I have to try to time them)?
All advice welcome.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
由于您为每个用户提供了一个新数据库，因此我建议不要使用内置的 Lo Shipping。对于每个新配置的数据库，您必须添加新的日志传送会话、作业等等。
鉴于日志传送的核心（备份、复制、恢复、重复）确实微不足道，我会考虑从头开始构建自动化解决方案，减少作业（例如，一个作业循环备份、一份副本、一两次应用恢复） ）。
Since you provision a new database per user, I would advice against the built in Lo Shipping. With each newly provisioned db you'd have to add a new Log Shipping session, jobs and all that.
Given that Log Shipping is really trivial at it's core (backup, copy, restore, repeat) I would consider instead an automated solution build from scratch, with fewer jobs (eg. One job cycles through backups, one copyes , one or two aplly restores).
如果您正在管理数百个数据库，请购买一些能够自动执行所有操作并可靠地完成操作的产品。如果这意味着 Quest 的 LiteSpeed（我对它不熟悉），那就这样吧。您不想管理随之而来的所有工作，所以只需找到一些可以自动执行此操作的东西即可。如果你不让它自动化的话，你以后会自责的！
If you're managing hundreds of databases, buy some product that automates it all and does it reliably well. If that means Quest's LiteSpeed (I'm unfamiliar with it), then so be it. You do NOT want to manage all of the jobs that would come with this, so just find something that automates it by itself. You'll be kicking yourself in the butt later if you don't have it automated!
这是日志传送的一种非常糟糕的使用。 300 个日志文件，每个小文件每隔 15 分钟发送一次？如果日志备份间隔大于 15-30 分钟，那么可以说它并不重要。
我真的会考虑数据库镜像是“少工作”还是完全集群。就价格而言，数据库镜像胜出。
高可用性概述（SQL Server 2008，但也适用于 '2005）
后期编辑：
2 篇有关镜像和线程的文章
这可能不相关，但无论如何都是值得了解的好东西。
This is a very poor use of log shipping. 300 log files, each tiny being shipped every, what, 15 minutes? If the log backup interval is greater then 15-30 mins then it isn't critical, arguably.
I really would consider database mirroring which is "job less" or full clustering. For cheapness, database mirroring wins.
High availability overview (SQL Server 2008 but applies to '2005 too)
Late edit:
2 articles on mirroring and threads
This might not be relevant, but good stuff to know anyway.