Problemas conhecidos e limitações para Db2 e Db2 Warehouse

O usuário cpadmin não é reconhecido como parte do grupo ALL USERS ao se conectar via terminal

Aplicável a:5.3.1 e versões posteriores

O usuário cpadmin faz parte do grupo ALL USERS no Cloud Pak for Data. No entanto, ao conectar-se ao banco de dados pelo terminal usando db2 connect to bigsql user cpadmin, a conexão é estabelecida, mas o cpadmin não é reconhecido como parte do grupo ALL USERS na sessão.

Solução alternativa

No momento, não há nenhuma solução alternativa disponível.

O fluxo de trabalho de criação do banco de dados não é concluído quando a interface do IBM Software Hub usuário do cliente usa um idioma de navegador diferente do inglês

Aplica-se a: 5.3.0 e posteriores

Quando você usa o cliente IBM Software Hub web com um idioma de navegador diferente do inglês (por exemplo, espanhol), não é possível concluir o fluxo de provisionamento do banco de dados. Na página Credenciais da Cloud Pak for Data interface do usuário, quando você seleciona Criar segredo do cofre, a interface do usuário não exibe os campos suspensos necessários para selecionar um segredo.

Solução alternativa

Defina o navegador e o idioma Cloud Pak for Data da interface do usuário para inglês. O problema ocorre apenas quando você usa um idioma diferente do inglês.

Db2 A implantação restrita falha na atualização no hardware Power ( ppc64le ) e Z ( s390x ) devido à falta do arquivo da biblioteca. libmklidax.so

Aplica-se a : 5.3.0 e posteriores

A implantação Db2 restrita OLTP (implantada via db2aaservice ) falha durante a atualização de 5.1.x ou 5.2.x para 5.3 no hardware Power ( ppc64le ) e Z ( s390x ) devido à falta do arquivo de biblioteca libmklidax.so.

Sintomas

Durante a atualização, o pod de atualização é encerrado com um erro indicando que libmklidax.so não pode ser encontrado em s390x/ppc64le platforms.

O seguinte erro é observado nos registros do pod de atualização:

Error: library file libmklidax.so not found for current architecture (s390x/ppc64le)
Upgrade aborted.

Causa

O arquivo da biblioteca libmklidax.so está faltando nas plataformas Power ( ppc64le ) e Z ( s390x ).

Solução alternativa

Após obter os erros do pod de atualização, continue as etapas restantes da atualização manualmente a partir do db2u pod.

1. Execute no db2u pod.

   # Example (adjust namespace/pod name as appropriate):
   kubectl exec -it -n <namespace> <db2u-pod-name> -- bash

2. Abra um Python shell e execute as etapas restantes da atualização:

   python3
   from instance.db2oltp import Db2OLTPRestrictedInstance
   inst = Db2OLTPRestrictedInstance()
   inst.apply_license()
   inst._cleanup_db2image_directory()
   inst._delete_temporary_db2inst1_files()

   Saia da Python sessão após executar as etapas com sucesso.

3. Continue a atualização no db2u pod:

   # Update databases as part of the upgrade
   db2_update_upgrade --databases
   
   # Run post-upgrade tasks
   db2_update_upgrade --post-upgrade

Db2 e a Db2 Warehouse instância OLTP não inicia após a atualização com SQL0290N erro

Aplica-se a : 5.3.0 e posteriores

Após a atualização de Cloud Pak for Data5.1 ou 5.2 para 5.3, Db2 Warehouse ou as Db2 instâncias OLTP podem não iniciar e exibir SQL0290N erro.

Sintomas

Db2 Os pods reiniciam continuamente e os seguintes erros são observados nos logs dos pods ou ao tentar conectar-se manualmente ao banco de dados:

ERROR: SQL0290N Table space access is not allowed. SQLSTATE=55039

Causa

O espaço de tabela TEMPSPACE1 temporário do sistema está ausente ou corrompido após a atualização devido à falta de tags de contêiner na pasta de backup local.

Solução alternativa

1. Acesse o ambiente Db2 do contêiner:

   oc exec -it <pod_name> -- /bin/bash
   su - db2inst1

2. Elimine o espaço de tabela temporário incorreto:

   db2_all "db2 restart db bludb drop pending tablespaces \(TEMPSPACE1\)"

3. Recrie o espaço temporário do sistema:

   db2 -tf /db2u/scripts/create_sys_temp_tablespace.sql

