Impressionante. Pensei da mesma forma que o Mulafani pensei que eram schemas. Em 08/01/2013 18:48, "JLSilva" <jljlsi...@yahoo.com.br> escreveu:
> Marcelo, realmente acho q só um exadata full para suportar algo assim.. > hehe.. > mas, não justificaria um exadata para esse caso, porque os bancos não são > muito grandes nem de uso tão intenso. > Existem alguns que são os principais, esses sim consomem mais. Os demais, > são bancos dedicados a pequenos sistemas satélites. > Essa situação començou há muito tempo (lá no Oracle 6), quando um dos > sistemas era grande demais para que o banco de dados funcionasse em uma só > máquina. Daí começou a segregação. E esse "método" acabou sendo utilizado > para os demais sistemas e se manteve até os dias atuais. consequentemente, > o número de bancos foi aumentando até atingir esse nível.. > > On Jan 8, 2013, at 5:16 PM, Marcelo Procksch <marceloprock...@gmail.com> > wrote: > > > Pensei a mesma coisa que o Mulafani. > > > > Já vi cliente chamar schema de banco de dados, base de dados, base, > > instância, usuário e até mesmo de "espaço de acesso". > > > > Pedi para o cliente executar um ps -ef | grep pmon caso seja linux ou > unix > > ai terá a certeza de quantos bancos de dados estão rodando nesses > > servidores. > > Atualmente estou acompanhando um ambiente com 28 bancos de dados, entrará > > mais alguns, passará dos 30, mas é um Exadata full que foi comprado para > > consolidar e reduzir a quantidades de maquinas, hardware preparado para > > aguentar coisa desse tipo. > > > > Abrax > > > > > > Em 8 de janeiro de 2013 16:31, Rodrigo Mufalani > > <rodr...@mufalani.com.br>escreveu: > > > >> ** > >> > >> > >> Boa tarde JLSilva, > >> > >> Cara, em alguns outros bancos de dados como Mysql, postgres, sqlserver e > >> outros, a palavra database seria o que no Oracle nós chamados de schema. > >> Talvez o seu cliente tenha usado esse termo um desses bancos de dados e > >> tenha lhe passado essa informação (meio equivocada). Eu nunca ouvi > falar de > >> um ambiente com tantas instances de banco de dados em uma só máquina. > >> > >> Olha que já vi muita coisa por ai... > >> > >> Atenciosamente, > >> > >> Rodrigo Mufalani > >> > >> Descrição: Description: Description: O_ACELogo_clr > >> Database Administrator, Oracle OCP > >> rodr...@mufalani.com.br> rodr...@mufalani.com.br > >> ----------------------------------------------------- > >> Mufalani IT Services > >> > >> Rua Candelária 9, Grupo 803 > >> > >> Centro Rio de Janeiro CEP 20091-904 > >> > >> http://www.mufalani.com.br/> www.mufalani.com.br > >> ----------------------------------------------------- > >> > >> > >> De: oracle_br@yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br] > Em > >> nome de JLSilva > >> Enviada em: terça-feira, 8 de janeiro de 2013 16:18 > >> Para: oracle_br@yahoogrupos.com.br > >> > >> Assunto: Re: [oracle_br] Quantidade de instances num Oracle RAC 11gR2 em > >> Linux > >> > >> É, Chiappa. Se nem vc, que, de certa forma, é referência aqui no grupo, > viu > >> coisa assim.. Imagine os demais.. > >> Agradeço pelas respostas. Era o que eu esperava ouvir (ou ler..). > >> Curiosamente, esse cliente tem essa quantidade de databases > distribuídos em > >> 2 servidores não-cluster, e ele diz que está funcionando à contento. > >> Mas, conforme vcs citaram, o cluster insere um contexto diferente, com > mais > >> comunicação entre os processos, e isso gera um overhead expressivo. > >> É uma conclusão ruim, mas é a correta: acredito que o Oracle RAC é > inviável > >> para esse caso. > >> Concordo que a melhor opção é a consolidação dos bancos em schemas, > >> reduzindo para uns 10 bancos, no máximo. > >> Abraço! > >> > >> On Jan 8, 2013, at 4:04 PM, J. Laurindo Chiappa jlchia...@yahoo.com.br > >>> wrote: > >> > >>> Bem, restrição técnica não há por parte da Oracle , e eu até já vi > >> ambiente com múltiplos databases/instâncias nos mesmos servidores, mas > >> coisa > >> de meia dúzia ou pouco mais - nunca vi algo no que vc diz , de várias e > >> várias DEZENAS de databases/instâncias.... > >>> O ponto aqui é que, cfrme nós sabemos, CADA instância além de consumir > >> RAM > >> extra, Também obrigatoriamente VAI TER os seus próprios processos > ativos em > >> background, VAI ter o seu overhead de I/O ** interno **, pelo RDBMS ... > >> Pense no que vai acontecer se casualmente muitas instâncias solicitarem, > >> digamos, block cleanout ao mesmo tempo, o seu sub-sistema de I/O (que > pra > >> variar vc não diz qual é) ** vai ** aguentar isso ??? > >>> Esse pontos de consumo interno do RDBMS são Cruciais - o pessoal até > pode > >> adotar instance caging para tentar "evitar" que um SQL malfeito de uma > >> instância consuma recursos das outras, mas caging basicamente é para os > >> SQLs > >> de usuários/aplicações, o processamento interno feito pelo RDBMS vc não > >> consegue controlar lá muito não... > >>> Outra coisa é oo seu hardware : pra começo de conversa, Gigabit é o ** > >> MÍNIMO ** hoje em dia para utilização em interconnect de RAC, prum > ambiente > >> monstro desse tipo imho isso é INSUFICIENTE, teríamos que estar falando > já > >> em algo na faixa de Infiniband... Idem para o seu poder de > processamento, 4 > >> processadores por mais cores que vc tenha, ao se colocar na balança o > >> montão > >> de processos que esse montão de instâncias vai implicar, imho vai ter > >> espera > >> aí, vai ter gargalo na comunicação dos cores com : para um ambiente > como vc > >> descreve, pra mim tinha que ser algo na faixa de 16 processadores ou > mais, > >> e > >> ambiente Wintel não aguenta isso, então imho pra suportar uma demanda do > >> tipo estaríamos falando de um unix-like, talvez um Superdome ou uma Sun > de > >> alta escala.... E LÓGICO, montes de instâncias VÃO estar fazendo montes > de > >> I/Os muito provavelmente, então vc TEM que ter algo muito forte para I/O > >> também - discos de 15k rpm num storage moderno com lotes de cache, muito > >> certamente... > >>> Então em resumo a sua resposta de minha parte é : não, eu nunca vi nada > >> do > >> tipo funcionando, então não tenho casos concretos de "problemas para te > >> relatar, , MAS certamente (pelos pontos acima citados) com CERTEZA não é > >> nada impossível que vc se depare problemas de > >> Administração/schedule/capacidade do hardware, okdoc ?? A minha > >> Recomendação > >> assim sendo não pode deixar de ser : OU vc centraliza FORTEMENTE esse > >> ambiente em schemas de mesmas instâncias (a opção Preferida, pois assim > vc > >> inclusive vai EVITAR algum eventual bug ou limitação não-documentada, > uma > >> questão sempre presente quando vc trabalha acima do normalmente > esperado), > >> OU vc sobe o hardware FORTEMENTE, caso contrário os riscos vão ser > reais e > >> presentes... > >>> > >>> []s > >>> > >>> Chiappa > >>> > >>> --- Em oracle_br@yahoogrupos.com.br > >> , JLSilva escreveu > >>>> > >>>> Boa tarde, pessoal. > >>>> > >>>> Gostaria de saber se alguém já passou por problemas devido a um grande > >> número de instances em um Oracle RAC 11gR2. > >>>> Algo em torno de 40 e 80 bancos de dados. > >>>> > >>>> Descrição do ambiente: > >>>> 2 servidores HP DL580 G7 > >>>> 4 processadores intel hexacore em cada servidor > >>>> 256GB de RAM em cada servidor > >>>> 2 interfaces gigabit para interconnect (bond mode 6) > >>>> > >>>> Obrigado. > >>>> JLSilva. > >>>> > >>> > >>> > >>> > >>> > >>> ------------------------------------ > >>> > >>> ---------------------------------------------------------- > >>>> 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] > >> > >> > >> > > > > > > > > -- > > Att. > > Marcelo E. Procksch > > > > > > [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 > > > > > > > > ------------------------------------ > > > -------------------------------------------------------------------------------------------------------------------------- > >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] ------------------------------------ -------------------------------------------------------------------------------------------------------------------------- >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
