folow's questions

No Db2 v11.5 no Linux, tenho vários bancos de dados com centenas de tabelas no esquema MYSCHEMA.

EXIGÊNCIA

a) Preciso atribuir permissão SELECT a todas as tabelas no esquema MYSCHEMA, exceto para uma tabela específica MYSCHEMA.NO_ACCESS à qual os usuários não devem ter acesso.

b) Se uma nova tabela for criada no esquema MYSCHEMA, preciso adicionar manualmente GRANT SELECT na nova tabela. Gostaria de evitar qualquer tipo de administração de segurança quando uma nova tabela for criada.

c) Quando temos auditoria de uma empresa de auditoria, precisa ser simples fornecer informações sobre qual acesso algum usuário tem e qual não tem. Ter centenas de concessões é difícil de mostrar que os usuários realmente têm apenas o acesso de que precisam.

SOLUÇÃO ATUAL

Atualmente, concedemos seleção em todas as tabelas, exceto na tabela MYCHEMA.NO_ACCESS, assim:

GRANT SELECT ON TABLE MYSCHEMA.TAB1 TO GROUP GROUP1
GRANT SELECT ON TABLE MYSCHEMA.TAB2 TO GROUP GROUP1
...
GRANT SELECT ON TABLE MYSCHEMA.TAB5000 TO GROUP GROUP1 
(make sure there is no MYSCHEMA.NO_ACCESS on grant list)

A abordagem acima tem limitações: sempre que uma nova tabela é criada no esquema MYSCHEMA, preciso definir GRANT SELECT na nova tabela.

Além disso, na auditoria, devido às inúmeras permissões, é difícil provar que os usuários realmente têm apenas as permissões que deveriam ter.

NOVA ABORDAGEM, SE POSSÍVEL

O Db2 v11.5 tem o privilégio GRANT SELECTIN no esquema.

Existe algo parecido como:

GRANT SELECTIN ON SCHEMA MYSCHEMA TO GROUP GRUP1
DENY SELECT ON TABLE MYSCHEMA.NO_ACCESS TO GROUP GROUP1

Onde negar tem maior importância que conceder.

Ou existe alguma outra abordagem?

No Db2 v11.5 no Linux, eu gostaria de criar uma variável e então usar essa variável na instrução SELECT. Eu não quero criar um procedimento ou função no banco de dados, eu só quero fazer isso em SQL dinâmico do db2cmd ou alguma ferramenta de banco de dados.

Exemplo simplificado:

BEGIN
     DECLARE name VARCHAR(10);
     SET name = 'John';
     SELECT * FROM SYSIBM.SYSDUMMY1 WHERE name = :name;
END;

EDIT: Por que não quero criar um procedimento/função armazenado? Eu realizo auditorias a cada semestre para privilégios/autorizações de banco de dados em vários bancos de dados e não tenho privilégio de criar procedimento em alguns dos bancos de dados, devido a configurações de segurança rígidas. Na maioria dos casos, só tenho acesso às tabelas do catálogo do sistema, o que é perfeitamente suficiente para criar auditoria. Eu listo os usuários do banco de dados e, em seguida, para usuários "suspeitos", realizo verificações completas de permissão/autoridade executando vários SQL-s do catálogo do sistema. Até agora, para cada usuário, usei o editor de texto e usei localizar/substituir, o que é uma solução OK, mas a variável é uma solução melhor. Obrigado!

No Db2 v11.5 no Linux, se eu executar um comando para verificar se a instância do banco de dados está ativa e em execução:

ps -e -o command | grep db2sysc

a saída é:

db2sysc 0

O que significa o número 0? Só estou perguntando porque, talvez isso possa ser útil para usar em scripts bash.

Em "SQL Server 2019" no Windows 2019:

1. Abri o Microsoft SQL Server Management Studio.
2. Entrei no servidor de banco de dados.
3. Cliquei em "SQL Server Agent" e cliquei em "Logs de erros" e cliquei duas vezes em "Atual".
4. O programa Log File Viewer é exibido. No site certo vejo muitos erros, mas erros antigos não são mais importantes. Como limpar/excluir esses erros para remover a desordem?

Em nossos computadores o Db2 v11.5.8.0 Linux/x86-64 está instalado. Gostaria de instalar novas correções como atualizações regulares, especialmente para implantar correções de segurança.