4. Limpe o diretório local-backup existente:

   rm -rf /mnt/blumeta0/local-backup

5. Crie o backup_tempspace script e salve-o.

   backup_tempspace.sh Script:

   #!/bin/sh
   
   # --- Simple Logging Functions ---
   logger_debug() { echo "[DEBUG] $*"; }
   logger_info()  { echo "[INFO]  $*"; }
   logger_error() { echo "[ERROR] $*"; }
   
   # boolean for either smp or mpp
   is_smp=false  # or true depending on your environment
   
   backup_tempspace() {
       local data_dir="/mnt/bludata0/db2/databases/db2inst1"
       logger_debug "Backing up Tempspace..."
       if [[ $(${GLOBAL_SUDO_CMD} ls ${TEMPTSDIR}/${FORMATION_ID}/db2inst1 | grep NODE | wc -l) -eq 0 ]]; then
           logger_debug "Backing up Tempspace skipped: node directory not found in ${TEMPTSDIR}/${FORMATION_ID}/db2inst1"
           return 0
       fi
       tempspace_dirs=$(rah "ls ${TEMPTSDIR}/${FORMATION_ID}/db2inst1" | grep NODE)
       echo -e "Tempspace directories are:\n${tempspace_dirs}"
   
       data_dirs=$(rah "ls ${data_dir}" | grep NODE)
       [[ "$is_smp" == true ]] && data_dirs="NODE0000"
       if [[ "$data_dirs" == "" ]]; then
           logger_error "Backing up Tempspace skipped: failed to list data node dirs"
           return 0
       fi
       echo -e "Node directories are:\n${data_dirs}"
   
       mkdir -p ${LOCAL_BACKUP_DIR}
       ${GLOBAL_SUDO_CMD} chown ${DB2INSTANCE?}:${INST_GROUP?} ${LOCAL_BACKUP_DIR}
   
       # Backup local temp space from all dashdb nodes -- only need directories and small SQLTAG.NAM files.
       # Preserve directory/file ownership and permission.
       local backup_rc=0
       logger_info "Creating checksums for system tempspace"
       ${GLOBAL_SUDO_CMD} find "${TEMPTSDIR}/${FORMATION_ID}/${DB2INSTANCE?}" -type f -exec md5sum {} \+ |logger_info
       logger_info "Backing up Tempspace"
       ${GLOBAL_SUDO_CMD} rsync -rdgop --numeric-ids --checksum --exclude '*TLB' --exclude '*TDA' --exclude '*TBA' ${TEMPTSDIR}/${FORMATION_ID}/db2inst1/NODE* ${LOCAL_BACKUP_DIR} 2>&1 | logger_debug
       backup_rc=${PIPESTATUS[0]}
       ${GLOBAL_SUDO_CMD} chown -R ${DB2INSTANCE?}:${INST_GROUP?} ${LOCAL_BACKUP_DIR}/NODE*
       echo -e "The dir contents of ${LOCAL_BACKUP_DIR} after backup are:\n$(${GLOBAL_SUDO_CMD} find "${LOCAL_BACKUP_DIR}" -type f -exec ls -l {} +)"
       if [[ $backup_rc -eq 0 ]]; then
           logger_info "Backing up Tempspace succeeded"
       else
           logger_error "Backing up Tempspace failed with rc=$backup_rc"
       fi
       return $backup_rc
   }
   
   # --- Run the Function ---
   backup_tempspace

6. Execute o script de backup do espaço temporário:

   ./backup_tempspace.sh

7. Verifique se o backup foi bem-sucedido e se os diretórios dos nós foram criados:

   ls -la /mnt/blumeta0/local-backup

8. Saia do pod e corrija o ponto Db2StatefulSet de entrada:

   Copie o script db2u_root_entrypoint.sh do ponto de entrada do pod para sua máquina local:

   oc cp <pod_name>:/db2u/db2u_root_entrypoint.sh ./db2u_root_entrypoint.sh

9. Edite o script e comente as linhas 188–208:

   vi db2u_root_entrypoint.sh

10. Crie um configmap usando o script atualizado:

    oc create configmap db2u-root-entrypoint --from-file=db2u_root_entrypoint.sh

11. Encontre o nome do StatefulSet (por exemplo):

    oc get sts | grep db2wh

