All perguntas(dba)

Hoje, aprendi da maneira mais difícil que você não pode verificar a corrupção de um secundário do Basic Availability Group . Dada essa limitação, como posso saber se é seguro fazer failover de um BAG? Pelo que sei, o secundário pode estar corrompido.

Os dados em um campo longo no Oracle são encapsulados e não são exibidos com um simples select. Embora esse tipo esteja obsoleto, ele ainda é encontrado em várias visualizações internas do Oracle, provavelmente por compatibilidade com versões anteriores e/ou dificuldade em substituí-lo. Existe algum truque sobre como o texto dentro de um campo tão longo pode ser recuperado e manipulado apenas com SQL? Não estou interessado em uma solução pl/sql.

Por exemplo, a consulta a seguir falharia com "ORA-00932: tipos de dados inconsistentes: CHAR esperado ficou LONG":

select * 
  from dba_triggers a 
 where a.OWNER = 'YOUR_OWNER'
   and a.TRIGGER_BODY like '%begin%';

Estou trabalhando com SQL-Server, usando o SQL-Server Management Studio (SSMS).

Para executar a restauração de um backup, criei um login do SQL Server via SSMS, chamado PORT-DDM\SQLEXPRESS, que é a maneira típica de se conectar a um banco de dados SQL Server.

Também criei um segundo, chamado PORT-DDM\SQLEXPRESS01(onde PORT-DDMestá o nome do meu PC), e agora gostaria de restaurar um backup da PORT-DDM\SQLEXPRESSinstância para a PORT-DDM\SQLEXPRESS01instância . Peguei o PORT-DDM\SQLEXPRESSbackup e o armazenei no meu diretório local C:\Temp_Folder\<filename>.bak, mas ao executar a ação de restauração, recebo a seguinte mensagem de erro:

===================================
Restore of database '<Prod>_<Customer>' failed. (Microsoft.SqlServer.Management.RelationalEngineTasks)
------------------------------
Program Location:
   at Microsoft.SqlServer.Management.RelationalEngineTasks.RestoreDatabaseTaskFormComponent.PerformTask(ITaskExecutionContext context)
   at Microsoft.SqlServer.Management.RelationalEngineTasks.RestoreDatabaseTaskFormComponent.Perform(ITaskExecutionContext context)
   at Microsoft.SqlServer.Management.TaskForms.TaskExecutionManager.ExecuteTaskSequence(ISfcScriptCollector collector)
===================================
System.Data.SqlClient.SqlError: The operating system returned the error '5(Access is denied.)' while attempting 'RestoreContainer::ValidateTargetForCreation' on 'C:\Program Files\Microsoft SQL Server\MSSQL15.SQLEXPRESS\MSSQL\DATA\<Prod>_<Customer>.mdf'. (Microsoft.SqlServer.SmoExtended)
------------------------------
For help, click: https://go.microsoft.com/fwlink?ProdName=Microsoft+SQL+Server&ProdVer=16.100.47021.0&LinkId=20476
------------------------------
Program Location:
   at Microsoft.SqlServer.Management.Smo.RestorePlan.Execute()
   at Microsoft.SqlServer.Management.RelationalEngineTasks.RestoreDatabaseTaskFormComponent.PerformTask(ITaskExecutionContext context)

(O link mencionado parece estar inativo.)

Como posso prosseguir?

Ah, esqueci de mencionar: o local onde meu backup está localizado é acessível para todos os usuários do meu PC:

Eu dei controle total a todos, usando icalcs. Agora estou preso porque o seguinte arquivo está sendo usado pelo SQL-Server: C:\Program Files\Microsoft SQL Server\MSSQL15.SQLEXPRESS\MSSQL\DATA\<Prod>_<Cust>.mdf.

Para evitar isso, reiniciei minha sessão do SQL Server e até mesmo meu PC inteiro, mas o problema persiste.

Conforme solicitado, a imagem da tela "restaurar banco de dados":