Algumas semanas atrás, o novo fixpack 11.5.9.0 foi lançado. Mas agora vejo que o Cumulative Special Build também está listado na página Download do fixpack do Db2 . Analisando detalhadamente a página do CSB , há informações: "Os CSB são cumulativos, cada CSB contém todas as correções entregues no CSB anterior." Se bem entendi, o CSB não deve ser instalado sobre a v11.5.9.0, mas sobre o CSB anterior (se estiver instalado no servidor Db2). Isso está correto?

Qual é o propósito do CSB em primeiro lugar? Para conter apenas correções de segurança e falhas sem novos recursos? Qual é o lançamento do Db2 após a aplicação do CSB?

Obrigado

No Red Hat 8.8, tenho o Db2 v11.5.8.0 instalado e o banco de dados está funcionando bem.

1. Hoje baixei a v11.5.9.0 e descompactei o arquivo tar.
2. Eu executei db2prereqchecke todos os pré-requisitos foram atendidos. Bem-sucedido.
3. Instalado o Db2 usando db2_installo comando. Bem-sucedido.
4. Instância atualizada com db2iupdtcomando. Bem-sucedido.
5. Então tentei iniciar uma instância com db2startum erro: db2start: erro ao carregar bibliotecas compartilhadas: libaws-cpp-sdk-transfer.so: não é possível abrir o arquivo de objeto compartilhado: esse arquivo ou diretório não existe

Parece que alguma biblioteca está faltando. Tento pesquisar na web, mas não consigo encontrar como instalar esta biblioteca. Qualquer ideia?

IBM DB2

C:\>db2 create table public.tab1 (id int not null, col1 int not null)
C:\>db2  create unique index tab1_ix on public.tab1 (id) include (col1)
C:\>db2  alter table public.tab1 add primary key (id)
SQL0598W  Existing index "IN1139.TAB1_IX" is used as the index for the primary
key or a unique key.  SQLSTATE=01550

É apenas uma informação que o índice existente foi usado.

POSTGRESQL

db=# create table public.tab1 (id int not null, col1 int not null);
db=# create unique index tab1_ix on public.tab1 (id) include (col1);
db=# alter table public.tab1 add primary key (id);

db=# \d public.tab1;
                Table "public.tab1"
 Column |  Type   | Collation | Nullable | Default
--------+---------+-----------+----------+---------
 id     | integer |           | not null |
 col1   | integer |           | not null |
Indexes:
    "tab1_pkey" PRIMARY KEY, btree (id)
    "tab1_ix" UNIQUE, btree (id) INCLUDE (col1)

PostgreSQL criou índice adicional para chave primária.

Por que isso é importante? a) Em muitos casos explicados, vi que se a chave primária for criada, o banco de dados usa o índice de chave primária para consultas. Mas se eu descartar a chave primária, o índice exclusivo e as consultas serão executadas muito mais rapidamente (por causa do Index Only Scan). b) Espaço adicional em disco é usado para índice de chave primária adicional. c) Cada atualização/inserção/exclusão e dois índices devem ser atualizados em vez de um.

Questões:

1. Existe uma maneira de forçar o banco de dados PostgreSQL a usar o índice existente, quando a chave primária é adicionada à tabela com o índice exclusivo existente (como no IBM Db2)?
2. Existe uma maneira de forçar o PostgreSQL a usar um índice exclusivo (e, portanto, usar o Index Only Scan) em vez do índice de chave primária (e usando apenas o Index Scan) quando as consultas são executadas?

No Db2 v11.5.8.0 no Linux x86_64, tenho várias instâncias e bancos de dados.

Gostaria de saber se existe alguma configuração pendente em:

• variáveis ​​db2set
• dbm cfg
• nível dg cfg?

Questões:

1. Existe uma maneira de descobrir qual comando db2set foi alterado desde a reinicialização da instância e ainda não foi aplicado até a próxima reinicialização da instância? Ou pelo menos para obter informações verdadeiras ou falsas de que pelo menos uma das configurações está em estado pendente.
2. Existe alguma maneira mais simples de executar "get db/dbm cfg show detail" e comparar duas colunas exibidas para alterações pendentes? O "db cfg" é particularmente irritante, porque tenho que me conectar ao banco de dados para obter o resultado. Existe alguma maneira mais simples de obter informações? O dbm cfg ou o db cfg foi alterado e algumas configurações estão pendentes.

