about concurrency?

How can i say what the number of concurrency in our db is?

many thanks

That was too loose of a question to get any deliberate and meaningful responses, more like a scattershot of 'quesses' about what you may have meant to ask.

The Number of concurrent users is significantly influenced by the hardward -CPUs and memory, network bandwidth, etc.

There is no way to provide a definitive answer even if that is what you are asking.

|||

Hi Andrew,

Sorry, can you clarify what you mean? Are you trying to determine how many users are connected/active at a given time, or are you trying to determine capacity (max concurrent users)?

Cheers,

Rob

|||

sorry for my confused question

yes,that's what i want ,thanks

also tow questions,how to determine if there are deadlock occur at a given time? and if i can set rollback for specified transactions?If so, how to do thant?

thanks in advance

|||

Hi Andrew,

Hmmm...I still don't know what your question is , but I'll take a punt and assume you meant my first clarifying question.

If you want to determine the current number fo user connections, you can interrogate master.dbo.sysprocesses in MSSQL2000 or the dynamic management views in 2005 (sys.dm_exec_connections etc.).

Deadlocks (victimis) are rolled-back automatically.

Cheers,

Rob

|||

many thanks

any advice about your second assume?

I'm struggling to be a DBA, but I am lack of many actual experiences in this fields, this can be saw from my confused questions

also one more question , If there is one regular method for DBA to detect where the bottleneck of app is?

|||

Well, I'd guess that the regular method is 'detective work' together with experience...

There aren't any particular method, but you have some tools to help you out that may be considered 'regular'.

To find a bottleneck you must first monitor your system/app in order to determine what the bottleneck is, and where it's located.

Common bottlenecks are hardware related (disk, CPU, memory) or 'application related', in which case the app's SQL code is among the first places to look. Sometimes the network constitutes a bottleneck. This along with the methods of acces that the app uses may give you a pointer to where a problem lies.

To monitor, Perfmon and Profiler are great tools. On SQL 2005 you also have many dmv's (datamanagement views) to help you out with different kinds of metrics. But basically, it's just like any other 'problemhunt'. You monitor, then analyze and then (hopefully =;o) correct the problem.

/Kenneth