Histórico da Página
Resumimos abaixo as recomendações e informações relevantes para migração do seu ambiente Oracle Database para a versão 19c.
PREMISSAS
É fortemente recomendável que as atualizações de versão de banco de dados sejam realizadas primariamente em ambiente de homologação, para avaliar possíveis impactos nas principais rotinas utilizadas pela operação do ERP, em especial, as rotinas envolvidas nos tópicos abaixo.
01. Versão do ERP
Obrigatório É obrigatório estar na versão 22.01 ou superior do ERP.
02. Release Update Oracle
É obrigatório utilizar a versão 19.10 ou superior de acordo com o RU disponível na ocasião da atualização.
03. Limitação de CPU na Versão Standard
A partir da versão 12.2 a Oracle impôs uma limitação de CPU para a licença Standard, assim, se houver mais CPU (threads) na máquina do que essa limitação, o Oracle não utilizará na instância e caso haja demanda dos usuários poderá haver contenção afetando o desempenho das aplicações. Portanto, ambientes Oracle Standard que estão em 11g e irão migrar para versões superiores, como a 19c, é importante atentar-se ao consumo atual de CPU para verificar se atinge essa limitação.
...
04. Diretórios e Objetos de Diretório
Na versão 19c não há mais suporte a caminhos absolutos (ex: /u01/oracle/dbx) para leitura e escrita de arquivos no Oracle, sendo necessário obrigatoriamente trabalhar com objetos de diretórios (directory). O ERP na versão 22.01 já está preparado para trabalhar com objetos de diretório, portanto, basta o DBA responsável pelo ambiente mapear os diretórios existentes atualmente no Oracle para exportação e importação de arquivos (se utilizar) e criar os objetos de diretórios com base nestes caminhos. Após o mapeamento e criação dos objetos de diretório, basta ajustar as configurações das rotinas no ERP que utilizam estes caminhos substituindo o caminho pelo nome criado pelo DBA.
É obrigatório a criação de um objeto de diretório (directory) no banco de dados pelo DBA com o nome GET_DIR_RMSpara ser utilizado pelas rotinas do ERP que precisam ler e escrever arquivo à partir do banco de dados. A configuração do parâmetro 50 no Acesso U: terá que ser ajustado para o valor conforme o nome do objeto de diretório. No Exemplo abaixo, o objeto de diretório foi criado com o nome GET_DIR_RMS, portanto, o parâmetro deve ser definido com este valor.
...
05. Jobs e Schedules
A partir da versão 19c o recurso de job foi descontinuado oficialmente, e os jobs existentes são automaticamente migrados para a funcionalidade de scheduler, que tem a mesma finalidade. Porém, recomenda-se evitar a migração automática, dando preferência para migração manual antecipada, ou seja, migrar os jobs para schedules antes de migrar para a versão 19c.
...
. A migração automática cria os schedules em modo "legado" tornando-os ainda visíveis para as views de jobs, o que pode gerar confusão na administração dos agendamentos.
O usuário de banco de dados do RMS deverá receber o privilégio para criação de job (grant create job to RMS) para que as aplicações que criam job possam executar sem falha (ex: Exportação PDV).
A aplicação VGGMJOBS somente suporta a visualização de jobs "legado" (criados com DBMS_Job), portanto, schedules criados diretamente usando DBMS_Scheduler não aparecerão nesta aplicação.
Informações |
---|
Importante: A migração manual dos jobs para schedules é uma tarefa administrativa, portanto, deve ser realizada pelo cliente ou DBA responsável pela gestão do ambiente. Caso necessite de apoio nessa atividade, poderá ser solicitado a área de serviço da TOTVS. |
06. Senha do Usuário RMS
Checar se É obrigatório que a senha do owner RMS no banco de dados está exatamente igual a configurada no ERP, pois a partir da versão 19c não há mais como desligar o senstive key para senhas dos owners (exceto senhas criadas em versões anteriores).
...
usuário de banco de dados do RMS esteja com retro compatibilidade para a versão 10g devido a incompatibilidades com o componente utilizado atualmente nas aplicações desktop. Para isso, o DBA deve certificar-se que o usuário de banco de dados utilizado pelo RMS está com essa compatibilidade após a migração para o ambiente 19c. Essa retro compatibilidade é controlada no banco de dados pelo parâmetro SQLNET.ALLOWED_LOGON_VERSION_SERVER que fica no arquivo sqlnet.ora.
Informações |
---|
Em versões futuras do RMS esse componente de conexão será atualizado e eliminaremos a necessidade de retro compatibilidade da senha com a versão 10g. |
07. Oracle Client
Deve-se manter o Oracle Client 11g 32-bit nas estações de trabalho dos usuários, uma vez que o Oracle Client 12 e 19 na versão 2122.01 ainda não são homologados pelos módulos desktop. Consulta a documentação de Oracle Client homologados na ocasião da atualização.
...
08. Bugs Oracle Catalogados
Consulte a página de bugs Oracle catalogados para verificar se há indicação de bugs para a versão a ser atualizada do banco de dados, e em caso positivo, efetive a aplicação do patch ou workaround indicado pela Oracle.
...
09.
...
Parâmetros Oracle
Recomenda-se utilizar o último Release Update disponível para a versão 19c (19.10 ou superior de acordo com ocasião da atualização)Caso o parâmetro do Oracle Optimizer_Adaptive_Plans esteja definido como FALSE, é recomendável que seja retornando para o valor padrão TRUE na versão 19c.