Pular para o conteúdo
  • Este tópico contém 6 respostas, 2 vozes e foi atualizado pela última vez 7 anos, 6 meses atrás por Avatar de Edgar Rombesso RisolaEdgar Rombesso Risola.
Visualizando 7 posts - 1 até 7 (de 7 do total)
  • Autor
    Posts
  • #108738
    Avatar de Edgar Rombesso RisolaEdgar Rombesso Risola
    Participante

      Tenho um database em oracle 10g Enterprise e fiz um hot backup, porém, o restore desse hot backup será efetuado em um database 10g standard.
      Existe algum impedimento ou algum procedimento que deve ser efetuado devido à diferença das versões??

      #108739
      Avatar photoJosé Laurindo Chiappa
      Moderador

        Sem a ** menor ** dúvida, existem sim restrições : cfrme vc vê na Documentação (online em https://docs.oracle.com/cd/B19306_01/license.102/b14199/editions.htm#BABJICBB) há ** diversas ** features/funcionalidades Enterprise que simplesmente não funcionam no Standard Edition – se os teus DADOS foram fisicamente gravados no Enterprise usando uma dessas (digamos, a COMPACTAÇÃO DE DADOS via DATA COMPRESSION, a SEGURANÇA DE DADOS via VPD ou OSA, PARTICIONAMENTO via partition, BITMAP INDEXES, entre muitas outras) vc OBVIAMENTE não conseguirá nem sequer LER esses dados no Standard Edition, pois a funcionalidade necessária para os “decodificar” e/ou pra recriar a estrutura física deles não está presente no Standard…
        Outra possibilidade é sobre as features de processamento de dados eventualmente presentes no Enterprise, elas terão que ser SUBSTITUÍDAS por uma solução desenvolvida por vc ou comprada do mercado : por exemplo, se vc faz replicação de dados via built-ins do banco (seja STREAMS, seja Advanced Replication, seja via CDC, seja via Messaging Gateway) ao vc restaurar esse database num RDBMS Standard Edition ele *** não tem nenhum *** dessas tools, é POR SUA CONTA comprar ou programar algo que as substitua….
        ==> Assim , a sua resposta primeira é : Existem Restrições, é por sua conta verificar se no banco-origem Enterprise está se usando qualquer feature/recurso que não exista no Standard e não possa ser substituído, E TAMBÉM é vc que deverá checar se há alguma feature de processamento de dados que necessite ser reprogramada/substituída por produto de terceiros no banco Standard….

        ==> Para responder a sua outra pergunta sobre os mecanismos de RESTORE, seguinte : tenha em mente os conceitos que um DATABASE no Oracle é o conjunto de arquivos todos (o que INCLUI as tablespaces do sistema, como a SYSTEM), esse database vai ter que ser aberto por uma INSTÂNCIA (um conjunto de binários, que pode ser Enterprise ou Standard Edition) E ** obrigatoriamente ** a instância precisa ter tabelas e views de uso interno no formato específico para a Edition e para a versão/release em que o database foi criado.
        Assim, além de tudo que falei acima, se for um backup completo e apropriado de todo o database (como o que é feito pelo RMAN, por exemplo) esse backup NECESSARIAMENTE VAI CONTER as tabelas internas do database (schema SYS / tablespace SYSTEM), e POR DEFINIÇÃO a estrutura desses objetos é incompatível entre Edições e Versões….OK ??? Então se é RMAN ou cópia completa de database esse teu ‘backup hot’ forget : fosse o restore de uma versão mais antiga para uma mais recentevc até poderia fazer o RESTORE normalmente e depois rodar os scripts/procedimentos de upgrade, mas não é o seu caso… Assim, se esse teu backup HOT é um backup apropriado, DO BANCO TODO, aí vc NÂO VAI CONSEGUIR restaurar de maneira Confiável no Standard esse backup feito no Enterprise, pois tal backup VAI trazer estruturas internas do Enterprise que são INCOMPATÍVEIS com o Standard….

        A sua opção seria algum tipo de BACKUP LÓGICO ou TRANSPORTE DE DADOS, ie : vc teria o database criado vazio no Standard Edition (com o dicionário de dados/tabelas e views internas criado no formato STANDARD EDITION, portanto) e vc enviaria/backupearia no Enterprise APENAS os dados de usuário, que seriam ‘restaurados’ no Standard….

        As suas escolhas para isso seriam :

        a. backup “Lógico”, onde só os dados e as estruturas a serem criadas para suportar os dados vão ser enviadas e lidas : vc faz via EXPORTAÇÃO DE DADOS (via utilitários de export, seja imp/exp tradicional seja datapump) ou gerando um dump/arquivo-texto com seus dados (vc pode escrever algo para isso ou usar as soluções de mercado)

        b. backup Parcial, onde será feita cópia dos datafiles apenas das tablespaces de dados de usuários : para isso vc poderia usar TRANSPORTABLE TABLESPACES (veja em https://blogs.oracle.com/db/entry/master_note_transportable_tablespaces_tts_–_common_questions_and_issues que o Standard PODE SIM importar tablespaces transportadas de um Enterprise, o Standard só não pode é exportar PARA um Enterprise)

        c. LOGICAL STANDBY : ao contrário do stand-by físico que usa redo logs (em princípio INCOMPATÍVEIS entre diferentes Editions) o LOGICAL STANDBY gera comandos SQL (ie, INSERTs, UPDATE, DELETEs, etc) – SQLs básicos do tipo não tem diferença nenhuma entre Editions, tais comandos poderiam ser gerados no Enterprise e enviados pro Standard para lá serem aplicados

        d. envio de dados entre bancos : vc mesmo escreveria um programa que recupera dados do Enterprise e os envia pro Standard (via database link, via geração de arquivos de dados, ou coisa do tipo) OU adquire soluções de mercado que trabalham como homem-no-meio, ie : o programa envia SQLs pro banco Enterprise, recupera os dados, os salva nalgum ponto intermediário (arquivos flat talvez) e os envia pro banco Standard…. Googla por oracle data replication between enterprise and standard edition que vc cai nas mais conhecidas, como SHAREPLEX e DBVISIT por exemplo

        =====>>> E é claro, TODAS as opções de backup lógico/transporte de dados tem suas limitações, cabe a vc checar na Documentação Oracle quais são elas e se elas te impedem de usar alguma delas…

        []s

        Chiappa

        #108740
        Avatar de Edgar Rombesso RisolaEdgar Rombesso Risola
        Participante

          Bom dia jlchiappa…

          Então…eu estava efetuando um restore do banco inteiro via um procedimento que montei e com as outras instancias funciona normalmente, porém esta estancia em particular está em outro servidor e na hora de subir o banco ele sempre dava problema no datafile relativo ao SYSTEM…depois de quebrar a cabeça algumas horas é que reparei na diferença das versões…então estou restaurando da versão enterprise para a standard e como sei que existem diferenças achei que o erro estava ae e você acabou de me confirmar isso…tenho duas situações então…instalar um novo servidor com enterprise para manter esse hot backup ou de alguma maneira adequar um restore completo do banco na versao standard, pois trata-se de um clone de homologação onde tudo é igual, exceto o HOSTNAME e o IP do servidor…

          #108741
          Avatar photoJosé Laurindo Chiappa
          Moderador

            Então : se o objetivo é um CLONE da produção, para servir de Homologação sorry mas NÂO FAZ SENTIDO usar um Standard Edition – se o banco original é Enterprise, a Homologação TEM QUE SER FEITA NUM ENTERPRISE, se não vc NÂO ESTÀ HOMOLOGANDO coisa nenhuma, é um homologação PRA INGLÊS VER, algo FALSO, só pra Enganar incautos…. O objetivo de Homologação é PREVER como o ambiente se comportará em PROD, então é ULULANTEMENTE Óbvio que Quantas MAIS diferenças vc tiver entre PROD e HOMOLOGAÇÃO mais distante de prever o comportamento de PROD vc está – QUALQUER diferença como EDITION, VERSÃO, DIFERENÇAS DE HARDWARE, não precisa ser expert pra dizer que PODEM causar erro na estimativa pois PODEM fazer o ambiente diferente Não se comportar tal como PROD…. A REGRA é uma só, para homologar X vc tem que ter um CLONE de X no exato mesmo hardware com o mesmo exato número de usuários simultáneos, qualquer coisa fora disso é um passo na direção da homologação-pra-inglês-ver… O ** máximo ** que aceito é uma homologação equivalente , ie : usar o mesmo software no mesmo hardware MAS de modelo equivalente com capacidade menor, tipo : um sistema de disco que seja capaz de 50% dos IOs em 50% da memória de prod com 50% dos usuários simultâneos com 50% da capacidade de CPU atendendo 50% do volume do database, aí eu até aceitaria que esse tipo de homologação seja usado pra prever o comportamento de prod…

            No seu caso então seguinte : SE vc quer Homologar na vera, taque Enterprise Edition na mesma versão do banco-origem e cabou….

            SE por qualquer motivo não puder fazer isso, aí vc está na terra da fantasia, vai saber se as diferenças entre Enterprise x Standard não vai interferir na ‘homologação’ eu não aceitaria, mas se vc for obrigado a isso, como eu falei NÂO TEM COMO colnar INTEGRALMENTE um banco Enterprise numa instãncia Standard Edition, não tem essa de “alguma maneira adequar um restore completo do banco na versao standard”, tá claro ???

            Se for absoluta e completamente obrigado a isso, a maneira de vc ter os dados vindos de um banco Enterprise sendo enviados prum banco Standard (e aceitar que essa ‘homologação’ é baseada em sorte e acaso) é uma dessas que indiquei, ie, criar o banco Standard vazio com o software Standard Edition (assegurando que o dicionário de dados está no formato Standard Edition) e depois enviar os dados de usuários pra lá, via EXPORT+IMPORT, TRANSPORTABLE TABLESPACES, SQLs via DATABASE LINK , softwares que transmitem dados/replicam, é isso aí… Com QUALQUER dessas técnicas vc NÃO OBTEVE um clone exato e integral do banco, mas já que vc ‘engoliu’ a gritante chance de divergências por causa das Editions diferentes, talvez esse banco não exatamente clonado te sirva…

            []s

            Chiappa

            []s

            Chiappa

            #108742
            Avatar de Edgar Rombesso RisolaEdgar Rombesso Risola
            Participante

              Pois é…foram exatamente esses meus argumentos…mas não foram aceitos…seria realmente um clone imperfeito…depois de muito argumentar aceitaram que eu montasse um novo servidor Enterprise para efetuar o clone.

              Tks jlchiappa pela ajuda.

              #108743
              Avatar photoJosé Laurindo Chiappa
              Moderador

                Blz…. Já que vc conseguiu autorização para usar um RDBMS de mesma versão e mesma EDIÇÃO da origem, okdoc, ao menos o banco vai ser um clone completo e exato…. NÂO esqueça de equalizar os OUTROS sofwares envolvidos (ie, código do aplicativo, Sistema Operacional, drivers, middlewares, etc) E os hardwares no novo servidor em relação ao servidor original E mesma quantidade de usuários/acessos simultâneos para ter um ambiente de Homologação o mais REALISTA possível, só assim vc consegue efetivamente MENSURAR a performance que deve ser atingida quando a aplicação ir para PROD e também confirmar a ausência de erros, HOMOLOGAÇÂO é bem isso, são esses dois Objetivos o que normalmente se quer….

                []s

                Chiappa

                #108745
                Avatar de Edgar Rombesso RisolaEdgar Rombesso Risola
                Participante

                  Bem isso mesmo..havia mesmo esquecido da quantidade de usuários a mensurar mas já corrigi isso…vlw a ajuda jlchiappa…tks man

                Visualizando 7 posts - 1 até 7 (de 7 do total)
                • Você deve fazer login para responder a este tópico.
                plugins premium WordPress