Histórico da Página
...
Pré Requisitos para migração para o e utilização do Novo Log de Auditoria.
ORACLE
...
Os tablespaces serão criados nos mesmos diretórios de dados onde já existem os arquivos de dados dos tablespaces de sistema RM_DADOS e RM_INDICES. (Caso seja de sua preferência os tablespaces podem ser criados antecipadamente pela sua equipe de DBA's, assim pode-se definir um local diferente para os mesmos.)
Para esta migração utilização é pré-requisito que o usuário que irá realizar a migração(RM) tenha perfil DBA e possua usuário possua as seguintes permissões:
GRANT SELECT ANY DICTIONARY, SELECT ON DBA_LOBS TO RM;GRANT e SELECT ON DBA_SEGMENTS TO RM;.
É necessário também que o parâmetro do SGBD Oracle JOB_QUEUE_PROCESSES esteja com o valor maior que superior a 100.
Para confirmar o valor do parâmetro execute o seguinte query:
SELECT name, value FROM v$parameter WHERE name = 'job_queue_processes';
Caso o usuário não atenda aos pré-requisitos acima, poderão ocorrer erros na conversão da Base de Dados para nova versão.
Testes de Homologação de Novas versões em Bases de Dados Oracle
A partir da versão 12.1.24 foi necessário se colocar implementada uma nova ACTION que realiza algumas verificações a na base de dados Oracle, caso o Novo Log já esteja em utilização.
Com isto sempre que for necessário se fazer um RESTORE do ambiente de produção em homologação é necessário que se faça de ambos os schemas RM e TOTVSAUDIT.
Assim o conversor não irá travar nas verificações devido a falta de objetos na base de dados.
a mesma tem a funcionalidade de verificar se existem problemas no Schema ou objetos do Novo Log de Auditoria, para que não ocorra problemas na Conversão da base de dados.
Caso apresente o erro abaixo durante a conversão, deve-se realizar as seguintes verificações.
As verificações acima devem ser executadas com o Owner do Sistema RM no banco de dados. (Padrão, Schema RM)
Testes de Homologação de Novas versões em Bases de Dados Oracle
Caso seja necessário restaurar uma base de dados Oracle em um ambiente de homologação, utilizando-se das ferramentas IMP ou IMPDP, deve-se restaurar o Schema RM, após o final da restauração deve-se executar a Stored Procedure p_FixNovoLog.(Disponível nas versões 12.1.22 e superiores, verificar junto ao suporte o Patch que possui esta feature disponível)
Comando: EXEC p_FixNovoLog;
Esta nova Stored Procedure faz uma verificação e cria ou recria os objetos necessários para o correto funcionamento do Novo Log de Auditoria como Schema de Auditoria, Tabelas, Grants, Etc.
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------Caso não seja possível fazer o RESTORE do schema TOTVSAUDIT, após realizar o RESTORE do schema RM deve-se desabilitar o Novo Log antes de proceder com a conversão.
SQL SERVER
Caso esteja sendo utilizado o Novo Log de Auditoria em MS SQL Server e aplicações em Delphi é necessário se atentar ao seguinte ponto:
...
* CorporeRM será o nome do Database em uso pela aplicação.
Observações sobre Grants no Oracle para o user RM e user TOTVSAudit:
Na versão 12.1.31 não utilizamos mais sinônimos, contudo o RM precisa ter atribuição de DBA para execução/configuração do TOTVSAudit.
Na versão 12.1.32 foi retirada a atribuição de DBA para o RM, porém, é necessário atribuir alguns grants para execução/configuração do TOTVSAudit:
Sugestão de comandos para adequação do RM nesta versão:
GRANT ALTER ANY TABLE, CREATE ANY TABLE, DROP ANY TABLE, DELETE ANY TABLE, SELECT ANY TABLE, INSERT ANY TABLE, CREATE ANY INDEX, DROP ANY INDEX, CREATE ANY SEQUENCE, DROP ANY SEQUENCE, SELECT ANY SEQUENCE TO RM;