Tag Info

New answers tagged

3

The preemptive_xe_* wait types are associated with Extended Events from what I understand and can find. Considering that and your first sentence: We currently use a monitoring tool which shows us our top wait stats either by number of waiting tasks or total wait time. I would start looking at your monitoring tools as the culprit. However being that ...


0

SQL Server works in Non preemtive mode which means that if SQLOS asks it to yeild because it got request from windows OS it will ask SQL server to yeild and SQL Server will listen to it and will yeild or will do as SQLOS has asked it to do. This is because SQL server runs as application and is allocated resources by SQLOS which is monitored by windows O. ...


1

PreEmptive_XXX wait types are those that are: Used to indicate a worker is running code that is not under the SQLOS Scheduling Systems So essentially SQL Server is waiting on external processes to complete before it can continue with it's own processing. It can be caused by the use of CLR or extended stored procedures, so if you have any of those, ...


0

To know whether 7 is high or low, you'd need to know something about the database server. If, for example, you have a single CPU with 4 cores, 7 sessions would mean that, at any given time, 3 of your 7 threads were probably waiting to get scheduled for the CPU since your machine is only capable of running 4 sessions at any instant in time. That would imply ...


0

pagefile.sys % Usage shows total system committed not what currently is utilized. This value can increase due to load when system finds out it has to back process with more page file. Have a look at below link for detailed explanation http://blogs.technet.com/b/perfguru/archive/2008/01/08/explanation-of-pagefile-usage-as-reported-in-the-task-manager.aspx I ...


0

If all you want to do is waste a lot of space, you don't need a fancy table at all. A single varchar(4000) (filled up) should be enough: SQL> create table foo(a varchar(4000)); Table created. SQL> insert into foo select rpad(to_char(rownum), 4000, '*') from dual connect by level <= 1024 ; 1024 rows created. SQL> exec ...


4

Your query_cache_min_res_unit is 4KB and you have 6GB of query cache free ? Look at this 6 MB = 6144 KB 6144 KB divided by 4KB/query = 1536 queries. You can potentially fit up 1536 small query results in that 6GB of free space in the query cache. That 6GB is most likely being viewed as memory fragmentation. Why ? According to the MySQL Documentation on ...



Top 50 recent answers are included