Menu de navegação

[rmanParticipante]

Boa tarde,

Atualmente temos 8 sistemas rodando, cada sistema de um fornecedor diferente, cada sistema possui 1 máquina (servidor) própria, são 8 Oracle 10g R2 (10.2.0.4.0).

A ideia é montar o Oracle 11g R2 RAC com 2 nós.

A pergunta é, qual é a melhor forma de gerenciar em termos de Instancias ?

Para facilitar o raciocínio vamos pensar em apenas 1 nó, eu sei que a quantidade de instancia em 1 nó deve ser igual a do outro. Então vamos considerar apenas 1 nó.

Opções:

1- Criar 1 instancia com 8 schemas, 1 schema para cada sistema.
2- Criar 2 instancias, cada uma com 4 schemas.
3- Criar 8 instancias, uma para cada sistema.
4-

[Douglas Paiva de SousaParticipante]

Estou executando um projeto muito semelhante que esse, só que no meu caso vou trazer 13 servidores de instancia (10g R2) única para um RAC de 4 nós (11g R2), mais um Active Data Guard para um outro Data Center em um RAC de mesma estrutura.

Na questão dos usuários, nosso projeto foi desenhado para ter uma unica instancia com 13 schemas, pois é a forma mais facil de se gerenciar.

[rmanParticipante]

@DPaiva

A solução sugerida pela empresa que vai fazer a instalação do RAC também era criar apenas 1 instancia e dividir em 8 schemas, e também me falaram que desta forma é mais fácil de gerenciar.

Mas não consegui entender por que é “mais fácil de gerenciar” ?

Quando me falaram isso ficou parecendo que essa solução é coisa de DBA preguiçoso que costuma trabalhar com politica reativa. Talvez eu esteja falando besteira por falta de conhecimento em RAC. Mas você conseguiu entender por que é mais fácil de gerenciar ?

Alguns pontos que essa solução não atende:
– Não é possível identificar qual sistema está consumindo mais o banco, já que está tudo misturado na instancia.
– Não é possível fazer backup via RMAN por sistema.
– Caso ocorra um desastre vou ter 8 sistemas off line.
– A manutenção fica amarrada em 8 sistemas.

Como pode ser mais fácil de gerenciar se eu não tenho as informações isoladas por sistema ?

[Douglas Paiva de SousaParticipante]

Não sei se você já trabalha com Oracle a algum tempo ou é novato, mais aqui vão algumas opiniões de quem já lida com isso a um bom tempo.

1 – Quando se faz tunning de Oracle, é claro e evidente saber “quem está consumindo o que”, pois o que consome recursos são instruções SQL, procedures functions e etc, e sempre é possivel saber quem são seus respectivos owners e executores. Além disso existem várias ferramentas já inclusas no banco que nos auxilian nestas tarefas (o AWR, ADDM e os famosos ADVISORS por exemplo). Se tiver algum exemplo de algo que não se pode monitorar por estar misturado em uma unica instancia, por favor me dê um exemplo.

2 – Backup se faz do banco de dados inteiro, porém eu sei que todo dia um backup full vai consumir disco pra caramba, mais é por isso que existem backups incrementais de nivel 0 e nivel 1, ou seja backups somente de blocos alterados. Mais um backup por schema não é inutil eu particularmente faço, porém para isso uso ferramentas como import/export ou datapump (que é melhor).

3 – RAC não é ferramenta de DR (disaster recovery), é ferramenta de balanceamento de carga (Load balance), se você quer ter uma solução para DR, o correto é Oracle Data Gaurd, Oracle Golden Gate ou Oracle Streams.

4 – Que tipo de manutenção você diz que fica amarrada em 8 sistemas???

Outro ponto que você mencionou é que seu RAC vai trabalhar com 2 nós somente, porém isso não é uma boa prática, porque imgine se os seus 2 nós estão trabalhando com mais de 50% de carga cada um e de repente algum deles para de funcionar, o nó sobrevivente não terá capacidade de assumir toda a carga de trabalho, ou seja recomenda-se trabalhar com no mínimo 3 nós.

Se tiver mais alguma dúvida esotu a disposição.