Isto está se tornando um pesadelo sangrento :

1. Primeiro, recebo mensagens de erro informando que ele precisa de acesso de administrador para os arquivos.
2. Então ele reclama que os arquivos estão em uso, então tenho que reiniciar meu computador.
3. Depois ele reclama que há outros arquivos para os quais ele precisa de direitos de administrador.
4. Depois que isso é resolvido, ele reclama novamente que os arquivos estão em uso, então preciso reiniciar meu computador novamente .
5. Por fim, ele diz: "Mas você não pode fazer isso: você está restaurando um banco de dados em seu local original".

=> Essa última coisa é a razão exata pela qual criei o login "SQLExpress 01 ": para poder ter diferentes instâncias dos mesmos bancos de dados: uma para testes de tempo de execução e uma para restaurar os backups, recuperados dos sites do cliente. Geralmente essa última coisa está funcionando bem, mas agora estou lidando com um cliente cujo servidor de banco de dados está inacessível, então estou usando "Gerar script" para obter o ±backup. A ideia era fazer outro backup do meu computador (sob o login "SQLEXPRESS"), restaurar sob o login "SQLEXPRESS01" e usá-lo para o cenário "Gerar script" mencionado.

Estou tentando limpar o banco de dados MySQL e restaurar o SQL --no-data para abrir uma nova instalação do meu aplicativo da web. Também tentei SET FOREIGN_KEY_CHECKS = 0, depois TRUNCATE TABLE 'table', depois SET FOREIGN_KEY_CHECKS = 1. Ainda não consigo me livrar dos valores AUTO_INCREMENT. Sei que estou esquecendo de algo óbvio. Qual é a maneira mais fácil de limpar esses dados para que eu possa reinstalar uma versão nova? Obrigado.

Com tabelas particionadas no SQL Server, há um problema notório de desempenho importante ao usar funções min/max ou TOP. Soluções alternativas do documento da Microsoft para isso aqui . Estou confiante de que isso não foi corrigido no SQL Server 2022. A Microsoft certamente teria atualizado a lista de soluções alternativas se dar a eles mais dinheiro fosse uma solução alternativa.

No entanto, isso mudou depois do SQL Server 2022? Tenho certeza de que vi um link funcional para este item do Connect em 2024. Hoje, não consigo encontrá-lo nem mesmo nas sugestões modernas do Azure para as quais todos os itens do Connect foram migrados. Isso me sugere que algo aconteceu com esse bug de uma década nos últimos anos.

Não posso responder isso sozinho, pois não tenho acesso ao SQL Server 2025 ou a qualquer outro recurso de ponta do Azure. Ouvi dizer que versões de pré-visualização do SQL Server 2025 foram lançadas.

Pegue o seguinte código:

pragma foreign_keys = ON;

create table people(people_id integer primary key, name text not null);
insert into people (name) values ("Mom"), ("Jack the Ripper");

create table family_member(people_id integer primary key references people(people_id));

insert into family_member values ((select people_id from people where name = "Mom"));
insert into family_member values ((select people_id from people where name = "Dad"));  -- silent error here

select name from family_member inner join people using (people_id);
-- Jack the Ripper is part of the family

Como isso é legítimo no sqlite? Nem mesmo um aviso é gerado. Isso é por boas razões, por razões de legado, há algo na documentação sobre isso que eu não encontrei? Para mim, isso é preocupante e acredito que nenhum outro SQL DB se comporte dessa forma.

Sempre que fecho um script SQL que não tenho interesse em manter ou mesmo salvá-lo, a caixa de diálogo "Resultados da execução da consulta" aparece antes da pergunta regular se você deseja salvar ou não.

Alguém sabe como se livrar?

Como posso ver se esse patch foi aplicado ao meu servidor SQL Server?

Eu sei sobre @@version , mas isso me mostra o último patch aplicado, e os outros patches anteriores a esse?

