tag:blogger.com,1999:blog-5738872960415708519.post2229642472051285105..comments2024-01-29T06:38:46.574-03:00Comments on Blog do DBA/Instrutor Fábio Prado: Boas práticas para gerenciar TablespacesFábio Pradohttp://www.blogger.com/profile/05498446367081034213noreply@blogger.comBlogger5125tag:blogger.com,1999:blog-5738872960415708519.post-61876790746655000392018-12-11T19:26:38.281-02:002018-12-11T19:26:38.281-02:00Quando ocorrer autoextend, as operações DML poderã...Quando ocorrer autoextend, as operações DML poderão entrar em wait, gerando uma indisponibilidade ou atraso temporário.Fábio Pradohttps://www.blogger.com/profile/05498446367081034213noreply@blogger.comtag:blogger.com,1999:blog-5738872960415708519.post-27598288273948933202018-09-27T09:45:39.021-03:002018-09-27T09:45:39.021-03:00Fábio bom dia!
Show de bola, com relação o que voc...Fábio bom dia!<br />Show de bola, com relação o que você ao que você informa no autoextend, tenho uma dúvida.<br />Aqui tivemos um certo problema de lentidão e quedas de conexão ou até desistência de alguns clientes na hora de comprar. A tablespace nossa correlata a loja está com autoextend, gostaria de saber se existe a possibilidade de que ao mesmo tempo que esteja sendo feito o autoextend ter algum tipo de concorrência de informações inputadas ou gravadas nestes datafiles, gerando assim essa indisponibilidade? Ou no caso é possível haver uma alteração maior que o próprio tamanho expandido? Fico preocupado com relação a esse autoextend, sei que é a premissa básica de manutenção dos datafiles, mas qual é o real impacto desse autoextend? Existe sim essa questão de concorrência quando o oracle executa o mesmo!<br /><br />Muito obrigado!Matheushttps://www.blogger.com/profile/02789272291918152694noreply@blogger.comtag:blogger.com,1999:blog-5738872960415708519.post-78810150857466716452014-02-12T11:22:25.572-02:002014-02-12T11:22:25.572-02:00Valeu Fábio. É isso aí, do 11g onwards. Seu post n...Valeu Fábio. É isso aí, do 11g onwards. Seu post não precisa de tantos detalhes. Apenas complementei com minha experiência que é um de nossos papéis como leitores e membros dessa comunidade. Isso enriquece o post!<br /><br />Abraços!<br /><br />Eduardo Valentim<br />Fortaleza-CEAnonymoushttps://www.blogger.com/profile/16732469301825968170noreply@blogger.comtag:blogger.com,1999:blog-5738872960415708519.post-17163600682631693562014-02-12T09:37:30.936-02:002014-02-12T09:37:30.936-02:00Eduardo, eu não entro em detalhes, mas falo sobre ...Eduardo, eu não entro em detalhes, mas falo sobre dividir o backup em seções no item 4. Que bom que vc viu o ganho de performance, mas é bom deixar claro que SECTION SIZE é um recurso que só existe a partir do 11G e que vc só consegue ganhar performance no backup se estiver usando paralelismo e múltiplos canais, ok?<br /><br />Obrigado pelo comentário!<br /><br />[]sFábio Pradohttps://www.blogger.com/profile/05498446367081034213noreply@blogger.comtag:blogger.com,1999:blog-5738872960415708519.post-15909814553734189892014-02-12T09:30:19.601-02:002014-02-12T09:30:19.601-02:00Oi Fábio, parabéns pelo BLOG. Ele é muito rico e a...Oi Fábio, parabéns pelo BLOG. Ele é muito rico e a linguagem facilita o entendimento. Também estou nesta jornada em obter cada vez mais a excelência em banco de dados Oracle e estou acompanhado e seguindo os seus passos em obter mais conhecimento, certificações e reconhecimento.<br />Queria adicionar para os demais leitores do seu blog como comentário do item 4 "BIGFILES" que o script de backup que estava sendo usado em ambientes sem BIGFILES deverá ser ajustado para usar "MULTISECTION". É impressionante como o tempo de backup aumenta drasticamente quando há BIGFILES e não usamos o multisection no RMAN.<br />Fiz um teste onde numa base de dados "X" haviam 190GBs ocupados (180GBs só um tablespace BIGFILE) e o backup levava mais tempo que uma outra base de dados "Z" com o dobro do espaço alocado SEM BIGFILES (o tamanho final de saída em disco do backup era praticamente o mesmo). Tudo isso por conta do BIGFILE.<br /><br />O backup deve usar a cláusula SECTION SIZE (tamanho) para quebrar os BIGFILES do banco de dados. Por exemplo:<br /><br />RMAN> backup section size 5G database;<br /><br />(o RMAN automaticamente dividirá todos os tablespaces bigfiles do banco de dados em pedaços de 5GB durante o backup total.)<br /><br />Somente adicionando "SECTION SIZE", o backup que levava 8h30min, caiu pra 2h30min. Para melhorar mais ainda o tempo de backup/restore, avalie com cuidado também o uso de paralelismo se tiver Enterprise Edition.Anonymoushttps://www.blogger.com/profile/16732469301825968170noreply@blogger.com