Perguntas[docker](dba)

Eu tenho uma instância do SQL Server 2022 em execução em um contêiner do Docker no Linux. Meu entendimento é que os contêineres do Docker podem simplesmente expandir seu uso de disco para preencher todo o espaço de volume disponível. O espaço no volume é de cerca de 10 GB:

$ sudo df -h /var/lib/docker/
Filesystem      Size  Used Avail Use% Mounted on
/dev/xvda1       47G   34G   10G  78% /

No entanto, quando entro no SSMS e vejo as propriedades do banco de dados, ele diz "Tamanho do banco de dados 80,00 MB, espaço disponível 1,78 MB". Por que diz que apenas 1,78 MB está disponível? Meu banco de dados ainda poderá usar todos esses 10 GB na partição?

Eu tenho um MacBook com um chip M1, então (sobre) a única opção para eu executar o SQL Server é executá-lo como um contêiner do Docker . Isso funciona bem para SQL padrão, mas nosso aplicativo usa alguns recursos CLR como COMPRESS; quando eu tento usar isso, ele me diz

Msg 50000, Level 16, State 1, Line 45 Common Language Runtime(CLR) não está habilitado nesta instância.

Ativar não funciona:

EXEC sp_configure 'clr enabled', 1;  
RECONFIGURE;  
GO

dá

Msg 15392, Level 16, State 1, Procedure sp_configure, Line 166
A opção especificada 'clr enabled' não é suportada por esta edição do SQL Server e não pode ser alterada usando sp_configure.

Encontrei esta postagem do Stack Overflow, mas é sobre alguém usando uma biblioteca .NET personalizada; Estou procurando a funcionalidade 'padrão' disponível no SQL Server para Windows.

Estou executando um cluster docker CockroachDB de três nós (Debian OS) e recentemente atualizei o cluster da versão v21.1 para a versão v21.2 seguindo o procedimento descrito na documentação usando a opção

SET CLUSTER SETTING cluster.preserve_downgrade_option = '21.1';

Em seguida, reiniciei o contêiner de cada nó, um de cada vez, e quando não surgiram problemas, executei

RESET CLUSTER SETTING cluster.preserve_downgrade_option;

Agora, todos os três nós estão executando a mesma versão e a opção cluster.preserve_downgrade_option está definida como uma string vazia. No entanto, mesmo depois de horas decorridas desde então, quando estou tentando criar uma tabela que possui um recurso incluído na versão 21.2

create table randdb.public.randtable
(
    name_surname varchar(30),
    update_tim TIMESTAMPTZ DEFAULT now() ON UPDATE now(),
    PRIMARY KEY (name_surname)
)

recebo a mensagem de erro

SQL Error [0A000]: ERROR: version 21.1-1152 must be finalized to use ON UPDATE

Fora isso, o cluster parece estar totalmente funcional. Alguma ideia do que deu errado?

Gostaria de saber como otimizar o uso de RAM do meu banco de dados PostgreSQL implantado no Kubernetes.

Particularmente estou interessado em configurar os valores shared_bufferse effective_cache_size.

Normalmente, a recomendação declarada por várias fontes é usar:

• Se você tiver um sistema com 1 GB ou mais de RAM, um valor inicial razoável para shared_buffers é 1/4 da memória em seu sistema. Se você tiver menos RAM, terá que considerar com mais cuidado a quantidade de RAM que o sistema operacional está ocupando; perto de 15% é mais típico lá. Existem algumas cargas de trabalho em que configurações ainda maiores para shared_buffers são eficazes, mas, como o PostgreSQL também depende do cache do sistema operacional, é improvável que você ache que usar mais de 40% de RAM funcione melhor do que uma quantidade menor. ( site PostgreSQL )

• O valor deve ser definido de 15% a 25% da RAM total da máquina ( site EDB )

• Não mais que 50% da RAM disponível ( ajuste EDB PostgreSQL )

Como os contêineres usam muito menos RAM em segundo plano, qual seria uma boa recomendação para definir o valor shared_buffers?