Preciso de uma solução simples para escrever um script bash do Linux para verificar as diferenças automaticamente e me retornar um aviso se houver alguma configuração pendente.

No Linux x86_64, instalei o Db2 v11.5.8.0 e estou no processo de atualização de instâncias e bancos de dados de v11.1 para v11.5.

Temos várias máquinas Linux e elas têm pelo menos duas versões do Db2 instaladas: v11.1 e v11.5 e cada versão do banco de dados possui várias instâncias e cada instância vários bancos de dados.

Eu posso checar:

• Versões do Db2 instaladas no Linux com:db2ls
• qual versão do Db2 é aplicada a uma instância específica:db2greg -dump | grep ^I

Mas como verificar em particular a instância do Db2 quais bancos de dados já foram atualizados com o banco de dados de atualização do db2 <db_name>

No banco de dados Db2 v11.5.8.0 Linux x86_64 a cada poucos meses, algum aplicativo abre muitas conexões e as libera rapidamente, como em 10 minutos.

Presumo que seja um aplicativo cliente gordo do Windows, porque, para aplicativos WAS, o número de conexões é restrito no nível do servidor de aplicativos.

Verificando a marca d'água alta, obtenho:

db2 get snapshot for dbm | grep "High water mark for agents registered"

Marca d'água alta para agentes registrados = 4296

Qual é a melhor maneira de limitar o número de conexões por endereço IP (desconhecido)? Por exemplo, desejo restringir o número máximo de conexões de determinado endereço IP para 100 conexões. Tenha em mente que não sei o endereço IP, pode ser qualquer um.

No Db2/Linux_x86_64 em db2diag.log, vejo constantemente um aviso sobre o parâmetro CATALOGCACHE_SZ ser muito pequeno, como:

2022-12-02-14.40.53.536711+060 E5979903E769          LEVEL: Warning
PID     : 4508                 TID : 140629241751296 PROC : db2sysc 0
INSTANCE: prod1                NODE : 000            DB   : MYDB
APPHDL  : 0-33700              APPID: 10.12.3.4.13429.221202134054
AUTHID  : USER1                HOSTNAME: myserver.com
EDUID   : 4958                 EDUNAME: db2agent (DB2P) 0
FUNCTION: DB2 UDB, catcache support, sqlrlc_check_available_memory, probe:100
MESSAGE : ADM4000W  A catalog cache overflow condition has occurred.  There is
          no error but this indicates that the catalog cache has exceeded the
          configured maximum size.  If this condition persists, you may want to
          adjust the CATALOGCACHE_SZ DB configuration parameter.

Eu verifiquei a recomendação:

 db2 autoconfigure apply none | grep CATALOGCACHE_SZ
 Catalog cache size (4KB)              (CATALOGCACHE_SZ) = 1093     1093

e vejo ambos: "valor atual" e "recomendação" têm o mesmo valor 1093.

Existe algum outro método para determinar o tamanho do cache do Catálogo? Ou qualquer método para fazer o aumento como dobrá-lo e ver se o problema reaparece.

Uma versão fraca do Db2 v11.5.8.0 foi lançada. Há uma lista de problemas que foram resolvidos nesta versão.

Mas, como sempre, cada nova versão tem alguns novos bugs. Existe alguma lista de novos problemas descobertos desde a última versão v11.5.8.0?

Estamos planejando atualizar para a v11.5.8.0 e gostaria de verificar todos os problemas conhecidos para saber se eles nos afetam.

No Db2 v11.5.7 no Linux eu tenho uma tabela simples:

create table admin.patient_data (
patientid int not null primary key,
patient_name varchar(10),
illness varchar(15),
doctor_name varchar(10)
);

insert into admin.patient_data values (1, 'Alice', 'illness A', 'DOCTOR1');
insert into admin.patient_data values (2, 'Bob', 'illness B', 'DOCTOR2');
select * from admin.patient_data;

Resultado:

PATIENTID   PATIENT_NAME ILLNESS         DOCTOR_NAME
----------- ------------ --------------- ----------
          1 Alice        illness A       DOCTOR1
          2 Bob          illness B       DOCTOR2

