Paulo,
Se você separar bem as tablespaces por projeto, e os objetos do banco, é
uma boa idéia. Isso facilita a administração, mas ao mesmo tempo tem
efeitos colaterais (p.e, se você precisar reiniciar o banco, todos os
projetos vão parar).
É preciso analisar bem cada caso. Eu administrava um banco único Oracle em
que cada versão do nosso sistema (precisamos ter bases para pelo menos 3
versões no ar) eram criadas em um novo schema. Se eu tinha a versão 1, 2 e
3, por exemplo, e criávamos a versão 4, a versão 1 era excluída. Como no
nosso projeto os nomes de tablespaces eram padrão, todos os schemas usavam
as mesmas tablespaces, e sempre acontece de termos que edeletar um schema
(que estava no inicio dos datafiles), e não podermos desalocar o espaço. O
banco acabava ficando com tablespace enormes, com muito espaço livre e sem
utilização. Quando precisei duplicar o banco, ou movê-lo de servidor, o
espaço passou a ficar crítico.
Por esses e outros motivos, hoje estou migrando tudo para utilizar uma
instância diferente para cada versão do sistema. Tenho mais instâncias para
administrar (e a memória passou a ficar mais crítica), mas cada banco tem um
tamanho reduzido e pode ser facilmente movimentado. Se preciso deletar uma
versão, baixo o banco e removo tudo. Quando vou criar uma nova versão,
duplico o banco e rodo poucos scripts (antes era export, import, acertar
sinônimos, grants, jobs, etc). Tenho isolamento total entre os ambientes, os
nomes dos schemas, usuários de aplicação, tablespaces são fiéis aos da
produção, e posso fazer atividades em um banco sem afetar quem está
utilizando os outros.
Não sei se foi muito útil para você... mas vários pontos que comentei acima
envolve o que deve ser levado em consideração na decisão entre utilizar
várias instâncias separadas para cada ambiente, ou uma única instância,
separando os ambientes por schemas.
2008/12/3 Reginaldo Ribeiro <[EMAIL PROTECTED]>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Você trabalha ou trabalhava com Sql Server? Este tipo de abordagem é o
> que normalmente se faz com sql server ou mysql. Pense desta forma:
> chamamos de banco de dados no sql server ou no mysql se chama "schema"
> no oracle. É QUASE (eu disse quase; é possível criar usuários sem
> objetos) como dizer que cada banco de dados sql server ou mysql é um
> usuário no Oracle, sacou? Dê uma lida no concepts da versão de banco que
> está utilizando. Procure pelo manual de concepts em
> http://tahiti.oracle.com .
> Sua mudança de pensamento é perfeita.
>
> Ribeiro, Reginaldo
> Administrador de Bancos de Dados
> Oracle Certified Associate 10g
> -
> DBCom Brazil Consultoria em Tecnologia da Informação
> skype: rflribeiro
> mobile: 551192344290
> fone: 551135225172
> e-mail: [EMAIL PROTECTED]
> site: http://www.dbcom.com.br
> Chave Pública:
>
> http://keyserver.noreply.org/pks/lookup?search=rflribeiro%40dbcom.com.br&fingerprint=on&op=index
>
> Paulo wrote:
> |
> | Olá novamente pessoal.
> |
> | Estou percebendo que apesar de ter trocado o Hardware do servidor para
> | uma maquina mais potente e com mais memória RAM, o número de Bases
> | Oracle que consigo subir nela não é tão maior do que na minha maquina
> | anterior.
> |
> | Estive pensando em criar menos Databases e substituir por Tablespaces
> | separadas. Cada Database irá possuir Tablespaces de um determinado
> | projeto. As DB's serão a divisão de projetos diferentes. Esta
> | implementação/organização é correta? Qual é o impacto de desempenho de
> | utilizar Tablespaces ao invés de Databases?
> |
> | OBS.: No caso estas implementações estão sendo feitas em maquinas para
> | o desenvolvimento, sem impacto na produção.
> |
> | Agradeço a atenção!
> |
> | Paulo Andrade
> | MobileCard
> |
> |
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
>
> iJwEAQECAAYFAkk2ubcACgkQ9hsrz6ieG2jbtgP+PXZECkGFEW6zrYmuz/XHa1av
> 5X/Ll3989iJI/vrJntguJb5u3tfXEDZkM/SZIoqikrvvl4bUEoZPUB7Wv9RtYXej
> cQCusBun7iNyxi7dhOXBntY31FMDlcAiivadCCtb39xhcRe7jy2wimd0ldWbQ+mh
> 1Azi5jFNOCyTP0KmPwE=
> =sfmj
> -END PGP SIGNATURE-
>
>
>
--
Thiago Delfim
Oracle & SQL Server Database Administrator
Oracle 9i Database Certified Associate
[EMAIL PROTECTED] (MSN)
Campinas/SP
(19) 8204-2681 / 9111-1439
[As partes desta mensagem que não continham texto foram removidas]
