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, 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> [mailto: > > oracle_br@yahoogrupos.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> > > 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> [mailto: > > > oracle_br@yahoogrupos.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> > > > 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] >
