Servidor de Banco de Dados

01. Premissas Gerais

• As informações deste documento devem ser utilizadas como referência, considerando também fatores externos e tendências de negócio, como crescimento do número de estabelecimentos, usuários concorrentes e uso de softwares de terceiros no mesmo ambiente do TOTVS Varejo Supermercados - ERP Linha Consinco.
• O dimensionamento do ambiente de banco de dados deve ser realizado por empresa ou profissional com experiência em planejamento de capacidade. Temos parceiros especializados que podem apoiar nessa atividade.
• Recomenda-se a utilização de servidor dedicado exclusivamente ao Oracle Database, sem hospedar outros serviços ou softwares que não estejam relacionados aos produtos da Oracle ou à sua sustentação.
• Não há restrições quanto ao uso de ambiente Oracle em alta disponibilidade (RAC).
• Não há restrições quanto à virtualização do ambiente Oracle Database, desde que todos os pré-requisitos e orientações da fabricante sejam integralmente atendidos.
• Os itens descritos como “exemplos”, “referências” e/ou “padrões” de tecnologias têm caráter meramente informativo e explicativo. Sempre considerar os recursos e tecnologias mais atuais disponíveis no mercado.
• Recomenda-se a adoção e implementação de políticas adequadas de segurança de acesso ao banco de dados. Consulte nossa documentação de Política de acesso ao banco de dados para atendimentos de suporte.
• Recomenda-se que a administração do banco de dados seja realizada por empresa ou profissional especializado.
• A TOTVS reserva-se o direito de atualizar, modificar, incluir ou excluir informações deste documento a qualquer momento, sem aviso prévio, em função da evolução de seus produtos e tecnologias.

02. Requisitos de Ambiente

Validação de Pré-requisitos

Os requisitos básicos e verificáveis podem ser validados por meio da ferramenta de validação de banco de dados.

Requisitos de Hardware

• Processador com arquitetura de servidor 64-bit (recomendado x86)

• Espaço mínimo disponível inicial de 200 GB

• Método RAID de alta performance para banco de dados recomendado pelo fabricante

• Discos de armazenamento de alta performance para banco de dados (recomendado SSD, NVMe ou superior)

Planejamento de Capacidade - Com ERP Completo

Requisitos de Software

• Utilizar plataforma operacional homologada (ver tópico Sistemas Operacionais Homologados).
• Oracle Standard ou Enterprise. ¹
• Oracle AWS RDS. ²

¹ A versão Oracle Express Edition (Oracle XE ou FREE) não é suportada.

² Devido às características e restrições do ambiente Amazon RDS para Oracle, algumas funcionalidades podem não estar disponíveis ou podem exigir ações operacionais específicas.

03. Requisitos de Instalação

Os requisitos descritos neste item são obrigatórios para o correto funcionamento do ERP Linha Consinco. Alguns requisitos são opcionais, mas sua ausência pode impedir o funcionamento de determinados recursos do produto.

Premissas

• Utilizar versão Oracle Database homologada (ver tópico Oracle Database Homologados).
• Utilizar character set no padrão WE8MSWIN1252.
• Utilizar national character set no padrão AL16UTF16.

Parâmetros Oracle

• Manter o valor All_Rows (default) ou Choose para o parâmetro Optimizer_Mode
• Manter o valor Exact (default) para o parâmetro Cursor_Sharing ¹
• Manter o valor Manual (default) para o parâmetro Result_Cache_Mode ¹
• Definir o valor de 2000 para o parâmetro Open_Cursors
• Definir o valor False para o parâmetro Optimizer_Adaptive_Features (12.1) ¹
• Definir o parâmetro Optimizer_Index_Cost_Adj com valor de 20 ²
• Definir o parâmetro Optimizer_Index_Caching com valor de 90 ²

¹ Existem problemas de performance conhecidos no ERP ao alterar esses parâmetros.

² De forma geral, recomenda-se seguir a sugestão e ajustá-la conforme o entendimento específico de cada ambiente.

Pacotes de Componentes

• Oracle XML Database
• Oracle Database Java Packages

Criação de Usuário e Tablespace

• Criar o usuário CONSINCO destinado aos módulos do ERP ¹
• A senha do usuário CONSINCO obrigatoriamente precisa estar em maiúscula
• Criar a tablespace TSD_CONSINCO para armazenamento de dados ²
• Criar a tablespace TSI_CONSINCO para armazenamento de índices
• Definir a tablespace padrão do usuário CONSINCO como TSD_CONSINCO
• Criar usuário INTEGRACAO destinado a integração com software de NFe ¹
• Criar a tablespace TSD_INTEGRACAO para armazenamento de dados
• Definir a tablespace padrão do usuário INTEGRACAO como TSD_INTEGRACAO

¹ A importação do dump de implantação já cria os usuários CONSINCO e INTEGRACAO.

² Caso o gerenciamento de alocação da tablespace não seja automático, é necessário que o tamanho do initial extent suporte a criação de campos LOBs (XMLType).

