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 <*> 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
