Servidor de Banco de Dados

01. Premissas

• As informações contidas neste documento devem ser utilizadas como referência, sendo essencialmente necessário considerar fatores externos e tendências de negócio, como crescimento do número de estabelecimentos, usuários concorrentes e aquisição e utilização de softwares de terceiro no mesmo ambiente do ERP Linha Consinco. É imprescindível que o dimensionamento do ambiente de banco de dados seja feito por empresa ou profissional com know how em planejamento de capacidade. Temos parceiros especializados que podem auxiliar nesta atividade.
• Recomendamos a utilização de servidor dedicado exclusivamente ao produto Oracle Database, não hospedando quaisquer outros serviços e softwares que não estejam relacionados aos produtos da Oracle ou a sua sustentação.
• Não há restrições quanto a utilização de ambiente Oracle de alta disponibilidade (RAC).
• Não há restrições quanto a virtualização do ambiente Oracle Database, desde que, os pré-requisitos e orientações da fabricante do banco de dados sejam completamente atendidos.
• Os itens descritos como "exemplos" e/ou "referências" e/ou "padrões" de tecnologias são meramente informativos e com proposito explicativo, portanto, considerar sempre os recursos e tecnologias mais atuais disponíveis no mercado.
• Recomendamos a adoção e implementação de políticas razoáveis de segurança de acesso ao banco de dados. Consulte nossa documentação sobre política de acesso ao banco de dados para atendimentos de suporte.
• A TOTVS reserva-se no direito de atualizar, modificar, incluir ou excluir informações deste documento a qualquer momento, sem aviso prévio, decorrente da evolução de seus produtos e tecnologias utilizadas.

02. Requisitos de Ambiente

Validação

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

Requisitos de Hardware

• Processador com arquitetura servidor de 64-bit (Xeon, Opteron, Sparc)
• Espaço inicial mínimo disponível de 200 GB
• Método RAID de alta performance para banco de dados
• Discos de armazenamento de alta performance para banco de dados (SAS, SSD)

Planejmento de Capacidade - Com ERP Completo

Requisitos de Software

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

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

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

03. Requisitos de Instalação

Os requisitos descritos neste item, são obrigatórios para o correto funcionamento do ERP Linha Consinco. Alguns itens são opcionais, porém, impedem que determinados recursos do produto tornem-se funcionais.

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 ²

¹ Há problemas de performance conhecidos no funcionamento do ERP com a alteração destes parâmetros.

² Em linhas gerais, recomenda-se seguir a sugestão e ajustar de acordo com o entendimento do 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.

² É recomenda a realocação periódica dos índices, em especial se as tablespaces de dados e índices estiverem em disco distintos.

³ Caso o gerenciamento de alocação da tablespace não seja automático, é necessário que o tamanho da 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.

² Privilégio opcional e sua ausência pode impossibilitar ou dificultar atividades de análise de suporte.

³ Privilégio opcional e sua ausência pode inibir ou desabilitar recursos de encerramento de sessões dentro do produto. Como alternativa pode ser criada a procedure abaixo para que alguns recursos do produto consigam realizar o encerramento de sessões.

-- 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;

04. Administração

As informações descritas neste item baseiam-se em boas práticas na administração do banco de dados Oracle para os produtos TOTVS Varejo Supermercados. Em alguns cenários, as características de ambiente, equipamento, volumetria e número de acessos simultâneos ao servidor podem exigir recomendações específicas ou diferentes, inclusive da própria fabricante Oracle. Recomenda-se que a administração do banco de dados Oracle seja feita por empresa ou profissional especializado.

Pré-requisitos

• A criação e manutenção de tarefas agendadas (jobs/schedules) no banco de dados é uma tarefa administrativa (DBA).
• As tarefas agendadas, quando necessárias, devem ser criadas com na 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 feita utilizando o objeto Pkg_Estatistica ou DBMS_Stats (ou método semelhante) para todo o schema. ¹
• Deve-se manter sem estatísticas as tabelas e índices temporários (GTT), preferencialmente, alocando-os para que não seja coletado.
• A coleta de estatísticas deve ser realizada para todos os owners Consinco.
• Periodicamente e oportunamente o DBA deverá avaliar a exclusão de colunas sinalizadas como unsable para liberação de espaço no banco de dados. ²

¹ A coleta de estatísticas automática do Oracle não é suficiente na maioria dos casos para o ERP Linha Consinco, portanto, recomenda-se a sua desativação e a implantação de política de coleta periódica conforme orientações descritas neste item.

² Eventualmente o comando drop de uma coluna pode ser substituído pelo comando unsable no processo de atualização do ERP, caso a tabela apresente uma volumetria de dados elevado. Esta medida é importante para não comprometer o tempo de atualização, exigindo uma janela atípica.

Recomendações