Um dos desenvolvedores da minha empresa configurou um profiler SQL com um filtro no ID do banco de dados .

Ele está me dizendo que o ID do banco de dados que ele está procurando mudou.

O banco de dados em questão ainda está lá, mas em vez de 61 agora é 60.

Quando executo mysqldump, a saída não inclui a collation padrão da tabela para algumas tabelas. Como incluo a collation para todas as tabelas?

A versão do MySQL é 5.7.

mysqldump --version
mysqldump  Ver 10.13 Distrib 5.7.38, for FreeBSD13.1 (amd64)

A linha de comando é a seguinte (mas com uma série de opções --ignore-table)

mysqldump --defaults-file=.fmd-acdb-dev.cnf my-db-name --set-gtid-purged=OFF

O arquivo cnf tem isto:

[client]
host=localhost
user=root
password=[redacted]
max_allowed_packet=1073741824

Seguem algumas seleções da saída.

/*!40000 ALTER TABLE `cluster_categorizations` DISABLE KEYS */;
-- MySQL dump 10.13  Distrib 5.7.38, for FreeBSD13.1 (amd64)
--
-- Host: localhost    Database: analyst_console_condense
-- ------------------------------------------------------
-- Server version       5.7.38-log

/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8 */;
/*!40103 SET @OLD_TIME_ZONE=@@TIME_ZONE */;
/*!40103 SET TIME_ZONE='+00:00' */;
/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;
/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
/*!40111 SET @OLD_SQL_NOTES=@@SQL_NOTES, SQL_NOTES=0 */;
...
DROP TABLE IF EXISTS `false_positive_selections`;
/*!40101 SET @saved_cs_client     = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `false_positive_selections` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `display` varchar(255) DEFAULT NULL,
  `created_at` datetime NOT NULL,
  `updated_at` datetime NOT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8mb4;
/*!40101 SET character_set_client = @saved_cs_client */;
...
DROP TABLE IF EXISTS `companies`;
/*!40101 SET @saved_cs_client     = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `companies` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `name` varchar(255) DEFAULT NULL,
  `created_at` datetime NOT NULL,
  `updated_at` datetime NOT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `index_companies_on_name` (`name`)
) ENGINE=InnoDB AUTO_INCREMENT=32957 DEFAULT CHARSET=utf8;
/*!40101 SET character_set_client = @saved_cs_client */;

Para comparação, no banco de dados de origem que está sendo despejado:

show create table false_positive_selections;
CREATE TABLE `false_positive_selections` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `display` varchar(255) DEFAULT NULL,
  `created_at` datetime NOT NULL,
  `updated_at` datetime NOT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8mb4

SELECT DEFAULT_COLLATION_NAME FROM information_schema.SCHEMATA WHERE SCHEMA_NAME = 'my-schema';
utf8mb4_general_ci

SELECT TABLE_SCHEMA, TABLE_NAME, TABLE_COLLATION FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_NAME = 'false_positive_selections';
| my-schema | false_positive_selections | utf8mb4_general_ci |

No banco de dados de destino após a restauração:

show create table false_positive_selections;
CREATE TABLE `false_positive_selections` (
  `id` bigint NOT NULL AUTO_INCREMENT,
  `display` varchar(255) DEFAULT NULL,
  `created_at` datetime NOT NULL,
  `updated_at` datetime NOT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci

SELECT DEFAULT_COLLATION_NAME FROM information_schema.SCHEMATA WHERE SCHEMA_NAME = 'my-schema';
utf8mb4_0900_ai_ci

SELECT TABLE_SCHEMA, TABLE_NAME, TABLE_COLLATION FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_NAME = 'false_positive_selections';
| my-schema | false_positive_selections | utf8mb4_0900_ai_ci |

Para enfrentar possíveis diferenças na ordenação padrão do banco de dados, estamos tentando padronizar a definição da ordenação padrão em cada tabela.