Re: [oracle_br] Quantidade de instances num Oracle RAC 11gR2 em Linux

2013-01-08 Por tôpico Rodrigo Mufalani 
Pow... Esse cara aí deve entrar no livro dos recordes... Ta aí uma coisa que 
nunca tinha visto antes...

Enviado via iPhone

Em 08/01/2013, às 20:26, Marcelo Procksch  escreveu:

> Impressionante.
> Pensei da mesma forma que o Mulafani pensei que eram schemas.
> Em 08/01/2013 18:48, "JLSilva"  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 
>> 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
>>> 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

Re: [oracle_br] Quantidade de instances num Oracle RAC 11gR2 em Linux

2013-01-08 Por tôpico Marcelo Procksch 
Impressionante.
Pensei da mesma forma que o Mulafani pensei que eram schemas.
 Em 08/01/2013 18:48, "JLSilva"  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 
> 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
> > 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

Re: [oracle_br] Quantidade de instances num Oracle RAC 11gR2 em Linux

2013-01-08 Por tôpico Wadson Ramon 
Em 08/01/2013 19:08, "Wadson Ramon"  escreveu:
>
> Creio que a latencia e a largura de banda entre os nós seja o calcanhar
de aquiles aliado ao comportamento da base em relação a IO .
>
> Em 08/01/2013 16:26, "JLSilva"  escreveu:
>
>>
>>
>> É, 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
>> >
>> >
>>

Re: [oracle_br] Quantidade de instances num Oracle RAC 11gR2 em Linux

2013-01-08 Por tôpico Wadson Ramon 
Creio que a latencia e a largura de banda entre os nós seja o calcanhar de
aquiles aliado ao comportamento da base em relação a IO .
Em 08/01/2013 16:26, "JLSilva"  escreveu:

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

Re: [oracle_br] Quantidade de instances num Oracle RAC 11gR2 em Linux

2013-01-08 Por tôpico JLSilva 
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  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
> 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
>

Re: [oracle_br] Quantidade de instances num Oracle RAC 11gR2 em Linux

2013-01-08 Por tôpico Marcelo Procksch 
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
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 re

Re: [oracle_br] Quantidade de instances num Oracle RAC 11gR2 em Linux

2013-01-08 Por tôpico JLSilva 
É, 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  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
> 
>

Re: [oracle_br] Quantidade de instances num Oracle RAC 11gR2 em Linux

2013-01-08 Por tôpico Vitor Jr 
Caraca... 40, 80 bancos nessa config? Num RAC de apenas dois nós??? O.o
Nunca vi nada parecido, e acho que tão pouco é comum... rrsrsrsrs
Mas está ocorrendo algum problema? Ou questiona apenas pra saber antes 
de implementar?




Att,/Regards,


Vitor Jr.
Infraestrutura / Infrastructure Team
Oracle 11g DBA Certified Professional - OCP
Oracle Certified Expert, Oracle Real Application Clusters 11g and Grid 
Infrastructure Administrator - OCE
Oracle Database 11g Performance Tuning Certified Expert - OCE
Oracle Exadata 11g Certified Implementation Specialist
Oracle Certified Associate, MySQL 5
mail, gtalk e msn:vitorj...@gmail.com 
http://certificacaobd.com.br/
skype: vjunior1981


Em 08/01/2013 14:30, 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.
>
> 



[As partes desta mensagem que não continham texto foram removidas]