在使用 SQL2005 的日志传送配置中，未添加主服务器的备份作业
我正在两个 sql server 2005 实例之间创建日志传送配置。 我正在传送单个数据库的日志，并且我没有使用监视器服务（暂时）。 当我在数据库上运行 SQL Server 日志传送向导时，脚本按预期执行并声称没有错误。 但是当它完成时，辅助服务器具有正确的作业列表（复制/恢复），但我认为主服务器应该具有“备份”作业。 事实并非如此。
所以它要么默默地失败，要么我误解了日志传送的工作原理。 有谁知道a）是否应该向主服务器添加一个作业，b）如果应该有一个作业，那么未添加该作业的可能原因是什么？
谢谢。
I'm creating a log shipping configuration between two sql server 2005 instances. I'm shipping the logs of a single database and I'm not using a Monitor service (for the time being). When I run the SQL Server Log Shipping Wizard on the database, the script executes as it should and claims there are no errors. But when it's complete, the secondary server has the correct list of Jobs (copy/restore) but the primary server, I think, should have a "backup" job. It doesn't.
So it's either failing silently or I'm misunderstanding how log shipping works. Does anyone know a) if there should be a job added to the primary server and b) if there is supposed to be a job, what some of the likely causes for it not being added might be?
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
事实证明，无提示故障是由于辅助服务器实际上是一个虚拟机，并且是主服务器的克隆而引起的。 即使我更改了计算机名称和 sql 服务器名称。 我猜测还有其他东西可以识别未更改的实例，这导致了失败。 但这只是一个猜测。
It turns out that the silent failure was being caused by the fact that the secondary server was actually a virtual machine that was a clone of the primary server. Even though I had changed both the computer name and the sql server name. I'm guessing there's something else that identifies the instance that was not changed and this was causing the failure. That's just a guess, though.