12. Aplique o patch StatefulSet para montar o script modificado:

    oc patch sts <db2wh-statefulset-name> --type=json -p='[
      {
        "op": "add",
        "path": "/spec/template/spec/volumes/-",
        "value": {
          "name": "db2u-root-entrypoint",
          "configMap": {
            "name": "db2u-root-entrypoint",
            "defaultMode": 509
          }
        }
      },
      {
        "op": "add",
        "path": "/spec/template/spec/containers/0/volumeMounts/-",
        "value": {
          "name": "db2u-root-entrypoint",
          "mountPath": "/db2u/db2u_root_entrypoint.sh",
          "subPath": "db2u_root_entrypoint.sh"
        }
      }
    ]'

    Aguarde até que o Db2 pod reinicie automaticamente.
13. Verifique a atualização e Db2 a funcionalidade:
    1. Depois que o pod estiver pronto, verifique se o ponto de entrada atualizado foi aplicado:

       oc exec -it <pod_name> -- /bin/bash
       cat /db2u/db2u_root_entrypoint.sh

    2. Teste a Db2 conexão e verifique os detalhes do espaço de tabela:

       db2 connect to bludb
       db2 list db directory
       db2 "list tablespaces show detail"

    A Db2 instância deve agora iniciar com sucesso, com TEMPSPACE1 restaurado e o status do serviço aparecendo como RUNNING.

Db2 usuários que não conseguem se autenticar no banco de dados Db2 OLTP por meio d JDBC

Aplica-se a : 5.3.0 e posteriores

Quando os usuários tentam acessar o banco de Db2 dados OLTP por meio de JDBC, eles enfrentam falhas de autenticação, mesmo quando possuem acesso de administrador.

[jcc][t4][2013][11249][4.33.31] Connection authorization failure occurred.  Reason: User ID or Password invalid. ERRORCODE=-4214, SQLSTATE=28000

Solução alternativa

1. Selecione sua implantação executando o seguinte comando:

   oc -n ${PROJECT_CPD_INST_OPERANDS} exec -it ${db2_podname} -- bash

2. Mude para o perfil " db2inst1 ":

   su - db2inst1

3. Desative o valor da variável de ambiente DB2_BEDROCK_ROUTE :

   unset DB2_BEDROCK_ROUTE

4. Pare, Wolverine:

   sudo sv stop wolverine

5. Atualize o plug-in de segurança do db2u e reinicie Db2:

   db2stop force && ipclean -a
   /bin/bash -c "source /db2u/scripts/include/db2_functions.sh && refresh_db2_sec_plugin"
   db2inst1]$ db2start

   Agora você pode se conectar ao seu Db2 banco de dados como cpadmin.

Faltam registros de auditoria com IDs de transação contendo caracteres especiais

Aplica-se a : 5.2.0 e posteriores

Alguns registros de auditoria podem estar faltando no serviço de auditoria IBM Software Hub, pois o serviço de auditoria Db2 em contêiner não consegue processar alguns IDs de transação gerados aleatoriamente que contêm caracteres especiais.

No momento, não há nenhuma solução alternativa disponível para resolver esse problema.

Solução alternativa

Reinicie o site Db2 para corrigir o problema.

DB2OLTP a instância está em um estado de falha

Aplica-se a : 5.0.0 e posterior

Corrigido em : 5.2.1

Na página Instâncias, você vê que a instância db2oltp está em um estado de falha, mas os pods e db2ucluster estão íntegros.

Solução alternativa

Reinicie o site Db2 para corrigir o problema.

Db2 os registros que usam a capacidade total do disco fazem com que o serviço Db2 fique em estado inutilizável

Aplica-se a: 4.8.4 e posteriores

Mesmo quando o cluster está ocioso, o disco Db2 usa toda a capacidade do disco, o que interrompe todas as operações do cluster, como testes funcionais, backup e restauração e upgrade.

No pod db2u ou etcd, a execução de df -k mostra que a utilização do disco dos diretórios archivelogs, activelogs e blumeta0 é de 100% (ou próxima disso).

Solução alternativa

Para colocar a Db2 implantação em um estado ativo ou íntegro, execute as etapas a seguir:

1. Exclua manualmente os registros de arquivamento mais antigos em /mnt/logs/archive/db2inst1/BLUDB/NODE0000/LOGSTREAM0000/C0000000.
2. Exclua manualmente os arquivos .dump.bin em DIAGPATH.
3. Desativar/ativar Db2 db.
4. Limpe os registros de transações seguindo as etapas descritas em Gerenciamento de registros Db2 de transações.

