Re: [oracle_br] Re: Privilégios
Obrigado pessoal, sobre as outras soluções como (AUDIT, VIEW MATERIALIZADAS etc...) já havia verificado e até uso em algum casos, mas esta solução precisa ser genéria (teria outros bancos de dados de outros fornecedores) e precisaria gravar da mesma forma esses LOGs, pois isso pensei em trigger, já que os outros bancos que utilizamos também é possível implementar a mesma solução. Mas claro que iremos testar muito antes de colocar isso em produção.. se tivermos resultados ruins iremos pensar em outra solução. Obrigado. Em 6 de setembro de 2013 19:49, J. Laurindo Chiappa escreveu: > ** > > > Um exemplo demonstrando o que eu disse : primeiro, crio o usuário > SISTEMA,com os privilégios mínimos : > > SYSTEM@O10GR2:SQL>create user SISTEMA identified by sistema; > > Usußrio criado. > > SYSTEM@O10GR2:SQL>grant create table to sistema; > > ConcessÒo bem-sucedida. > > SYSTEM@O10GR2:SQL>grant create trigger to sistema; > > ConcessÒo bem-sucedida. > > SYSTEM@O10GR2:SQL>grant create session to SISTEMA; > > ConcessÒo bem-sucedida. > > => ÓBVIO, num caso real seria uma tablespace específica, e provavelmente > SEM quota ilimitada > > SYSTEM@O10GR2:SQL>alter user sistema quota unlimited on users; > > Usußrio alterado. > > SYSTEM@O10GR2:SQL>grant create role to SISTEMA; > > ConcessÒo bem-sucedida. > > ==> okdoc, vamos criar o schema de LOGs : > > SYSTEM@O10GR2:SQL>create user LOG_SCHEMA identified by LOG_SCHEMA; > > Usußrio criado. > > => novamente, a tablespace USERS aqui é só para o teste... > > SYSTEM@O10GR2:SQL>alter user LOG_SCHEMA quota unlimited on USERS; > > Usußrio alterado. > > => crio as tabelas de logs... > > SYSTEM@O10GR2:SQL>create table LOG_SCHEMA.LOG_INS_TAB_TESTE(username > varchar2(40), data_insert date); > > Tabela criada. > > => e o usuário SISTEMA recebe o GRANT de INSERT nelas... > > SYSTEM@O10GR2:SQL>grant insert on LOG_SCHEMA.LOG_INS_TAB_TESTE to SISTEMA; > > ConcessÒo bem-sucedida. > > ===>> Tudo pronto, vamos criar as tabelas e os triggers de log no usuário > SISTEMA : > > SYSTEM@O10GR2:SQL>conn sistema/sistema > Conectado. > > SISTEMA@O10GR2:SQL>create table TAB_TESTE(c1 number, c2 varchar2(80)); > > Tabela criada. > > SISTEMA@O10GR2:SQL>create or replace trigger TRG_INS_TAB_TESTE after > insert on TAB_TESTE > 2 BEGIN > 3 insert into LOG_SCHEMA.LOG_INS_TAB_TESTE values(user, sysdate); > 4 END; > 5 / > > Gatilho criado. > > => okdoc, agora o usuário SISTEMA vai dar via ROLEs os privilégios para os > usuários-finais , que no meu caso vai ser o SCOTT : > > SISTEMA@O10GR2:SQL>create role ROLE_INSERT ; > > AtribuiþÒo criada. > > SISTEMA@O10GR2:SQL>grant INSERT on TAB_TESTE to ROLE_INSERT; > > ConcessÒo bem-sucedida. > > SISTEMA@O10GR2:SQL>grant ROLE_INSERT to scott; > > ConcessÒo bem-sucedida. > > ==> Muito bem, o usuário final faz o INSERT dele : > > SISTEMA@O10GR2:SQL>conn scott/tiger > Conectado. > > SessÒo alterada. > > SCOTT@O10GR2:SQL>insert into SISTEMA.tab_teste values(1, 'Linha 1'); > > 1 linha criada. > > SCOTT@O10GR2:SQL>commit; > > Commit concluÝdo. > > ==> veja que o trigger DISPAROU, mesmo o usuário final Não Tendo recebido > nenhum privilégio especial , como eu disse : > > SCOTT@O10GR2:SQL>conn system/oracle > Conectado. > > SessÒo alterada. > > SYSTEM@O10GR2:SQL>select * from log_schema.log_ins_tab_teste; > > USERNAME DATA_INSERT > --- > SCOTT 06/09/2013 19:34:31 > > SYSTEM@O10GR2:SQL> > > []s > > Chiappa > > IMPORTANTE : reitero NOVAMENTE, apesar de funcionar use JUDICIOSAMENTE as > triggers, dando *** TOTAL *** preferência às built-ins de Audit e LOgging, > sob risco de overhead ** SEVERO ** nas transações de maior porte, okdoc ?? > > --- Em oracle_br@yahoogrupos.com.br, "J. Laurindo Chiappa" > escreveu > > > > > Fabiano, seguinte : > > > > 1. com certeza, TRIGGERS de DML (que respondem a > INSERTs/UPDATEs/DELETEs) podem facilmente causar Sérios problemas de > performance, EM ESPECIAL se dispararem para cada linha, como é o caso se vc > quer/precisa auditar os valores exatos que foram > inseridos/atualizados/deletados - isso principalmente devido ao fato deles, > em disparando uma vez para cada linha, Impedem na prática processamento > BULK, forçando row-by-row processing > > Assim, de cara o que eu digo é : ** ESTUDE ** as built-ins de Auditoria > e Logging (ie, comando AUDIT, DBMS_FGA, LOG MINER, views materializadas, > query monitoring se vc estiver no 11g, etc) para ver se ao menos > parcialmente vc não consegue Evitar o uso de triggers... Triggers quanto > menos vc usar. melhor... > > > > 2. outra opção ** EXCELENTE ** ,nem sempre possível (por exemplo, nos > casos em que os dados TEM que ser acessados por tools de reporting ou BI, > que normalmente só executam SQLs) seria vc ENCAPSULAR os SQLs todos (por > transação - NADA de TABLE APIs aqui !) em rotinas normalmente feitas em > PL/SQL) no schema SISTEMA e aí os usuários demais receberia GRANTs de > EXECUTE nos PL/SQLs apropriados ao invés de GRANTS de > SELECT/INSERT/UPDATE/DELETE.
RES: [oracle_br] Re: alter index shrink space
De novo, não vejo a minha resposta no Grupo, xô então enviar de novo, e desculpas antecipadas a quem receber 2x.. Opa, então (mais uma vez, dando DE BARATO que vc JÁ Fez as análises correspondentes e TÁ PROVADo que vc Realmente Precisa reorganizar seu índice) : a) sim, é bem pouco provável mas é possível, então é algo que deveria ser checado, de qquer maneira c) realmente avalie direitinho, e ** não deixe ** de estudar os links que te dei - num deles o Autor discorre sobre as diferenças entre Coalesce e SHRINK, noutro o Autor cita uns casos em que o REBUILD ao final deixou um índice ** MAIOR ** (e portanto menos efetivo) do que antes Veja lá... d) REPITO, não é só não ter Transações abertas, a possibilidade de vc ter segmentos ainda RESERVADOS por causa de transações que já fecharam mas ainda não se completou o tempo de RETENTION é, como eu disse, sempre presente Plz faça uma consulta tipo : select status, round(sum_bytes / (1024*1024), 0) as MB, round((sum_bytes / undo_size) * 100, 0) as PERC from ( select status, sum(bytes) sum_bytes from dba_undo_extents group by status ), ( select sum(a.bytes) undo_size from dba_tablespaces c join v$tablespace b on b.name = c.tablespace_name join v$datafile a on a.ts# = b.ts# where c.contents = 'UNDO' and c.status = 'ONLINE' ); E veja o quanto EXATAMENTE vc tem de extents ATIVOS (provavelmente nada, se realmente não houverem Transações), UNEXPIRED (que podem ser usados para consistência de leitura) e EXPIRED (que podem ser reusados, pois já cumpriram o tempo de retenção) O ponto é : embora não seja possível mensurar o quanto de undo a "deleção" de linhas que o COALESCE ou o SHRINK vão gerar (só podemos dizer que o do COALESCE tipicamente deve ser menor, já que cfrme http://richardfoote.wordpress.com/2008/02/06/differences-and-similarities-between-index-coalesce-and-shrink-space/ nos diz o SHRINK fisicamente tem que liberar quaisquer blocos free, enquanto o COALESCE só re-estrutura), mas em casos extremos já vi casos de 1,5x o tamanho , então vc precisaria de algo em torno de uns quase 4 GB usáveis de UNDO (seja livre, seja liberável por já estar expirado) CASO vc realmente tenha isso de undo realmente usável e ainda assim tá tendo erro de falta de undo, o que vc pode fazer (além de testar as outras opções apresentadas E de checar por eventuais bugs ocasionando consumo excessivo, como os citados na nota "Master Note: High Undo Space Usage" (Doc ID 1578639.1) poderia ser também, como eu disse, temporariamente criar uma tablespace de UNDO sensivelmente maior e monitorar o uso durante a movimentação []s Chiappa --- Em oracle_br@yahoogrupos.com.br, "Grupos" escreveu > > Chiappa, segue resposta. > > > > a) Não é provável. A nota também fala para versões Enterprise Edition > > b) Essa opção também só para Enterprise Edition > > c) Não testei. Vou ver uma janela para fazer os testes > > d) Tenho certeza que não tinha transações abertas. Pois depois de > fechar as aplicações, eu tirei a instância do ar e subi novamente, > verifiquei a área de UNDO e não tinha nada. > > Table Size: 3.1GB > > Index Size: 1.4GB > > > > De: oracle_br@yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br] Em > nome de J. Laurindo Chiappa > Enviada em: segunda-feira, 9 de setembro de 2013 13:53 > Para: oracle_br@yahoogrupos.com.br > Assunto: [oracle_br] Re: alter index shrink space > > > > > > Opa : eu tinha respondido mas ao que parece a internet comeu minha resposta > : então estou re-enviando, e desde já me desculpo com quem receber 2x ... > > Bom, dando de barato que vc já verificou e REALMENTE PROVOU que > precisa da movimentação (por exemplo, cfrme > http://richardfoote.wordpress.com/2008/02/08/index-rebuild-vs-coalesce-vs-sh > rink-space-pigs-3-different-ones/ a sua aplicação deletou uma porção > Significatica de linhas, cujos valores ** não ** vão ser reusados, talvez > porque sequenciais/artificiais, E o acesso não é single-row, ou coisa do > tipo), NÂO estando portanto seguindo algum 'tutorial' na base do achômetro > e/ou da autoridade tipo eu-sou-o-expert (que é Muito Comum quando se fala de > 'fragmentação', é o tipo do tópico que todo mundo Acha que sabe mas na > prática muitos só perpetuam mitos furados), aí temos que SIM, qualquer tipo > de movimentação de blocos VAI gerar algum UNDO e algum REDO, nem que seja > para as tabelas internas do RDBMS, que são SIM em sua maioria protegidas / > transacionadas do mesmo modo que as tabelas de usuário... > Aí eu digo : > > a) vc deveria checar no Suporte Oracle por possibilidades como o Bug 3888229 > : HUGE REDO AND UNDO GENERATED DURING A TABLE SHRINK OPERATION , e similares > : não é provável (até dada a antiguidade e a especifidade de plataforma),mas > é possível que vc esteja vendo um re-run .. > > b) já que vc tem a opção de "fechar todos os aplicativos que acessam a
Re: [oracle_br] Re: alter index shrink space
Boa tarde, Teve uma apresentação no GUOB do Francisco Muñoz Alvarez, creio que do ano passado ou retrasado, sobre logging e nologging, pode ser uma ajuda para fazer movimentações com menor impacto. Segue o paper que resultou na apresentação: http://upload.wikimedia.org/wikipedia/commons/d/de/Redo_reduction_v_1.5.pdf Atenciosamente, Rodrigo Mufalani rodr...@mufalani.com.br www.mufalani.com.br On 09/09/2013, at 14:02, Fabio Prado wrote: > > Só para complementar a resposta do chiappa, a operação de shrink internamente > faz delete e depois insert nas linhas de tabelas que são movimentadas. No > índice deve funcionar de forma parecida e por isso, a geração de UNDO! > > Não aconselho a usar COALESCE, o SHRINK é mais eficiente e o REBUILD mais > ainda, porém o impacto do REBUILD é muito grande (consome muito > processamento) e por isso ele é evitado em muitos ambientes de produção! > > []s > > Fábio Prado > www.fabioprado.net > > > Em 9 de setembro de 2013 13:52, J. Laurindo Chiappa > escreveu: > > Opa : eu tinha respondido mas ao que parece a internet comeu minha resposta : > então estou re-enviando, e desde já me desculpo com quem receber 2x ... > > Bom, dando de barato que vc já verificou e REALMENTE PROVOU que > precisa da movimentação (por exemplo, cfrme > http://richardfoote.wordpress.com/2008/02/08/index-rebuild-vs-coalesce-vs-shrink-space-pigs-3-different-ones/ > a sua aplicação deletou uma porção Significatica de linhas, cujos valores ** > não ** vão ser reusados, talvez porque sequenciais/artificiais, E o acesso > não é single-row, ou coisa do tipo), NÂO estando portanto seguindo algum > 'tutorial' na base do achômetro e/ou da autoridade tipo eu-sou-o-expert (que > é Muito Comum quando se fala de 'fragmentação', é o tipo do tópico que todo > mundo Acha que sabe mas na prática muitos só perpetuam mitos furados), aí > temos que SIM, qualquer tipo de movimentação de blocos VAI gerar algum UNDO e > algum REDO, nem que seja para as tabelas internas do RDBMS, que são SIM em > sua maioria protegidas / transacionadas do mesmo modo que as tabelas de > usuário... > Aí eu digo : > > a) vc deveria checar no Suporte Oracle por possibilidades como o Bug 3888229 > : HUGE REDO AND UNDO GENERATED DURING A TABLE SHRINK OPERATION , e similares > : não é provável (até dada a antiguidade e a especifidade de plataforma),mas > é possível que vc esteja vendo um re-run .. > > b) já que vc tem a opção de "fechar todos os aplicativos que acessam a > instância", para tentar diminuir o redo vc pode experimentar um INDEX REBUILD > NOLOGGING PARALLEL - via de regra isso não interfere grande coisa (até porque > a diminuição Efetiva é numa operação de APPEND, que só pode ocorrer em > tabelas - índices sempre tem que ser Ordenados fisicamente, não dá pra > apendar), mas vale a tentativa > > c)vc TESTOU as Outras opções de movimentação/reordenação do índice, como > COALESCE, além do REBUILD em si, cfrme alguns artigos em > http://richardfoote.wordpress.com/category/index-shrink/ do índice ?? E as > opções de redefinição da tabela em si (como DBMS_REDEFINE, INSERT /*+ APPEND > */, etc) , talvez até numa outra tabela-temporária vazia que depois de dropar > a tabela original vc a renomearia ??? > Como eu não trabalho com Standard Edition, não faço idéia de quais opções > dessa lista estariam vedadas para vc, mas é algo a checar... > > d) sobre o UNDO especificamente, vc TEM Certeza que não tinha aí nenhuma > outra Transação aberta usando o tal índice e/ou a tabela a qual o índice > pertence ??? OU AINDA, uma situação COMUNÍSSIMA , será que vc não teria ** > OUTRAS TRANSAÇÕES quaisquer ** de modo geral consumindo o UNDO, OU mesmo > Transações que acabaram há pouco tempo e portanto ainda não puderam liberar o > espaço devido ao RETENTION ainda não cumprido, caso em que (OBVIAMENTE) vc > Não teria os 5 GB todos disponíveis para uso ??? QUAL é o tamanho da tabela E > do índice, em bytes, por falar nisso ?? > DEPENDENDO dessas respostas, talvez a melhor opção seja vc simplesmente > temporariamente criar uma nova undo tablespace bem maior, a usar para a > movimentação e depois a dropar... > > []s > > Chiappa > > --- Em oracle_br@yahoogrupos.com.br, "Grupos" escreveu > > > > > > Bom dia! > > > > > > > > Oracle 10.2.0.5 Standard Edition one > > > > > > > > Tentei fazer um shrink en um índice, e deu erro no UNDO. O meu UNDO está > > com tamanho de 5G, ele estava vazio no momento do shrink, pois antes de > > começar tirei a minha instância do ar, e fechei todos os aplicativos que > > acessam a instância. > > > > > > > > Além de ocupar toda a minha área de UNDO, é gerado muitos archives. Tem > > alguma maneira de executar o shrink sem ocupar tanto o UNDO e gerar muitos > > archives? > > > > > > > > Vi que tem a opção nologging no rebuild online, mas essa feature está apenas > > para o EE. Para o Standard One, alguém conhece alguma maneira de fa
Re: [oracle_br] Re: alter index shrink space
Só para complementar a resposta do chiappa, a operação de shrink internamente faz delete e depois insert nas linhas de tabelas que são movimentadas. No índice deve funcionar de forma parecida e por isso, a geração de UNDO! Não aconselho a usar COALESCE, o SHRINK é mais eficiente e o REBUILD mais ainda, porém o impacto do REBUILD é muito grande (consome muito processamento) e por isso ele é evitado em muitos ambientes de produção! []s Fábio Prado www.fabioprado.net Em 9 de setembro de 2013 13:52, J. Laurindo Chiappa escreveu: > ** > > > Opa : eu tinha respondido mas ao que parece a internet comeu minha > resposta : então estou re-enviando, e desde já me desculpo com quem receber > 2x ... > > Bom, dando de barato que vc já verificou e REALMENTE PROVOU que > precisa da movimentação (por exemplo, cfrme > http://richardfoote.wordpress.com/2008/02/08/index-rebuild-vs-coalesce-vs-shrink-space-pigs-3-different-ones/a > sua aplicação deletou uma porção Significatica de linhas, cujos valores > ** não ** vão ser reusados, talvez porque sequenciais/artificiais, E o > acesso não é single-row, ou coisa do tipo), NÂO estando portanto seguindo > algum 'tutorial' na base do achômetro e/ou da autoridade tipo > eu-sou-o-expert (que é Muito Comum quando se fala de 'fragmentação', é o > tipo do tópico que todo mundo Acha que sabe mas na prática muitos só > perpetuam mitos furados), aí temos que SIM, qualquer tipo de movimentação > de blocos VAI gerar algum UNDO e algum REDO, nem que seja para as tabelas > internas do RDBMS, que são SIM em sua maioria protegidas / transacionadas > do mesmo modo que as tabelas de usuário... > Aí eu digo : > > a) vc deveria checar no Suporte Oracle por possibilidades como o Bug > 3888229 : HUGE REDO AND UNDO GENERATED DURING A TABLE SHRINK OPERATION , e > similares : não é provável (até dada a antiguidade e a especifidade de > plataforma),mas é possível que vc esteja vendo um re-run .. > > b) já que vc tem a opção de "fechar todos os aplicativos que acessam a > instância", para tentar diminuir o redo vc pode experimentar um INDEX > REBUILD NOLOGGING PARALLEL - via de regra isso não interfere grande coisa > (até porque a diminuição Efetiva é numa operação de APPEND, que só pode > ocorrer em tabelas - índices sempre tem que ser Ordenados fisicamente, não > dá pra apendar), mas vale a tentativa > > c)vc TESTOU as Outras opções de movimentação/reordenação do índice, como > COALESCE, além do REBUILD em si, cfrme alguns artigos em > http://richardfoote.wordpress.com/category/index-shrink/ do índice ?? E > as opções de redefinição da tabela em si (como DBMS_REDEFINE, INSERT /*+ > APPEND */, etc) , talvez até numa outra tabela-temporária vazia que depois > de dropar a tabela original vc a renomearia ??? > Como eu não trabalho com Standard Edition, não faço idéia de quais opções > dessa lista estariam vedadas para vc, mas é algo a checar... > > d) sobre o UNDO especificamente, vc TEM Certeza que não tinha aí nenhuma > outra Transação aberta usando o tal índice e/ou a tabela a qual o índice > pertence ??? OU AINDA, uma situação COMUNÍSSIMA , será que vc não teria ** > OUTRAS TRANSAÇÕES quaisquer ** de modo geral consumindo o UNDO, OU mesmo > Transações que acabaram há pouco tempo e portanto ainda não puderam liberar > o espaço devido ao RETENTION ainda não cumprido, caso em que (OBVIAMENTE) > vc Não teria os 5 GB todos disponíveis para uso ??? QUAL é o tamanho da > tabela E do índice, em bytes, por falar nisso ?? > DEPENDENDO dessas respostas, talvez a melhor opção seja vc simplesmente > temporariamente criar uma nova undo tablespace bem maior, a usar para a > movimentação e depois a dropar... > > []s > > Chiappa > > --- Em oracle_br@yahoogrupos.com.br, "Grupos" escreveu > > > > > Bom dia! > > > > > > > > Oracle 10.2.0.5 Standard Edition one > > > > > > > > Tentei fazer um shrink en um índice, e deu erro no UNDO. O meu UNDO está > > com tamanho de 5G, ele estava vazio no momento do shrink, pois antes de > > começar tirei a minha instância do ar, e fechei todos os aplicativos que > > acessam a instância. > > > > > > > > Além de ocupar toda a minha área de UNDO, é gerado muitos archives. Tem > > alguma maneira de executar o shrink sem ocupar tanto o UNDO e gerar > muitos > > archives? > > > > > > > > Vi que tem a opção nologging no rebuild online, mas essa feature está > apenas > > para o EE. Para o Standard One, alguém conhece alguma maneira de fazer os > > shrink para corrigir a fragmentação nas minhas tabelas e índices que não > > gere muito UNDO? > > > > > > > > Grato. > > > > > -- Fábio Prado www.fabioprado.net "Compartilhando conhecimentos e treinando profissionais em Bancos de Dados Oracle"
RES: [oracle_br] Re: alter index shrink space
Chiappa, segue resposta. a) Não é provável. A nota também fala para versões Enterprise Edition b) Essa opção também só para Enterprise Edition c) Não testei. Vou ver uma janela para fazer os testes d) Tenho certeza que não tinha transações abertas. Pois depois de fechar as aplicações, eu tirei a instância do ar e subi novamente, verifiquei a área de UNDO e não tinha nada. Table Size: 3.1GB Index Size: 1.4GB De: oracle_br@yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br] Em nome de J. Laurindo Chiappa Enviada em: segunda-feira, 9 de setembro de 2013 13:53 Para: oracle_br@yahoogrupos.com.br Assunto: [oracle_br] Re: alter index shrink space Opa : eu tinha respondido mas ao que parece a internet comeu minha resposta : então estou re-enviando, e desde já me desculpo com quem receber 2x ... Bom, dando de barato que vc já verificou e REALMENTE PROVOU que precisa da movimentação (por exemplo, cfrme http://richardfoote.wordpress.com/2008/02/08/index-rebuild-vs-coalesce-vs-sh rink-space-pigs-3-different-ones/ a sua aplicação deletou uma porção Significatica de linhas, cujos valores ** não ** vão ser reusados, talvez porque sequenciais/artificiais, E o acesso não é single-row, ou coisa do tipo), NÂO estando portanto seguindo algum 'tutorial' na base do achômetro e/ou da autoridade tipo eu-sou-o-expert (que é Muito Comum quando se fala de 'fragmentação', é o tipo do tópico que todo mundo Acha que sabe mas na prática muitos só perpetuam mitos furados), aí temos que SIM, qualquer tipo de movimentação de blocos VAI gerar algum UNDO e algum REDO, nem que seja para as tabelas internas do RDBMS, que são SIM em sua maioria protegidas / transacionadas do mesmo modo que as tabelas de usuário... Aí eu digo : a) vc deveria checar no Suporte Oracle por possibilidades como o Bug 3888229 : HUGE REDO AND UNDO GENERATED DURING A TABLE SHRINK OPERATION , e similares : não é provável (até dada a antiguidade e a especifidade de plataforma),mas é possível que vc esteja vendo um re-run .. b) já que vc tem a opção de "fechar todos os aplicativos que acessam a instância", para tentar diminuir o redo vc pode experimentar um INDEX REBUILD NOLOGGING PARALLEL - via de regra isso não interfere grande coisa (até porque a diminuição Efetiva é numa operação de APPEND, que só pode ocorrer em tabelas - índices sempre tem que ser Ordenados fisicamente, não dá pra apendar), mas vale a tentativa c)vc TESTOU as Outras opções de movimentação/reordenação do índice, como COALESCE, além do REBUILD em si, cfrme alguns artigos em http://richardfoote.wordpress.com/category/index-shrink/ do índice ?? E as opções de redefinição da tabela em si (como DBMS_REDEFINE, INSERT /*+ APPEND */, etc) , talvez até numa outra tabela-temporária vazia que depois de dropar a tabela original vc a renomearia ??? Como eu não trabalho com Standard Edition, não faço idéia de quais opções dessa lista estariam vedadas para vc, mas é algo a checar... d) sobre o UNDO especificamente, vc TEM Certeza que não tinha aí nenhuma outra Transação aberta usando o tal índice e/ou a tabela a qual o índice pertence ??? OU AINDA, uma situação COMUNÍSSIMA , será que vc não teria ** OUTRAS TRANSAÇÕES quaisquer ** de modo geral consumindo o UNDO, OU mesmo Transações que acabaram há pouco tempo e portanto ainda não puderam liberar o espaço devido ao RETENTION ainda não cumprido, caso em que (OBVIAMENTE) vc Não teria os 5 GB todos disponíveis para uso ??? QUAL é o tamanho da tabela E do índice, em bytes, por falar nisso ?? DEPENDENDO dessas respostas, talvez a melhor opção seja vc simplesmente temporariamente criar uma nova undo tablespace bem maior, a usar para a movimentação e depois a dropar... []s Chiappa --- Em oracle_br@yahoogrupos.com.br, "Grupos" escreveu > > Bom dia! > > > > Oracle 10.2.0.5 Standard Edition one > > > > Tentei fazer um shrink en um índice, e deu erro no UNDO. O meu UNDO está > com tamanho de 5G, ele estava vazio no momento do shrink, pois antes de > começar tirei a minha instância do ar, e fechei todos os aplicativos que > acessam a instância. > > > > Além de ocupar toda a minha área de UNDO, é gerado muitos archives. Tem > alguma maneira de executar o shrink sem ocupar tanto o UNDO e gerar muitos > archives? > > > > Vi que tem a opção nologging no rebuild online, mas essa feature está apenas > para o EE. Para o Standard One, alguém conhece alguma maneira de fazer os > shrink para corrigir a fragmentação nas minhas tabelas e índices que não > gere muito UNDO? > > > > Grato. >
[oracle_br] Re: alter index shrink space
Bom, dando de barato que vc já verificou e REALMENTE PROVOU que precisa da movimentação (por exemplo, cfrme http://richardfoote.wordpress.com/2008/02/08/index-rebuild-vs-coalesce-vs-shrink-space-pigs-3-different-ones/ a sua aplicação deletou uma porção Significativa de linhas, cujos valores ** não ** vão ser reusados, talvez porque sequenciais/artificiais, E o acesso não é single-row, é full index scan, ou coisa do tipo), NÂO estando portanto seguindo algum 'tutorial' na base do achômetro e/ou da autoridade tipo eu-sou-o-expert (que é Muito Comum quando se fala de 'fragmentação', é o tipo do tópico que todo mundo Acha que sabe mas na prática muitos só perpetuam mitos furados), aí temos que SIM, qualquer tipo de movimentação de blocos VAI gerar algum UNDO e algum REDO, nem que seja para as tabelas internas do RDBMS, que são SIM em sua maioria protegidas / transacionadas do mesmo modo que as tabelas de usuário... Aí eu digo : a) vc deveria checar no Suporte Oracle por possibilidades como o Bug 3888229 : HUGE REDO AND UNDO GENERATED DURING A TABLE SHRINK OPERATION , e similares : não é provável (até dada a antiguidade e a especifidade de plataforma),mas é possível que vc esteja vendo um re-run .. b) já que vc tem a opção de "fechar todos os aplicativos que acessam a instância", para tentar diminuir o redo vc pode experimentar um INDEX REBUILD NOLOGGING PARALLEL - via de regra isso não interfere grande coisa (até porque a diminuição Efetiva é numa operação de APPEND, que só pode ocorrer em tabelas - índices sempre tem que ser Ordenados fisicamente, não dá pra apendar), mas vale a tentativa c)vc TESTOU as Outras opções de movimentação/reordenação do índice, como COALESCE, além do REBUILD em si, cfrme alguns artigos em http://richardfoote.wordpress.com/category/index-shrink/ do índice ?? E as opções de redefinição da tabela em si (como DBMS_REDEFINE, INSERT /*+ APPEND */, etc) , talvez até numa outra tabela-temporária vazia que depois de dropar a tabela original vc a renomearia ??? Como eu não trabalho com Standard Edition, não faço idéia de quais opções dessa lista estariam vedadas para vc, mas é algo a checar... d) sobre o UNDO especificamente, vc TEM Certeza que não tinha aí nenhuma outra Transação aberta usando o tal índice e/ou a tabela a qual o índice pertence ??? OU AINDA, uma situação COMUNÍSSIMA , será que vc não teria ** OUTRAS TRANSAÇÕES quaisquer ** de modo geral consumindo o UNDO, OU mesmo Transações que acabaram há pouco tempo e portanto ainda não puderam liberar o espaço devido ao RETENTION ainda não cumprido, caso em que (OBVIAMENTE) vc Não teria os 5 GB todos disponíveis para uso ??? QUAL é o tamanho da tabela E do índice, em bytes, por falar nisso ?? DEPENDENDO dessas respostas, talvez a melhor opção seja vc simplesmente temporariamente criar uma nova undo tablespace bem maior, a usar para a movimentação e depois a dropar e voltar a usar a atual, que (imagino) afora este caso especial de manutenção te atende bem no dia a dia... []s Chiappa --- Em oracle_br@yahoogrupos.com.br, "Grupos" escreveu > > Bom dia! > > > > Oracle 10.2.0.5 Standard Edition one > > > > Tentei fazer um shrink en um índice, e deu erro no UNDO. O meu UNDO está > com tamanho de 5G, ele estava vazio no momento do shrink, pois antes de > começar tirei a minha instância do ar, e fechei todos os aplicativos que > acessam a instância. > > > > Além de ocupar toda a minha área de UNDO, é gerado muitos archives. Tem > alguma maneira de executar o shrink sem ocupar tanto o UNDO e gerar muitos > archives? > > > > Vi que tem a opção nologging no rebuild online, mas essa feature está apenas > para o EE. Para o Standard One, alguém conhece alguma maneira de fazer os > shrink para corrigir a fragmentação nas minhas tabelas e índices que não > gere muito UNDO? > > > > Grato. >
[oracle_br] Re: alter index shrink space
Opa : eu tinha respondido mas ao que parece a internet comeu minha resposta : então estou re-enviando, e desde já me desculpo com quem receber 2x ... Bom, dando de barato que vc já verificou e REALMENTE PROVOU que precisa da movimentação (por exemplo, cfrme http://richardfoote.wordpress.com/2008/02/08/index-rebuild-vs-coalesce-vs-shrink-space-pigs-3-different-ones/ a sua aplicação deletou uma porção Significatica de linhas, cujos valores ** não ** vão ser reusados, talvez porque sequenciais/artificiais, E o acesso não é single-row, ou coisa do tipo), NÂO estando portanto seguindo algum 'tutorial' na base do achômetro e/ou da autoridade tipo eu-sou-o-expert (que é Muito Comum quando se fala de 'fragmentação', é o tipo do tópico que todo mundo Acha que sabe mas na prática muitos só perpetuam mitos furados), aí temos que SIM, qualquer tipo de movimentação de blocos VAI gerar algum UNDO e algum REDO, nem que seja para as tabelas internas do RDBMS, que são SIM em sua maioria protegidas / transacionadas do mesmo modo que as tabelas de usuário... Aí eu digo : a) vc deveria checar no Suporte Oracle por possibilidades como o Bug 3888229 : HUGE REDO AND UNDO GENERATED DURING A TABLE SHRINK OPERATION , e similares : não é provável (até dada a antiguidade e a especifidade de plataforma),mas é possível que vc esteja vendo um re-run .. b) já que vc tem a opção de "fechar todos os aplicativos que acessam a instância", para tentar diminuir o redo vc pode experimentar um INDEX REBUILD NOLOGGING PARALLEL - via de regra isso não interfere grande coisa (até porque a diminuição Efetiva é numa operação de APPEND, que só pode ocorrer em tabelas - índices sempre tem que ser Ordenados fisicamente, não dá pra apendar), mas vale a tentativa c)vc TESTOU as Outras opções de movimentação/reordenação do índice, como COALESCE, além do REBUILD em si, cfrme alguns artigos em http://richardfoote.wordpress.com/category/index-shrink/ do índice ?? E as opções de redefinição da tabela em si (como DBMS_REDEFINE, INSERT /*+ APPEND */, etc) , talvez até numa outra tabela-temporária vazia que depois de dropar a tabela original vc a renomearia ??? Como eu não trabalho com Standard Edition, não faço idéia de quais opções dessa lista estariam vedadas para vc, mas é algo a checar... d) sobre o UNDO especificamente, vc TEM Certeza que não tinha aí nenhuma outra Transação aberta usando o tal índice e/ou a tabela a qual o índice pertence ??? OU AINDA, uma situação COMUNÍSSIMA , será que vc não teria ** OUTRAS TRANSAÇÕES quaisquer ** de modo geral consumindo o UNDO, OU mesmo Transações que acabaram há pouco tempo e portanto ainda não puderam liberar o espaço devido ao RETENTION ainda não cumprido, caso em que (OBVIAMENTE) vc Não teria os 5 GB todos disponíveis para uso ??? QUAL é o tamanho da tabela E do índice, em bytes, por falar nisso ?? DEPENDENDO dessas respostas, talvez a melhor opção seja vc simplesmente temporariamente criar uma nova undo tablespace bem maior, a usar para a movimentação e depois a dropar... []s Chiappa --- Em oracle_br@yahoogrupos.com.br, "Grupos" escreveu > > Bom dia! > > > > Oracle 10.2.0.5 Standard Edition one > > > > Tentei fazer um shrink en um índice, e deu erro no UNDO. O meu UNDO está > com tamanho de 5G, ele estava vazio no momento do shrink, pois antes de > começar tirei a minha instância do ar, e fechei todos os aplicativos que > acessam a instância. > > > > Além de ocupar toda a minha área de UNDO, é gerado muitos archives. Tem > alguma maneira de executar o shrink sem ocupar tanto o UNDO e gerar muitos > archives? > > > > Vi que tem a opção nologging no rebuild online, mas essa feature está apenas > para o EE. Para o Standard One, alguém conhece alguma maneira de fazer os > shrink para corrigir a fragmentação nas minhas tabelas e índices que não > gere muito UNDO? > > > > Grato. >
[oracle_br] Re: Executar proc com type array
Colega, pelo que entendi o que acontece aqui é que vc está criando um TYPE **
local **, aqui no teu bloco anônimo : é ** ÓBVIO ** que essa área de memória é
LOCAL, assim a procedure, que NÂO está na mesma área, ** não vai ** conseguir
enxergar isso, yep ???
O procedimento correto é : OU vc cria um TYPE a nível de database com CREATE
TYPE (e aí, sendo a nível de database, tanto o seu PL/SQ quanto a procedure vão
a poder enxergar), OU (o que é Muito Comum, também) vc já tem o TYPE criado na
própria ** PACKAGE ** aonde a procedure está definida , pois objetos definidos
na SPEC de uma package são PÚBLICOS, aí todo mundo enxerga Um exemplo de
utilização de TYPE PÚBLICO, definido em package :
SCOTT@O10GR2:SQL>CREATE OR REPLACE PACKAGE ARRAY_EXAMPLE AS
2 --
3 -- Definição de GLOBAIS
4 --
5 TYPE stringArrayVar IS TABLE OF VARCHAR2(1000);
6 -- ---
7 --
8 -- --
9 -- Definição de Componentes
10 -- --
11 PROCEDURE PROCESS_ARRAY(stringArrayIn IN stringArrayVar);
12 --
13 END ARRAY_EXAMPLE;
14 /
Pacote criado.
SCOTT@O10GR2:SQL>CREATE OR REPLACE PACKAGE BODY ARRAY_EXAMPLE AS
2 PROCEDURE PROCESS_ARRAY(stringArrayIn IN stringArrayVar ) IS
3 Begin
4FOR i IN 1..stringArrayIn.Count LOOP
5DBMS_OUTPUT.PUT_LINE('Posição '||stringArrayIn(i));
6END LOOP;
7 End PROCESS_ARRAY;
8 END;
9 /
Corpo de Pacote criado.
==>> okdoc... Veja agora que eu no meu bloco PL/SQl eu ** NÃO ***
defino um type meu, mas sim vou valorar diretamente o stringArrayVar, que é um
TYPE ** PÚBLICO ** (definido no SPEC da minha package), certinho
SCOTT@O10GR2:SQL>set serveroutput on
SCOTT@O10GR2:SQL>BEGIN
2
ARRAY_EXAMPLE.PROCESS_ARRAY(array_example.stringArrayVar('AAA','BBB','CCC','DDD'));
3 End;
4 /
Posição AAA
Posição BBB
Posição CCC
Posição DDD
Procedimento PL/SQL concluÝdo com sucesso.
Confere ? Então veja lá com quem criou a tal Procedure e peça para ele **
OU ** te dizer exatamente qual o TYPE público que ele crioi, OU se ele não usou
um TYPE público aí que ele te diga a definição do registro lógico , para que vc
possa criar um TYPE a nível de database com CREATE TYPE
[]s
Chiappa
--- Em oracle_br@yahoogrupos.com.br, Jales Jose Moraes escreveu
>
> Pessou estou precisando executar uma proc, porém ela tem um type Array, me
> foi passado os parametros para ser substituído no array
>
>
> O parâmetro é um Array:
> acoes=215, 455, 101, 457
>
> Fiz o bloco abaixo para passar então o array, mas me retorna o erro RA-06550:
> linha 9, coluna 7: PLS-00306: número incorreto de tipos de argumentos na
> chamada para 'REM_ACOES' ORA-06550: linha 9, coluna 7: PL/SQL: Statement
> ignored
>
>
>
> DECLARE
> v_t AO_FNDE.ARRAY_TABLE33;
> BEGIN
> v_t := AO_FNDE.ARRAY_TABLE33(141, 341, 421, 401, 441, 321, 281, 261,
> 301, 221, 481, 521, 621, 361, 501, 381);
> REM_ACOES ('2013',V_T(16), 'observacao', 'sicon', '127.0.0.1',
> sysdate,99);
> END;
> /
>
>
> Alguém poderia me ajudar?
>
[oracle_br] Executar proc com type array
Pessou estou precisando executar uma proc, porém ela tem um type Array, me foi
passado os parametros para ser substituído no array
O parâmetro é um Array:
acoes=215, 455, 101, 457
Fiz o bloco abaixo para passar então o array, mas me retorna o erro RA-06550:
linha 9, coluna 7: PLS-00306: número incorreto de tipos de argumentos na
chamada para 'REM_ACOES' ORA-06550: linha 9, coluna 7: PL/SQL: Statement ignored
DECLARE
v_t AO_FNDE.ARRAY_TABLE33;
BEGIN
v_t := AO_FNDE.ARRAY_TABLE33(141, 341, 421, 401, 441, 321, 281, 261, 301,
221, 481, 521, 621, 361, 501, 381);
REM_ACOES ('2013',V_T(16), 'observacao', 'sicon', '127.0.0.1',
sysdate,99);
END;
/
Alguém poderia me ajudar?
[oracle_br] alter index shrink space
Bom dia! Oracle 10.2.0.5 Standard Edition one Tentei fazer um shrink en um índice, e deu erro no UNDO. O meu UNDO está com tamanho de 5G, ele estava vazio no momento do shrink, pois antes de começar tirei a minha instância do ar, e fechei todos os aplicativos que acessam a instância. Além de ocupar toda a minha área de UNDO, é gerado muitos archives. Tem alguma maneira de executar o shrink sem ocupar tanto o UNDO e gerar muitos archives? Vi que tem a opção nologging no rebuild online, mas essa feature está apenas para o EE. Para o Standard One, alguém conhece alguma maneira de fazer os shrink para corrigir a fragmentação nas minhas tabelas e índices que não gere muito UNDO? Grato.
Re: [oracle_br] Selecionar os últimos registros
Bom dia! É uma boa solução Milton, mas para as tabelas antigas não tenho este campo. Vou fazer um ORDER BY DESC pela chave primária, elas são sequenciais, acho que vai nos atender. Obrigado pela dica... De: Milton Bastos Henriquis Jr. Para: oracle_br@yahoogrupos.com.br Enviadas: Sexta-feira, 6 de Setembro de 2013 13:50 Assunto: Re: [oracle_br] Selecionar os últimos registros Claro que dá Basta ter um campo que armazene o horário da inserção (pode ser preenchido via trigger), e fazer o select dando ORDER BY DESC por esse campo. 2013/9/6 Jales Jose Moraes > >Boa tarde! > > >Pessoal é possível selecionar em uma tabela (tanto no oracle como no postgres) >os últimos 1000 registros inseridos?