[rmanParticipante]

@DPaiva

Eu sei que é possível identificar o owner, mas imagine a seguinte situação, tenho 8 sistemas rodando dentro da mesma instancia dividido por schemas, vou comprar mais um sistema, e por dentro dessas instancia.

Agora como vou dizer ao fornecedor do sistema que o sistema dele não tem performance no banco, e que ele precisa modificar a forma como é feita ? Não é possível dizer em que ponto do sistema ele deve otimizar, já que tem outros sistema junto com ele.

Relatórios como AWR, ADDM e ADVISORS trabalham por instancia. Para eu conseguir tunnar esse novo sistema, tenho que tunnar todos os outros primeiro. Se o fornecedor me pedir um desses relatórios, o resultado não será real, pois tem elementos externos (outros sistemas) influenciando o resultado.

Até o gerenciamento de memoria é comprometido, pois estará compartilhando com os outros sistemas. Não será usado de forma exclusiva.

Se eu for analisar por exemplo as 10 querys que mais consomem recursos, vai ter um pouco de cada sistema, ou seja, eu não tenho as 10 querys do sistema A ou sistema B. É um top 10 global, não um top 10 por sistema.


4 - Que tipo de manutenção você diz que fica amarrada em 8 sistemas???


Por exemplo, alteração de um parâmetro de inicialização que não é dinâmico. Eu sei que como são 2 nós o sistema não vai ficar off, mas por algum tempo a carga vai cair toda em cima de apenas 1 nó, se ele não aguentar realmente fico amarrado em 8 sistemas.

Creio que a arquitetura de 2 nós foi feita devido a custo, 2 nós é o minimo de um RAC. Mas se 1 nó não aguenta sozinho, realmente o projeto foi mal elaborado.

[Douglas Paiva de SousaParticipante]

Isso é um debate para várias horas, pois temos pontos de vista completamente distintos, mais enfim acho que nossa troca de ideias foi válida pois sempre acaba agregando conhecimento aos dois lados. Essas informações que te passei, são resultado de um trabalho de que foi feito aqui na empresa baseado nas praticas de mercado e em experiencias que tive em outros projetos.

[rmanParticipante]

@DPaiva

Esse RAC de 4 nós já está em produção ?

No meu caso 8 instancias você totalmente inviável ? Ou é que 1 instancia tem muito mais benefícios ?

[Douglas Paiva de SousaParticipante]

Talvez essa necessidade de 8 instancias seja alguma particularidade de seu dia a dia, mais eu me imagino nessa situação e acho estranho, porque administrar uma instancia RAC já dá trabalho pra caramba, imagina 8.
Agora a pouco tive uma ideia que talvez possa lhe ser util, no RAC você pode criar serviços (é + ou – como se fossem instancias virtuais falando a grosso modo) para que os usuários utilizem e assim segregar os recursos e responsabilidades, pesquise sobre isso, o nome do utilitário que faz isso é o “srvctl”.

[PetersonParticipante]

rman, acredito que a escolha da modalidade de disponibilização do banco vai depender mais dos sistemas.
Uma instância com 8 schemas é mais fácil administrar, você faz backup de uma única instância, além disso, pode fazer backups pelo RMAN das respectivas tablespaces de cada schema e complementar com um dump.
Há sistemas que têm necessidades diferentes de dimensionamento da área de memória da instância, o que impossibilitaria concatená-los em schemas distintos dentro de uma única instância.
Avalie a necessidade dos sistemas sem se preocupar com o RAC, pois ele vai ser usar a mesma modalidade que você usaria em uma instalação convencional.
Ao usar um RAC com 2 nós, preocupe-se em ter 2 nós sendo que, cada um é suficiente para atender a todos os usuários. Assim você terá uma solução de alta-disponibilidade. Para uma solução de Loadbalance realmente é recomendado mais de dois nós, pois você terá uma capacidade computacional suficiente para manter o sistema no caso da perda de um dos nós.
Atente-se à performance e a configuração da área de disco do database desse RAC.
No mais é isso. A discussão está em alto nível e agrega a todos.
abraço.

[Autor]

Posts