Re: [oracle_br] Estouro de processos
Situação atual da instancia:
INST_ID RESOURCE_NAME CURRENT_UTILIZATION
MAX_UTILIZATION INITIAL_ALLOCAT LIMIT_VALUE PERC
-- -- ---
--- --- - --
1 processes 711
1000 10001000 71.10
1 sessions44
70 15281528 2.88
SQL SELECT USERNAME, COUNT(*) FROM V$PROCESS GROUP BY USERNAME;
USERNAME COUNT(*)
--- --
1
oracle 710
SQL SELECT USERNAME, COUNT(*) FROM V$SESSION GROUP BY USERNAME;
USERNAME COUNT(*)
-- --
27
SYS 1
DBSNMP 3
SQL
Como tinha dito no email anterior, baixei a aplicação que foi atualizada
recentemente, conforme sugeriu um outro colega. Pode-se notar que diminuiu
bastante os processos.
Atenciosamente,
Rogério Camatini.
Em 2 de dezembro de 2014 18:21, jlchia...@yahoo.com.br [oracle_br]
oracle_br@yahoogrupos.com.br escreveu:
Colega, dando como certo que ** realmente ** vc está conectado na exata
mesma instância que deu o erro ORA-00020: maximum number of processes
(1000) exceeded, as possibilidades são que :
a) vc tem algum problema de setting no SO (seja params de kernel, seja
ULIMIT, que o pessoal ** sempre ** se esquece de verificar) : junto com o
seu sysadmin, *** CONFIRA ** que essas coisas estão ok...
ou
b) a aplicação está criando PROCESSOS mas por qquer falha não consegue
abrir as SESSÔES relacionadas aos processos : plz faça um COUNT na
V$PROCESS... Esse tipo de cenário é sim possível,
https://community.oracle.com/thread/2585132?start=0tstart=0 mostra uma
thread onde esse foi o diagnóstico
ou
c) simplesmente, vc teve no passado recente uma enorme contagem de
sessões, as sessões foram eliminadas mas os processos não ... Plz consulta
o HISTÓRICO do consumo de recursos com a query :
column initial_allocation format a15
column limit_value format a17
set lines 133
column perc format 99D99
select t.*, (t.CURRENT_UTILIZATION/to_number(LIMIT_VALUE)) * 100 perc
from gv$resource_limit t
where resource_name in ('sessions', 'processes') order by 1,2
/
[]s
Chiappa
RES: [oracle_br] Usuário para Export
Andre, Dei esse Grant SQL grant unlimited tablespace to dbExport; Grant succeeded. mtzvp01a$ expdp dbExport/data14@prd DIRECTORY=EXPORT DUMPFILE=AUX.dmp LOGFILE=AUX.log TABLESPACES=AUX COMPRESSION=ALL Export: Release 11.2.0.4.0 - Production on Wed Dec 3 08:42:18 2014 Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved. Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production With the Partitioning option Starting DBEXPORT.SYS_EXPORT_TABLESPACE_01: dbExport/@prd DIRECTORY=EXPORT DUMPFILE=AUX.dmp LOGFILE=AUX.log TABLESPACES=AUX COMPRESSION=ALL Estimate in progress using BLOCKS method... Total estimation using BLOCKS method: 0 KB ORA-31655: no data or metadata objects selected for job Job DBEXPORT.SYS_EXPORT_TABLESPACE_01 completed with 1 error(s) at Wed Dec 3 08:42:21 2014 elapsed 0 00:00:02 ALERT: Wed Dec 03 08:42:19 2014 DM00 started with pid=612, OS id=27832, job DBEXPORT.SYS_EXPORT_TABLESPACE_01 Wed Dec 03 08:42:20 2014 DW00 started with pid=553, OS id=27842, wid=1, job DBEXPORT.SYS_EXPORT_TABLESPACE_01 Grato Ednilson Silva De: oracle_br@yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br] Enviada em: terça-feira, 2 de dezembro de 2014 18:16 Para: oracle_br@yahoogrupos.com.br Assunto: Re: [oracle_br] Usuário para Export Ednilson O usuário precisa ter quota em tablespace para criar tabelas de controle (exemplo, conforme a mensagem de erro: SYS_EXPORT_TABLESPACE_05). Veja se ele tem quota na tablespace default. [ ] André 2014-12-02 17:46 GMT-02:00 'Ednilson Silva' ednilson.si...@jbs.com.br [oracle_br] oracle_br@yahoogrupos.com.br: Dalton / Emerson, Obrigado pelo retorno. Fiz da seguinte forma. SQL create user dbExport identified by data14 temporary tablespace temp default tablespace dba; User created. SQL grant connect to dbExport; Grant succeeded. SQL grant EXP_FULL_DATABASE to dbExport; Grant succeeded. SQL grant read, write on directory EXPORT to dbExport; Grant succeeded. Diretorio EXPORT já existia. Mas ao tentar fazer um EXPORT com esse usuário deu erro. mtzvp01a$ expdp dbExport/data14@prd DIRECTORY=EXPORT DUMPFILE=AUX.dmp LOGFILE=AUX.log TABLESPACES=AUX COMPRESSION=ALL Export: Release 11.2.0.4.0 - Production on Tue Dec 2 17:36:31 2014 Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved. Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production With the Partitioning option ORA-31626: job does not exist ORA-31633: unable to create master table DBEXPORT.SYS_EXPORT_TABLESPACE_05 ORA-06512: at SYS.DBMS_SYS_ERROR, line 95 ORA-06512: at SYS.KUPV$FT, line 1038 ORA-01950: no privileges on tablespace 'DBA' Grato, Ednilson Silva De: oracle_br@yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br] Enviada em: terça-feira, 2 de dezembro de 2014 17:09 Para: oracle_br@yahoogrupos.com.br Assunto: Re: [oracle_br] Usuário para Export Olá Ednilson Além do citado acimo precisará do privilégio de leitura e escrita no diretório conforme abaixo -- Criar o diretório (via SYSTEM) SQL CREATE DIRECTORY dmpdir AS '/expdp/'; Directory created. SQL GRANT read, write ON DIRECTORY dmpdir TO scott; Grant succeeded. SQL SELECT directory_path FROM dba_directories WHERE directory_name = 'DATA_PUMP_DIR'; DIRECTORY_PATH /expdp/ Att, Emerson Martins DBA Oracle Oracle 11g Certified Associate 2014-12-02 15:35 GMT-03:00 'Ednilson Silva' ednilson.si...@jbs.com.br [oracle_br] oracle_br@yahoogrupos.com.br: Pessoal, Estou querendo criar um usuário para gerar exports (Data Pump) do meu banco de dados, quais as permissões que preciso atribuir para esse usuário? - Oracle Database 11g (Release 11.2.0.4) Grato, Ednilson Silva
[oracle_br] Campo Calculado
Bom dia pessoal do forum. Estou querendo cria um campo calculado em uma tabela. Este campo fara o calculo da qtde (esta na mesma tabala do campo calculado) com o peso (esta em outra tabela). Isso é possivel de fazer? Obriagdo. Emerson Sanches Analista de Sistemas
Re: RES: [oracle_br] Usuário para Ex port
Opa, então : primeira coisa, UNLIMITED TABLESPACE significa que o usuário poderá usar ** qualquer ** tablespace (INCLUSIVE a SYSTEM ) - isso bate DE FRENTE com o conceito de se ter segurança, de se dar o MÍNIMO de privilégios possíveis , eu é que não faria NUNCA isso, especialmente quando (não SE, mas QUANDO!!) neguim começar a criar lixo e mais lixo na SYSTEM e o banco der pau por causa de tablespace SYSTEM cheia e eu é que ter que limpar a sujeira... Certamente, QUOTA UNLIMITED na tablespace que ele precisa, e apenasmente isso... Quanto á msg, ela é clara : ORA-31655: no data or metadata objects selected for job isso decorre do fato que quando vc Não informa que quer um export full e não informa o nome do schema a exportar, o exp/expdp assume que vc quer um export só do schema do usuário conectando, e esse usuário dbExport deve estar vazio, sem objetos no schema dele... okdoc ?? Assim, OU vc informa FULL=Y se vc quer um export full do banco todo, OU então vc informa SCHEMAS=listadosschemasaseremexportados []s Chiappa OBS : só lembrando, se vc quer que o usuário X possa exportar objetos de OUTROS schemas que não o dele, X ** TEM ** que ter recebido um GRANT de EXP_FULL_DATABASE... Além disso, para que X possa criar as tabelinhas de controle do expdp, além de CREATE SESSIOn ele ** TEM ** que ter recebido CREATE TABLE...
Re: [oracle_br] Estouro de processos
Nada como consultar a fonte da verdade real, né não ? A query na RESOURCE_LIMIT mostra claramente que SIM, vc chegou a ter uma quantidade de sessions E de processes que bateu no limite, então MUITO CERTAMENTE isso foi a causa da tua impossibilidade de conectar... Vc vai ter que fazer o seguinte agora : 1. fazer a investigação (principalmente no log do listener, cfrme mostrado nos links que passei) para vc ver se realmente não está tendo leaking de processos : isso parece provável, pois a tua situação de agora, com mais de 700 processes para apenas 30 e poucas sessions absolutamente *** Não é Normal *** 2. alteração dos parâmetros : primeiro 1000 como job_queue_processes é questionável : via de regra isso não pega nada porque ninguém sai criando centenas de jobs simultãneos em banco, mas vai saber... Acho mais seguro vc colocar um valor não-default e Realista nesse cara... Também recomendo que, se vc achar por bem subir um pouco sessions/processes, que vc siga a fórmula da Doc (ie, (1.1 * PROCESSES) + 5, iirc) para SESSIONS e PROCESSES 3. restart do database (sendo banco homo, não-prod, não deve ter grandes impedimentos), para que zerem os contadores da resource_limit 4. ativar os recursos que vc tiver de MONITORAÇÃO nesse database, para ser Alertado quando o consumo chegar perto do limite : o OEM tem recursos pra isso por default, vc pode ter um job (interno ou externo ao db) que periodicamente checa isso, pode ter uma trigger de logon, enfim, n possibilidades... O ponto é que, pelo que vejo, está PROVADO que o problema é EXTERNO ao database, é aplicação abrindo muitas sessões e/ou com leaking e/ou com erro na config de pools e/ou criando centenas de jobs ou abrindo threads no database NADA disso tem a ver com o database, que no caso está sendo é Vítima desse consumo externo inapropriado... []s Chiappa
[oracle_br] Re: Campo Calculado
Isso *** totalmente depende *** da VERSÃO do database, que vc não nos disse, yep ??? SE for 11g ou superior SIM, vc tem o recurso de criar uma coluna derivada/calculada a partir de outras (veja na doc 11g a entrada sobre CREATE TABLE), MAS se for versão inferior a 11g (ie, 10g e anteriores) aí vc não tem isso : nesse caso, vc pode criar uma VIEW cujo SELECT englobe o cálculo que vc precisa, OU pode criar a coluna adicional que vc quer e a popular numa trigger de INSERT/UPDATE, é isso ... []s Chiappa
[oracle_br] Re: Campo Calculado
Adicionalmente, sendo 11g, se vc for usar a feature built-in veja em http://www.oracle.com/technetwork/database/database-technologies/rdb/automatic-columns-132042.pdf , nele vc tanto encontra exemplos adicionais de colunas computadas QUANTo ele também cita algumas das RESTRIÇÕES da feature... []s Chiappa
RES: RES: [oracle_br] Usuário para Ex port
Chiappa, Entendi, quero criar um Export Diario por Tablespace, montei um script que ele já traz o comando EXPDP de todas as tablesapces. Neste caso o dbExport não precisaria ter acesso a todas as Tablespaces? O Schema será um só (PRODUCAO), que irei colocar no meu script. Fui fazer já um teste e ocorreram erros. mtzvp01a$ expdp dbExport/data14@prd DIRECTORY=EXPORT DUMPFILE=AUX.dmp LOGFILE=AUX.log TABLESPACES=AUX COMPRESSION=ALL SCHEMAS=producao Export: Release 11.2.0.4.0 - Production on Wed Dec 3 10:22:34 2014 Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved. Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production With the Partitioning option UDE-00010: multiple job modes requested, schema and tablespaces. Grato Ednilson Silva De: oracle_br@yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br] Enviada em: quarta-feira, 3 de dezembro de 2014 09:45 Para: oracle_br@yahoogrupos.com.br Assunto: Re: RES: [oracle_br] Usuário para Ex port Opa, então : primeira coisa, UNLIMITED TABLESPACE significa que o usuário poderá usar ** qualquer ** tablespace (INCLUSIVE a SYSTEM ) - isso bate DE FRENTE com o conceito de se ter segurança, de se dar o MÍNIMO de privilégios possíveis , eu é que não faria NUNCA isso, especialmente quando (não SE, mas QUANDO!!) neguim começar a criar lixo e mais lixo na SYSTEM e o banco der pau por causa de tablespace SYSTEM cheia e eu é que ter que limpar a sujeira... Certamente, QUOTA UNLIMITED na tablespace que ele precisa, e apenasmente isso... Quanto á msg, ela é clara : ORA-31655: no data or metadata objects selected for job isso decorre do fato que quando vc Não informa que quer um export full e não informa o nome do schema a exportar, o exp/expdp assume que vc quer um export só do schema do usuário conectando, e esse usuário dbExport deve estar vazio, sem objetos no schema dele... okdoc ?? Assim, OU vc informa FULL=Y se vc quer um export full do banco todo, OU então vc informa SCHEMAS=listadosschemasaseremexportados []s Chiappa OBS : só lembrando, se vc quer que o usuário X possa exportar objetos de OUTROS schemas que não o dele, X ** TEM ** que ter recebido um GRANT de EXP_FULL_DATABASE... Além disso, para que X possa criar as tabelinhas de controle do expdp, além de CREATE SESSIOn ele ** TEM ** que ter recebido CREATE TABLE...
Re: [oracle_br] Estouro de processos
Chiappa, Fiz a alteração mencionada, mas decidi manter os valores para PROCESSES e SESSIONS: NAME TYPEVALUE --- -- aq_tm_processes integer 1 cell_offload_processing boolean TRUE db_writer_processes integer 1 gcs_server_processes integer 0 global_txn_processes integer 1 job_queue_processes integer 10 log_archive_max_processesinteger 4 processesinteger 1000 processor_group_name string SQL show parameter session NAME TYPEVALUE --- -- java_max_sessionspace_size integer 0 java_soft_sessionspace_limit integer 0 license_max_sessions integer 0 license_sessions_warning integer 0 session_cached_cursors integer 50 session_max_open_files integer 10 sessions integer 1528 shared_server_sessions integer SQL exit Situação atual: oracle@hostname:/oracle ps -ef | grep homol11 | grep -v grep | wc -l 135 oracle@hostname:/oracle Situação após restart da instancia: oracle@hostname:/oracle ps -ef | grep homol11 | grep -v grep | wc -l 22 oracle@hostname:/oracle Utilizamos aqui o Cloud Control 12c, consigo monitorar essa anomalia com esta ferramenta? Atenciosamente, Rogério Camatini. Em 3 de dezembro de 2014 10:13, jlchia...@yahoo.com.br [oracle_br] oracle_br@yahoogrupos.com.br escreveu: Nada como consultar a fonte da verdade real, né não ? A query na RESOURCE_LIMIT mostra claramente que SIM, vc chegou a ter uma quantidade de sessions E de processes que bateu no limite, então MUITO CERTAMENTE isso foi a causa da tua impossibilidade de conectar... Vc vai ter que fazer o seguinte agora : 1. fazer a investigação (principalmente no log do listener, cfrme mostrado nos links que passei) para vc ver se realmente não está tendo leaking de processos : isso parece provável, pois a tua situação de agora, com mais de 700 processes para apenas 30 e poucas sessions absolutamente *** Não é Normal *** 2. alteração dos parâmetros : primeiro 1000 como job_queue_processes é questionável : via de regra isso não pega nada porque ninguém sai criando centenas de jobs simultãneos em banco, mas vai saber... Acho mais seguro vc colocar um valor não-default e Realista nesse cara... Também recomendo que, se vc achar por bem subir um pouco sessions/processes, que vc siga a fórmula da Doc (ie, (1.1 * PROCESSES) + 5, iirc) para SESSIONS e PROCESSES 3. restart do database (sendo banco homo, não-prod, não deve ter grandes impedimentos), para que zerem os contadores da resource_limit 4. ativar os recursos que vc tiver de MONITORAÇÃO nesse database, para ser Alertado quando o consumo chegar perto do limite : o OEM tem recursos pra isso por default, vc pode ter um job (interno ou externo ao db) que periodicamente checa isso, pode ter uma trigger de logon, enfim, n possibilidades... O ponto é que, pelo que vejo, está PROVADO que o problema é EXTERNO ao database, é aplicação abrindo muitas sessões e/ou com leaking e/ou com erro na config de pools e/ou criando centenas de jobs ou abrindo threads no database NADA disso tem a ver com o database, que no caso está sendo é Vítima desse consumo externo inapropriado... []s Chiappa
Re: RES: RES: [oracle_br] Usuário pa ra Ex port
veja que o GRANT de UNLIMITED TABLESPACE te dá é capacidade de GRAVAR coisas nas tablespaces todas, ele ** não ** controla acesso ás tablespaces (nós * NÂO TEMOS * esse conceito de privilégio de acesso às tablespaces no RDBMS Oracle) : o que nós temos no RDBMS Oracle em relação a tablespaces é a QUOTA , o limite de tamanho máximo de GRAVAÇÃO dentro de uma tablespace, okdoc ?? A LEITURA / acesso nós fazemos aos OBJETOS (ie, tabelas) que estão dentro das tablespaces, e são os OBJETOS que podem ser permissionados, confere okdoc ?? Quando vc faz um export de tablespaces, na verdade o que vc está filtrando são os OBJETOS (pertencentes á N usuários diferentes em tese), que ESTÃO CONTIDOS nas tais tablespaces, então o que o usuário X precisa é de acesso a TODOS esses objetos, isso é o que faz o GRANT de EXPORT FULL DATABASE - no caso o GRANT ref. DATAPUMP, já que é ISSO que vc quer usar... Quanto á msg de erro, ela é DIRETAMENTE CLARA : UDE-00010: multiple job modes requested, schema and tablespaces. OU SEJA, vc tá tentando fornecer DOIS filtros diferentes e não-compatíveis : faz sentido o erro, pois os objs dentro de uma tablespace podem pertencer á N usuários, assim o expdp não teria como honrar de modo completo ao mesmo tempo as duas requisições Assim, se vc quer os objetos de uma ou mais tablespace informe isso, E SE vc quer os objetos de um ou mais schemas informe isso Exemplo : sys@o11GR2:SQLcreate user LIXO identified by lixo default tablespace EXAMPLE temporary tablespace TEMP; Usuário criado. sys@o11GR2:SQLgrant create session to lixo; Concessăo bem-sucedida. sys@o11GR2:SQLgrant datapump_exp_full_database to lixo; Concessăo bem-sucedida. sys@o11GR2:SQLalter user lixo quota unlimited on EXAMPLE; Usuário alterado. sys@o11GR2:SQLgrant create table to LIXO; Concessăo bem-sucedida. sys@o11GR2:SQLgrant read on directory DATA_PUMP_DIR to lixo; Concessăo bem-sucedida. sys@o11GR2:SQLgrant write on directory DATA_PUMP_DIR to lixo; Concessăo bem-sucedida. SQL === E PRONTO: com isso (SEM privilégios Desnecessários de GRAVAR em qquer tablespace, que é o que UNLIMITED te dá!!!), esse usuário já pode exportar objetos de outros usuários : C:\Users\chiappaexpdp lixo/lixo DIRECTORY=DATA_PUMP_DIR DUMPFILE=objs_schema_SCOTT.dmp LOGFILE=objs_schema_SCOTT.exp SCHEMAS=SCOTT COMPRESSION=ALL Export: Release 11.2.0.1.0 - Production on Qua Dez 3 11:11:57 2014 Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved. Conectado a: Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production With the Partitioning, OLAP, Data Mining and Real Application Testing options Iniciando LIXO.SYS_EXPORT_SCHEMA_01: lixo/ DIRECTORY=DATA_PUMP_DIR DUMPFILE=objs_schema_SCOTT.dmp LOGFILE=objs_schema_SCOTT.exp SCHEMAS=SCOTT COMPRESSION=ALL Estimativa em andamento com o método BLOCKS... Processando o tipo de objeto SCHEMA_EXPORT/TABLE/TABLE_DATA Estimativa total usando o método de BLOCKS: 192 KB Processando o tipo de objeto SCHEMA_EXPORT/USER Processando o tipo de objeto SCHEMA_EXPORT/SYSTEM_GRANT Processando o tipo de objeto SCHEMA_EXPORT/ROLE_GRANT Processando o tipo de objeto SCHEMA_EXPORT/DEFAULT_ROLE Processando o tipo de objeto SCHEMA_EXPORT/PRE_SCHEMA/PROCACT_SCHEMA Processando o tipo de objeto SCHEMA_EXPORT/TABLE/TABLE Processando o tipo de objeto SCHEMA_EXPORT/TABLE/INDEX/INDEX Processando o tipo de objeto SCHEMA_EXPORT/TABLE/CONSTRAINT/CONSTRAINT Processando o tipo de objeto SCHEMA_EXPORT/TABLE/INDEX/STATISTICS/INDEX_STATISTICS Processando o tipo de objeto SCHEMA_EXPORT/TABLE/CONSTRAINT/REF_CONSTRAINT Processando o tipo de objeto SCHEMA_EXPORT/TABLE/STATISTICS/TABLE_STATISTICS . . exportou SCOTT.DEPT 4.992 KB 4 linhas . . exportou SCOTT.EMP 5.648 KB 14 linhas . . exportou SCOTT.SALGRADE 4.898 KB 5 linhas . . exportou SCOTT.BONUS 0 KB 0 linhas Tabela-mestre LIXO.SYS_EXPORT_SCHEMA_01 carregada/descarregada com sucesso ** Conjunto de arquivos de dump para LIXO.SYS_EXPORT_SCHEMA_01 é: C:\APP\ORACLE\ADMIN\O11201\DPDUMP\objs_schema_SCOTT.DMP O job LIXO.SYS_EXPORT_SCHEMA_01 foi concluído com sucesso em 11:12:42 SE eu quiser filtrar por tablespace, REPETINDO que uma tablespace pode conter N objetos de não-sei-quantos usuários, eu informo A TABLESPACE, e não os usuários : C:\Users\chiappaexpdp lixo/lixo DIRECTORY=DATA_PUMP_DIR DUMPFILE=exp_tablespace_USERS.dmp LOGFILE=exp_tablespace_USERS.exp tablespaces=USERS COMPRESSION=ALL Export: Release 11.2.0.1.0 - Production on Qua Dez 3 11:15:16 2014 Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved. Conectado a: Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production With the Partitioning, OLAP, Data Mining and Real
[oracle_br] Novos Artigos sobre EXADATA
Bom dia amigos! Muito trabalho, por isso estou muito sumido aqui do grupo. Alguns artigos novos lá do nosso blog: http://certificacaobd.com.br/2014/10/23/exadata-vamos-falar-de-exadata/ http://certificacaobd.com.br/2014/11/09/exadata-o-que-e-oracle-exadata/ http://certificacaobd.com.br/2014/11/26/exadata-software-arquitetura-discos-e-comunicacao/ http://certificacaobd.com.br/2014/12/03/exadata-exadata-e-asm/ Escritos pelo Fernando Simon! Abraço!
Re: [oracle_br] Estouro de processos
Sem a menor sombra de dúvida : o alerta referente á isso é Database alert on % of Processes or Sessions Used, e iirc ele faz parte do conjunto-default quando vc adiciona um target de database... Só o que talvez vc tenha que ajustar é o threshold (iirc ele é por default algo de 70 ou 80% usado, o que é muito prum caso aonde vc quer ser alertado/informado assim que o bug lá da aplicação (BUG totalmente, como eu disse o db é Vítima aí no caso) mostrar a cara feia)... []s Chiappa
Re: [oracle_br] Estouro de processos
Chiappa, Consegui habilitar a métrica para monitorar PROCESSES no cloud control. Atenciosamente, Rogério Camatini. Em 3 de dezembro de 2014 11:21, Roger Camatini rogerio.camat...@gmail.com escreveu: Chiappa, Fiz a alteração mencionada, mas decidi manter os valores para PROCESSES e SESSIONS: NAME TYPEVALUE --- -- aq_tm_processes integer 1 cell_offload_processing boolean TRUE db_writer_processes integer 1 gcs_server_processes integer 0 global_txn_processes integer 1 job_queue_processes integer 10 log_archive_max_processesinteger 4 processesinteger 1000 processor_group_name string SQL show parameter session NAME TYPEVALUE --- -- java_max_sessionspace_size integer 0 java_soft_sessionspace_limit integer 0 license_max_sessions integer 0 license_sessions_warning integer 0 session_cached_cursors integer 50 session_max_open_files integer 10 sessions integer 1528 shared_server_sessions integer SQL exit Situação atual: oracle@hostname:/oracle ps -ef | grep homol11 | grep -v grep | wc -l 135 oracle@hostname:/oracle Situação após restart da instancia: oracle@hostname:/oracle ps -ef | grep homol11 | grep -v grep | wc -l 22 oracle@hostname:/oracle Utilizamos aqui o Cloud Control 12c, consigo monitorar essa anomalia com esta ferramenta? Atenciosamente, Rogério Camatini. Em 3 de dezembro de 2014 10:13, jlchia...@yahoo.com.br [oracle_br] oracle_br@yahoogrupos.com.br escreveu: Nada como consultar a fonte da verdade real, né não ? A query na RESOURCE_LIMIT mostra claramente que SIM, vc chegou a ter uma quantidade de sessions E de processes que bateu no limite, então MUITO CERTAMENTE isso foi a causa da tua impossibilidade de conectar... Vc vai ter que fazer o seguinte agora : 1. fazer a investigação (principalmente no log do listener, cfrme mostrado nos links que passei) para vc ver se realmente não está tendo leaking de processos : isso parece provável, pois a tua situação de agora, com mais de 700 processes para apenas 30 e poucas sessions absolutamente *** Não é Normal *** 2. alteração dos parâmetros : primeiro 1000 como job_queue_processes é questionável : via de regra isso não pega nada porque ninguém sai criando centenas de jobs simultãneos em banco, mas vai saber... Acho mais seguro vc colocar um valor não-default e Realista nesse cara... Também recomendo que, se vc achar por bem subir um pouco sessions/processes, que vc siga a fórmula da Doc (ie, (1.1 * PROCESSES) + 5, iirc) para SESSIONS e PROCESSES 3. restart do database (sendo banco homo, não-prod, não deve ter grandes impedimentos), para que zerem os contadores da resource_limit 4. ativar os recursos que vc tiver de MONITORAÇÃO nesse database, para ser Alertado quando o consumo chegar perto do limite : o OEM tem recursos pra isso por default, vc pode ter um job (interno ou externo ao db) que periodicamente checa isso, pode ter uma trigger de logon, enfim, n possibilidades... O ponto é que, pelo que vejo, está PROVADO que o problema é EXTERNO ao database, é aplicação abrindo muitas sessões e/ou com leaking e/ou com erro na config de pools e/ou criando centenas de jobs ou abrindo threads no database NADA disso tem a ver com o database, que no caso está sendo é Vítima desse consumo externo inapropriado... []s Chiappa
Re: [oracle_br] Estouro de processos
Maravilha : para seu registro futuro, faz um novo select na resource limit e counts na (G)V$session/(G)v$process e guarda essaa info : depois, (além da monitoração) de vez em quando dá uma consultada novamente e compara... E claro : se vc tem o OEM, provavelmente vc deve ter Licenciado e ativo aí o ASH/AWR, imagino : se sim, além de consultar as telas de Histórico de performance e recursos no OEM, vc pode efetuar consultas tipo a abaixo, para tentar identificar mais ou menos quando que vc tem picos de aumento de consumo de sessions/processes nas apps daí (OBVIAMENTE, filtrando por uma qtdade de dias razoável aí no seu ambiente) : -- histórico de processos AWR select a.instance_number, a.snap_id AWR_SNAP to_char(b.begin_interval_time,'dd-mon- hh24:mi:ss') , to_char(b.end_interval_time,'dd-mon- hh24:mi:ss') , a.resource_name,max_utilization from sys.wrh$_resource_limit A, sys.wrm$_snapshot b where a.resource_name like '%processes%' and a.snap_id=b.snap_id and a.instance_number=b.instance_number; []s Chiappa
Re: [oracle_br] Estouro de processos
Obrigado a todos pela ajuda. Em breve posto atualizações sobre esse caso. Atenciosamente, Rogério Camatini. Em 3 de dezembro de 2014 11:45, jlchia...@yahoo.com.br [oracle_br] oracle_br@yahoogrupos.com.br escreveu: Maravilha : para seu registro futuro, faz um novo select na resource limit e counts na (G)V$session/(G)v$process e guarda essaa info : depois, (além da monitoração) de vez em quando dá uma consultada novamente e compara... E claro : se vc tem o OEM, provavelmente vc deve ter Licenciado e ativo aí o ASH/AWR, imagino : se sim, além de consultar as telas de Histórico de performance e recursos no OEM, vc pode efetuar consultas tipo a abaixo, para tentar identificar mais ou menos quando que vc tem picos de aumento de consumo de sessions/processes nas apps daí (OBVIAMENTE, filtrando por uma qtdade de dias razoável aí no seu ambiente) : -- histórico de processos AWR select a.instance_number, a.snap_id AWR_SNAP to_char(b.begin_interval_time,'dd-mon- hh24:mi:ss') , to_char(b.end_interval_time,'dd-mon- hh24:mi:ss') , a.resource_name,max_utilization from sys.wrh$_resource_limit A, sys.wrm$_snapshot b where a.resource_name like '%processes%' and a.snap_id=b.snap_id and a.instance_number=b.instance_number; []s Chiappa
Re: [oracle_br] Equiparação de bases
Obrigado vitor, ajudou muito.
Respondendo à sua pergunta, o que queríamos era gerar um arquivo com as
comparações entre as bases e depois implementar as diferenças na base de
produção.
Em Quarta-feira, 26 de Novembro de 2014 13:11, Vitor Junior
vitorj...@gmail.com [oracle_br] oracle_br@yahoogrupos.com.br escreveu:
Aniway:
http://apgdiff.com/
Att,/Regards,
Vitor Jr.
Infraestrutura / Infrastructure Team
Oracle 11g DBA Certified Professional - OCPOracle Certified Expert, Oracle Real
Application Clusters 11g and Grid Infrastructure Administrator - OCE
Oracle Database 11g Performance Tuning Certified Expert - OCE
Oracle Exadata 11g Certified Implementation Specialist
Oracle Certified Associate, MySQL 5
mail, gtalk e msn: vitorj...@gmail.com
http://certificacaobd.com.br/
skype: vjunior1981https://mybizcard.co/vitor.jr.385628
Em 26 de novembro de 2014 12:52, Jales Jose Moraes malphig...@yahoo.com.br
[oracle_br] oracle_br@yahoogrupos.com.br escreveu:
Senhores sei que este não é o canal, mas como estou precisando
urgentemente do serviço, vou perguntar por aqui mesmo:
Estou precisando equiparar as bases de homologação com a de produção no
POSTGRES, alguém sabe uma ferramenta para tal serviço (se possível free)?
Para o Oracle eu uso o TOAD, mas não tem para o Postgres...
#yiv9238749240 #yiv9238749240 -- #yiv9238749240ygrp-mkp {border:1px solid
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv9238749240
#yiv9238749240ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv9238749240
#yiv9238749240ygrp-mkp #yiv9238749240hd
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px
0;}#yiv9238749240 #yiv9238749240ygrp-mkp #yiv9238749240ads
{margin-bottom:10px;}#yiv9238749240 #yiv9238749240ygrp-mkp .yiv9238749240ad
{padding:0 0;}#yiv9238749240 #yiv9238749240ygrp-mkp .yiv9238749240ad p
{margin:0;}#yiv9238749240 #yiv9238749240ygrp-mkp .yiv9238749240ad a
{color:#ff;text-decoration:none;}#yiv9238749240 #yiv9238749240ygrp-sponsor
#yiv9238749240ygrp-lc {font-family:Arial;}#yiv9238749240
#yiv9238749240ygrp-sponsor #yiv9238749240ygrp-lc #yiv9238749240hd {margin:10px
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv9238749240
#yiv9238749240ygrp-sponsor #yiv9238749240ygrp-lc .yiv9238749240ad
{margin-bottom:10px;padding:0 0;}#yiv9238749240 #yiv9238749240actions
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv9238749240
#yiv9238749240activity
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv9238749240
#yiv9238749240activity span {font-weight:700;}#yiv9238749240
#yiv9238749240activity span:first-child
{text-transform:uppercase;}#yiv9238749240 #yiv9238749240activity span a
{color:#5085b6;text-decoration:none;}#yiv9238749240 #yiv9238749240activity span
span {color:#ff7900;}#yiv9238749240 #yiv9238749240activity span
.yiv9238749240underline {text-decoration:underline;}#yiv9238749240
.yiv9238749240attach
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px
0;width:400px;}#yiv9238749240 .yiv9238749240attach div a
{text-decoration:none;}#yiv9238749240 .yiv9238749240attach img
{border:none;padding-right:5px;}#yiv9238749240 .yiv9238749240attach label
{display:block;margin-bottom:5px;}#yiv9238749240 .yiv9238749240attach label a
{text-decoration:none;}#yiv9238749240 blockquote {margin:0 0 0
4px;}#yiv9238749240 .yiv9238749240bold
{font-family:Arial;font-size:13px;font-weight:700;}#yiv9238749240
.yiv9238749240bold a {text-decoration:none;}#yiv9238749240 dd.yiv9238749240last
p a {font-family:Verdana;font-weight:700;}#yiv9238749240 dd.yiv9238749240last p
span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv9238749240
dd.yiv9238749240last p span.yiv9238749240yshortcuts
{margin-right:0;}#yiv9238749240 div.yiv9238749240attach-table div div a
{text-decoration:none;}#yiv9238749240 div.yiv9238749240attach-table
{width:400px;}#yiv9238749240 div.yiv9238749240file-title a, #yiv9238749240
div.yiv9238749240file-title a:active, #yiv9238749240
div.yiv9238749240file-title a:hover, #yiv9238749240 div.yiv9238749240file-title
a:visited {text-decoration:none;}#yiv9238749240 div.yiv9238749240photo-title a,
#yiv9238749240 div.yiv9238749240photo-title a:active, #yiv9238749240
div.yiv9238749240photo-title a:hover, #yiv9238749240
div.yiv9238749240photo-title a:visited {text-decoration:none;}#yiv9238749240
div#yiv9238749240ygrp-mlmsg #yiv9238749240ygrp-msg p a
span.yiv9238749240yshortcuts
{font-family:Verdana;font-size:10px;font-weight:normal;}#yiv9238749240
.yiv9238749240green {color:#628c2a;}#yiv9238749240 .yiv9238749240MsoNormal
{margin:0 0 0 0;}#yiv9238749240 o {font-size:0;}#yiv9238749240
#yiv9238749240photos div {float:left;width:72px;}#yiv9238749240
#yiv9238749240photos div div {border:1px solid
#66;height:62px;overflow:hidden;width:62px;}#yiv9238749240
#yiv9238749240photos div label
Re: [oracle_br] Re: Campo Calculado
Obrigado Chippa. Emerson Sanches Analista de Sistemas Em 3 de dezembro de 2014 10:27, jlchia...@yahoo.com.br [oracle_br] oracle_br@yahoogrupos.com.br escreveu: Adicionalmente, sendo 11g, se vc for usar a feature built-in veja em http://www.oracle.com/technetwork/database/database-technologies/rdb/automatic-columns-132042.pdf , nele vc tanto encontra exemplos adicionais de colunas computadas QUANTo ele também cita algumas das RESTRIÇÕES da feature... []s Chiappa
Re: [oracle_br] Re: Campo Calculado
Emerson Na versão 11g você pode criar uma coluna calculada (coluna virtual), mas a expressão não pode conter colunas de outras tabelas. Então, o que você quer, só com uma view/mview ou com trigger [ ]'s André Em 3 de dezembro de 2014 16:31, Emerson Sanches emerson.sanc...@gmail.com [oracle_br] oracle_br@yahoogrupos.com.br escreveu: Obrigado Chippa. Emerson Sanches Analista de Sistemas Em 3 de dezembro de 2014 10:27, jlchia...@yahoo.com.br [oracle_br] oracle_br@yahoogrupos.com.br escreveu: Adicionalmente, sendo 11g, se vc for usar a feature built-in veja em http://www.oracle.com/technetwork/database/database-technologies/rdb/automatic-columns-132042.pdf , nele vc tanto encontra exemplos adicionais de colunas computadas QUANTo ele também cita algumas das RESTRIÇÕES da feature... []s Chiappa