Privilégios

• Privilégio ao usuário CONSINCO para Connect
• Privilégio ao usuário CONSINCO para Resource
• Privilégio ao usuário CONSINCO para Administer Database Trigger
• Privilégio ao usuário CONSINCO para Create Trigger
• Privilégio ao usuário CONSINCO para Unlimited Tablespace
• Privilégio ao usuário CONSINCO para Connect e Resolve na ACL ¹
• Privilégio ao usuário CONSINCO para acesso V$Session
• Privilégio ao usuário CONSINCO para acesso Gv$Session
• Privilégio ao usuário CONSINCO para executar Alter System ² ³
• Privilégio ao usuário CONSINCO para executar Alter Session
• Privilégio ao usuário CONSINCO para acesso Select Any Dictionary ou Select Catalog Role ²
• Privilégio ao usuário CONSINCO para Debug Connect Session ²
• Privilégio ao usuário CONSINCO para Debug Any Procedure ²
• Privilégio ao usuário CONSINCO para executar Sys.Utl_Smtp
• Privilégio ao usuário CONSINCO para executar Sys.Utl_File
• Privilégio ao usuário CONSINCO para executar Sys.Utl_Tcp
• Privilégio ao usuário CONSINCO para read, write, delete na java.io.FilePermission ¹

¹ Privilégio necessário para o correto funcionamento de recursos específicos do produto.

² A ausência do privilégio pode impossibilitar ou dificultar atividades de análise de suporte (ex: encerramento de sessão).

³ A ausência do privilégio pode inibir ou desabilitar recursos do produto, necessários para a atualização do ERP, como por exemplo o encerramento de sessões e a parada da fila de JOBs e Schedules. Como alternativa, podem ser criadas Stored Procedures que permitam ao produto encerrar sessões e manipular a fila de JOBs/Schedules de forma controlada.

-- Procedure
CREATE OR REPLACE PROCEDURE sys.sp_kill_session(p_sid NUMBER, p_serial NUMBER, inst_id NUMBER)
as
BEGIN