Depois de executar as etapas acima, nenhum diretório está em 100%, o que permite que os pods db2u e etcd entrem em funcionamento.

Não é possível autenticar a conexão com a instância de serviço

Aplica-se a: 4.8.0 e posterior

Ao reinstalar o serviço Db2 em IBM Software Hub, pode ocorrer um problema ao autenticar uma conexão. Isso se deve a uma incompatibilidade da ID do emissor entre os segredos de certificado usados pelo pod db2u.

Você vê um erro no pod zen-database-core que é semelhante à seguinte saída:

" level=error msg="Service instance 'db2oltp-wkc' database ping check failed" func="zen-databases-core/pkg/impl/operator.(Db2Connection).pingDb" file="/go/src/zen-databases-core/pkg/impl/operator/dbConnection.go:72" error="SQLDriverConnect: {08001} [IBM][CLI Driver] 
SQL30081N A communication error has been detected. Communication protocol being used: "SSL". Communication API being used: "SOCKETS". Location where the error was detected: "SOCKETS". 
Communication function detecting the error: "sqlccSSLSocketSetup". Protocol specific error code(s): "414", "", "*". SQLSTATE=08001\n"

Execute os seguintes comandos para determinar se você está tendo o mesmo problema em ambos os certificados:

• oc get secret internal-tls -o jsonpath='{.data.ca\.crt}' | base64 -d | openssl x509 -noout -dates -issuer -subject

  Consulte o exemplo de saída a seguir:

  notBefore=Dec 27 09:31:31 2023 GMT
  notAfter=Dec 26 09:31:31 2025 GMT
  issuer=CN = cs-ca-certificate
  subject=CN = cs-ca-certificate

• oc get secret <dbtype>-internal-tls -o jsonpath='{.data.ca\.crt}' | base64 -d | openssl x509 -noout -dates -issuer -subject

  Consulte o exemplo de saída a seguir:

  notBefore=Aug 22 14:20:46 2022 GMT
  notAfter=Aug 21 14:25:46 2025 GMT
  issuer=CN = zen-ca-certificate
  subject=CN = zen-ca-certificate

Antes de iniciar

O procedimento a seguir usa a variável <dbtype>. Substitua <dbtype> pelo tipo de banco de dados em seu ambiente. As entradas corretas são:

• db2oltp
• db2wh
• db2aaservice

Solução alternativa

1. Atualize o segredo de seu certificado.
   1. Execute o seguinte comando para editar seu certificado:

      oc edit certificate <dbtype>-internal-tls-certificate

   2. Adicione test como uma nova entrada em spec.dnsName. Consulte o exemplo a seguir:

      spec:
        commonName: <dbtype>-internal-tls-certificate
        dnsNames:
          'test'
          '*.zen'
          '*.zen.svc'
          '*.zen.svc.cluster.local'
          zen-ca-cert.zen

   3. Execute o seguinte comando para verificar se um novo certificado foi criado:

      oc get certificaterequest | grep db2

      Consulte o exemplo de saída a seguir:

      <dbtype>-internal-tls-certificate-1 True True zen-tls-issuer system:serviceaccount:ibm-cert-manager:ibm-cert-manager-controller 127m

2. Execute o seguinte comando para verificar suas alterações:

   oc get secret <dbtype>-internal-tls -o jsonpath='{.data.ca\.crt}' | base64 -d | openssl x509 -noout -dates -issuer -subject

3. Reinicie o pod db2u para confirmar que a conexão foi bem-sucedida.

   Se você ainda estiver enfrentando problemas, entre em contato com o suporte do IBM.

A ativação de archiveToDb afeta o desempenho

Aplica-se a: 4.7.0 e mais recente

Ao ativar a criação de log de auditoria e configurar archiveToDb como true, Db2 a auditoria armazena imagens carregadas após a tarefa LOAD ser concluída. A manutenção dessas imagens requer uma grande quantidade de espaço em disco nos caminhos /mnt/bludata0/db2/copy ou /mnt/bludata0/scratch/db2/copy AUDIT.* tabelas exibem logs repetitivos.

Problemas ao criar uma conexão do Db2 com credenciais do IBM Software Hub

Ao criar uma conexão do Db2 no console da web, poderá ocorrer um erro se você marcar a caixa de autenticação do Cloud Pak for Data. Como solução alternativa desse problema, insira suas credenciais do IBM Software Hub nos campos Nome do usuário e Senha e não marque a caixa de autenticação do Cloud Pak for Data.