Intrebari

Re: blocare sql server - probabil la conexiune

ignatandrei — Fri, 04 Sep 2009 10:17:18 GMT

OK, nu era blocat ... Insa din afara ( de pe alta masina) nu raspundea la deschiderea de conexiuni - iar ca sa obtin datele m-am conectat cu remote desktop si am rulat comenzile care erau deja in SSMS rulate anterior...
am restartat PC-ul - asa ca nu mai are sens, deocamdata, sys.dm_exec_requests pentru sql_handle si sys.dm_exec_sql_text pentru query - desi sugestia este buna pentru data viitoare.

Cum as putea monitoriza sa vad daca am taskuri , asemenea cu 106 si 111, inainte sa se intimple ? ( varianta mea e sa fac un programel in C#... dar poate sqldiag sau ... ?)
Multumesc mult Remus ca te-ai uitat ...
Daca te pot ajuta cindva cu ceva, te rog sa imi spui .

Re: blocare sql server - probabil la conexiune

rremus — Thu, 03 Sep 2009 14:10:22 GMT

CPU 80-90% nu e acelasi lucru cu blocat. Putea-i sa te conectezi si sa rulezi query-uri normal? Banuiesc ca da, din view-uri nu exista nici in task pending si nimic in scheduler's queues. Singura chestie care atrage atentia este taskul 0x0000000000EDB828 care are 610486 context switches si 64180 blocari pentru pending IO, pentru session id 111. Asta inseamna ce exista un request in system care se executa de ceva vreme (mult mai mult comparat cu celelate, si singurul cu session_id 'user' in starea asta). In sys.dm_exec_requests ai sql_handle-ul la ce se executa, si cu sys.dm_exec_sql_text poti obtine textul. Task-ul asta ruleaza pe CPU 2. Mai este interesant si session_id 106 care are cite un task pe fiecare CPU (2 pe CPU 3), si toate taskurile lui au rulat ceva destul de semnificativ ca timp si IO. Toate sint acuma suspended. Asta ar insemna ca SPID 106 ruleaza un query care a fost paralelizat si toate sub-taskurile lui paralele asteapta IO, deci ai un request care genereaza o gramada de I/O (asta ar fi cel care duce CPU la 80-90% pe toate CPU). Din nou, sys.dm_exec_requests pentru sql_handle si sys.dm_exec_sql_text pentru query.

Re: blocare sql server - probabil la conexiune

ignatandrei — Thu, 03 Sep 2009 07:24:56 GMT

Am reusit sa prind in "real-time" blocajul.
Cele 4 CPU erau in 80-90% ( de obicei sunt in maxim 25-30%)
Am atasat fisierul cu rezultatul la view-urile recomandate de Remus . Daca aveti timp sa va uitati pe ele si sa imi spuneti ce vi se pare ciudat ...
Ma gindesc si la SqlDiag sa il pun - dar trebuie sa ma uit cum imi afecteaza serverul
Multumesc,
Andrei

Re: blocare sql server - probabil la conexiune

rremus — Thu, 03 Sep 2009 02:18:26 GMT

View-urile sint disponibile sin in afara DAC si nu afecteaza foarte mult serverul, dar nu as recomanda sa le rulezi periodic. Mult mai bine sa capturezi intr-un performance log:

- all counters, all instances la toate categoriile care sint SQL Server
- all counters, all instances la Physical Disks, la Processor
- all counters, 'sqlservr' instance la Process
- all counters la memory

Seteaza un log (binar, *.blg !) care monitorizeaza astea cu interval citire de 20-30 secunde si lasa-l sa mearga.

O alta varianta este sa folosesti SQLDiag.exe care stie el sa porneasca counterii care sint mai interesanti.

Re: blocare sql server - probabil la conexiune

ignatandrei — Wed, 02 Sep 2009 06:10:29 GMT

rremus:
Cind se mai intimpla conecteaza-te la conexiunea administrativa DAC si:

1) uitat-te la sys.dm_os_schedulers, sys.dm_os_workers si sys.dm_os_tasks. Ce ma intereseaza este daca ai ceva in work_queue_count in schedulers, daca workers sint deja egali cu valoarea din sp_configure max workers count si daca ai multe task-uri. Impreuna astea ar indica un thread starvation, care este una din cauzele pentru care nu se pot accepta conexiuni.

2) uita-te la sys.dm_os_memory_clerks, order by (single_page_kb + multi_pages_kb) desc. Primele recorduri sint mai putine importatnt (node0 si node1, buffer pool) pentru astea sint totdeauna mari. Conteaza ce e dupa ele, ce tip de clerk si cit de mult a alocat. Ideea e sa cauti daca exista ceva care consuma memorie excesiv.

3) uita-te la sys.dm_os_memory_cache_clock_hands order by last_tick_count desc. Vezi cit de recent a rulat algoritmul de cache-eviction. Daca nu exista schimbari recente probabil ca Resource Monitor-ul este blocat (care este si mesajul din errorlog).

Ideea e ca daca Resource Monitor-ul este blocat, nu prea ai ce-i face tu. Trebuie sa contactezi suportul tehnic care poate sa identifice care este cauza.

Multumesc pentru sfaturi .
daca as rula aceste view-uri, sa zicem din sfert in sfert de ora, si as prelua rezultatele, as putea observa un trend ?
Cit de tare as incarca serverul daca le-as rula din 5 in 5 minute ?
Se pot rula view-urile si fara conexiunea administrativa DAC ?Sunt afectate rezultatele ?

Inca o data, multumesc,
Andrei

Re: blocare sql server - probabil la conexiune

ignatandrei — Wed, 02 Sep 2009 06:07:21 GMT

