SQL Server 2008 与 SQL Server 2008 Express 大小
我将 SQL Server 数据库(源)迁移到 SQL Server Express 数据库(目标)。在 SSMS 中使用“生成脚本...”。
我验证了源数据库中的表(使用 3 个最大的表进行测试)是否具有与 Express 相同的行数,并且所有看起来都正常。
我执行了sp_spaceused
,发现原来的数据库大小是16MB,而Express版本是4MB。
Express DB 使用的空间是否较少,或者这是否表明迁移出现问题?
谢谢
I migrated a SQL Server database (source) into a SQL Server Express database (destiny). Used "generate scripts..." in SSMS.
I verified if the tables (tested with the 3 biggest tables) in the source DB had the same number of rows has the Express and all looked OK.
I executed sp_spaceused
and found that the original database size is 16MB, while the Express version is 4MB.
Does the Express DB uses less space or is this a sign that something went wrong with the migration?
Thank you
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
原因很简单。当您迁移数据时,您正在执行非常干净、有序的插入。没有垃圾数据,没有删除的记录,没有空的未使用的页面等。
此外,如果您曾经从原始数据库中删除了列(包含数据),则数据不会被删除,只是标记为不可用 - 这又会占用空间。
缩小数据库将恢复一些空间,如果包含移动数据页选项,它甚至会进一步打包数据。但请检查删除的列并重建这些表。
http://www.simple-talk .com/community/blogs/andras/archive/2009/02/19/72068.aspx
The reason is simple. When you migrated data, you are doing a very clean, ordered insert. There is no junk data, no removed records, no empty unused pages etc.
Also, if you have ever dropped columns (containing data) from the original database, the data is not removed, just marked as unusable - that again takes up space.
Shrinking the database will recover some space, if you include the move data pages option, it will even pack the data further. But do check for dropped columns and rebuild those tables.
http://www.simple-talk.com/community/blogs/andras/archive/2009/02/19/72068.aspx
Sql Server 引擎将根据自己的需要扩展文件的大小。例如,源数据库中某一时刻的数据可能比当前多。我敢打赌,如果您在源数据库上运行收缩数据库命令,您会发现文件大小相同/相似。简而言之,文件大小的差异并不表明出现了问题。
The Sql Server engine will expand the size of the file as required for its own means. For example, you may have had more data in the source database at one point than it currently has. I would bet if you ran a shrink database command on the source DB, you would find that the file size is the same / similar. So in short, no, the difference in file size is not an indication something went wrong.