Menu de navegação

[HitotuziParticipante]

Senhores DBAs

Gostaria de um direcionamento sobre o banco de dados em um ambiante de desenvolvimento, estou tendo problemas (atritos) com os desenvolvedores pois os mesmos querem que sejam instalados um banco de dados nas suas estações de trabalho, para os mesmo utilizarem nos seus respectivos desenvolvimentos e testes, alegando a questão da concorrência de um banco de desenvolvimento centralizado no sentido que alguns procedimentos utilizam a mesma tabela e as vezes estas são modificada na estrutura e nos dados por um desenvolvedor e acaba interferindo no trabalho de outro desenvolvedor, temos 8 desenvolvedores. Administro os bancos de produção, homologação e desenvolvimento e não vejo a necessidade de ter que administrar mais 8 instâncias individuais, eles disseram que eu só preciso disponibilizar o dump que eles se viram para atualizar e manter. Mas eu sei que não vai ser bem assim, quando der algum problema eles vão querer suporte. Não quero ser o dba que trava ou dificulta os processos, porém quero seguir os melhores procedimentos afinal tenho responsabilidade pelos bancos da instituição. Não sei se estou com uma visão fechada demais quanto a isso, também nem sei quanto a questão de licenciamento se é possível ter essas instâncias de desenvolvimento em cada estação, afinal compramos licença para os servidores de grande porte. Se algum de vocês colegas dbas passaram por essa situação, favor me deem um direcionamento, qual as melhores práticas quanto a isso? Como devo proceder?

Desde já agradeço!

@Hitotuzi

[José Laurindo ChiappaModerador]

Blz ? Então, de cara posso dizer que ** não é ** a situação-padrão cada um ter o seu banco particular (até porque concordo com vc, que cedo ou tarde eles VÃO precisar de ação de DBA, por mais simples que um banco seja ** dificilmente ** ele sobrevive muuuuito tempo sem manutenção que só um DBA pode dar, e aí sobraria para VOCÊ ser esse DBA, além do que que já faz hoje nos outro bancos da Empresa) : há Diversas possibilidades para se evitar isso , vou explanar algumas na minha resposta nos parágrafos futuros….
Agora : eu vou listar mais abaixo as opções / possibilidades para não chegar à situação de realmente cada um ter um banco de dados próprio na sua máquina desktop particular, mas se por qquer particularidade essas opções não forem adequadas pra sua empresa/ambiente, uma opção seria vc apelar para o banco Oracle Express Edition (XE) – esse tipo de RDBMS Oracle é gratuito para ser usado em qualquer tipo de operação e máquina e em qualquer quantidade, o que Eliminaria as suas preocupações com Licença, mas possui LIMITES CLAROS em termos de máximo de RAM que pode acessar, número de processadores que pode acessar, funcionalidados do RDBMS Oracle que se pode usar e (principalmente) no volume máximo de dados, veja a documentação online em https://docs.oracle.com/cd/E17781_01/install.112/e18803/toc.htm#XEINW119 para ficar ciente deles…. Tecnicamente falando, *** SE *** os dados que vc vai passar estão abaixo desse limite E SE os desenvolvedores não vão testar/usar nenhuma das MUITAS features e recursos do banco que o XE não tem , então Sim, vc poderia instalar em cada máquina pessoal (ou ainda, dar o link e mandar cada um instalar na sua máquina) um banco XE….
*** OBVIAMENTE ***, mesmo sendo um banco limitado e com muita coisa automática teu instinto está certo, sim, cedo ou tarde vc VAI ser chamado pra mexer/dar manutenção nesses bancos, por mais simplificado que seja o RDBMS em questão NÃO TEM COMO um Desenvolvedor conseguir controlar/manter/cuidar de um RDBMS sozinho…

Aí vem a sua primeira resposta , então : se as técnicas/opções que vou listar mais a frente e compartilhamento de um único banco não sejam usáveis por vc (e assim vc tem que ter outros bancos para os desenvolvedores) E as limitações do XE impedem o uso então SIM, vc VAI TER QUE comprar licenças de uma outra Edição qualquer do RDBMS Oracle …. Não faz mal que as máquinas dos desenvolvedores sejam de hardware inferior e rodem versão “não-Enterprise” de Windows, o RDBMS Oracle roda em qualquer máquina que tenha pelo menos 2 GB de RAM (embora 4 GB sejam melhores pra performance), umas tantas dezenas de GBs livres de esoaço em disco e Windows ou Linux relativamente recente (Windows 7 pra cima, e no caso de Linux qquer distro de Linux compatível com Red Hat Enterprise Linux 5 pra cima)…

===> A sua segunda resposta : o procedimento mais adequado para evitar não só questões de licença mas (principalmente) o teu trabalho extra de vc ter que Administrar n novas instâncias e seus N desenvolvedores poderem dividir o mesmo database se baseia nestes dois conceitos :

a. o conceito de que, dentro de um único banco Oracle, vc pode ter múltiplos schemas (ie, áreas de criação), que cada usuário que vc cria no banco tem seu schema próprio ** E ** que os schemas são independentes : assim, se o usuário JOAZINHO criar uma tabela PRODUTOS no schema dele e o usuário ZEZINHO criar uma tabela com esse mesmo nome de PRODUTOS, as duas tabelas são ** ABSOLUTAMENTE DIFERENTES ** para o RDBMS, podendo ter dados diferentes e/ou estruturas diferentes, cfrme desejado

e

b. o conceito de que vc pode dar acesso às tabelas de um schema a quaisquer outros, se preciso criando um sinônimo para que não seja necessário acessar como nomedoschemadono.nomedatabela

