Oi Como prometido em um
post anterior sobre redefinição baseada em edição - esta é a segunda parte.
Então, com o que estamos trabalhando? Nosso principal servidor de produção é o Oracle 12C, Enterprise Edition. E, o que é importante observar, várias dezenas de aplicativos estão sendo executados simultaneamente. Por que estamos focando nisso? A tecnologia é relativamente nova, não é muito boa. E seria ilógico transferir alguns sistemas críticos para ele imediatamente. Portanto, decidimos por nós mesmos que passaríamos lentamente de sistemas menos críticos para sistemas mais críticos. Portanto, o próximo problema que precisávamos entender: como trabalhar com a tecnologia EBR e como organizar a integração na situação quando temos uma versão com versão e a outra não. Na versão 12 do Oracle, como se viu, você pode criar objetos não-versionados, pacotes não-versionados, representações não-versionadas em um esquema versionado para organizar a própria integração.
Obviamente, podemos criar uma API não versionada e fornecê-la ao esquema não versionado para uso. Mas e se essa API sem versão (ou parte dela) for usada dentro de nosso aplicativo e precisarmos fazer a versão dentro de nós mesmos e fornecer objetos sem versão para o lado? Este é apenas o próximo problema com o qual lutamos. Usamos a API várias vezes, mas, como você se lembra, há uma limitação de que objetos com versão não podem ser usados sem versão. Naturalmente, desde que vários aplicativos estivessem em execução no servidor, era necessário entender como alternaríamos um aplicativo para a nova Edição e manteríamos a capacidade de usar a API desse esquema com outros esquemas de banco de dados.
Existem várias opções para instalar o Edition:
- defina o valor padrão da Edição para o banco de dados inteiro
- instale o ambiente, novamente em todo o banco de dados.
Essas opções são descartadas imediatamente porque pelo menos alguns aplicativos não mudam para o EBR.
Também é possível criar um serviço para determinar a versão ou determinar a versão ao conectar o aplicativo ao circuito. Isso é conveniente se nos conectarmos ao banco de dados através de algum aplicativo de terceiros.
E se precisamos de trabalhos para executar dentro do cronograma e trabalhar em alguma edição específica? Consequentemente, há outra opção para alternar para uma nova versão - isto é,
orientar a sessão atual para uma versão específica .
Na verdade, nós escolhemos isso por nós mesmos como uma solução. Você pode anexar um gatilho após o logon ao esquema com versão, o que dirá que a sessão atual neste esquema funcionará nesta edição.
Voltando à integração e duplicação de lógica. Existem tarefas: quero versão de algum tipo de lógica de aplicativo dentro do meu esquema e também preciso expô-lo a um usuário que não seja da versão. A princípio, parecia que isso não podia ser implementado, mas, depois de investigarmos a questão, vimos que o pacote dbms_sql habitual, que em princípio se destina a executar algum tipo de consulta dinâmica, pode ajudar a resolver esse problema. Como Muito simples - ao processar uma solicitação ou chamar qualquer bloco anônimo, podemos lançar o nome da condição como um parâmetro, indicando assim a versão na qual esse código será analisado e executado. Se precisarmos usar algum procedimento dentro de nós mesmos e atribuir o mesmo a um esquema de terceiros, simplesmente o envolvamos com uma chamada no procedimento dbms_sql.parse, criando um wrapper que pode ser colocado em um objeto que não seja da versão e - por favor, nosso objeto com versão pode usar usuário não versão.
O que você está enfrentando aqui? Por alguma razão, ao especificar uma condição, os parâmetros out não são emitidos nos procedimentos. Por que - não está claro, mas nos esquemas em que trabalhamos, isso não é usado com frequência. Talvez refizemos a lógica de alguma forma ou procuremos outras soluções.
Os seguintes problemas são erros ou recursos do EBR que encontramos. O primeiro é um problema com tipos construídos e funções em pipeline. O que o Pipeline tem a ver com isso? Além do fato de termos realmente certos algoritmos que funcionam com base em funções em pipeline, o Pipeline é uma certa solução para colocar de lado a visão versionada. Herdamos as visualizações, que contêm uma lógica bastante complicada para o pré-processamento de dados, e os esquemas de terceiros também usam essas visualizações. Portanto, era necessário entender como definir nossas visualizações de versão para um circuito consumidor de dados não-versão, desde que o conjunto de colunas de saída não seja alterado. Como uma solução desse tipo, ficou claro que você poderia agrupar todas essas visualizações com dbms_sql na função Pipeline e, finalmente, colocá-las na visualização para o consumidor; sim, isso consome muitos recursos do servidor, mas não exigiria nenhuma modificação por parte do sistema de recebimento.
Portanto, voltando ao uso das funções de pipeline, verificou-se que, se o tipo que está sendo construído não for criado no pacote de versão que está sendo criado e estiver sendo construído pela primeira vez, o pacote simplesmente não será compilado e desmoronará. Imediatamente uma solução não veio, foi procurar o que foi sugerido por colegas programadores? Alguém disse que é necessário criar esse tipo na versão zero do pacote ou criar um pacote com o tipo correspondente na versão zero do banco de dados. Não ficou claro por que fazer isso. Eles descobriram uma solução em que esses tipos, criados implicitamente quando o pacote foi compilado, poderiam ser simplesmente colocados em um tipo separado como um objeto de banco de dados. Assim, o problema com as funções do transportador é resolvido.
O próximo recurso que encontramos é o comportamento não padrão das visualizações de versão.
Lembre-se, eu falei sobre o fato de que os objetos são herdados e atualizados? Portanto, se você e eu criamos uma visualização com versão em uma edição condicionalmente zero, na quinta edição, percebemos que tínhamos imprecisões nos comentários. Por exemplo, percebo por mim mesmo que em um comentário em uma coluna posso trocar duas letras em alguns lugares. Não deixe tanta imperfeição!
Portanto, o comando de comentários usual leva ao fato de que nossa visualização de versão é atualizada na versão atual. Por causa disso, todos os pacotes dependentes desmoronam e como lidar com isso? Para fazer isso, eles escreveram um certo script que, ao criar uma nova edição, atualizará a visualização de versão toda vez que o próximo lançamento for lançado. Isso não carrega muita carga no dicionário do banco de dados, mas, se necessário, faça pequenas correções ou, por exemplo, emita novas concessões, não precisamos criar uma nova edição
Bem, o último bug ou recurso desse tipo ... Não está claro por que, ao alterar não nulo, as restrições na coluna de visualizações de versão desmoronaram. Ou seja, assim que dissermos que nossa coluna da tabela base agora não deve ter restrições nulas, a exibição se desfaz, mesmo ao usar a redifinição dbms. Nós não poderíamos derrotar isso de forma alguma, talvez os leitores tenham se deparado com isso, será interessante descobrir se uma solução foi encontrada.
O que eu gostaria de dizer em conclusão? A redefinição baseada em edição é uma tecnologia eficaz para uma oportunidade real de lançar uma versão ou hotfix online, no modo de usuário. Tocamos, sentimos, percebemos que a organização da integração em um servidor, quando nem todos os esquemas passarão a usar essa tecnologia, é real, sem mencionar que o esquema com versão pode funcionar em um servidor dedicado ou em um banco de dados de contêiner separado.
E como aplicativo, e como resposta à pergunta-chave, “é possível em produção?” ... Esperamos que a Redefinição baseada em edição seja mais cedo ou mais tarde para todos os nossos projetos, e talvez essa seja a última parada de nossos aplicativos e garanta uma calma suspensão do desenvolvedor responsável pela instalação da nova versão.
Na verdade, é tudo. Obrigado pela atenção.