Minha experiência em administração do IBM DB2 Express-C quando usada com 1C: Enterprise

Eu tive a chance de trabalhar com o IBM DB2. Tanto no 1C quanto no servidor Django usaram esse DBMS de uma só vez, ele processou solicitações OLAP rapidamente (embora fosse necessário configurar manualmente os índices e o servidor da Web, é claro, para que a resposta fosse dentro de 2 segundos). Em 2015, preparei esta pequena instrução para mim, para não esquecer. E, como complemento ao currículo, talvez alguém tenha lido no papel, os anos restantes de trabalho permanecem ociosos. Alguma generalização da minha experiência com o DB2. Corrigi um pouco e sugiro a leitura aqui para ampliar meus horizontes. Talvez alguém esteja interessado. Devo dizer imediatamente que desde então não trabalho com o DB2, tudo foi esquecido, mas ainda me lembro de algo. Críticas e esclarecimentos são bem-vindos, mas como eu não trabalho mais, talvez não seja para mim, mas para outra pessoa, eles serão úteis.

Há muitas instruções na Internet sobre como organizar o trabalho de 1C: Enterprise com o IBM DB2 DBMS. Para iniciantes, isso não é ruim, mas não é suficiente para uso na produção. Anteriormente, recomendei iniciar o IBM DB2 com o curso de treinamento DB101RU da Big Data University. Eu próprio fiz este curso, passei no exame em 2012, acho muito útil. É uma pena que o recurso tenha deixado de existir. Na nova plataforma, não encontrei nada parecido. Na produção, o IBM DB2 requer configuração e manutenção adicionais, das quais as mais necessárias serão brevemente descritas aqui. Estamos considerando uma edição gratuita do IBM DB2 Express-C para Windows versões 10.1fp2 e 10.5fp4 (a primeira é suportada pela 1C para trabalhar no modo de teste, a segunda é oficialmente suportada, é uma pena que as versões mais recentes sejam pagas apenas). Faz sentido instalar o 10.5 de 64 bits onde há altos requisitos de RAM (tamanho do buffer para velocidade) ou tamanho de gravação (EXTENDED_ROW_SZ = ENABLE) ao usar tipos compostos que contêm sequências longas de tamanho fixo.

A primeira coisa a ser feita é mudar o uso de diários arquivados para fazer backups sem interromper a operação do 1C: Enterprise e poder restaurar o banco de dados a qualquer momento (a restauração para 10.1fp2 tem suas próprias peculiaridades devido a uma correção não corrigida). bug na versão gratuita - é necessária a movimentação manual dos arquivos de log). Diferentemente do MS SQL, o arquivamento de logs não é realizado em determinados momentos pré-determinados (no MS SQL não é forte, talvez exista outra coisa) e, quando o arquivo de log atinge um determinado tamanho predeterminado, não é necessário fazer backup do log antes da operação de restauração, basta desativar a base. O arquivamento de logs em duas direções é facilmente configurado, um dos quais em uma unidade de rede, por exemplo. Além disso, no caso de interrupções curtas na rede, o aumento do espaço ocupado por periódicos ativos não é significativo. Para logs ativos, você deve fornecer espaço livre suficiente para poder restaurar o banco de dados a qualquer momento. Se, durante o trabalho do programador com a base 1C, forem necessários retornos frequentes em vários momentos próximos, um backup é suficiente para restaurar, a escolha dos arquivos de log para recuperação é muito simples. Certifique-se de ativar o banco de dados no início da instância, caso contrário, obteremos um grande número de pequenos arquivos de log com ativação implícita. Obviamente, você deve definir o tempo de armazenamento de backup (parece-me que precisa armazenar logs por pelo menos dois meses) e configurar a exclusão automática. A base e os backups (logs) devem estar em discos físicos diferentes; em casos extremos, você pode fazer backups em outro computador na rede local.

A ativação da base também é necessária por outro motivo. Para operação normal, você deve instalar o Windows online e offline. Neste momento, a base deve estar ativa. Periodicamente, você deve examinar o histórico do banco de dados para descobrir quais ações foram executadas durante a janela offline. A janela de manutenção offline provavelmente deve ser definida entre 22:00 - 0:00, pois não há tarefas de manutenção 1C pesadas no momento. Talvez para pequenas bases uma janela com duração de 1 hora seja suficiente.

Periodicamente, é necessário executar uma verificação da necessidade de reorganização no modo manual e, após analisar o estado de tabelas e índices, executar uma reorganização de objetos individuais. A reorganização manual de vários milhares de tabelas e índices pode levar muito tempo. A análise é facilmente acelerada por um filtro simples (em .js, por exemplo) usando regexp.

O AUTOCONFIGURE, é claro, deve ser feito periodicamente, corrigindo manualmente as configurações individuais, por exemplo, definindo seu próprio tamanho de arquivo de log.

Após um dia, é possível e com mais freqüência executar backup online do banco de dados (não requer um desligamento e a presença de um DBA), a frequência depende do tempo de recuperação necessário, que por sua vez depende do número de arquivos de log arquivados após o último backup, ou seja, a carga no banco de dados. Para bancos de dados médios, grandes e com muita carga, faz sentido usar vários tipos de backups incrementais para reduzir o espaço ocupado por backups e reduzir o tempo de recuperação dos backups. Após cada backup e antes da restauração, verifique a integridade dos backups. O tempo de armazenamento de backup fica a critério do DBA, mas não menos que o tempo de armazenamento dos logs.

