Performance question

We have a server product which talks to SQL Server. One of the tables
we maintain is a session table. So a session row is added when login
occurs, it is looked up on subsequent requests and at certain points
may be updated to reflect recent activity (meaning the session's
lifetime is extended).
So what we essentially have is a fairly dynamic table of data whose
value is limited to however long the server is running. If the server
or DBMS machine is restarted, there is no particular need to retain
the contents of this table.
While this is currently a standard database table, I wondered whether
might be a more performant way to hold this information. For
instance, I note in Kalen Delaney's "Inside Microsoft SQL Server 2000"
that because of reduced logging requirements, "...data modification
operations on tables in tempdb can be up to four times faster than the
same operations in other databases." (p.310)
However reading more on the web I get the impression that some feel
tempdb operations can be less performant - the fear seems to relate to
contention.
Can anyone offer suggestions, particularly with regard to the scenario
I outlined above?
Thanks in advance.
Ed BarrettI do wonder though what happens if a client connection bombs out for some
reason. For example, if the client becomes disconnected in a non-proper
manner, e.g., network wire disconnected, blue screen. What happens if that
occurrs while you're updating this temp table? Will you get bad data? I
assume you already know to keep your transactions short and to update and
access the tables always in the same order whereby you can reduce the
probablility of contention.
Perhaps if you're looking for performance you can look to hardware. Since
high IOs are important, have you considered moving your special database (or
TEMPDB if you so choose) to an array of numerous spindles? If it's
available to you, go with a vacant BUS, private RAID CARD, and new drives
(RAID 10 recommended) for the best IO you can achieve. Testing of course is
recommended, but I am sure you know that.
Moving TEMPDB to its own RAID array is always recommended anyway.
hth
Eric
"Ed Barrett" <ebarrett@.metastorm.com> wrote in message
news:4026318.0310200720.21613799@.posting.google.com...
> We have a server product which talks to SQL Server. One of the tables
> we maintain is a session table. So a session row is added when login
> occurs, it is looked up on subsequent requests and at certain points
> may be updated to reflect recent activity (meaning the session's
> lifetime is extended).
> So what we essentially have is a fairly dynamic table of data whose
> value is limited to however long the server is running. If the server
> or DBMS machine is restarted, there is no particular need to retain
> the contents of this table.
> While this is currently a standard database table, I wondered whether
> might be a more performant way to hold this information. For
> instance, I note in Kalen Delaney's "Inside Microsoft SQL Server 2000"
> that because of reduced logging requirements, "...data modification
> operations on tables in tempdb can be up to four times faster than the
> same operations in other databases." (p.310)
> However reading more on the web I get the impression that some feel
> tempdb operations can be less performant - the fear seems to relate to
> contention.
> Can anyone offer suggestions, particularly with regard to the scenario
> I outlined above?
> Thanks in advance.
> Ed Barrett

Performance on wan

Hi,I have 2 server SQL 2000, 15 days ago everything worked well,

but days back, the performance on WAN is poor, it takes long time in login and make querys, in the local net everything work well, my problem is only on WAN, i dont have problem with Memory and CPU, the use of CPU never exceed 25 %, although i have poor performance on WAN local its fine, my bandwith is excelent, with other services i dont have problem(Terminal Services, Ftp, etc)

Some idea?

Thanks.

Javier Muro

When you connect, can you confirm your network library is TCP/IP? You can query against sysprocesses to find this out:
SELECT loginame, net_library
FROM sysprocesses
WHERE loginame = '<your login>'
If it's not, run cliconfg.exe and check the order of your enabled protocols. If you've got TCP/IP first, was the SQL Server restarted recently? If so, check the SQL Server log to ensure it was able to listen on TCP/IP.
If none of that, were any changes made on the networking equipment for the WAN? For instance, did the network engineers adjust QoS or anything of that sort?