在 SQL Server 2008 上使用 sqlalchemy 等待数据库恢复完成
我正在尝试在开发过程中自动执行数据库恢复,在 SQL Server 2008 上使用 TSQL,使用 sqlalchemy 和 pyodbc 作为传输。
我正在执行的命令是:
"""CREATE DATABASE dbname
Restore database dbname FROM DISK='C:\Backups\dbname.bak' WITH REPLACE,MOVE 'dbname_data' TO 'C:\Databases\dbname_data.mdf',MOVE 'dbname_log' TO 'C:\Databases\dbname_log.ldf'"""
不幸的是,在 SQL Management Studio 中,代码运行后,我看到数据库仍处于“正在恢复...”状态。
如果我通过管理工作室恢复,它就可以工作。如果我使用子进程调用“sqlcmd”,它就可以工作。 pymssql 在身份验证方面存在问题,甚至还没有做到这一点。
可能出了什么问题?
I'm trying to automate my db restores during development, using TSQL on SQL Server 2008, using sqlalchemy with pyodbc as a transport.
The command I'm executing is:
"""CREATE DATABASE dbname
restore database dbname FROM DISK='C:\Backups\dbname.bak' WITH REPLACE,MOVE 'dbname_data' TO 'C:\Databases\dbname_data.mdf',MOVE 'dbname_log' TO 'C:\Databases\dbname_log.ldf'"""
Unfortunately, the in SQL Management Studio, after the code has run, I see that the DB remains in state "Restoring...".
If I restore through management studio, it works. If I use subprocess to call "sqlcmd", it works. pymssql has problems with authentication and doesnt even get that far.
What might be going wrong?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
BACKUP 和 RESTORE 语句异步运行,因此它们在继续执行其余代码之前不会终止。
使用 while 语句,如 http://ryepup.unwashedmeme.com/blog/2010/08/26/making-sql-server-backups-using-python-and-pyodbc/ 为我解决了这个问题:
The BACKUP and RESTORE statements run asynchronously so they don't terminate before moving on to the rest of the code.
Using a while statement as described at http://ryepup.unwashedmeme.com/blog/2010/08/26/making-sql-server-backups-using-python-and-pyodbc/ solved this for me:
无法重现直接从 pyodbc(没有 sqlalchemy)恢复的问题,执行以下操作:
一些需要澄清的问题:
感谢 geographika 提供的Cursor.nextset() 示例!
Unable to reproduce the problem restoring directly from pyodbc (without sqlalchemy) doing the following:
Some questions that need clarification:
Thanks to geographika for the Cursor.nextset() example!
对于 SQL Alchemy 用户,感谢 geographika 的回答:我最终使用了“原始”DBAPI 连接 来自连接池。
它与 geographika 的解决方案完全相同,但有一些额外的部分:
For SQL Alchemy users, and thanks to geographika for the answer: I ended up using the “raw” DBAPI connection from the connection pool.
It is exactly as geographika's solution but with a few additional pieces:
五件事解决了我的问题,具有相同的症状。
发现我的 test.bak 文件包含错误的 mdf 和 ldf 文件:
<前><代码>>>> cursor.execute(r"从磁盘恢复文件列表 = 'test.bak'").fetchall()
[(u'WRONGNAME', u'C:\\Program Files\\Microsoft SQL ...),
(u'WRONGNAME_log', u'C:\\Program Files\\Microsoft SQL ...)]
创建了一个新的 bak 文件并确保设置
仅复制备份
选项< /p>为我的连接设置自动提交选项。
仅将connection.cursor用于单个RESTORE命令,仅用于单个RESTORE命令,
将
test_data
MOVE更正为在我的 RESTORE 命令中进行测试
(由 @beargle 提供)。Five things fixed my problem with identical symptoms.
Found that my test.bak file contained the wrong mdf and ldf files:
Created a new bak file and made sure to set the
copy-only backup
optionSet the autocommit option for my connection.
Used the connection.cursor only for a single RESTORE command and nothing else
Corrected the
test_data
MOVE totest
in my RESTORE command (courtesy of @beargle).