A coluna DOENÇA são dados confidenciais. Gostaria de permitir que esta coluna seja exibida apenas se a coluna DOCTOR_NAME corresponder ao usuário logado do Db2.

create mask admin.patient_data on admin.patient_data
   for column illness return
   case when doctor_name = USER then illness else 'Masked data' end
   enable;
alter table admin.patient_data activate column access control;

Agora o usuário DOCTOR1 se conecta ao banco de dados e verifica os dados com:

select * from admin.patient_data

é devolvido:

PATIENTID   PATIENT_NAME ILLNESS         DOCTOR_NAME
----------- ------------ --------------- -----------
          1 Alice        illness A       DOCTOR1
          2 Bob          Masked data     DOCTOR2

Espera-se que a linha PATIENTID=2 coluna ILLNESS seja mascarada.

Mas o médico é educado, então ele conhece todas as doenças e agora tem como alvo a "doença B"

db2 "select * from admin.patient_data where illness = 'illness B'"

e fica:

PATIENTID   PATIENT_NAME ILLNESS         DOCTOR_NAME
----------- ------------ --------------- -----------
          2 Bob          Masked data     DOCTOR2

O campo ILLNESS ainda está marcado como esperado, mas agora por causa de onde o DOCTOR1 condicional sabe que o paciente Bob tem "doença B".

Eu esperava que os usuários finais pudessem filtrar por valores que são retornados com where condition. Ou seja: "doença A" e "dados marcados".

Existe alguma solução simples para evitar isso? Espero não ter nenhum registro retornado para a última instrução select.

Tenho vários servidores Linux e neles pode haver uma ou mais instâncias Db2. As instâncias do Db2 podem ser de diferentes versões do Db2.

Para auditoria de segurança, preciso escrever um script bash simples para verificar algumas configurações de "dbm cfg" em todos os servidores Linux. Eu tenho alguma ferramenta que me permite conectar a servidores Linux com acesso root e então posso executar qualquer comando bash no servidor Linux remoto.

PERGUNTA: O que estou tendo um problema é, como obter a lista de instâncias do Db2 no servidor Linux com usuário root sem saber os proprietários das instâncias do Db2 ou os nomes das instâncias do Db2?

Quando recebo os proprietários, posso "sudo" ou "su" para esse usuário Linux do proprietário da instância do Db2 e executar o comando "db2 get dbm cfg".

No Linux/x86-64 tenho o Db2 v11.1 instalado. Quando tentei instalar o Db2 v11.5 junto com a instalação existente do Db2, recebi o erro " DBI1004W /usr/lib/libdb2.so detectado ".

Eu verifiquei e vejo links simbólicos em caminhos:

ls -l /usr/lib | grep "/opt/ibm/db2/"
ls -l /usr/include | grep "/opt/ibm/db2"

Na descrição do erro há sugestão para excluir esses links. Depois de usar db2rmlno comando, esses links são removidos.

A instalação do Db2 v11.5 agora foi bem-sucedida. Mas eu verifiquei e esses links simbólicos não são recriados. De acordo com https://www.ibm.com/docs/en/db2/11.5?topic=servers-multiple-db2-copies-one-system-linux-unix , isso funciona conforme o esperado. Info: " Os links não devem ser criados quando várias cópias do Db2 devem coexistir. "

É tão bom que esses links simbólicos não existem se várias cópias do Db2 resistirem no mesmo Linux.

Minha pergunta é, qual é o propósito desses links simbólicos e posso esperar alguns problemas por não tê-los mais?

Até agora, sempre "atualizei" o banco de dados usando instalação limpa (nova instalação do Linux, etc) dentro da máquina virtual.

Mas agora eu tenho a necessidade de atualizar o Db2/Linux do Db2 v11.1 para o Db2 v11.5 instalado na máquina física (não na máquina virtual).

A instância existente do Db2 v11.1 está instalada na máquina.

1. Durante a instalação, recebi um erro sobre bibliotecas incompatíveis, então fui forçado a usar o comando db2rmln para remover links do Linux para bibliotecas.
2. Após a instalação foi necessário atualizar (não atualizar!) instância e eu fiz isso com: ./db2iupgrade
3. Em seguida, migre o banco de dados.

Eu só estou querendo saber em caso de algum azar. É possível fazer downgrade da instância e do banco de dados de V11.5 para V11.1? O downgrade é suportado entre duas versões do Db2?

