测试具有从 SQL 2000 到 2005 的数据库迁移的 Web 应用程序的提示

发布于 2024-08-09 07:32:19 字数 110 浏览 2 评论 0原文

我正在测试 Web 应用程序(具有用户、内容项、报告、分配...的电子学习),该应用程序具有从 SQL 2000 到 2005 的数据库迁移。

如果有人知道我应该重点测试哪些领域,请告诉我。

im testing web application(e-learning which having users, content items, reporting,assigning ...) which had a DB migration from SQL 2000 to 2005.

If somebody knows what are the area i should focus on testing Please let me know.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

谷夏 2024-08-16 07:32:19

从 DBA 的角度以及 SQL Server 性能(因此也是应用程序)的角度来看,如果您使用备份的数据库还原或 SQL 2000 的复制数据库向导将数据库迁移到 SQL Server 2005,那么您将需要以确保您更新数据库统计信息。

这是因为 SQL Server 2005 中的数据库引擎和查询优化器的行为与 SQL 2000 不同。必须更新数据库统计信息以确保新环境中的最佳性能。

摘自SQL Server 联机丛书

为了确保最佳性能
升级数据库,运行 sp_updatestats
(更新统计数据)
SQL Server 上升级的数据库
2005年服务器。

一旦您验证了您的应用程序正常运行,我就会建议您通过识别性能最差的查询来进行性能调优。

From a DBA's point of view and so a SQL Server Performance (and therefore also an application) perspective, if you migrated your database to SQL Server 2005 using a database restore of a backup or the Copy Database Wizard from sql 2000, then you will want to ensure that you update the database statistics.

This is because the both the database engine and the query optimizer in SQL Server 2005 behave differently to SQL 2000. Your database statistics must be updated in order to ensure optimal performance in the new environment.

Taken from SQL Server Books Online:

To ensure optimal performance of an
upgraded database, run sp_updatestats
(update statistics) against the
upgraded database on the SQL Server
2005 server.

Once you have validated that your application is functioning correctly, I would then recommend conducting a performance tuning exercise by identifying your poorest performing queries.

森罗 2024-08-16 07:32:19

您应该测试应用程序的所有主要区域(管理、最终用户测试等)。如果应用程序之前经过测试,您应该有一些应该遵循的测试计划。你永远不知道哪一部分会受到影响,所以最好进行全面的测试。

You should test all main areas of the application (administration, end user testing etc.). If the application was tested before you should have some test plans that you should follow. You never know which part might be affected, so it would be better to have a comprehensive testing.

喜爱皱眉﹌ 2024-08-16 07:32:19

我突然想到的一件事是,SQL 2000 支持分别用于 LEFT OUTER JOIN 和 RIGHT OUTER JOIN 的简写运算符“*=”和“=*”。 SQL 2005 不再支持它们。这意味着您必须根据具体情况将这些运算符替换为“LEFT OUTER JOIN”或“RIGHT OUTER JOIN”。

但正如 rslite 所说,您应该测试整个应用程序以确保没有任何失败。

Off the top of my head, one thing I can think of is that SQL 2000 supported the short-hand operators '*=' and '=*' for LEFT OUTER JOIN and RIGHT OUTER JOIN respectively. SQL 2005 no longer supports them. This means that you'll have to replace these operators with 'LEFT OUTER JOIN' or 'RIGHT OUTER JOIN' as the case may be.

But as rslite says, you should test the entire app to ensure that nothing fails.

宛菡 2024-08-16 07:32:19

您没有说明您的网络应用程序使用什么编程语言,这可能是相关的。

无论如何,您需要确定您正在执行的涉及数据库的不同操作:

  • 简单读取(检查您在整个应用程序中是否具有相同类型的选择,例如,您是否始终仅向前打开结果集,或者您是否使用可滚动结果集等)
  • 复杂读取(您是否读取大量数据,您是否随时读取 blob 等)
  • 插入(例如检查批量插入或任何可能会给数据库带来大量负载的插入)
  • 更新(可能会在某些表上加锁,因此如果 MS 端发生任何更改,则会出现并发问题或语法问题)

如果您的应用程序统一处理这些类型的操作,则每种类型的几个测试应该足够了,但您应该仔细检查代码中是否有任何可能导致不同行为的内容,并测试这些部分。

您还需要检查有关数据类型更改、sql 更改的 SQL 2005 文档,并在代码中验证是否有影响并重新测试这些部分。

希望这有帮助。

You're not saying what programming language are you using for your web application, this might be relevant.

Anyway you need to identify the different operations you're doing that concern the database :

  • simple reads ( check if you have the same type of selects all over the app, are you opening result sets always forward-only for instance, or do you use scrollable result sets, etc. )
  • complex reads ( do you read large amounts of data, do you read blobs at any moment, etc. )
  • inserts ( check for bulk inserts for instance or any insert that can put a lot of load on the db )
  • updates ( might put locks on some tables hence concurrency issues or problems with syntax if anything has changed on MS side )

If these kinds of operations are treated uniformly by your app, a couple of tests of each type should be enough, but you should check carefully the code for anything that can result in a different behavior and test those parts as well.

You'll also want to check the SQL 2005 documentation regarding changes in datatypes, sql changes and verify in your code if there's an impact and re-test those parts.

Hope this helps.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文