[oracle_br] Re: Auditing - SYS.AUD$
2009/2/9 Júlio César Corrêa juliocesar.ora...@gmail.com Alguem do grupo sabe se esta tabela SYS.AUD$ tem alguma definição especial de storage? Porque aqui no trabalho está acontecendo de ela estourar o tamanho,mesmo com a tablespace SYSTEM estar com free space. O que encontrei é que o tamanho desta tabela depende dos parametros de storage da tablespace SYSTEM. O crescimento desta tabela é muito rapido.Por isso temos uma rotina que faz a limpeza desta tabela,porem mesmo assim hoje ocasionou o erro. Alguem teria mais informações? -- Júlio César Corrêa IS Technologist - Oracle DBA http://jccorrea.blogspot.com To stay competitive in the tech industry, never stop learning. Always be on the lookout for better ways of doing things and new technologies. Our industry does not reward people who let themselves stagnate John Hall, Senior Vice President, Oracle University -- Júlio César Corrêa IS Technologist - Oracle DBA http://jccorrea.blogspot.com To stay competitive in the tech industry, never stop learning. Always be on the lookout for better ways of doing things and new technologies. Our industry does not reward people who let themselves stagnate John Hall, Senior Vice President, Oracle University [As partes desta mensagem que não continham texto foram removidas] -- Atenção! As mensagens do grupo ORACLE_BR são de acesso público e de inteira responsabilidade de seus remetentes. Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/ -- Apostilas » Dicas e Exemplos » Função » Mundo Oracle » Package » Procedure » Scripts » Tutoriais - O GRUPO ORACLE_BR TEM SEU PROPRIO ESPAÇO! VISITE: http://www.oraclebr.com.br/ 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: oracle_br-unsubscr...@yahoogrupos.com.br * O uso que você faz do Yahoo! Grupos está sujeito aos: http://br.yahoo.com/info/utos.html
[oracle_br] Re: Auditing - SYS.AUD$
Um dos DBA's colocou o parametro de MAXEXTENTS para UNLIMITED,porem eu fiz algumas pesquisas e achei em outros artigos,foruns até do Don Burleson que a Oracle não recomenda colocar objetos SYS com MAXEXTENTS UNLIMITED. 2009/2/9 Júlio César Corrêa juliocesar.ora...@gmail.com Alguem do grupo sabe se esta tabela SYS.AUD$ tem alguma definição especial de storage? Porque aqui no trabalho está acontecendo de ela estourar o tamanho,mesmo com a tablespace SYSTEM estar com free space. O que encontrei é que o tamanho desta tabela depende dos parametros de storage da tablespace SYSTEM. O crescimento desta tabela é muito rapido.Por isso temos uma rotina que faz a limpeza desta tabela,porem mesmo assim hoje ocasionou o erro. Alguem teria mais informações? -- Júlio César Corrêa IS Technologist - Oracle DBA http://jccorrea.blogspot.com To stay competitive in the tech industry, never stop learning. Always be on the lookout for better ways of doing things and new technologies. Our industry does not reward people who let themselves stagnate John Hall, Senior Vice President, Oracle University -- Júlio César Corrêa IS Technologist - Oracle DBA http://jccorrea.blogspot.com To stay competitive in the tech industry, never stop learning. Always be on the lookout for better ways of doing things and new technologies. Our industry does not reward people who let themselves stagnate John Hall, Senior Vice President, Oracle University [As partes desta mensagem que não continham texto foram removidas] -- Atenção! As mensagens do grupo ORACLE_BR são de acesso público e de inteira responsabilidade de seus remetentes. Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/ -- Apostilas » Dicas e Exemplos » Função » Mundo Oracle » Package » Procedure » Scripts » Tutoriais - O GRUPO ORACLE_BR TEM SEU PROPRIO ESPAÇO! VISITE: http://www.oraclebr.com.br/ 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: oracle_br-unsubscr...@yahoogrupos.com.br * O uso que você faz do Yahoo! Grupos está sujeito aos: http://br.yahoo.com/info/utos.html
Re: [oracle_br] Re: Auditing - SYS.AUD$
Camarada, seria ideal vc mover a AUD$ para uma tablespace independente... Dá uma olhada no Note *Moving AUD$ to Another Tablespace and Adding Triggers to AUD$ (72460.1)* Ele explica certinho como fazer... E vc não terá mais estes problemas. Abraços. Gustavo Venturii. 2009/2/9 Júlio César Corrêa juliotubi...@yahoo.com.br Um dos DBA's colocou o parametro de MAXEXTENTS para UNLIMITED,porem eu fiz algumas pesquisas e achei em outros artigos,foruns até do Don Burleson que a Oracle não recomenda colocar objetos SYS com MAXEXTENTS UNLIMITED. 2009/2/9 Júlio César Corrêa juliocesar.ora...@gmail.com Alguem do grupo sabe se esta tabela SYS.AUD$ tem alguma definição especial de storage? Porque aqui no trabalho está acontecendo de ela estourar o tamanho,mesmo com a tablespace SYSTEM estar com free space. O que encontrei é que o tamanho desta tabela depende dos parametros de storage da tablespace SYSTEM. O crescimento desta tabela é muito rapido.Por isso temos uma rotina que faz a limpeza desta tabela,porem mesmo assim hoje ocasionou o erro. Alguem teria mais informações? -- Júlio César Corrêa IS Technologist - Oracle DBA http://jccorrea.blogspot.com To stay competitive in the tech industry, never stop learning. Always be on the lookout for better ways of doing things and new technologies. Our industry does not reward people who let themselves stagnate John Hall, Senior Vice President, Oracle University -- Júlio César Corrêa IS Technologist - Oracle DBA http://jccorrea.blogspot.com To stay competitive in the tech industry, never stop learning. Always be on the lookout for better ways of doing things and new technologies. Our industry does not reward people who let themselves stagnate John Hall, Senior Vice President, Oracle University [As partes desta mensagem que não continham texto foram removidas] -- Atenção! As mensagens do grupo ORACLE_BR são de acesso público e de inteira responsabilidade de seus remetentes. Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/ -- Apostilas » Dicas e Exemplos » Função » Mundo Oracle » Package » Procedure » Scripts » Tutoriais - O GRUPO ORACLE_BR TEM SEU PROPRIO ESPAÇO! VISITE: http://www.oraclebr.com.br/ Links do Yahoo! Grupos [As partes desta mensagem que não continham texto foram removidas] -- Atenção! As mensagens do grupo ORACLE_BR são de acesso público e de inteira responsabilidade de seus remetentes. Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/ -- Apostilas » Dicas e Exemplos » Função » Mundo Oracle » Package » Procedure » Scripts » Tutoriais - O GRUPO ORACLE_BR TEM SEU PROPRIO ESPAÇO! VISITE: http://www.oraclebr.com.br/ 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: oracle_br-unsubscr...@yahoogrupos.com.br * O uso que você faz do Yahoo! Grupos está sujeito aos: http://br.yahoo.com/info/utos.html
[oracle_br] Re: Auditing - SYS.AUD$
Eu me pergunto, ** qual ** será a exata msg de estouro que ele está tendo (unable to allocate extent of, ou Maximum Extents reached in a table) ?? Pois vc definir MAXIMUM EXTENTS, como os DBAs dele lá fizeram, só faz sentido pro último erro, se não foi esse , me parece que neguinho tá meio perdido pelaí, tão chutando a torto e a direito... E qual será a versão de banco do colega, e como fisicamente a tablespaces SYSTEM dele está criada ? Isso se pergunta porque SE for banco 10g não-migrado, o default é se ter tablespace SYSTEM LMT e com extent size SYSTEM-allocated , caso em que se tem POUCOS tamanhos diferentes de extents, e tamanhos múltiplos entre si, é remota a chance de haver FRAGMENTAÇÂO real física (ie, largo espaço livre mas com extent size totalmente diferente do especificado no segmento, no caso o AUD$). Já ** SE ** a tablespace SYSTEM dele está como DMT, como era default em versões mais antigas, fatalmente abre a chance de fragmentação física estar ocorrendo , tipo a tablespace SYSTEM possui n extents livres mas de tamanhos diferentes entre si, e incompatíveis com o especificvado na AUD$ Em qquer caso acho que a recomendação de mover a AUD$ para fora da SYSTEM , recriando-a em tablespace á parte, pode ser aplicado, sim []s Chiappa --- Em oracle_br@yahoogrupos.com.br, Gustavo Venturini de Lima gventur...@... escreveu Camarada, seria ideal vc mover a AUD$ para uma tablespace independente... Dá uma olhada no Note *Moving AUD$ to Another Tablespace and Adding Triggers to AUD$ (72460.1)* Ele explica certinho como fazer... E vc não terá mais estes problemas. Abraços. Gustavo Venturii. 2009/2/9 Júlio César Corrêa juliotubi...@... Um dos DBA's colocou o parametro de MAXEXTENTS para UNLIMITED,porem eu fiz algumas pesquisas e achei em outros artigos,foruns até do Don Burleson que a Oracle não recomenda colocar objetos SYS com MAXEXTENTS UNLIMITED. 2009/2/9 Júlio César Corrêa juliocesar.ora...@... Alguem do grupo sabe se esta tabela SYS.AUD$ tem alguma definição especial de storage? Porque aqui no trabalho está acontecendo de ela estourar o tamanho,mesmo com a tablespace SYSTEM estar com free space. O que encontrei é que o tamanho desta tabela depende dos parametros de storage da tablespace SYSTEM. O crescimento desta tabela é muito rapido.Por isso temos uma rotina que faz a limpeza desta tabela,porem mesmo assim hoje ocasionou o erro. Alguem teria mais informações? -- Júlio César Corrêa IS Technologist - Oracle DBA http://jccorrea.blogspot.com To stay competitive in the tech industry, never stop learning. Always be on the lookout for better ways of doing things and new technologies. Our industry does not reward people who let themselves stagnate John Hall, Senior Vice President, Oracle University -- Júlio César Corrêa IS Technologist - Oracle DBA http://jccorrea.blogspot.com To stay competitive in the tech industry, never stop learning. Always be on the lookout for better ways of doing things and new technologies. Our industry does not reward people who let themselves stagnate John Hall, Senior Vice President, Oracle University [As partes desta mensagem que não continham texto foram removidas] -- Atenção! As mensagens do grupo ORACLE_BR são de acesso público e de inteira responsabilidade de seus remetentes. Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/ -- Apostilas » Dicas e Exemplos » Função » Mundo Oracle » Package » Procedure » Scripts » Tutoriais - O GRUPO ORACLE_BR TEM SEU PROPRIO ESPAÇO! VISITE: http://www.oraclebr.com.br/ Links do Yahoo! Grupos [As partes desta mensagem que não continham texto foram removidas]
Re: [oracle_br] Re: Auditing - SYS.AUD$
Vamos lá. Ambiente: Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 RHEL 4 on IBM Power PC 64(P550). Tablespace SYSTEM: TABLESPACE_NAME SYSTEM BLOCK_SIZE 8192 INITIAL_EXTENT 65536 NEXT_EXTENT MIN_EXTENTS 1 MAX_EXTENTS 2147483645 PCT_INCREASE MIN_EXTLEN 65536 STATUS ONLINE CONTENTS PERMANENT LOGGING LOGGING FORCE_LOGGING NO EXTENT_MANAGEMENT LOCAL ALLOCATION_TYPE SYSTEM PLUGGED_IN NO SEGMENT_SPACE_MANAGEMENT MANUAL DEF_TAB_COMPRESSION DISABLED RETENTION NOT APPLY BIGFILE NO Pelo que vi ela é LMT.E por consequencia as outras também.Tenho a informação que ele não foi migrado. Temos uma aplicação(não gerenciada por nós,é de uma prestadora) que faz as vendas de credito para os clientes.Hoje aconteceu que parou as vendas.A empresa que gerencia a aplicação depois de um tempo,informou que o erro encontrado foi : ORA-02002 error while writing to audit trail Procurei o erro e reportei ao DBA Pl.,assim que ele truncou a tabela de audit,voltou a funcionar a aplicação. Então suponho que seja este o problema.Porque na hora ele estava monitorando e disse que o banco estava ok,estava tranquilo,sem locks.O que acontecia é que os DML's falhavam.Na hora não pensei em criar uma tabela e tentar um insert para ver s egerava erro ORA- 02002.Nem sabia que poderia ser isso. O outro DBA me disse que não era problema porque a system está com espaço livre e tabela SYS.AUD$ está com maxextents unlimited. Dando uma pesquisada na documentação,diz que a sys.aud$ segue os parametros de storage da system. Se vc verifica os parametros da sys.aud$ é identico aos da SYSTEM. Acho que é isso. 2009/2/9 jlchiappa jlchia...@yahoo.com.br Eu me pergunto, ** qual ** será a exata msg de estouro que ele está tendo (unable to allocate extent of, ou Maximum Extents reached in a table) ?? Pois vc definir MAXIMUM EXTENTS, como os DBAs dele lá fizeram, só faz sentido pro último erro, se não foi esse , me parece que neguinho tá meio perdido pelaí, tão chutando a torto e a direito... E qual será a versão de banco do colega, e como fisicamente a tablespaces SYSTEM dele está criada ? Isso se pergunta porque SE for banco 10g não-migrado, o default é se ter tablespace SYSTEM LMT e com extent size SYSTEM-allocated , caso em que se tem POUCOS tamanhos diferentes de extents, e tamanhos múltiplos entre si, é remota a chance de haver FRAGMENTAÇÂO real física (ie, largo espaço livre mas com extent size totalmente diferente do especificado no segmento, no caso o AUD$). Já ** SE ** a tablespace SYSTEM dele está como DMT, como era default em versões mais antigas, fatalmente abre a chance de fragmentação física estar ocorrendo , tipo a tablespace SYSTEM possui n extents livres mas de tamanhos diferentes entre si, e incompatíveis com o especificvado na AUD$ Em qquer caso acho que a recomendação de mover a AUD$ para fora da SYSTEM , recriando-a em tablespace á parte, pode ser aplicado, sim []s Chiappa --- Em oracle_br@yahoogrupos.com.br oracle_br%40yahoogrupos.com.br, Gustavo Venturini de Lima gventur...@... escreveu Camarada, seria ideal vc mover a AUD$ para uma tablespace independente... Dá uma olhada no Note *Moving AUD$ to Another Tablespace and Adding Triggers to AUD$ (72460.1)* Ele explica certinho como fazer... E vc não terá mais estes problemas. Abraços. Gustavo Venturii. 2009/2/9 Júlio César Corrêa juliotubi...@... Um dos DBA's colocou o parametro de MAXEXTENTS para UNLIMITED,porem eu fiz algumas pesquisas e achei em outros artigos,foruns até do Don Burleson que a Oracle não recomenda colocar objetos SYS com MAXEXTENTS UNLIMITED. 2009/2/9 Júlio César Corrêa juliocesar.ora...@... Alguem do grupo sabe se esta tabela SYS.AUD$ tem alguma definição especial de storage? Porque aqui no trabalho está acontecendo de ela estourar o tamanho,mesmo com a tablespace SYSTEM estar com free space. O que encontrei é que o tamanho desta tabela depende dos parametros de storage da tablespace SYSTEM. O crescimento desta tabela é muito rapido.Por isso temos uma rotina que faz a limpeza desta tabela,porem mesmo assim hoje ocasionou o erro. Alguem teria mais informações? -- Júlio César Corrêa IS Technologist - Oracle DBA http://jccorrea.blogspot.com To stay competitive in the tech industry, never stop learning. Always be on the lookout for better ways of doing things and new technologies. Our industry does not reward people who let themselves stagnate John Hall, Senior Vice President, Oracle University -- Júlio César Corrêa IS Technologist - Oracle DBA http://jccorrea.blogspot.com To stay competitive in the tech industry, never stop learning. Always be on the lookout for better ways of doing things and new technologies. Our industry does not reward people who let themselves stagnate John Hall, Senior Vice President, Oracle University
Re: [oracle_br] Re: Auditing - SYS.AUD$
Chiappa e companheiros, O que passei ajuda? Pelo visto Chiappa está como vc disse. Este parametro de storage MAX_EXTENTS está com valor 2147483645 para todas a tablespaces.Isto é default em tablespace LMT?Isto é um limite de EXTENTS? 2009/2/9 Júlio César Corrêa juliotubi...@yahoo.com.br Vamos lá. Ambiente: Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 RHEL 4 on IBM Power PC 64(P550). Tablespace SYSTEM: TABLESPACE_NAME SYSTEM BLOCK_SIZE 8192 INITIAL_EXTENT 65536 NEXT_EXTENT MIN_EXTENTS 1 MAX_EXTENTS 2147483645 PCT_INCREASE MIN_EXTLEN 65536 STATUS ONLINE CONTENTS PERMANENT LOGGING LOGGING FORCE_LOGGING NO EXTENT_MANAGEMENT LOCAL ALLOCATION_TYPE SYSTEM PLUGGED_IN NO SEGMENT_SPACE_MANAGEMENT MANUAL DEF_TAB_COMPRESSION DISABLED RETENTION NOT APPLY BIGFILE NO Pelo que vi ela é LMT.E por consequencia as outras também.Tenho a informação que ele não foi migrado. Temos uma aplicação(não gerenciada por nós,é de uma prestadora) que faz as vendas de credito para os clientes.Hoje aconteceu que parou as vendas.A empresa que gerencia a aplicação depois de um tempo,informou que o erro encontrado foi : ORA-02002 error while writing to audit trail Procurei o erro e reportei ao DBA Pl.,assim que ele truncou a tabela de audit,voltou a funcionar a aplicação. Então suponho que seja este o problema.Porque na hora ele estava monitorando e disse que o banco estava ok,estava tranquilo,sem locks.O que acontecia é que os DML's falhavam.Na hora não pensei em criar uma tabela e tentar um insert para ver s egerava erro ORA- 02002.Nem sabia que poderia ser isso. O outro DBA me disse que não era problema porque a system está com espaço livre e tabela SYS.AUD$ está com maxextents unlimited. Dando uma pesquisada na documentação,diz que a sys.aud$ segue os parametros de storage da system. Se vc verifica os parametros da sys.aud$ é identico aos da SYSTEM. Acho que é isso. 2009/2/9 jlchiappa jlchia...@yahoo.com.br Eu me pergunto, ** qual ** será a exata msg de estouro que ele está tendo (unable to allocate extent of, ou Maximum Extents reached in a table) ?? Pois vc definir MAXIMUM EXTENTS, como os DBAs dele lá fizeram, só faz sentido pro último erro, se não foi esse , me parece que neguinho tá meio perdido pelaí, tão chutando a torto e a direito... E qual será a versão de banco do colega, e como fisicamente a tablespaces SYSTEM dele está criada ? Isso se pergunta porque SE for banco 10g não-migrado, o default é se ter tablespace SYSTEM LMT e com extent size SYSTEM-allocated , caso em que se tem POUCOS tamanhos diferentes de extents, e tamanhos múltiplos entre si, é remota a chance de haver FRAGMENTAÇÂO real física (ie, largo espaço livre mas com extent size totalmente diferente do especificado no segmento, no caso o AUD$). Já ** SE ** a tablespace SYSTEM dele está como DMT, como era default em versões mais antigas, fatalmente abre a chance de fragmentação física estar ocorrendo , tipo a tablespace SYSTEM possui n extents livres mas de tamanhos diferentes entre si, e incompatíveis com o especificvado na AUD$ Em qquer caso acho que a recomendação de mover a AUD$ para fora da SYSTEM , recriando-a em tablespace á parte, pode ser aplicado, sim []s Chiappa --- Em oracle_br@yahoogrupos.com.br oracle_br%40yahoogrupos.com.br, Gustavo Venturini de Lima gventur...@... escreveu Camarada, seria ideal vc mover a AUD$ para uma tablespace independente... Dá uma olhada no Note *Moving AUD$ to Another Tablespace and Adding Triggers to AUD$ (72460.1)* Ele explica certinho como fazer... E vc não terá mais estes problemas. Abraços. Gustavo Venturii. 2009/2/9 Júlio César Corrêa juliotubi...@... Um dos DBA's colocou o parametro de MAXEXTENTS para UNLIMITED,porem eu fiz algumas pesquisas e achei em outros artigos,foruns até do Don Burleson que a Oracle não recomenda colocar objetos SYS com MAXEXTENTS UNLIMITED. 2009/2/9 Júlio César Corrêa juliocesar.ora...@... Alguem do grupo sabe se esta tabela SYS.AUD$ tem alguma definição especial de storage? Porque aqui no trabalho está acontecendo de ela estourar o tamanho,mesmo com a tablespace SYSTEM estar com free space. O que encontrei é que o tamanho desta tabela depende dos parametros de storage da tablespace SYSTEM. O crescimento desta tabela é muito rapido.Por isso temos uma rotina que faz a limpeza desta tabela,porem mesmo assim hoje ocasionou o erro. Alguem teria mais informações? -- Júlio César Corrêa IS Technologist - Oracle DBA http://jccorrea.blogspot.com To stay competitive in the tech industry, never stop learning. Always be on the lookout for better ways of doing things and new technologies. Our industry does not reward people who let themselves stagnate John Hall, Senior Vice President, Oracle University -- Júlio César Corrêa
[oracle_br] Re: Auditing - SYS.AUD$
Intão : sim, esse valor da MAX_EXTENTS é o limite de extents que podem ser alocados, e é resultado de vc ter feito o ALTER UNLIMITED, o UNLIMITED é convertida pra esse valorzão aí . No caso, pra gente poder teorizar melhor o que aconteceu, seria legal que além dessas infos, como eu disse na msg anterior, tivéssemos o erro ** EXATO ** , o error stack dum DML feito no sqlplus falhando, , bem como uma amostra do ALERT.LOG em questão na hora que deu o erro, o tamanho EXATO que estava de free space na system, mas de qquer forma : vc mostrou na msg anterior que a tablespace SYSTEM é LMT com extent size automático, então a chance de fragmentação física é praticamente nenhuma. Assim, a suposição seria mesmo de que na hora em questão ou a AUD$ estava crescendo a mais do que a SYSTEM tinha livre, ou tinha mais algum objeto competindo com ela por espaço na SYSTEM : agora vc não tem mais a situação, mas é uma suposição razoável. A recomendação é mesmo mover a AUD$ pruma tablespace própria, descobrir EXATAMENTE o que estava rodando quando deu o erro e ** monitorar ** o crescimento da sujeita - isso pode acabar te demonstrando que há alguma rotina X aí que gera montanhas de entradas na aud$, se for o caso a aud$ tem que ser limpa antes dela, e/ou talvez vc tenha que diminuir a frequência do seu job de limpeza da aud$. []s Chiappa --- Em oracle_br@yahoogrupos.com.br, Júlio César Corrêa juliotubi...@... escreveu Chiappa e companheiros, O que passei ajuda? Pelo visto Chiappa está como vc disse. Este parametro de storage MAX_EXTENTS está com valor 2147483645 para todas a tablespaces.Isto é default em tablespace LMT?Isto é um limite de EXTENTS? 2009/2/9 Júlio César Corrêa juliotubi...@... Vamos lá. Ambiente: Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 RHEL 4 on IBM Power PC 64(P550). Tablespace SYSTEM: TABLESPACE_NAME SYSTEM BLOCK_SIZE 8192 INITIAL_EXTENT 65536 NEXT_EXTENT MIN_EXTENTS 1 MAX_EXTENTS 2147483645 PCT_INCREASE MIN_EXTLEN 65536 STATUS ONLINE CONTENTS PERMANENT LOGGING LOGGING FORCE_LOGGING NO EXTENT_MANAGEMENT LOCAL ALLOCATION_TYPE SYSTEM PLUGGED_IN NO SEGMENT_SPACE_MANAGEMENT MANUAL DEF_TAB_COMPRESSION DISABLED RETENTION NOT APPLY BIGFILE NO Pelo que vi ela é LMT.E por consequencia as outras também.Tenho a informação que ele não foi migrado. Temos uma aplicação(não gerenciada por nós,é de uma prestadora) que faz as vendas de credito para os clientes.Hoje aconteceu que parou as vendas.A empresa que gerencia a aplicação depois de um tempo,informou que o erro encontrado foi : ORA-02002 error while writing to audit trail Procurei o erro e reportei ao DBA Pl.,assim que ele truncou a tabela de audit,voltou a funcionar a aplicação. Então suponho que seja este o problema.Porque na hora ele estava monitorando e disse que o banco estava ok,estava tranquilo,sem locks.O que acontecia é que os DML's falhavam.Na hora não pensei em criar uma tabela e tentar um insert para ver s egerava erro ORA- 02002.Nem sabia que poderia ser isso. O outro DBA me disse que não era problema porque a system está com espaço livre e tabela SYS.AUD$ está com maxextents unlimited. Dando uma pesquisada na documentação,diz que a sys.aud$ segue os parametros de storage da system. Se vc verifica os parametros da sys.aud$ é identico aos da SYSTEM. Acho que é isso. 2009/2/9 jlchiappa jlchia...@... Eu me pergunto, ** qual ** será a exata msg de estouro que ele está tendo (unable to allocate extent of, ou Maximum Extents reached in a table) ?? Pois vc definir MAXIMUM EXTENTS, como os DBAs dele lá fizeram, só faz sentido pro último erro, se não foi esse , me parece que neguinho tá meio perdido pelaí, tão chutando a torto e a direito... E qual será a versão de banco do colega, e como fisicamente a tablespaces SYSTEM dele está criada ? Isso se pergunta porque SE for banco 10g não-migrado, o default é se ter tablespace SYSTEM LMT e com extent size SYSTEM-allocated , caso em que se tem POUCOS tamanhos diferentes de extents, e tamanhos múltiplos entre si, é remota a chance de haver FRAGMENTAÇÂO real física (ie, largo espaço livre mas com extent size totalmente diferente do especificado no segmento, no caso o AUD$). Já ** SE ** a tablespace SYSTEM dele está como DMT, como era default em versões mais antigas, fatalmente abre a chance de fragmentação física estar ocorrendo , tipo a tablespace SYSTEM possui n extents livres mas de tamanhos diferentes entre si, e incompatíveis com o especificvado na AUD$ Em qquer caso acho que a recomendação de mover a AUD$ para fora da SYSTEM , recriando-a em tablespace á parte, pode ser aplicado, sim []s Chiappa --- Em oracle_br@yahoogrupos.com.br oracle_br%40yahoogrupos.com.br, Gustavo Venturini de Lima gventurini@ escreveu Camarada, seria ideal vc mover a AUD$ para uma tablespace independente...
Re: [oracle_br] Re: Auditing - SYS.AUD$
Show de bola Chiappa. Bela explanação. Pena Vou passar estas informações para os colegas aqui e já posso lhe dizer que tem uma aplicação suspeita de gerar montanhas de entradas na aud$.É uma transação de venda que insere cada atividade em que ela está para cada venda feita.Na verdade ela insere(insert mesmo) em uma tabela de log desse sistema.São sei passos para venda e são feito 6 inserts!Tem uma média de 5.000 transações X 6 inserts.Pelo que conversei com o pessoal destes sistemas,todos eles não usam muito update.Cada estado de uma transação,loga o seu estado em uma tabela.Então a tabela aud$ não aguentou. Pelo visto se eu calcular o valor de MAXEXTENTS X o tamanho de cada EXTENT em KB tenho o tamho maximo da tabela AUD$.Correto? Provavelmente a procedure de expurgo do meu amigo DBA aqui fez o serviço dela,mas devido ao aumento de transação neste dia(volta as aulas e outras coisas) não foi suficiente. Legal esta conversa. Já passei a nota do metalink aqui e vamos estudar como se faz a migração(move). Vlw, 2009/2/9 jlchiappa jlchia...@yahoo.com.br Intão : sim, esse valor da MAX_EXTENTS é o limite de extents que podem ser alocados, e é resultado de vc ter feito o ALTER UNLIMITED, o UNLIMITED é convertida pra esse valorzão aí . No caso, pra gente poder teorizar melhor o que aconteceu, seria legal que além dessas infos, como eu disse na msg anterior, tivéssemos o erro ** EXATO ** , o error stack dum DML feito no sqlplus falhando, , bem como uma amostra do ALERT.LOG em questão na hora que deu o erro, o tamanho EXATO que estava de free space na system, mas de qquer forma : vc mostrou na msg anterior que a tablespace SYSTEM é LMT com extent size automático, então a chance de fragmentação física é praticamente nenhuma. Assim, a suposição seria mesmo de que na hora em questão ou a AUD$ estava crescendo a mais do que a SYSTEM tinha livre, ou tinha mais algum objeto competindo com ela por espaço na SYSTEM : agora vc não tem mais a situação, mas é uma suposição razoável. A recomendação é mesmo mover a AUD$ pruma tablespace própria, descobrir EXATAMENTE o que estava rodando quando deu o erro e ** monitorar ** o crescimento da sujeita - isso pode acabar te demonstrando que há alguma rotina X aí que gera montanhas de entradas na aud$, se for o caso a aud$ tem que ser limpa antes dela, e/ou talvez vc tenha que diminuir a frequência do seu job de limpeza da aud$. []s Chiappa --- Em oracle_br@yahoogrupos.com.br oracle_br%40yahoogrupos.com.br, Júlio César Corrêa juliotubi...@... escreveu Chiappa e companheiros, O que passei ajuda? Pelo visto Chiappa está como vc disse. Este parametro de storage MAX_EXTENTS está com valor 2147483645 para todas a tablespaces.Isto é default em tablespace LMT?Isto é um limite de EXTENTS? 2009/2/9 Júlio César Corrêa juliotubi...@... Vamos lá. Ambiente: Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 RHEL 4 on IBM Power PC 64(P550). Tablespace SYSTEM: TABLESPACE_NAME SYSTEM BLOCK_SIZE 8192 INITIAL_EXTENT 65536 NEXT_EXTENT MIN_EXTENTS 1 MAX_EXTENTS 2147483645 PCT_INCREASE MIN_EXTLEN 65536 STATUS ONLINE CONTENTS PERMANENT LOGGING LOGGING FORCE_LOGGING NO EXTENT_MANAGEMENT LOCAL ALLOCATION_TYPE SYSTEM PLUGGED_IN NO SEGMENT_SPACE_MANAGEMENT MANUAL DEF_TAB_COMPRESSION DISABLED RETENTION NOT APPLY BIGFILE NO Pelo que vi ela é LMT.E por consequencia as outras também.Tenho a informação que ele não foi migrado. Temos uma aplicação(não gerenciada por nós,é de uma prestadora) que faz as vendas de credito para os clientes.Hoje aconteceu que parou as vendas.A empresa que gerencia a aplicação depois de um tempo,informou que o erro encontrado foi : ORA-02002 error while writing to audit trail Procurei o erro e reportei ao DBA Pl.,assim que ele truncou a tabela de audit,voltou a funcionar a aplicação. Então suponho que seja este o problema.Porque na hora ele estava monitorando e disse que o banco estava ok,estava tranquilo,sem locks.O que acontecia é que os DML's falhavam.Na hora não pensei em criar uma tabela e tentar um insert para ver s egerava erro ORA- 02002.Nem sabia que poderia ser isso. O outro DBA me disse que não era problema porque a system está com espaço livre e tabela SYS.AUD$ está com maxextents unlimited. Dando uma pesquisada na documentação,diz que a sys.aud$ segue os parametros de storage da system. Se vc verifica os parametros da sys.aud$ é identico aos da SYSTEM. Acho que é isso. 2009/2/9 jlchiappa jlchia...@... Eu me pergunto, ** qual ** será a exata msg de estouro que ele está tendo (unable to allocate extent of, ou Maximum Extents reached in a table) ?? Pois vc definir MAXIMUM EXTENTS, como os DBAs dele lá fizeram, só faz sentido pro último erro, se não foi esse , me parece que neguinho tá meio perdido pelaí, tão
Re: [oracle_br] Re: Auditing - SYS.AUD$
Pena que não pegamos o erro na hora do incidente,senão tinha mais assunto ae. Obrigado a todos, Julio Cesar Correa 2009/2/9 jlchiappa jlchia...@yahoo.com.br Intão : sim, esse valor da MAX_EXTENTS é o limite de extents que podem ser alocados, e é resultado de vc ter feito o ALTER UNLIMITED, o UNLIMITED é convertida pra esse valorzão aí . No caso, pra gente poder teorizar melhor o que aconteceu, seria legal que além dessas infos, como eu disse na msg anterior, tivéssemos o erro ** EXATO ** , o error stack dum DML feito no sqlplus falhando, , bem como uma amostra do ALERT.LOG em questão na hora que deu o erro, o tamanho EXATO que estava de free space na system, mas de qquer forma : vc mostrou na msg anterior que a tablespace SYSTEM é LMT com extent size automático, então a chance de fragmentação física é praticamente nenhuma. Assim, a suposição seria mesmo de que na hora em questão ou a AUD$ estava crescendo a mais do que a SYSTEM tinha livre, ou tinha mais algum objeto competindo com ela por espaço na SYSTEM : agora vc não tem mais a situação, mas é uma suposição razoável. A recomendação é mesmo mover a AUD$ pruma tablespace própria, descobrir EXATAMENTE o que estava rodando quando deu o erro e ** monitorar ** o crescimento da sujeita - isso pode acabar te demonstrando que há alguma rotina X aí que gera montanhas de entradas na aud$, se for o caso a aud$ tem que ser limpa antes dela, e/ou talvez vc tenha que diminuir a frequência do seu job de limpeza da aud$. []s Chiappa --- Em oracle_br@yahoogrupos.com.br oracle_br%40yahoogrupos.com.br, Júlio César Corrêa juliotubi...@... escreveu Chiappa e companheiros, O que passei ajuda? Pelo visto Chiappa está como vc disse. Este parametro de storage MAX_EXTENTS está com valor 2147483645 para todas a tablespaces.Isto é default em tablespace LMT?Isto é um limite de EXTENTS? 2009/2/9 Júlio César Corrêa juliotubi...@... Vamos lá. Ambiente: Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 RHEL 4 on IBM Power PC 64(P550). Tablespace SYSTEM: TABLESPACE_NAME SYSTEM BLOCK_SIZE 8192 INITIAL_EXTENT 65536 NEXT_EXTENT MIN_EXTENTS 1 MAX_EXTENTS 2147483645 PCT_INCREASE MIN_EXTLEN 65536 STATUS ONLINE CONTENTS PERMANENT LOGGING LOGGING FORCE_LOGGING NO EXTENT_MANAGEMENT LOCAL ALLOCATION_TYPE SYSTEM PLUGGED_IN NO SEGMENT_SPACE_MANAGEMENT MANUAL DEF_TAB_COMPRESSION DISABLED RETENTION NOT APPLY BIGFILE NO Pelo que vi ela é LMT.E por consequencia as outras também.Tenho a informação que ele não foi migrado. Temos uma aplicação(não gerenciada por nós,é de uma prestadora) que faz as vendas de credito para os clientes.Hoje aconteceu que parou as vendas.A empresa que gerencia a aplicação depois de um tempo,informou que o erro encontrado foi : ORA-02002 error while writing to audit trail Procurei o erro e reportei ao DBA Pl.,assim que ele truncou a tabela de audit,voltou a funcionar a aplicação. Então suponho que seja este o problema.Porque na hora ele estava monitorando e disse que o banco estava ok,estava tranquilo,sem locks.O que acontecia é que os DML's falhavam.Na hora não pensei em criar uma tabela e tentar um insert para ver s egerava erro ORA- 02002.Nem sabia que poderia ser isso. O outro DBA me disse que não era problema porque a system está com espaço livre e tabela SYS.AUD$ está com maxextents unlimited. Dando uma pesquisada na documentação,diz que a sys.aud$ segue os parametros de storage da system. Se vc verifica os parametros da sys.aud$ é identico aos da SYSTEM. Acho que é isso. 2009/2/9 jlchiappa jlchia...@... Eu me pergunto, ** qual ** será a exata msg de estouro que ele está tendo (unable to allocate extent of, ou Maximum Extents reached in a table) ?? Pois vc definir MAXIMUM EXTENTS, como os DBAs dele lá fizeram, só faz sentido pro último erro, se não foi esse , me parece que neguinho tá meio perdido pelaí, tão chutando a torto e a direito... E qual será a versão de banco do colega, e como fisicamente a tablespaces SYSTEM dele está criada ? Isso se pergunta porque SE for banco 10g não-migrado, o default é se ter tablespace SYSTEM LMT e com extent size SYSTEM-allocated , caso em que se tem POUCOS tamanhos diferentes de extents, e tamanhos múltiplos entre si, é remota a chance de haver FRAGMENTAÇÂO real física (ie, largo espaço livre mas com extent size totalmente diferente do especificado no segmento, no caso o AUD$). Já ** SE ** a tablespace SYSTEM dele está como DMT, como era default em versões mais antigas, fatalmente abre a chance de fragmentação física estar ocorrendo , tipo a tablespace SYSTEM possui n extents livres mas de tamanhos diferentes entre si, e incompatíveis com o especificvado na AUD$ Em qquer caso acho que a recomendação de mover a AUD$ para