1. Instalei o Db2 v11.5.7.0 no Linux/x86_64 dentro do meu PC virtual usando o VirtualBox no Windows 10.
2. Eu criei banco de dados com o nome TEST1
3. Eu me conectei ao banco de dados usando o soquete Unix: db2 connect to TEST1 e a conexão foi concluída com sucesso.
4. Verifique a configuração DB2COMM: db2set DB2COMM e a saída é DB2COMM=TCPIP
5. Apenas para garantir que a conexão TCP/IP funcione com o Db2, criei o nó local e o banco de dados do catálogo:

db2 catalog tcpip node loctcp remote localhost server 50000
db2 catalog database test1 as tcptest1 at node loctcp
db2 terminate
db2 connect to tcptest1 user db2inst1 using <password>

e a conexão foi concluída com sucesso.

6. Agora, no meu PC VirtualBox Windows 10 host, defino o encaminhamento de porta Host Port: 60127 e Guest Port: 50000.
7. No meu PC com Windows: netstat -an -p tcp | find ":60127" posso ver que a conexão está no estado LISTENING.
8. No meu PC com Windows:

db2 catalog tcpip node remtcp remote localhost server 60127
db2 catalog database test1 as tcptest1 at node remtcp
db2 terminate

9. No meu PC com Windows, conecte-se ao banco de dados

db2 connect to tcptest1 user db2inst1 using <password>

PROBLEMA: Parece que a conexão trava. Após alguns minutos, recebo erro no cliente Db2:

SQL30081N Foi detectado um erro de comunicação. Protocolo de comunicação utilizado: "TCP/IP". API de comunicação em uso: "SOCKETS". Local onde o erro foi detectado: "127.0.0.1". Função de comunicação detectando o erro: "recv". Código(s) de erro específico do protocolo: "10054", "*", "0". SQLSTATE=08001

10. Tentando entender o problema. No servidor Linux: a) Verifiquei o firewall e está desabilitado. b) IPv6 está desabilitado c) Db2 está escutando na porta 50000 usando IPv4
11. Wireshark no Windows ouvindo a porta 60127. a) A conexão TCP é estabelecida b) A conexão Db2 DRDA nunca aparece.
12. Tcpdump no servidor Linux capturando tráfego de rede de 50.000 portas. a) A conexão TCP é estabelecida b) A conexão Db2 DRDA nunca aparece.

Parece que algo está errado dentro da máquina virtual Linux, mas as etapas 4 e 5 devem estar bem com a conexão TCP/IP do Db2.

Alguma idéia do que mais para verificar por que a conexão do cliente Db2 não funciona?

PS Eu tenho exatamente a mesma instalação com Db2 v11.1 e conexão Db2 do meu PC está funcionando bem.

1. Instalei o Db2 do fixpack v11.5.7.0 usando o db2_installcomando.
2. Fiz download do arquivo "IBM Db2 Advanced Edition - VPC Option V11.5.6 - Activation (CC9WHML)" do IBM Passport Advantage.
3. Eu apliquei licença com:db2licm -a <license_file>
4. Eu verifiquei a licença aplicada: db2licm -le a saída é:

Product name:                     "DB2 Community Edition"
License type:                     "Community"
Expiry date:                      "Permanent"
Product identifier:               "db2dec"
Version information:              "11.5"
Max amount of memory (GB):        "16"
Max number of cores:              "4"
Features:
IBM DB2 Performance Management Offering:              "Not licensed"

Product name:                     "DB2 Advanced Edition"
License type:                     "Virtual Processor Core"
Expiry date:                      "Permanent"
Product identifier:               "db2adv"
Version information:              "11.5"
Enforcement policy:               "Hard Stop"
Features:
IBM DB2 Performance Management Offering:              "Not licensed"

Eu não tinha visto esse tipo de exibição antes. Parece que duas licenças são aplicadas na edição "Community" e "Advance".

Perguntas:

a) Tudo bem que duas licenças sejam exibidas? Qual deles é válido, ambos?

b) Na seção de edição "Avançada" a que se refere a "Política de aplicação" de "Hard Stop"? Até agora eu sempre vi apenas "Soft Stop". Como eu vejo, a edição "Advance" não tem limitações de núcleos de CPU, então o que significa "Hard Stop" nesta licença?