Candiurudba, Acho o fato de mensurar fisicamente o que cada DG ocupa não vale o esforço e a logística de ocupação. Como você pode facilmente mensurar crescimento de objetos agrupados por tipos (tabelas, indices, etc) através de consultas ao dicionário de dados criando um histórico, acho que talvez a utilização de um grande DG facilite a operação. Na prática, para organizar logicamente seu banco você pode continuar mantendo indices e tabelas em TABLESPACES diferentes, como fazemos em filesystems comuns.
Eu só vejo REALMENTE um ganho prático nisso se você tiver CANAIS diferentes no STORAGE para montar as luns e quiser separar algum trabalho pesado de I/O (algumas tabelas FATO grandes, ou um schema usado por um determinado sistema que pesa mais) sem que isso signifique necessariamente separar INDICES e TABELAS e sim separar objetos com demandas de I/O concorrentes. Espero ter ajudado! Abraços e boa sorte! Marcelo Em 28 de abril de 2010 10:02, candiurudba <candiuru...@yahoo.com.br>escreveu: > > > Então Marcos... > > Eu havia pensando a mesma coisa...com relação ao ASM, onde temos o Stripper > e Mirror como carro chefe, temos a distribuição de carga por todos os discos > do Storage e inclusive para trabalhar com BigFile Tablespace, que o > recomendado é tabalhar com ASM pois a distribuição da mesma será feita em > todos os discos, fica meio estranho criar muitos DG. > > Mas eu acho que a intenção do colega tenha sido somente fragmentar os DG > por tipos de segmentos, talvez para facilitar uma administração no que tange > a espaço em disco...assim conseguimos monitorar que o DG XXX, YYY ou ZZZ > cresceu tantos % em X tempo, ou que o DGDATA precisa de mais uma LUN de 50 > GB e que o responsável por este crescimento foi a tablespace BBB...nada que > uma boa volumetria não conseguisse fazer mas só vejo sentido assim pois como > os dados são distribuídos, cai o mito de separação das tablespaces por > sgmentos diferentes.... > > --- Em oracle_br@yahoogrupos.com.br <oracle_br%40yahoogrupos.com.br>, > Marcos Fontana <fontana.mar...@...> escreveu > > > > > Pessoal, > > > > Cá entre nós. Não é muito mais complicado criar este tanto de DG para > > administrar? Não seria melhor criar várias luns de 50 para racionalizar o > > uso do storage e ai sim criar apenas 2 DGs, +DATA e +ARCH? Para que criar > > DGSYSTEM, DGINDEX, DGSEILA? O ASM não faz o arranjo por ele mesmo? Ele > não > > distribui a carga dentro do DG? Acho que isso só aumenta o trabalho. > Dentro > > do storage você não tem nem controle de onde esta cada lun fisicamente. > Já > > vi vários documentos de boas práticas da Oracle e recomendações mesmo > para > > que se use no máximo dois DGs e concordo plenamente. Hoje temos vários > > clientes com esta arquitetura e nenhum problema. > > > > Atenciosamente, > > > > Marcos Fontana > > > > 2010/4/27 Ricardo Cardoso de Sá <ricardo....@...> > > > > > > > > > > > > Sim, pode. > > > > > > Neste caso, eu usaria mais por questões de economia de discos. > > > > > > Obs.: Você deverá ter o mesmo nome de mountpoint nos nodes, exemplo: > > > /oradata/banco/archive tem ser igual para os nodes. > > > Resumindo os archives serão gravados em cada node (thread). > > > > > > Considerando que as maquinas estarão dedicadas para o Oracle RAC, o > impacto > > > é quase 0 "zero". > > > > > > Att.: > > > Ricardo C.Sa > > > > > > -----Mensagem original----- > > > De: oracle_br@yahoogrupos.com.br > > > <oracle_br%40yahoogrupos.com.br><oracle_br% > 40yahoogrupos.com.br> [mailto: > > > oracle_br@yahoogrupos.com.br <oracle_br%40yahoogrupos.com.br><oracle_br% > 40yahoogrupos.com.br>] Em > > > nome de Marcelo Medrado > > > Enviada em: terça-feira, 27 de abril de 2010 12:02 > > > > > > Para: oracle_br@yahoogrupos.com.br > > > <oracle_br%40yahoogrupos.com.br><oracle_br% > 40yahoogrupos.com.br> > > > Assunto: Re: [oracle_br] SUGESTÕES !! Divisão de Discos para ASM + RAC > > > > > > > > > Boa tarde senhores! > > > > > > Uma pergunta: > > > > > > Achei que era pré-requisito ter os archivelogs num lugar comum, visível > > > pelos dois nós (ASM ou OCFS, etc) e sempre fiz dessa forma. Eu posso > > > efetivamente ter um filesystem local em cada nó e salvar os archivelogs > > > neles? Qual o impacto real disso? > > > > > > Abraços! > > > > > > Marcelo > > > > > > Em 27 de abril de 2010 11:57, Ricardo Cardoso de Sá < > > > ricardo....@... <ricardo.dba%40terra.com.br>> escreveu: > > > > > > > > > > > > > > > > Olá, > > > > > > > > Minha sugestão: > > > > > > > > Os discos de QUORUM e OCR, eu criaria no máximo 1G cada um, pois o > > > tamanho > > > > que cada um requer no máximo 256MB. > > > > > > > > Demais discos, eu criaria LUN´s de 64GB. > > > > > > > > Criaria ASM DiskGroup separadas por tipo de segmentos, exemplos: > > > > > > > > DGSYSTEM (SYSTEM, SYSAUX, REDO) 64 GB > > > > > > > > DGUNDO (UNDOTBS1, UNDOTBS2) 128GB > > > > > > > > DGTEMP (TEMP) (64GB) > > > > > > > > DGDATA (DADOS) Inicialmente 128GB e ia adicionando VOLUMES sobre > > > demanda... > > > > > > > > DGINDX (INDICES) Inicialmente 128GB e ia adicionando VOLUMES sobre > > > > demanda... > > > > > > > > Os archives eu colocaria em OCFS2 pois ficaria mais fácil a > administração > > > > ou > > > > caso tenha bastante disco locais, colocaria os archives nos discos > > > locais. > > > > Neste caso é mais uma opção do que pré-requisito. > > > > > > > > Att.: > > > > > > > > Ricardo C.Sa > > > > > > > > _____ > > > > > > > > De: oracle_br@yahoogrupos.com.br > > > > <oracle_br%40yahoogrupos.com.br><oracle_br% > 40yahoogrupos.com.br><oracle_br% > > > 40yahoogrupos.com.br> [mailto: > > > > oracle_br@yahoogrupos.com.br <oracle_br%40yahoogrupos.com.br><oracle_br% > 40yahoogrupos.com.br><oracle_br% > > > 40yahoogrupos.com.br>] Em > > > > nome de candiurudba > > > > Enviada em: terça-feira, 27 de abril de 2010 09:44 > > > > Para: oracle_br@yahoogrupos.com.br > > > > <oracle_br%40yahoogrupos.com.br><oracle_br% > 40yahoogrupos.com.br><oracle_br% > > > 40yahoogrupos.com.br> > > > > Assunto: [oracle_br] SUGESTÕES !! Divisão de Discos para ASM + RAC > > > > > > > > Bom dia colegas !! > > > > > > > > Gostaria de sugestões sobre a uma divisão dos discos do meu storage > que > > > > estou fazendo, para a implementação do ASM + RAC > > > > > > > > Hoje tenho 24 discos de 300 GB e começarei trabalhando com RAW > DEVICES e > > > em > > > > seguida, irei migra-los para BLOCK DEVICES. > > > > > > > > Os binarios do SO + Oracle ficarão armazanados nos discos dos > servidores > > > e > > > > as demais informações (dados, indices, flash recovery e etc) ficarão > no > > > > Storage. > > > > > > > > Pensei em iniciar o Storage trabalhando com um RAID 10 (deixando o > mirror > > > > somente a cargo do Storage e utilizando no ASM somente o stripping), > ou > > > > seja, deste 24 discos, teriamos para trabalhar 12 discos. > > > > > > > > TOTAL GERAL = 3.6 TB > > > > > > > > 300 GB - VOTING1 > > > > 300 GB - VOTING2 > > > > 100 GB - OCR1 > > > > 100 GB - OCR2 > > > > 100 GB - OCR3 > > > > TOTAL 900 GB > > > > + > > > > 1.5 TB - +DATA > > > > 500 GB - +INDX => Não sei se no caso do ASM, é vantajoso separar os > > > indices > > > > dos dados...fiquei na dúvida. > > > > TOTAL 3104 GB > > > > > > > > Restando 568 GB para serem divididos para os Archives e Backups > lógicos > > > !! > > > > > > > > Minha idéia é colocar a geração dos ARC fora do ASM, criando um > > > filesystem > > > > com EXT3 por exemplo... > > > > > > > > Alguma sugestão ? > > > > > > > > [As partes desta mensagem que não continham texto foram removidas] > > > > > > > > > > > > > > > > > > [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] > > > > > [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