No momento, o valor está definido para 25% (1 GB do limite total de contêiner de 4 GB) e noto que ele é preenchido rapidamente.

então eu sou realmente novo no docker e posso estar usando-o incorretamente aqui, mas torna a criação de um banco de dados mysql REALMENTE fácil, então é por isso que eu queria tentar em vez de instalar uma instância na minha máquina remota (na LAN).

Então eu quero acessar o banco de dados MariaDB de uma máquina diferente/remota porém em todos os lugares que eu olho parece estar fornecendo informações desatualizadas, ( mesmo a documentação oficial do mariaDB ) não fornece as informações corretas, eu tentei o que eles dizem e acredito que é apenas para acessar o contêiner da mesma máquina em que ele está sendo executado. Qualquer artigo ou * resposta de troca que vejo diz para você entrar no terminal bash do contêiner, em seguida, mude /etc/msql/my.cnfpara ter bind_address=0.0.0.0e isso está desatualizado, pois não está bind_addressmais no my.cnf em que está localizado /etc/mysql/mariadb.conf.d/50-server.cnfe há uma linha que indica

# Instead of skip-networking the default is now to listen only on
# localhost which is more compatible and is not less secure.

Eu também não consegui encontrar nenhuma referência a uma variável de ambiente que eu pudesse definir para me permitir acessá-la remotamente, então eu realmente não sei mais onde procurar sobre como alterar a configuração para me permitir acessar o banco de dados de minha rede.

E sim, eu tenho uma configuração de usuário para permitir conexões remotas. Toda e qualquer ajuda é apreciada.

Em uma nota lateral, parece ser muito difícil mudar isso, então isso me faz acreditar que isso é uma prática ruim ou a ser evitada e isso me faz acreditar que estou entendendo o docker errado, pensei que o docker deveria permitir que você executasse pequenas instâncias de software que não interagem entre si, portanto, se uma instância for prejudicada, o resto não, mas por que eles estão tão empenhados em não permitir uma conexão remota?

Eu tenho um banco de dados PostgreSQL em um contêiner docker com 50 MB de dados:

SELECT pg_size_pretty(pg_database_size('db_1'));
 pg_size_pretty 
------------------
 50 MB

mas o tamanho do volume é de 8,5 GB:

sudo du -hd1 db_volume
8.5G    db_volume

e meu docker-compose é assim:

version: '3.8'

services:
  r3-db:
    image: postgres:12
    restart: always
    ports:
      - 5432:5432
    environment:
      POSTGRES_PASSWORD: PASSWORD
      POSTGRES_USER: USER
      POSTGRES_DB: db_1
    volumes:
      - ./db_volume/:/var/lib/postgresql/data:Z

Eu tento usar VACUUM(FULL, ANALYZE, VERBOSE)em qualquer tabela mas o tamanho do arquivo do banco de dados não muda!

O volume contém muitos arquivos nomeados core.NUMBERcom tamanho de 145 MB,

Como posso reduzir o uso do disco do banco de dados?

Seguindo um tutorial em vídeo sobre carteiras oracle: https://youtu.be/LLZzUNb9ALU

O servidor db é executado a partir do contêiner docker oficial da Oracle.

Os passos que fiz são os seguintes:

1. No shell do servidor, executei o sql plus como sysdba:

$ sqlplus / as sysdba

2. Criou um usuário:

SQL> alter session set "_ORACLE_SCRIPT"=true;
SQL> CREATE USER fred identified by flintstone;
SQL> GRANT CONNECT, RESOURCE, DBA to fred;

3. Logon testado:

$ sqlplus fred/flintstone

SQL> show user;
User is "fred"

4. Criou uma carteira no local padrão:$ORACLE_BASE/admin/$ORACLE_SID/wallet

$ orapki wallet create -wallet $ORACLE_BASE/admin/$ORACLE_SID/wallet -auto_login -pwd MyWalletPass

5. Criou um perfil de carteira para o usuário fred:

$ mkstore -wrl $ORACLE_BASE/admin/$ORACLE_SID/wallet -createCredential $ORACLE_SID fred flintstone