rsocol:
3. Instalează Service Pack 3 şi CU4 for SP3, şi apoi activează treaba cu "Locked pages in memory", vezi http://support.microsoft.com/kb/970070

Da ... asta as vrea sa fac si eu - dar pierd suportul pentru ERP . O sa mai vorbesc cu cei de la ERP ...

Re: blocare sql server - probabil la conexiune

rremus — Wed, 02 Sep 2009 03:53:02 GMT

Cind se mai intimpla conecteaza-te la conexiunea administrativa DAC si:

1) uitat-te la sys.dm_os_schedulers, sys.dm_os_workers si sys.dm_os_tasks. Ce ma intereseaza este daca ai ceva in work_queue_count in schedulers, daca workers sint deja egali cu valoarea din sp_configure max workers count si daca ai multe task-uri. Impreuna astea ar indica un thread starvation, care este una din cauzele pentru care nu se pot accepta conexiuni.

2) uita-te la sys.dm_os_memory_clerks, order by (single_page_kb + multi_pages_kb) desc. Primele recorduri sint mai putine importatnt (node0 si node1, buffer pool) pentru astea sint totdeauna mari. Conteaza ce e dupa ele, ce tip de clerk si cit de mult a alocat. Ideea e sa cauti daca exista ceva care consuma memorie excesiv.

3) uita-te la sys.dm_os_memory_cache_clock_hands order by last_tick_count desc. Vezi cit de recent a rulat algoritmul de cache-eviction. Daca nu exista schimbari recente probabil ca Resource Monitor-ul este blocat (care este si mesajul din errorlog).

Ideea e ca daca Resource Monitor-ul este blocat, nu prea ai ce-i face tu. Trebuie sa contactezi suportul tehnic care poate sa identifice care este cauza.

Re: blocare sql server - probabil la conexiune

rsocol — Wed, 02 Sep 2009 03:33:02 GMT

Sugestii:

1. Vezi dacă e aplicabil vreunul din următoarele articole (deşi nu prea cred):
http://www.google.com/search?hl=en&lr=lang_en&q=site%3Asupport.microsoft.com+%22Worker+*+appears+to+be+non-yielding%22+kbfix

2. Citeşte http://support.microsoft.com/kb/918483 şi urmează paşii de la "How to troubleshoot this problem".

3. Instalează Service Pack 3 şi CU4 for SP3, şi apoi activează treaba cu "Locked pages in memory", vezi http://support.microsoft.com/kb/970070

4. Dacă tot nu se rezolvă problema, poate ar fi bine să apelezi la suportul tehnic MS.

Răzvan

Re: blocare sql server - probabil la conexiune

ignatandrei — Wed, 02 Sep 2009 03:26:08 GMT

ggciubuc:
Vezi ce iti arata SQL Server Profiler, poate se vede mai bine

crezi ca, daca sql server blocheaza conexiunile, ma pot lega la el cu Profiler?
O sa incerc totusi ....

Re: blocare sql server - probabil la conexiune

ggciubuc — Tue, 01 Sep 2009 12:04:41 GMT

Vezi ce iti arata SQL Server Profiler, poate se vede mai bine

blocare sql server - probabil la conexiune

ignatandrei — Tue, 01 Sep 2009 10:43:50 GMT

Date initiale ale problemei : Windows Server 2003 R2 Standard SP2 pe 64 biti, 4 GB RAM , un Sql Server 2005 (9.00.3077.00 )pe 64 biti   si un soft proprietar de ERP - daca fac upgrade la Sql Server sau Windows nu mai asigura suport etc...

Simptome : In ultima luna s-a blocat de 2 ori aplicatia de ERP, precum si o aplicatie proprie a dat erori de conectare.

In event log de Application ERP scrie : "Unable to log event." - asta inseamna la el ca nu a putut scrie in BD.
Event log de System / Security este fara mesaje deosebite la ora respectiva.

In Sql Server log , in jurul orei respective , sunt mesaje de genul :

Resource Monitor (0x718) Worker 0x000000008000C1C0 appears to be non-yielding on Node 0. Memory freed: 13528 KB. Approx CPU Used: kernel 125 ms, user 15 ms, Interval: 64998.

In sfirsit aplicatia proprie imi trimite erori de genul :

"System.Data.EntityException: The underlying provider failed on Open. ---> System.Data.SqlClient.SqlException: Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding.

   at System.Data.SqlClient.SqlInternalConnection.OnError(SqlException exception, Boolean breakConnection)

   at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj)

   at System.Data.SqlClient.TdsParserStateObject.ReadSniError(TdsParserStateObject stateObj, UInt32 error)

   at System.Data.SqlClient.TdsParserStateObject.ReadSni(DbAsyncResult asyncResult, TdsParserStateObject stateObj)

   at System.Data.SqlClient.TdsParserStateObject.ReadNetworkPacket()
"

System.Data.EntityException: The underlying provider failed on Open. ---> System.Data.SqlClient.SqlException: A connection was successfully established with the server, but then an error occurred during the login process. (provider: TCP Provider, error: 0 - An existing connection was forcibly closed by the remote host.)

   at System.Data.SqlClient.SqlInternalConnection.OnError(SqlException exception, Boolean breakConnection)

Pare sa fie blocare de conexiune ... dar nu am mai intilnit pina acum. Softul este utilizat intern - sa zicem ca sunt 100 de oameni ? Oricum, ERP + aplicatia mea folosesc autentificare Sql Server - un singur cont pentru toti oamenii ...

Am gasit ceva legat de mutarea paginilor in memorie, dar nu cred ca e asta - si, pe deasupra, implica mutarea contului sub care ruleaza serviciul de Sql Server).
Astept pareri/idei/sugestii, de ex. cum as putea monitoriza? Si la ce ar fi buna monitorizarea?
Multumesc,
Andrei