Os waits de "SQL*NETnnnn" são espera por rede (ie, o banco está "parado" esperando enviar/receber dados pela rede), então normalmente, numa aplicação saudável, comum, não-excêntrica, não é vitalmente importante : o manual "Database Performance Tuning Guide and Reference" te explica os eventos, e exatamente por este motivo o classifica como um "idle event", um período em que (em tese) o banco não está "trabalhando", ok ?
==>> O que vc TEM que ter em mente, porém, é o seguinte : idle ou não, vc deverá estar sempre preocupado com a participação de um evento no todo, junto com a duração : se nas suas medidas, o PORCENTUAL de ocorrência (** não ** a contagem) desse evento é alto, ** E ** o porcentual de tempo gasto nesse ebento TAMBÈM é alto, logicamente não tem a ver com performance do banco MAS tem a ver com performance da aplicação, talvez a aplicação erradamente esteja fazendo um processamento longo no cliente, ou não está usando array processing (fazer processamento row-by-row ,linha-a-linha, já foi chamado, entre outros nomes menos polidos, de "slow-by-slow", com razão).... Ou seja, resumo : waits por SQL*NET não servem pra indicar performance do banco, MAS podem indicar falha de design na aplicação, OU hardware de rede problemático. E vale também fazer um TKPROF Quanto ao PARSE, eu recomendo que vc use as estatísticas de parse pra investigar mais, tanto a geral do sistema (o statspack te dá) quanto uma análise por sessão, capturando antes e depois duma execução via V4sesstat : o objetivo ** SEMPRE ** é vc ter 1 parse para MUITOS executes, se a sua aplicação não está se comportando assim vc tem umbug em mãos... Uma alternativa simples, que funciona pra esmagadora maioria das linguagens/tools clientes, é não enviar SQLs ad-hoc, sempre chamar stored PL/SQL, entre outras N coisas o stored PL/SQL já te faz esse não-parseamento... Pra vc se aprofundar mais , recomendo : o citado manual de Tunning, uma pesquisa no http://asktom.oracle.com sobre PARSE, e os livros : "Oracle Wait Interface: A Practical Guide to Performance Diagnostics & Tuning", de Richmond Shee, Kirtikumar Deshpande and K Gopalakrishnan (bom pra se aprofundar no ponto dos waits) e o "Optimizing Oracle Performance", de Cary Millsap (às vezes um pouco avançado demais, mas inestimável pra se aprender o procedimento de tunning por comparação da participação de wait event no total do processo, como pela pergunta vc parece estar querendo fazer). []s Chiappa --- Em oracle_br@yahoogrupos.com.br, Rodrigo Passos <[EMAIL PROTECTED]> escreveu > Bom dia a todos, > > Gostaria de saber se o evento SQL*Net message from client é > importante para se otimizar algum processo pois como podem perceber a > maior parte do tempo se deve a esse evento. O que pode causar esse > evento? O que da para perceber é que o parser é sempre 2 x maior que o > exec. > > Se algum puder esclarecer algo, fico grato. > > > Statement Text > SELECT DISTINCT WPLABOR.LABORCODE, LABOR.NAME, WPLABOR.CRAFTQTY, > WPLABOR.LABORHRS, WPLABOR.RATE > FROM maxstr.WPLABOR, maxstr.LABOR > WHERE WPLABOR.SITEID = LABOR.PRIMARYSITEID (+) AND WPLABOR.LABORCODE > = LABOR.LABORCODE (+) AND WPLABOR.WONUM = :"SYS_B_0" > ORDER BY WPLABOR.LABORCODE > > > > > Statement Resource Profile > Response Time Component Duration # Calls - Duration per Call - > Avg Min Max > SQL*Net message from client 2.6110s 83.2% 3,420 0.0008s 0.0002s 0.2970s > CPU service 0.3300s 10.5% 1,520 0.0002s 0.0000s 0.0100s > latch free 0.1936s 6.2% 6 0.0323s 0.0000s 0.0856s > SQL*Net message to client 0.0051s 0.2% 3,743 0.0000s 0.0000s 0.0000s > Total 3.1398s 100.0% 8,689 0.0004s 0.0000s 0.2970s > > > Statement Cumulative Database Call Statistics Cursor > Action Library > Misses Action > Count Rows - Response Time - - LIO Blocks - PIO Blocks > Elapsed CPU Other Total Consistent Current > Parse 0 760 0 0.0962 0.1100 -0.0138 0 0 0 0 > Exec 0 380 0 0.0901 0.1000 -0.0099 0 0 0 0 > Fetch 0 380 323 0.3190 0.1200 0.1990 2,453 2,453 0 0 > Total 0 1,520 323 0.5053 0.3300 0.1753 2,453 2,453 0 0 > > Per Exe 0.0 1.0 0.8 0.0013 0.0009 0.0005 6.5 6.5 0.0 0.0 > Per Row 0.0 1.2 1.0 0.0016 0.0010 0.0005 7.6 7.6 0.0 0.0 > > > > Statement Latch Statistics > Latch# Duration # Calls - Duration Per Call - > Avg Min Max > 98 0.1936s 100.0% 6 0.0323s 0.0000s 0.0856s > Total 0.1936s 100.0% 6 0.0323s 0.0000s 0.0856s > > Statement Plan > > Rows Row Source Operation [Object Id] > -------- -------------------------------- > 323 SORT UNIQUE > 323 NESTED LOOPS OUTER > 323 TABLE ACCESS BY INDEX ROWID WPLABOR [28025] > 323 INDEX RANGE SCAN WPLABOR_NDX10 [33472] > 323 TABLE ACCESS BY INDEX ROWID LABOR [27884] > 342 INDEX RANGE SCAN LABOR_NDX6 [33971] > > > > > > SQL Statement Id: 1425697697 uid: 78 depth: 0 similar statements: 0 > > > Statement Text > SELECT WPTOOL.TOOLNUM, TOOL.DESCRIPTION, WPTOOL.TOOLQTY, > WPTOOL.TOOLHRS, WPTOOL.RATE > FROM maxstr.TOOL, maxstr.WPTOOL > WHERE TOOL.TOOLNUM (+) = WPTOOL.TOOLNUM AND WPTOOL.WONUM = > :"SYS_B_0"AND WPTOOL.TOOLNUM NOT IN (SELECT EQNUM > FROM MAXSTR.EQUIPMENT > WHERE CVRD_EQ39 IN(:"SYS_B_1",:"SYS_B_2")) > > > > > Statement Resource Profile > Response Time Component Duration # Calls - Duration per Call - > Avg Min Max > SQL*Net message from client 2.4385s 85.5% 3,420 0.0007s 0.0002s 0.2464s > CPU service 0.4100s 14.4% 1,520 0.0003s 0.0000s 0.0100s > SQL*Net message to client 0.0049s 0.2% 3,496 0.0000s 0.0000s 0.0000s > Total 2.8534s 100.0% 8,436 0.0003s 0.0000s 0.2464s > > > Statement Cumulative Database Call Statistics Cursor > Action Library > Misses Action > Count Rows - Response Time - - LIO Blocks - PIO Blocks > Elapsed CPU Other Total Consistent Current > Parse 0 760 0 0.1034 0.0800 0.0234 0 0 0 0 > Exec 0 380 0 0.1815 0.1600 0.0215 0 0 0 0 > Fetch 0 380 76 0.1426 0.1700 -0.0274 1,900 1,900 0 0 > Total 0 1,520 76 0.4276 0.4100 0.0176 1,900 1,900 0 0 > > Per Exe 0.0 1.0 0.2 0.0011 0.0011 0.0000 5.0 5.0 0.0 0.0 > Per Row 0.0 5.0 1.0 0.0056 0.0054 0.0002 25.0 25.0 0.0 0.0 > > > Statement Plan > > Rows Row Source Operation [Object Id] > -------- -------------------------------- > 76 NESTED LOOPS ANTI > 76 HASH JOIN OUTER > 76 TABLE ACCESS BY INDEX ROWID WPTOOL [28027] > 76 INDEX RANGE SCAN WPTOOL_NDX10 [33474] > 304 TABLE ACCESS FULL TOOL [27999] > 0 TABLE ACCESS BY INDEX ROWID EQUIPMENT [27848] > 0 INDEX RANGE SCAN EQUIPMENT_COL2 [28749] ______________________________________________________________________ Histórico: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/ Falar com os Moderadores:([EMAIL PROTECTED]) Dorian Anderson Soutto - Fernanda Damous - Alisson Aguiar ______________________________________________________________________ Links do Yahoo! Grupos <*> Para visitar o site do seu grupo na web, acesse: http://br.groups.yahoo.com/group/oracle_br/ <*> Para sair deste grupo, envie um e-mail para: [EMAIL PROTECTED] <*> O uso que você faz do Yahoo! Grupos está sujeito aos: http://br.yahoo.com/info/utos.html