6. Tentei fazer login no sqlplus:

$ sqlplus /@$ORACLE_SID

Isso falha. Obteve o erroORA-01017: invalid username/password; logon denied

Não é capaz de entender o que está errado. O objetivo final é usar esta carteira para um aplicativo nodejs com autenticação externa (node-oracledb). Mas acho que se eu puder corrigir a etapa 6, devo poder usar no nodejs.

Eu preciso habilitar a configuração COLUMNAR no DB2 Express Edition no Docker. Para que isso funcione, preciso definir INTRA_PARALLEL ON no nível da instância ou do banco de dados.

Eu me conecto ao db2comando db2inst1que é o dono da instância, mas estou recebendo um erro dizendo que o usuário é root. Como consertar esse problema?

db2 => connect to bank0002 user db2inst1 using xxxxx

   Database Connection Information

 Database server        = DB2/LINUXX8664 11.5.4.0
 SQL authorization ID   = DB2INST1
 Local database alias   = BANK0002

db2 => UPDATE DBM CFG  USING INTRA_PARALLEL ON
SQL5001N  "ROOT" does not have the authority to change the database manager 
configuration file.

Estou tentando aprender mais sobre bancos de dados Oracle no meu tempo livre. Tenho o Oracle Enterprise disponível em um Docker Container. Eu sou um desenvolvedor em vez de um DBA. Tenho bastante experiência com SQL Server.

Estou tentando usar o recurso de bomba de dados. Até agora eu fiz isso:

1. Criou um usuário chamado dummy e criou uma tabela (Dummy.table1).
2. Adicionadas algumas linhas à tabela1.
3. Criou um usuário chamado admin e deu a este usuário acesso dba.
4. Faça login no SQL Developer como administrador e selecione: Exibir/DBA.
5. Conecte-se ao meu banco de dados e use o Data Pump Export Wizard para criar um arquivo de despejo.
6. Gere um arquivo .sql a partir do arquivo .dmp.

Já tentei todas as quatro opções (Database; Tablespaces; Schemas e Tabeles) em: 'Types to be export in data pump', selecionando 'Data and DDL' a cada vez, porém não consigo ver as instruções INSERT, que devem ser criadas para Dummy .tabela 1. Por que é isso?

A única coisa que consigo pensar é que existe um item de menu chamado: Tools\Database Export. Devo usar isso para exportar os dados? Eu pensei que os dados deveriam ser exportados ao usar o Data Pump Export Wizard; conectado como um DBA?

Instalei esta imagem do Docker hoje: https://hub.docker.com/_/oracle-database-enterprise-edition

Eu segui as instruções aqui: https://www.youtube.com/watch?v=ciYsDbBx80s . Basicamente executei os seguintes comandos:

docker pull store/oracle/database-enterprise:12.2.0.1
docker run -d -p 1521:1521 --name oracle store/oracle/database-enterprise:12.2.0.1
docker exec -it 0500ab7ee75c bash -c "source /home/oracle/.bashrc; sqlplus /nolog"

Então no sqlpus:

connect sys as sysdba
Enter password: anyrandompassword
alter session set "_ORACLE_SCRIPT"=true;
create user dummy identified by dummy;
SQL> GRANT ALL PRIVILEGES TO dummy;
SQL>ALTER USER sysdba IDENTIFIED BY Password1 ACCOUNT UNLOCK;

Eu tenho duas perguntas:

1. Por que a senha do SQLDeveloper para o usuário fictício: dummy. Eu não especifiquei isso.

2. Parece que agora posso fazer login no SQL Developer com as seguintes credenciais (conforme descrito aqui: https://stackoverflow.com/questions/9129664/unable-to-log-in-to-database-as-sys-with-oracle -sql-desenvolvedor ):

   Nome de usuário: SYS AS SYSDBA Senha: Senha1

No entanto, quando executo o seguinte comando no sqlplus

connect sys as sysdba

Em seguida, sou solicitado a fornecer uma senha, no entanto, qualquer senha parece funcionar.