Pelo menos uma vez por mês, execute verificações de integridade do banco de dados offline e online (no modo offline, o trabalho com o banco de dados é suspenso por vários minutos) e, se necessário, execute reparos (o mais importante para “servidores” sem um no-break). Execute o backup offline do banco de dados mensalmente, apenas os backups offline serão armazenados por um longo período de tempo, porque quando você altera a versão do DB2, não é possível implementar o backup online. Se “1C: Enterprise” não permitir nem mesmo uma tradução de curto prazo do banco de dados offline para verificação ou backup, é possível executar as ações indicadas em uma cópia expandida do banco de dados. O banco de dados é restaurado do backup para outro local sem problemas, por exemplo, para outro disco em outro servidor. Deve-se observar que os backups e os logs de archive podem ser compactados usando as ferramentas do DB2 (nesse caso, a ferramenta de verificação de backup permanece funcional e a ferramenta de verificação do log de archive não funciona).

Antes de verificar offline o banco de dados e o backup offline, você deve definir o banco de dados e as tarefas agendadas para serem bloqueadas. Em caso de emergência, você pode fazer a estabilização do banco de dados, mas como o usuário sob o qual o servidor 1C: Enterprise está em execução está incluído no grupo SYSADM_GROUP, isso não cancelará a capacidade de conectar o 1C ao banco de dados na hora errada e, como resultado, exigirá um segundo lançamento de emprego.

Se o banco de dados não estiver funcionando rapidamente, após a atualização das estatísticas, você deverá obter os planos de consulta mais severos, experimentar os índices 1C em uma cópia do banco de dados, monitorar as alterações no plano de consulta no IBM Data Studio (neste caso, justificar o uso de eclipse, em outros, basta fazer isso com a interface de comando linhas) ou use as recomendações do DB2 Design Advisor e, se necessário, crie índices manualmente fora de 1C. Ao mesmo tempo, comece a coletar informações detalhadas de desempenho usando as ferramentas do DB2 (mais de uma dúzia de scripts SQL) e analise a carga com o monitor do sistema. Para reduzir a carga no sistema de disco, o banco de dados deve ser instalado em um disco de alta velocidade separado, de tamanho suficiente (a menos, é claro, que esteja disponível uma matriz de disco do servidor RAID 10 normal), é possível colocar logs ativos no SSD junto com o sistema operacional. Provavelmente, você também precisará alterar a localização dos tempos do servidor 1C: Enterprise. Se a compra de um disco for planejada apenas, para pequenas organizações, é permitido usar temporariamente um único disco físico para o banco de dados.

Revise o db2diag.log diariamente quanto a erros e os resultados das ações com o banco de dados. Arquive ao atingir um tamanho de várias dezenas de megabytes. O Far Manager pode ser um meio conveniente de visualizar o log (presume-se que haja poucos erros no banco de dados); também ajudará se você precisar mover manualmente os logs de arquivamento para restaurar em um determinado momento.

Uma das vantagens competitivas do IBM DB2, como me parece, pode ser considerada que, nos casos em que o MS SQL Server requer um servidor 1C: Enterprise de 64 bits para operação normal, o IBM DB2 pode funcionar com 32 bits.

UPD: Talvez ele não tenha cuidado ao verificar as versões do DB2 suportadas pelo 1C: Enterprise antes de publicar. No original deste texto de 2015, cerca de 10.5fp4 dizia: quando usado com 1C: Enterprise, "ainda não foram detectados erros". Ou seja, no momento, do novo Express-C, apenas 10.1 é possível (com seus recursos e limitações). Dos pagos de hoje, apenas 11,1 são oficialmente suportados. É possível que alguém tenha Developer-C suficiente com um tamanho de banco de dados de até 100 GB. Não alterei o link da documentação - é fácil mudar para lá.

UPD: Reli tudo, provavelmente, deve ficar claro para alguém que estava lidando com o DB2, mas talvez seja necessário algum esclarecimento para quem é novo no trabalho com este DBMS, por exemplo

deve ver o histórico da base

deve trazer aqui também

executar verificações de integridade do banco de dados offline e online

aqui , aqui e aqui , mas neste último caso já pode ser necessário
E aqui está isso

A análise é facilmente acelerada por um filtro simples (em .js, por exemplo) usando regexp.

pode causar dificuldade, não tenho certeza se alguém faz isso, depende da automação, o máximo é limitado a esta consulta: db2 "SELECT substr(TABSCHEMA,1,20), substr(TABNAME,1,20) FROM SYSIBMADM.ADMINTABINFO WHERE REORG_PENDING = 'Y'" No entantoEm seguida, analise a descrição e inicie a reorganização dos objetos selecionados ou aumente a janela de manutenção offline. Após várias iterações, fica claro quais objetos não fazem reorganização.
Espero não ter confundido nada, levantei o arquivo de scripts de cinco anos, provavelmente receita. Não sei se este suplemento será útil para alguém.

Links para recursos / arquivos mencionados

As informações básicas, exceto as que foram obtidas em cursos que não existem mais, podem ser encontradas aqui (o link era diferente).

Muito já foi esquecido, mas um link para o documento pdf “Melhores práticas. Foi encontrado o ajuste e o monitoramento do desempenho do sistema de banco de dados ” (o link agora é novo, o wiki antigo deixa de existir a partir de 01-01 2020, mas aqui tudo não é tão estável até agora).