Fica óbvio então a base do procedimento, ie : no mesmo banco de desenvolvimento vc vai criar um usuário (e portanto um schema) que vai ser o dono das tabelas todas da aplicação, vai importar o dump que vc citou pra esse schema, vai criar para cada desenvolvedor um usuário (e um schema portanto),vai dar a permissão de SELECT em cada uma das tabelas para cada usuário dos desenvolvedores E vai criar um sinônimo particular com o nome de cada tabela apontando para a tabela origem…..
Assim : suponha que vc criou para os os desenvolvedores os usuários de banco JOAOZINHO, ZEZINHO, HUGUINHO e LUIZINHO, que o schema APP_OWNER seja o dono dos objetos da aplicação e que ele tenha as tabelas NF, ITEM_NF, PRODUTO e CLIENTE : se APP_OWNER deu GRANT de SELECT em cada tabela para cada um dos usuários dos desenvolvedores, e vc criou ( na conta do cada um deles) sinônimos particulares apontando para cada tabela do APP_OWNER, qualquer desses desenvolvedores poderá se logar no banco, escrever queries envolvendo qualquer das tabelas da aplicação simplesmente indicando-as no FROM, tipo :
SELECT colunas FROM NF, ITEM_NF WHERE condições;
e AUTOMAGICAMENTE, sem precisar de nada, a query vai acessar os dados do APP_OWNER….

Quando um desenvolvedor quiser fazer testes de alteração da estrutura de uma tabela, ele simplesmente apaga o sinônimo, cria uma tabela com o mesmo nome a zupt, ele vai acessar a tabela alterada, que como é uma tabela particular NÂO VAI INTERFERIR EM NADA com os outros schemas….
Por exemplo, o ZEZINHO quer fazer um teste criando uma nova coluna DT_REEMISSAO na tabela NF : ele simplesmente faria, conectado com o usuário dele :

DROP SYNONYM NF;
CREATE TABLE NF as (select * from APP_OWNER.NF);
(e eventuais CREATE INDEX ou outras dependências se for o caso)
ALTER TABLE NF ADD DT_REEMISSAO date;

e pronto : transparentemente ele vai continuar acessando as tabela originais EXCETO quando se referir à tabela NF, que aí não havendo sinônimo o Oracle sabe que é tabela local).....

O bom deste procedimento é que no futuro, quando a alteração de tabela for Aprovada e precisar ser Homologada, basta que o ZEZINHO te dê os ALTER TABLEs que ele fez no teste e vc os executa no banco de Homologação, E depois que for Homologado vc executa os mesmos DDLs no banco PROD.....

É isso, ESSA (ou alguma forma derivada) é a maneira de vc poder ter tabelas com o mesmo nome tendo estruturas diferentes….

[]s

Chiappa

OBS :

uma outra opção poderia ser ter VIEWS em diferentes ‘versões’ usando o recurso de Edition-based Redefinition, se vc o tiver disponível na sua versão de RDBMS : dá uma estudada em https://oracle-base.com/articles/11g/edition-based-redefinition-11gr2#editionable_objects e em http://www.oracle.com/technetwork/issue-archive/2010/10-jan/o10asktom-172777.html para os detalhes, e veja se as limitações da Feature não impedem o uso no seu cenário….Normalmente impedem, mas veja lá…

[HitotuziParticipante]

@jlchiappa muito obrigado!

  Suas dicas clarearam bastante, os dados desse banco ultrapassam o limite do Oracle XE, vou analisar as opções que você me apresentou e aplicar a melhor estratégia, mais uma vez muito obrigado pelas dicas.

@Hitotuzi

[José Laurindo ChiappaModerador]

Blz… Adiciono apenas que tudo o que disse na questão de ‘compartilhamento’ (ie, que desconsiderando RAC uma instância Oracle só pode ter um database, e que portanto vc teria que ter schemas diferentes) vale até o banco 11gR2 : no banco 12c em diante nós passamos a ter a figura do PDB, o PLUGGABLE DATABASE, onde uma única instância (com portanto um só conjunto de binários pra vc administrar/controlar) pode gerenciar N databases , nesse caso vc poderia criar um pequeno database para cada desenvolvedor …. Isso implicaria em custos de licenciamento (pois não existe ainda um banco free XE versão 12c que permita PDB, e iirc na licença de uso do Oracle 12c não-gratuito só vem licença para UM PDB) mas ao menos seria uma instância só pra vc administrar, cheque isso…
E Obviamente, se vc optar pela opção de múltiplos schemas em um só database de uma só instância, ** TUDO ** o que eu mostrei que precisa se fazer vai ser feito via AUTOMAÇÃO, obviamente : é um trabalho de louco manso ficar criando na mão um sinônimo pra cada tabela, OBVIAMENTE vc vai usar uma técnica que crie isso para você – eu quando tenho uma necessidade de repetir N vezes uma ação costumo usar um script sqlplus que gere os comandos necessários, tipo :

SELECT ‘CREATE SYNONYM nomedousuáriodesenvolvedor.’ || table_name || ‘ FOR nomedodonodastabelas.’ || table_name || ‘;’
FROM DBA_TABLES
WHERE OWNER=’nomedodonodatabelas’;

Aí só executo os CREATEs todos gerados…

Também o procedimento de cada usuário desenvolvedor remover seus sinônimos particulares e criar a tabela local para que ela seja alterada pode ser Automatizado , provavelmente encapsulado numa Procedure que execute os SQLs via EXECUTE IMMEDIATE ou similar…

[]s

Chiappa

[Autor]

Posts