NHibernate + Oracle:查询数据时的速度问题

发布于 2024-10-05 08:42:42 字数 1207 浏览 1 评论 0原文

我们有一个 WCF 应用程序,它使用 NHibernate 从数据库查询数据。将应用程序安装到新的测试环境后,我们面临一些查询性能问题。我们的新旧环境使用不同的 Oracle 服务器,但两个数据库具有相同的数据。

我们检查了 NHibernate 日志并确定了有问题的部分:

2010-12-02 07:14:22,673 NHibernate.SQL                 - SELECT this_.CC...
2010-12-02 07:14:22,688 NHibernate.Loader.Loader       - processing result set
2010-12-02 07:14:27,235 NHibernate.Loader.Loader       - result set row: 0

在本例中,查询返回一行。但在我们的新环境中,“处理结果集”似乎比在其他环境中花费的时间要长得多(5 秒 vs 0.5 秒)。有没有什么方法可以准确地找出“处理结果集”中的内容花费了这么长时间?

注意。使用 Toad 直接在数据库中执行相同的查询不会重现该问题。 使用 Toad,两个数据库服务器都同样快。

我们使用 DetachedCriteria 创建查询,然后执行如下:

        Dim criteria As ICriteria = crit.GetExecutableCriteria(GetSession())
        Return New Generic.List(Of T)(criteria.List(Of T))

NHibernate 的版本是 2.1.2.4,我们使用 ActiveRecord 2.1.0创建映射。 Oracle 服务器的版本为 10g。

因此,在我们的例子中,我们有两个环境,它们具有相同版本的应用程序和相同的配置文件,并且正在查询相同的数据库,但它们具有不同的应用程序和 Oracle 服务器。 在一个环境中,通过 NHibernate 进行查询大约需要 5.5 秒,而在另一个环境中则需要 0.5 秒。结果是一致的,并且相同的查询已在这两种环境中执行了大约 50 次。

Oracle 配置中是否存在某些内容可能会导致其与 Niberate 出现异常行为?有没有办法从 NHibernate 获得更详细的注销,以便找到“处理结果集”中的确切问题?

非常感谢任何建议。

We have an WCF application which uses NHibernate to query data from the database. After installing the application into a new test environment we're facing some performance problems with queries. Our old and new environment use different Oracle-servers but both of the databases have the same data.

We have went through our NHibernate logs and identified the problematic part:

2010-12-02 07:14:22,673 NHibernate.SQL                 - SELECT this_.CC...
2010-12-02 07:14:22,688 NHibernate.Loader.Loader       - processing result set
2010-12-02 07:14:27,235 NHibernate.Loader.Loader       - result set row: 0

In this case the query returned one row. But it seems that in our new environment the "processing result set" is taking much longer (5 seconds vs 0.5 seconds) than in our other environment. Is there some way to find out exactly what inside the "processing result set" is taking so long?

Note. Executing the same exact query directly into the DB with Toad doesn't reproduce the problem. With Toad, both database server are equally fast.

We are using DetachedCriteria to create the query and then it is executed like this:

        Dim criteria As ICriteria = crit.GetExecutableCriteria(GetSession())
        Return New Generic.List(Of T)(criteria.List(Of T))

The version of NHibernate is 2.1.2.4 and we're using ActiveRecord 2.1.0 to create the mappings. Oracle servers are of version 10g.

So in our case we have two environments that have the same version of the application with identical configuration files and are querying against identical databases, but which have different application and oracle servers. In one environment querying through the NHibernate takes around 5.5 seconds and in the another 0.5 seconds. The results are consistent and the same query has been executed around 50 times to both environments.

Is there something in the Oracle configuration which could cause it to misbehave with NHiberate? And is there a way to get more detailed logging out from NHibernate so that the exact problem inside the "processing result set" could be found?

Any advice is greatly appreciated.

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

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

发布评论

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

评论(2

攒眉千度 2024-10-12 08:42:42

通过将数据库驱动程序从 Microsoft 切换到 Oracle 的 ODP.net,我们解决了问题。现在,两台服务器的速度相同,甚至我们以前快速的服务器执行查询的速度也快得多。我们不知道新服务器中的什么设置导致 Microsoft 的 Oracle 驱动程序如此缓慢。

现在,Microsoft 似乎建议每个人都使用自己的 Oracle 驱动程序之外的其他东西。 http://blogs.msdn .com/b/adonet/archive/2009/06/15/system-data-oracleclient-update.aspx

We were able to fix our problem by switching the database drivers from Microsoft's to Oracle's ODP.net. Now, both servers are equally fast and even our previously fast server executes the queries much more rapidly. We don't know what setting in our new server made the Microsoft's Oracle driver so slow.

And it seems that Microsoft is nowadays recommending everyone to use something else than their own Oracle-drivers. http://blogs.msdn.com/b/adonet/archive/2009/06/15/system-data-oracleclient-update.aspx

皇甫轩 2024-10-12 08:42:42

通过将此语句添加到会话中,在两个环境上执行 sql 跟踪:

alter session set timed_statistics=true;
更改会话设置 max_dump_file_size=无限制;
alter session set events '10046 跟踪名称上下文永远,级别 8' ;

-- 您的查询在这里
从 mytable 中选择 *,其中 x= 1;

alter session set events '10046 跟踪名称上下文关闭';

然后使用 tkprof 检查跟踪文件(转到 user_dump_dest 通常是名称中包含 udump 和 tkprof outputfile.log inputtracefilename.trc 的目录)

键入 tkprof

单独

以查看帮助屏幕和命令选项另

请检查您是否在中使用相同的设置 诸如 CURSOR_SHARING= 之类的 INIT.ORA

两个数据库中

Do a sql trace on both environments by adding this statement to your session:

alter session set timed_statistics=true;
alter session set max_dump_file_size=unlimited;
alter session set events '10046 trace name context forever, level 8' ;

-- your query goes here
select * from mytable where x= 1;

alter session set events '10046 trace name context off';

then use tkprof to examine the trace file ( goto the user_dump_dest usually a directory with udump in the name and tkprof outputfile.log inputtracefilename.trc )

type tkprof

by itself to see help screen and command options

Also

Check that you are using the same settings in the INIT.ORA for things like CURSOR_SHARING=

in both databases

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