EXECUTE IMMEDIATE 'ALTER SYSTEM KILL SESSION '''||p_sid||','||p_serial||','||'@'||inst_id||''' IMMEDIATE';

EXCEPTION
WHEN OTHERS THEN
RAISE_APPLICATION_ERROR(-20000, sqlerrm);
END sp_kill_session;
/
-- Criação do sinônimo
CREATE PUBLIC SYNONYM sp_kill_session
FOR sys.sp_kill_session;

--Grant na procedure
grant execute on sys.sp_kill_session to consinco;

CREATE OR REPLACE PROCEDURE sys.sp_altera_job_queue_processes(p_degree integer)
as
BEGIN
       EXECUTE IMMEDIATE 'ALTER SYSTEM SET JOB_QUEUE_PROCESSES = ' || p_degree; 
EXCEPTION
     WHEN OTHERS THEN
          RAISE_APPLICATION_ERROR(-20000, sqlerrm);
END sp_altera_job_queue_processes;
/
-- Criação do sinônimo
CREATE PUBLIC SYNONYM sp_altera_job_queue_processes FOR sys.sp_altera_job_queue_processes;
 
--Grant na procedure
grant execute on sys.sp_altera_job_queue_processes to consinco;

04. Administração

As informações deste item baseiam-se em boas práticas de administração do Oracle Database para os produtos TOTVS Varejo Supermercados - ERP Linha Consinco. Em alguns cenários, características do ambiente, equipamentos, volumetria e número de acessos simultâneos podem exigir recomendações específicas ou diferentes, inclusive conforme orientações da própria Oracle.

Premissas

• A criação e manutenção de tarefas agendadas (jobs/schedules) no banco de dados é responsabilidade administrativa (DBA).
• Quando necessárias, as tarefas agendadas devem ser criadas utilizando a funcionalidade Scheduler.
• As tarefas agendadas devem ter o parâmetro NLS_LANGUAGE definido com o valor AMERICAN.
• A coleta periódica de estatísticas deve ser realizada utilizando o objeto Pkg_Estatistica, DBMS_Stats ou método equivalente, para todo o schema ¹.
• Manter sem estatísticas as tabelas e índices temporários (GTT), preferencialmente alocando-os de forma que não sejam coletados.
• A coleta de estatísticas deve ser realizada para todos os owners Consinco.
• Periodicamente, o DBA deve avaliar a exclusão de colunas sinalizadas como unsable para liberação de espaço no banco de dados ².

¹ A coleta automática de estatísticas do Oracle não é suficiente na maioria dos casos para o TOTVS Varejo Supermercados - ERP Linha Consinco. Recomenda-se implementar uma política adicional de coleta periódica conforme descrito neste item.

² Em alguns casos, o comando drop de uma coluna pode ser substituído por unsable durante processos de atualização do ERP, especialmente quando a tabela possui grande volumetria. Essa prática evita comprometer o tempo de atualização, reduzindo a necessidade de janelas de atualização prolongadas

Recomendações

• Criar políticas de backup físico e lógico periódicas para o banco de dados (RMAN, Data Pump).
• Utilizar no máximo 70% da memória RAM disponível no servidor para o Oracle.
• Manter redo logs em quantidade e tamanho adequados para um bom intervalo de switch (~15 minutos).
• Configurar o parâmetro Expire_Time no arquivo sqlnet.ora com valor próximo a 10 minutos.
• Configurar o parâmetro Recv_Timeout no arquivo sqlnet.ora com valor NONE.
• Configurar o parâmetro Send_Timeout no arquivo sqlnet.ora com valor NONE.
• Definir o valor Unlimited para a regra Failed_Login_Attempts no perfil dos owners Consinco.
• Definir o valor Unlimited para a regra Password_Life_Time no perfil dos owners Consinco.
• Definir o parâmetro Job_Queue_Processes com valor inferior ao parâmetro Cpu_Count.
• Avaliar e, sempre que possível, aplicar periodicamente os Patch Set Updates (PSU) fornecidos pela Oracle para a versão utilizada.

05. Particionamento de tabelas

Para clientes que utilizam a versão Enterprise do Oracle Database e possuem licença da option de particionamento, as tabelas listadas abaixo são candidatas a particionamento, que, quando implementado corretamente, pode melhorar o desempenho das consultas, otimizar o consumo de recursos e facilitar o gerenciamento do banco de dados.

06. Compressão de dados

Para clientes com Oracle Exadata e recurso HCC (Hybrid Columnar Compression), é possível reduzir até 10x o espaço consumido aplicando compressão nos modos Query Low ou Archive High, conforme o padrão de acesso de cada tabela/partição.

Para clientes com Oracle Enterprise e licenciamento da option Advanced Compression, a compressão pode ser aplicada também em índices, oferecendo níveis superiores ao HCC.

Para clientes com Oracle Enterprise e apenas o recurso Basic Compression, é possível aplicar compressão mesmo em tabelas não particionadas, obtendo redução considerável no consumo de espaço.

Tabelas particionadas são candidatas à compressão utilizando os recursos acima; recomenda-se escolher o tipo de compressão conforme os recursos adquiridos e baseado em testes em ambiente de homologação.

07. Ambiente de Homologação

A criação de bases de homologação ou teste pode ser feita utilizando uma cópia reduzida da base de produção, reduzindo consumo de espaço no servidor e tempo de criação. Esse método aplica cortes nas maiores tabelas do ERP, reduzindo significativamente o tamanho da base. A redução influencia diretamente nos testes de desempenho; portanto, a execução de scripts e a atualização do ERP nesta base não refletem o tempo real de produção, servindo apenas como referência proporcional. Cortes em tabelas históricas podem afetar algumas consultas, mas normalmente não impactam a maioria dos testes e análises de homologação.

Utilize o template de arquivo de parâmetros (expdp) fornecido na Central de Downloads como exemplo para criar um dump reduzido do banco de produção. No arquivo de parâmetros, informe a data de corte conforme o exemplo fornecido; datas mais recentes resultam em dumps e bases de homologação menores. Tabelas de logs serão exportadas vazias e tabelas %BKP% serão ignoradas.

No template sugerido, estatísticas de tabelas e índices não são exportadas no dump; recomenda-se coletá-las após o restore da base de homologação.

08. Oracle Database homologados

As versões da tabela abaixo correspondem às releases mais recentes disponíveis (PSU, RU) na ocasião da homologação do ERP; não é recomendada a utilização de versões inferiores em produção, e para versões superiores, recomenda-se testar previamente em homologação, garantindo compatibilidade sem restringir atualizações de segurança e correções fornecidas pelo fabricante para a versão em uso.

Para versões de Oracle Client homologadas para o ERP, consulte a documentação de instalação do Oracle Client.

Informações adicionais sobre releases e patches de correção fornecidos pelo fornecedor do banco de dados estão disponíveis em https://support.oracle.com.

09. Sistemas Operacionais homologados

Recomenda-se utilizar plataforma operacional Unix 64-bit, preferencialmente Oracle Linux, conforme recomendação do fornecedor e por ser predominante em ambientes com TOTVS Varejo Supermercados - ERP Linha Consinco.

10. Parâmetros de Sistema Operacional

KERNEL

A Oracle especifica parâmetros de kernel e HugePages essenciais para o funcionamento adequado e performático do banco de dados. Para detalhes completos sobre esses parâmetros e suas configurações recomendadas, consulte a documentação oficial da Oracle:

• Changing Kernel Parameter Values

• Minimum Parameter Settings for Installation

• Oracle Database on Linux: HugePages

LIMITES

A Oracle recomenda configurações específicas de limites de recursos para garantir que o banco de dados tenha recursos suficientes para operar eficientemente. Para informações detalhadas sobre essas configurações, consulte a documentação oficial da Oracle:

• Checking Resource Limits for Oracle Software Installation Users