• Recomenda-se criar políticas de backup físico e lógico periódico para o banco de dados (RMan, Data Pump).
• Recomenda-se utilizar no máximo 70% da memória RAM disponível no servidor para o Oracle.
• Recomenda-se manter redo logs em quantidades e tamanhos para um bom intervalo de switch (~15 min).
• Recomenda-se o uso do parâmetro Expire_Time no arquivo Sqlnet.ora com valor próximo à 10 minutos.
• Recomenda-se o uso do parâmetro Recv_Timeout no arquivo Sqlnet.ora com valor igual a NONE.
• Recomenda-se o uso do parâmetro Send_Timeout no arquivo Sqlnet.ora com valor igual a NONE.
• Recomenda-se o uso do valor Unlimited para a regra Failed_Login_Attempts no profile dos owners Consinco.
• Recomenda-se o uso do valor Unlimited para a regra Password_Life_Time no perfil dos owners Consinco.
• Recomenda-se definir o parâmetro Job_Queue_Processes com valor inferior ao parâmetro Cpu_Count.
• Recomenda-se avaliar e, se possível, aplicar periodicamente os Patch Set Updates fornecidos pela Oracle para a versão utilizada.
• Recomenda-se realocar periodicamente os índices pelo DBA responsável pela administração do ambiente, em especial, se as tablespaces de dados e índices estiverem em disco distintos.

05. Particionamento de tabelas

Para clientes que adquiriram a versão Enterprise do Oracle Database e possuem a licença da option de particionamento, as tabelas listadas abaixo são candidatas a serem particionadas. O particionamento de tabelas quando implementado de forma adequada, pode auxiliar consultas a terem um melhor desempenho, otimizar o consumo de recursos e viabilizar um melhor gerenciamento do banco de dados.

Para as tabelas listadas acima que forem particionadas, recomendamos que todas as tabelas filhas sejam particionadas utilizando o método por Reference Partitioning.

06. Compressão de dados

Para clientes que adquiriram o Oracle Exadata e que possuem a disposição o recurso HCC (Hybrid Columnar Compression), é possível reduzir em até 10x o espaço consumido por dados aplicando a compressão nos modos Query Low ou Archive High, de acordo com a característica de acesso de cada tabela/partição.

Para clientes que adquiriram o Oracle Enterprise e possuem o licenciamento da option Advanced Compression, também é possível aplicar a compressão e em níveis superiores ao HCC, já que com este recurso também é possível fazer a compressão de índices.

Para clientes que adquiram o Oracle Enterprise e possuem a disposição apenas o recurso Basic de compressão, é possível aplicar a compressão mesmo em tabelas não particionadas e obter ganhos na redução do consumo de espaço.

Tabelas que foram particionadas são candidatas a serem comprimidas utilizando um dos recursos descritos acima. Recomendamos que o tipo de compressão seja escolhido de acordo com os recursos disponíveis adquiridos junto ao fornecedor e baseado em ensaios em ambiente de homologação.

07. Ambiente de Homologação

A criação de base de homologação ou de teste pode ser realizada utilizando uma cópia reduzida da base de produção, visando economizar o consumo de espaço no servidor e o tempo de criação da base de homologação. Esse método reduz significativamente o tamanho da base, pois será aplicado um corte nas maiores tabelas do ERP. A redução da base influencia diretamente nos testes de tomada de tempo, portanto, a execução de scripts e a própria atualização do ERP neste tipo de base não reflete diretamente o tempo necessário para execução no ambiente de produção, podendo apenas ser usado como referência dada a proporção de tamanho. Como haverá cortes em tabelas históricas, algumas consultas podem perder a referência/sentido de movimentação, mas algo que normalmente não influência na maioria dos testes e análises que são realizados em ambiente 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 dados de produção. Deve-se informar no arquivo de parâmetros a data para o corte, conforme consta como exemplo no arquivo fornecido. Quanto mais recente for a data informada, menor ficará o dump e a base de homologação respectivamente. Tabelas de logs serão exportadas vazias e tabelas %BKP% serão ignoradas.

Para o template sugerido acima, as estatísticas das tabelas e índices não são exportados no DMP, portanto, é altamente recomendado que as estatísticas sejam coletadas após o restore do DMP.

08. Oracle Database homologados

As versões descritas na tabela abaixo referem-se as releases mais recentes disponíveis (PSU, RU) na ocasião da homologação da versão do banco de dados para o ERP. Portanto, não é aconselhável a utilização de uma release inferior a informada abaixo em ambiente de produção, e para releases superiores, recomendamos que testes prévios sejam executados em ambiente de homologação, não restringindo sua utilização devido a necessidade de atualizações de segurança e correções que o próprio fornecedor pode eventualmente disponibilizar para garantir o correto funcionamento do banco de dados.

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 patchs de correção disponibilizados pelo fornecedor do banco de dados podem ser encontradas em https://support.oracle.com.

09. Sistemas Operacionais homologados

Recomendamos a utilização de plataforma operacional baseada em Unix de 64-bit, em especial a distribuição oferecida pelo próprio fornecedor do banco de dados (Oracle Linux), pelo fato da próprio fornecedor recomendar e por ser a plataforma predominante nos ambientes que utilizam os ERP TOTVS Varejo Supermercados.