Re: [oracle_br] OT - Livro Oracle Database 11g Manual do Dba
Pessoal so dando um retorno.. o livro chegou ... e agora entendo o q o chiappa disse sobre a tradução em alguns momentos fica confuso mas relendo da pra passar rsrsrs... ms enfim to achando bem interessante ... vlw a todos Sim sim aviso, independente do resultado ... Em 23 de setembro de 2014 17:37, angelo angelolis...@gmail.com [oracle_br] < oracle_br@yahoogrupos.com.br> escreveu: > > > Pô, se a experiencia com o site for boa, comenta na lista > > vou comprar um livro lá tb.. > > > > > > > > 2014-09-23 16:16 GMT-03:00 Mario Rodrigues marioirodrig...@gmail.com > [oracle_br] : > >> >> >> Diego, >> >> Obrigado ... aparentemente comprado rsrsrs (esperando só a mudança do >> status) >> >> >> Em 23 de setembro de 2014 15:55, Diego Rodrigues Ferreira >> diegorodrigues_ferre...@yahoo.com [oracle_br] < >> oracle_br@yahoogrupos.com.br> escreveu: >> >>> >>> >>> Comprei o meu neste site, fica na minha cidade...da uma olhada ai >>> >>> >>> http://www.proseculo.com.br/livro/55423481/oracle-database-11g-manual-do-dba >>> >>> >>> On Wednesday, September 17, 2014 4:54 PM, "Vera Porfírio Cascardo >>> veraporfiriocasca...@yahoo.com.br [oracle_br]" < >>> oracle_br@yahoogrupos.com.br> wrote: >>> >>> >>> >>> Dá uma olhada no site da Saraiva, eu consegui lá mas só na versão >>> digital >>> Enviado do Yahoo Mail no Android >>> De:"Mario Rodrigues marioirodrig...@gmail.com [oracle_br]" < >>> oracle_br@yahoogrupos.com.br> >>> Data:16:44 Qua, 17 de Set de PM >>> Assunto:Re: [oracle_br] OT - Livro Oracle Database 11g Manual do Dba >>> >>> >>> Também não ... :( >>> >>> >>> >>> Em 17 de setembro de 2014 16:22, angelo angelolis...@gmail.com >>> [oracle_br] escreveu: >>> >>> >>> Ja viu aqui ? >>> >>> >>> http://www.ciadoslivros.com.br/pesquisa?t=Oracle+Database+11g+Manual+do+Dba&f=&sr=GERAL >>> >>> >>> []s angelo >>> >>> >>> >>> 2014-09-17 14:29 GMT-03:00 Mario Rodrigues marioirodrig...@gmail.com >>> [oracle_br] : >>> >>> >>> Pessoal >>> >>> Estou desde ontem atras deste livro e em todos os locais esta esgotado. >>> >>> Somente e-book consegui encontrar. >>> >>> Alguém conhece algum site que possa ter ou ainda alguém teria esse livro >>> e gostaria de vender??(estando em bom estado, claro) >>> >>> >>> >>> >>> >>> >> > >
Re: [oracle_br] Flash Recovery Area
Colega, seguinte : antes de tudo, vc OLHOU o conteúdo do parâmetro db_recovery_file_dest nesse database (pode ser conectando como sysdba e pedindo um SHOW PARAMETER db_recovery_file_dest no sqlplus, por exemplo) para ter CERTEZA que vc TEM flash recovery_area setada ??? Se isso estiver legal : vc está errado ao supor que tem "tabelas dropadas no meu banco desde 2011, então tenho espaço usado na flash recovery area" : ora, o manual 10g correspondente "Oracle® Database Backup and Recovery Basics 10g Release 2 (10.2)" no item " "3.5.2 Files That Can Be Stored in the Flash Recovery Area ... A copy of all datafiles Incremental backups, as used by your chosen backup strategy Online redo logs Archived redo logs not yet backed up to tape Control files Control file autobackups (which include copies of the control file and SPFILE) Note: The Oracle Flashback Database feature, which provides an convenient alternative to point-in-time recovery, generates flashback logs, which are also considered transient files and must be stored in the flash recovery area. " A questão aqui é que : a) os FLASHBACK LOGS são opcionais, criados pela feature TOTALMENTE OPCIONAL de FLASHBACK DATABASE - se vc não tiver essa feature ativa, vc não vai estar ocupando espaço algum na flash_recovery_area Como, pelo jeito, isso aí deve ser um database de teste, e recentemente instalado, nunca foi feito um backup, então por isso que vc tem ZERO para a ocupação dos arquivos da FRA... b) além do que, veja que a RECYCLE BIN não fica aqui ***, não está citada lá na lista, tá certo E além disso, no manual "Oracle® Database Administrator's Guide 10g Release 2 (10.2)" cap. 15 Managing Tables, no link 'Using Flashback Drop and Managing the Recycle Bin' é dito JUSTAMENTE que é ela que se usa para e recuperar de DROPs normalmente, okdoc ?? Pelo jeito vc confundiu FLASHBACK DATABASE, cujos flashback logs REALMENTE são mesmo armazenados na FRA com FLASHBACK DROP, que usa a recycle bin : NADA A VER a sua preocupação de espaço usado por dropped tables com a FRA Consulte a DBA_RECYCLE_BIN pra ver como estão as suas recycle bins, ok ?? []s Chiappa
Re: RES: [oracle_br] Re: ORA-03113: end-of-file on communication channel
Como o 10.2.0.5 tá sem suporte também (a não ser que vc tenha comprado Suporte extendido) essas instâncias 10g não vão servir de muito para uma eventual investigação junto com o Suporte... Siga os links mas preste atenção nas ressalvas que eu fiz para ATUALIZAÇÃO até onde possível dos softwares envolvidos , E também (principalmente) para a questão de possíveis má-configurações do kernel e/ou pau de hardware, nada disso é impossível, de forma alguma... []s Chiappa
RES: [oracle_br] Re: ORA-03113: end-of-file on communication channel
Chiappa, Outra coisa, neste mesmo servidor tenho mais dois banco 10g (10.2.0.5), que também ocorre o mesmo erro. O estranho que no mês de Julho estava fazendo backup em fita, e do nada parou. Não sei se pode ajudar, mas somando essas três SGA não passa de 6GB, e a maquina esta com 16GB. [root@server030 backup]# free -m total used free sharedbuffers cached Mem: 16196 15517678 0231 14046 -/+ buffers/cache: 1239 14956 Swap:20481 1191 19289 Vou dar uma olhada nos links que vc passou. Grato, Ednilson De: oracle_br@yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br] Enviada em: quarta-feira, 8 de outubro de 2014 13:39 Para: oracle_br@yahoogrupos.com.br Assunto: [oracle_br] Re: ORA-03113: end-of-file on communication channel Lamento ser o portador de más notícias, mas vc vai ter um problemão aí em mãos : o fato é que praticamente TODOS os erros ORA-600, ORA-07445, ORA-03431 e alguns outros similares decorrem de BUGs (sejam bugs no RDBMS, no SO, no firmware, nos drivers, etc) , E sendo a versão 9ir2 que vc usa há MUUUITOS ANOS descontinuada/sem suporte, vc Não vai mais ter bugfix NENHUM pra ela O que vc pode fazer, ** ENQUANTO ** não rola o upgrade mais que necessário pra uma versão decente, SUPORTADA e SUPORTÁVEL, é : a) ver se é viável a aplicação do último PSU do patchset : o zero final da versão 9.2.0.8.0 indica que Provavelmente não deve ter sido aplicado nenhum, veja lá, EM CONUNTO com a verificação (junto do seu fornecedor!) de versão mais atualizada dos seus drivers/media manager b) obter os ** DETALHES ** do log do sbt e de TODOS os trace/log/dump files que possam ter sido gerados, cfrme mostrado em http://arjudba.blogspot.com.br/2011/05/ora-07445-exception-encountered-core.html c) ver se os bugs descritos em http://ora-07445.ora-code.com/msg/49214.html te ajudam c) consultar no metalink as notas de issues com os mesmos sintomas, talvez alguns dos work-arounds te ajudem : no caso, com a exata descrição ORA-07445: exception encountered: core dump [00F2D410] [SIGXFSZ] não achei nenhum numa busca rápida, mas tem vários com ORA-07445: exception encountered: core dump [SIGXFSZ], assim imagino que o primeiro argumento seja um endereço específico do seu ambiente, mas veja lá se algum dos textos te auxilia d) ler as respostas na thread http://www.freelists.org/post/oracle-l/RMAN-backup-failed-and-ORA07445 - a maioria dos participantes pensou em limites do software (seja o SO, os drivers de fita e media manager que vc tá usando), do hardware (principalmente se 32-bits) e/ou do RDBMS sendo ultrapassados e) cfrme http://danielwestermann.com/2012/04/15/sigsegv-and-the-ora-07445/ lembra, normalmente esse signal de SIGSEGV implica que algum processo morreu inesperadamente : assim sendo, NÂO TEM COMO vc não considerar, além dos possíveis bugs e/ou desajustamentos dos params de kernel, TAMBÉM uma possível issue no hardware... []s Chiappa
[oracle_br] Re: ORA-03113: end-of-file on communication channel
Lamento ser o portador de más notícias, mas vc vai ter um problemão aí em mãos : o fato é que praticamente TODOS os erros ORA-600, ORA-07445, ORA-03431 e alguns outros similares decorrem de BUGs (sejam bugs no RDBMS, no SO, no firmware, nos drivers, etc) , E sendo a versão 9ir2 que vc usa há MUUUITOS ANOS descontinuada/sem suporte, vc Não vai mais ter bugfix NENHUM pra ela O que vc pode fazer, ** ENQUANTO ** não rola o upgrade mais que necessário pra uma versão decente, SUPORTADA e SUPORTÁVEL, é : a) ver se é viável a aplicação do último PSU do patchset : o zero final da versão 9.2.0.8.0 indica que Provavelmente não deve ter sido aplicado nenhum, veja lá, EM CONUNTO com a verificação (junto do seu fornecedor!) de versão mais atualizada dos seus drivers/media manager b) obter os ** DETALHES ** do log do sbt e de TODOS os trace/log/dump files que possam ter sido gerados, cfrme mostrado em http://arjudba.blogspot.com.br/2011/05/ora-07445-exception-encountered-core.html c) ver se os bugs descritos em http://ora-07445.ora-code.com/msg/49214.html te ajudam c) consultar no metalink as notas de issues com os mesmos sintomas, talvez alguns dos work-arounds te ajudem : no caso, com a exata descrição ORA-07445: exception encountered: core dump [00F2D410] [SIGXFSZ] não achei nenhum numa busca rápida, mas tem vários com ORA-07445: exception encountered: core dump [SIGXFSZ], assim imagino que o primeiro argumento seja um endereço específico do seu ambiente, mas veja lá se algum dos textos te auxilia d) ler as respostas na thread http://www.freelists.org/post/oracle-l/RMAN-backup-failed-and-ORA07445 - a maioria dos participantes pensou em limites do software (seja o SO, os drivers de fita e media manager que vc tá usando), do hardware (principalmente se 32-bits) e/ou do RDBMS sendo ultrapassados e) cfrme http://danielwestermann.com/2012/04/15/sigsegv-and-the-ora-07445/ lembra, normalmente esse signal de SIGSEGV implica que algum processo morreu inesperadamente : assim sendo, NÂO TEM COMO vc não considerar, além dos possíveis bugs e/ou desajustamentos dos params de kernel, TAMBÉM uma possível issue no hardware... []s Chiappa
Re: [oracle_br] Re: SGA - nK Buffer Cache
Opa, tudo jóia ? Então, sobre o EXADATA não só é verdadeiro o ponto do SMART SCAN como (tal como o ótimo e já clássico paper http://kerryosborne.oracle-guy.com/papers/Tuning%20Exadata.pdf fala) também entra em ação a questão do OFFLOADING , ie, processamento feito pelo próprio storage - afinal, como o hardware é da Oracle também, o software se permite algumas "deduções" , evita alguns acessos por "saber" a situação exata e as exatas capacidades do sub-sistema de I/O ... Sem dúvida, coisas do tipo na prática abstraem questionamentos do tipo block size, até por isso em quase todos os bons papers e na documentação do Exadata quase não se fala de block size, sim É um outro nível, eu considero o Exadata o nosso velho amigo RDBMS Oracle mas on steroids, bombado, reforçado, use-se o termo que melhor se adeque... Sobre o DIRECT READ, sim : desde muito muito tempo os SQLs paralelos fazem I/O direto, bypassando o cache : porém, como SQL paralelo ** não faz sentido ** em ambiente OLTP (que além de tudo TIPICAMENTE fazem I/O single block, como dito), então o que eu falei de aumentar block size para tentar cachear mais linhas com um único I/O ainda valeria para OLTPs, que não fazem paralelismo, mantendo sempre presente a questão da versão : realmente o fato é que na versão 11g, cfrme reportado em http://www.pythian.com/blog/upgraded-to-11gr2-congrats-you-are-in-direct-reads-trouble/ , inclusive SQLs seriais passaram a poder implicar em DIRECT READ, o que pode ** SIM ** influenciar muitérrimo , eu tive essa má experiência numa colocação recente, em que o pessoal estava implementando um sistema OLTP (não cabia Paralelismo portanto) mas que empregava alguns full table scans , em tabelinhas de controle criadas pelo usuário, coisa pequena mas constantemente acessada (taí o indicador CLARO da utilidade do cache, acesso frequente)... O ponto era que se em muitas das sessões os I/Os não retornassem em x segundos o middleware abortava a conexão, aí com os direct reads cada vez mais ativos quase só tinha PIO, o cache não era de grande uso, aí não tinha como chegar na média que o sistema queria de tempo de leitura... O jeito foi desativar mesmo via evento, cfrme http://dioncho.wordpress.com/2009/07/21/disabling-direct-path-read-for-the-serial-full-table-scan-11g/ ... A gente até entende a intenção da mudança, o espírito dela foi correto (afinal, na maioria das situações se vc está fazendo um full table scan vc está lendo uma grande qtdade de dados, e nesse caso já nem ficariam mesmo no cache por ultrapassar o threshold do _small_table_threshold - o busílis foi em particularidades como o meu caso, em que o full table scan estava abaixo do threshold, e assim sendo seria cacheado, E o fornecedor ESPERAVA esse caching, com a introdução do direct i/o mais agressivo E válido para SQLs seriais no 11g aí que deu enrosco... []s Chiappa
Re: [oracle_br] Re: SGA - nK Buffer Cache
Olá Chiappa, Apenas um adendo sobre a sua informa de leitura de blocos e armazenamento em cache. 1º "Ocorre no RDBMS Oracle é que a informação numa tabela NUNCA é lida um registro/uma linha por vez, mesmo que seja apenas uma linha que interessa ao SQL em execução" Em ambiente Oracle tradicional sim isso é verdadeiro mas no Exadata existe um recurso chamado Smart Scan que processa consultas na camada de armazenamento, retornando somente linhas e colunas relevantes para o servidor de banco de dados. 2º "Sempre o que ocorre obrigatoriamente é que o BLOCO aonde a linha reside é localizado e esse bloco TODO (contendo não só a linha de interesse mas n outras) é trazido para o cache" Por padrão sim é verdadeiro, mas existe um recurso no Oracle chamado Direct Path Reads que orienta o Oracle a ignorar o "Buffer Cache". Isso pode ser extremamente útil em por exemplo de relatório extramemente complexo e com muitos dados, mas a consulta é feita uma vez por mês e por apenas uma sessão. Sem contar que consultas realizadas com paralelismo usam o Direct Path Reads. Alessandro Lúcio Cordeiro da Silva Analista de Sistema þ http://alecordeirosilva.blogspot.com/ Porque esta é a vontade de Deus, a saber, a vossa santificação: que vos abstenhais da prostituição. (1º Tessalonicenses 4:3) Em Terça-feira, 7 de Outubro de 2014 20:03, "Leandro Saes saes.lean...@gmail.com [oracle_br]" escreveu: Chiappa, Obrigado pelo complemento ! Ajudou absurdamente... rs Abs. Em 7 de outubro de 2014 10:45, jlchia...@yahoo.com.br [oracle_br] escreveu: > >Não é difícil se pensar em casos onde isso pode fazer alguma diferença : >primeiro pensando em ambientes OLTP, o que ocorre no RDBMS Oracle é que a >informação numa tabela NUNCA é lida um registro/uma linha por vez, >mesmo que seja apenas uma linha que interessa ao SQL em execução : sempre o >que ocorre obrigatoriamente é que o BLOCO aonde a linha reside é localizado e >esse bloco TODO (contendo não só a linha de interesse mas n outras) é trazido >para o cache, ok ? Isso é feito na esperança de que as n outras linhas que >estavam no bloco sejam em breve necessárias, aí já estando no cache vc poupou >I/Os, right ? Ora, com um bloco maior vc tem mais espaço para mais linhas, >assim esse único single block I/O trouxe mais linhas pro cache e portanto em >tese vc AUMENTA as chances de que no futuro breve as próximas linhas >necessárias sejam encontradas no cache... > O segundo cenário seriam sistemas DW/batch/DSS, onde tipicamente vc quer > recuperar uma enorme quantidade de linhas decada tabela : nesse caso, via de > regra como o RDBMS "sabe" que é quase que a totalidade da tabela que vai > precisar ser lida , ele vai optar por table full scan/index fast full scan, > caso em que ele fará I/Os multiblock (ou seja, ao invés de ler um bloco por > vez a tabela/índice, ele opta por ler todo um extent de uma vez, acessando > muitos blocos de uma vez só num único I/O) : evidentemente, se nesse único > I/O de x kbytes se vc conseguiu recuperar mais linhas e seu objetivo é ler > todas ou quase todas as linhas, óbvio que esse único I/O foi mais "rendoso", > mais eficiente, vc recuperou mais linhas da tabela com esse único I/O, no > final das contas menos I/Os serão necessários para se recuperar as linhas > todas... > > Evidentemente : > > a) pensando no OLTP, quando se fala em cache, nós estamos falando de CHANCES, > de ESTATÍSTICA : absolutamente NINGUÉM garante esse que as linhas cacheadas > por esse único single block I/O ** vão ** ser exigidas mesmo no futuro breve, > e que assim vc vai poupar I/Os, yep ?? > > b) podem haver overheads e riscos ** CLAROS ** e pesados com blocos grandes : > por exemplo, no RDBMS Oracle, os DMLs necessariamente ocorrem no bloco, e já > que ele é um banco multi-usuário, ele TEM que "travar" o bloco que vai ser > alterado na fração de segundo em que a alteração ocorre (o chamado LATCH) - > não é impossível que num bloco maior, contendo mais linhas, mais sessões > tenham que acessar as linhas desse bloco, mais sessões estarão esperando pelo > latch, portanto : isso é a contenção de linhas por bloco... > Outro ponto técnico é que no RDBMS Oracle o lock é feito por LINHA (ao > contrário de outros RDBMSs, em que pode haver lock por bloco/página) : isso > traz o efeito positivo que uma sessão A acessando/alterando uma linha X *** > NUNCA *** vai ser bloqueada por uma sessão B acessando/alterando uma linha Y > que calhou de estar no mesmo bloco/página Porém, essa informação TEM que > ser gravada no próprio bloco (é o chamado ITL, Interested Transaction List) - > com um bloco maior logicamente vc vai ter mais linhas presentes no bloco, > então é (em tese) maior a chance de vc mais transações acessando o mesmo > bloco, portanto mais slots de ITL sendo usados, talvez até esgotando a área > reservada a isso Claro que este é um cenário extremo, não tão fáci
Re: [oracle_br] Flash Recovery Area
Bom dia Fabio. Também não possui nada, já havia consultado ela. FILE_TYPE PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE NUMBER_OF_FILES -- - --- CONTROLFILE 0 0 0 ONLINELOG 0 0 0 ARCHIVELOG0 0 0 BACKUPPIECE 0 0 0 IMAGECOPY 0 0 0 FLASHBACKLOG 0 0 0
