Win 2003 Server上的性能问题 [英] Peformance issues on Win 2003 Server
问题描述
我需要一些建议。我们以前在Novell服务器上运行我们的多用户
Access 2002应用程序。自几个月前切换到Windows 2003服务器以来，我们在连接多个用户时遇到了严重的性能问题。简单的
a任务为表附加100,000条记录可以轻松占用30分钟。
这些性能问题发生在所有数据库上，无论是否为
，它们是分开的FE / BE还是集成的。
一旦所有其他用户退出，问题就会消失给出了
数据库。在单个用户负载下，相同的追加可能需要花费少于b / b
。
我一直在试图解决问题这个。所以
远，我看过TCPAckFrequency设置，
DisableFlushOnCleanup，EnableSecuritySignature，
RequireSecuritySignature，SMB签名。
使用示例数据库，我还尝试将数据库移动到顶级的
级目录，将数据库移动到另一个Windows 2003
服务器，将链接表更改为导入表，反之亦然，
设置持久记录集。
问题仍然存在。一旦第二个用户访问数据库，
将查询缓慢追加到绝对爬行。
我愿意接受建议......如果我我不能很快解决这个问题，我要去
将所有这些数据库转换为SQL，而那不是
我是什么意思津津乐道。
我们这个问题每天约有一篇文章，答案总是
相同：
尝试使用perssint连接。 10次中的9次，这将解决你的问题... ...这个群体的谷歌......
所以，这意味着你的启动代码打开后面的表格
结束，KEEPS打开。您可以使用全局reocrdset执行此操作，甚至可以将主要启动菜单表单附加到后端表。这可以
是后端的任何一个表。即使是为此设计的一个记录表。通过
执行此操作，您保持/强制连接保持打开状态（您的性能
问题是由于连接以及它如何打开。当您有更多时
一个用户，然后连接到后端需要FOREVER，并且
因此持久连接只会发生一次）。
那个30分钟的代码，尝试在后面打开一张桌子
结束...最小化...并运行你的代码（这将模拟一个持久的
连接）。
一个很棒的常见问题（提到上面的技巧），还有其他要检查的东西是
：
http://www.granite.ab.ca/access /perfafa.htm
完成以上每个建议（但是，因为一个用户运行正常......然后
它是持久的连接问题）。
-
Albert D. Kallal（访问MVP）
Ed加拿大阿尔伯塔省蒙顿
pl ********** *******@msn.com
Albert，
谢谢你输入。正如我在原帖中所提到的那样，我已经尝试过持久记录集而没有结果的
。但是，你确定这是一个持久性问题，这促使我做了一点实验。
今天早上我发现了如果我在同一个工作站上打开两个相同的
Access数据库的实例，打开一个表或一个绑定表格的表格，例如A，表格为A，并且在实例B中运行查询，即使其他用户正在访问
相同的后端，也不会出现
减速问题。
不幸的是，如果不在给定工作站上打开第二个
实例，即使使用各种技术实现
，我也无法复制此行为一个持久的记录集。我已经尝试了两种绑定表格和
全局记录集。
我绝对难过为什么在
上有第二个Access实例
工作站将达到预期的效果，而单个实例中的持久
记录集则不会。
Albert D. Kallal写道：
我们在这个问题上每天约有一篇帖子，答案总是与
相同：
尝试使用perssint连接。 10次中的9次，这将解决你的问题...这个群组的Google ...
< blockquote class =post_quotes>
我绝对难以理解为什么
工作站上的第二个Access实例将达到预期的结果，而持续的
$单个实例中的b $ b记录集不会。
Gollly ......这很有趣......
我想知道这里发生了什么......
尝试打开一张桌子（这是前端到后面的链接表
结束）。任何表都可以（只要它有记录）。现在，只需缩小
表（因此，它保持打开状态）。
现在测试...你应该得到与打开两个副本相同的效果。
嗯，也许持久性重新设定不是全局的，或者是超出
范围。 （或者，没有记录??）。如果mimzine上面的表格技巧有效，那么
reocrdset没有举行.....
有些奇怪，因为你的持久性 ;在这件事上，你已经设法重现，或者至少验证保持连接的想法
打开确实解决了这个......
-
Albert D. Kallal（访问MVP）
加拿大艾伯塔省埃德蒙顿
pl ***************** @ msn.com
I need some suggestions. We had previously been running our multi-user
Access 2002 applications on a Novell server. Since switching to
Windows 2003 servers a few months ago, we''ve been having severe
performance issues whenever multiple users are connected. As simple of
a task as appending 100,000 records to a table can easily take over 30
minutes.
These performance issues occur on all of databases, regardless of
whether they are split FE/BE or integrated.
The problems vanish as soon as all other users drop out of a given
database. Under single user load, the very same append may take less
than 45 seconds.
I''ve been beating my head against the wall trying to resolve this. So
far, I''ve looked at the TCPAckFrequency settings,
DisableFlushOnCleanup, EnableSecuritySignature,
RequireSecuritySignature, SMB Signing.
Using a sample database, I''ve also tried moving the database to a top
level directory, moving the database to a different Windows 2003
server, changing linked tables to imported tables and visa versa, and
setting up persistent recordsets.
The problem remains. As soon as a second user access the database,
append queries slow to an absolute crawl.
I''m open to suggestions...if I can''t get this resolved soon, I''m going
to have to convert all of these databases over to SQL, and that''s not
something I relish.
We have about one post per day on this issue, and the answer is always the
same:
Try a perssint connection. 9 out of 10 times, this will solve your
problem...Google the groups for this...
So, all that means is that your start-up code opens up a table to the back
end, and KEEPS it open. You can do this with a global reocrdset, or even
your main start-up menu form can be attached to a back end table. This can
be ANY table in the back end..even a one record table designed for this. By
doing this, you keep/force the connection to stay open (your performance
problem is due to the connection, and how it opens. When you have more then
one users, then making the connection to the back end takes FOREVER, and
thus a persistent connection makes this happen ONLY once).
And, that 30 minute code thing, try opening a table to the back
end...minimize it...and run your code (this will simulate a persistent
connection).
A great faq (that mentions the above trick), and other things to check is
here:
http://www.granite.ab.ca/access/performancefaq.htm
Go through each of the above suggetions (but, since one user runs ok..then
it is the persistant connection issue).
--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pl*****************@msn.com
Albert,
Thanks for the input. As I mentioned in my original post, I had
already tried persistent recordsets with no result. However, your
certainty that this was a persistence issue spurred me to a little
experiment.
I have discovered this morning that if I open two instances of the same
Access database on the same workstation, open a table, or a form bound
to table, in instance "A", and run a query in instance "B", the
slowdown issue will not appear, even when other users are accessing the
same back end.
Unfortunately, I can''t duplicate this behavior without opening a second
instance on a given workstation, even using the various techniques for
achieving a persistant recordset. I have tried both bound forms and
global recordsets.
I''m absolutely stumped as to why a second instance of Access on the
workstation will achieve the desired result, while a persistent
recordset within a single instance will not.
Albert D. Kallal wrote:We have about one post per day on this issue, and the answer is always the
same:
Try a perssint connection. 9 out of 10 times, this will solve your
problem...Google the groups for this...
I''m absolutely stumped as to why a second instance of Access on the
workstation will achieve the desired result, while a persistent
recordset within a single instance will not.Gollly...that is interesting....
I wonder what is going on here....
Try opening a table (that is a linked table in the front end to the back
end). Any table will do (as long as it has records). Now, just miminze the
table (so, it stays open).
Now test...you should get the same effect as having two copies open.
Hum, perhaps the persistence recodset is not global, or is going out of
scope. (or, no records??). If the mimzine the table trick above works, then
the reocrdset is not holding.....
Something is strange, since by your "persistence" on this matter, you have
managed to reproduce, or at least verify the idea that keeping a connection
open does seem to solve this...
--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pl*****************@msn.com
这篇关于Win 2003 Server上的性能问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
