A documentação da Microsoft indica que a função REPLACE() aceita e retorna apenas tipos de dados de caracteres. No entanto, estes funcionam sem erros:
SELECT REPLACE(123456, 'X', 'Y')
;
SELECT REPLACE(CAST(123456 AS INT), 'X', 'Y')
;
Além disso, você pode tratar o resultado como um INT, sugerindo que a função reteve o tipo de dados do argumento sem tentar convertê-lo:
SELECT REPLACE(123456, 'X', 'Y') / 3
;
O que não está sendo declarado na documentação da Microsoft?
Queremos calcular o total de bytes de armazenamento "na linha" para cada linha na tabela. Como entendemos, devemos somar o DATALENGTH() de cada coluna enquanto também contabilizamos NULLs e coisas como VARCHAR(MAX) que possuem apenas um ponteiro de 24 bytes "na linha". Estamos cientes de que também há alguma sobrecarga para cada linha que não é contabilizada na consulta abaixo.
SELECT ROW_ID,
CASE
WHEN COLUMNPROPERTY(OBJECT_ID('EXAMPLE_TABLE'),'COL1','PRECISION') = -1 THEN 24
ELSE ISNULL(DATALENGTH(COL1), 1)
END
+
CASE
WHEN COLUMNPROPERTY(OBJECT_ID('EXAMPLE_TABLE'),'COL2','PRECISION') = -1 THEN 24
ELSE ISNULL(DATALENGTH(COL2), 1)
END
+
CASE
WHEN COLUMNPROPERTY(OBJECT_ID('EXAMPLE_TABLE'),'COL3','PRECISION') = -1 THEN 24
ELSE ISNULL(DATALENGTH(COL3), 1)
END
+
...
...
AS ROW_SIZE
FROM EXAMPLE_TABLE
ORDER BY ROW_SIZE DESC
;
Que fera! E é apenas uma aproximação.
Então descobrimos
DBCC SHOWCONTIG ('EXAMPLE_TABLE') WITH TABLERESULTS
que retorna MaximumRecordSize. Isso revela que já existe um algoritmo enterrado em algum lugar no SQL Server que é capaz de calcular o tamanho exato de uma linha.
Como podemos acessar esse algoritmo diretamente?
Vindo para SQL de outras linguagens de programação, a estrutura de uma consulta recursiva parece bastante estranha. Ande por ela passo a passo, e ela parece desmoronar.
Considere o seguinte exemplo simples:
CREATE TABLE #NUMS
(N BIGINT);
INSERT INTO #NUMS
VALUES (3), (5), (7);
WITH R AS
(
SELECT N FROM #NUMS
UNION ALL
SELECT N*N AS N FROM R WHERE N*N < 10000000
)
SELECT N FROM R ORDER BY N;
Vamos percorrê-lo.
Primeiro, o membro âncora é executado e o conjunto de resultados é colocado em R. Assim, R é inicializado como {3, 5, 7}.
Então, a execução cai abaixo de UNION ALL e o membro recursivo é executado pela primeira vez. Ele é executado em R (ou seja, no R que temos atualmente em mãos: {3, 5, 7}). Isso resulta em {9, 25, 49}.
O que ele faz com esse novo resultado? Ele anexa {9, 25, 49} ao {3, 5, 7} existente, rotula a união resultante R e então continua com a recursão a partir daí? Ou ele redefine R para ser apenas este novo resultado {9, 25, 49} e faz toda a união depois?
Nenhuma das escolhas faz sentido.
Se R agora for {3, 5, 7, 9, 25, 49} e executarmos a próxima iteração da recursão, terminaremos com {9, 25, 49, 81, 625, 2401} e teremos perdeu {3, 5, 7}.
Se R agora é apenas {9, 25, 49}, então temos um problema de rotulagem incorreta. R é entendido como a união do conjunto de resultados do membro âncora e todos os conjuntos de resultados do membro recursivo subsequentes. Considerando que {9, 25, 49} é apenas um componente de R. Não é o R completo que acumulamos até agora. Portanto, escrever o membro recursivo selecionando de R não faz sentido.
Eu certamente aprecio o que @Max Vernon e @Michael S. detalharam abaixo. Ou seja, que (1) todos os componentes são criados até o limite de recursão ou conjunto nulo, e então (2) todos os componentes são unidos. É assim que entendo a recursão SQL para realmente funcionar.
Se estivéssemos redesenhando o SQL, talvez pudéssemos impor uma sintaxe mais clara e explícita, algo assim:
WITH R AS
(
SELECT N
INTO R[0]
FROM #NUMS
UNION ALL
SELECT N*N AS N
INTO R[K+1]
FROM R[K]
WHERE N*N < 10000000
)
SELECT N FROM R ORDER BY N;
Mais ou menos como uma prova indutiva em matemática.
O problema com a recursão SQL como está atualmente é que ela é escrita de maneira confusa. A forma como está escrito diz que cada componente é formado selecionando de R, mas isso não significa o R completo que foi (ou parece ter sido) construído até agora. Significa apenas o componente anterior.
Importamos acidentalmente algumas tabelas de dados para nosso banco de dados mestre com um script CREATE TABLE e BULK INSERT. Provavelmente eram cerca de 20 GB de dados antes de capturá-lo.
Excluímos imediatamente todas as tabelas.
Que outras ferramentas de limpeza ou diagnóstico devemos executar? Devemos estar atentos a alguma coisa?
Somos uma equipe de matemáticos (ou seja, sem experiência em DBA).
Estamos migrando de uma caixa de servidor antiga (SQL Server 2012) para uma nova caixa de servidor (SQL Server 2017). Para cada banco de dados no servidor antigo, fizemos uma cópia de backup, transferimos para o novo servidor e restauramos a glória completa do banco de dados a partir do arquivo de backup.
Até agora tudo bem.
No entanto, houve um atraso em nossa data de mudança e ainda estamos usando o servidor antigo. À medida que continuamos a trabalhar no servidor antigo, as alterações continuam sendo acumuladas nesses bancos de dados. Portanto, isso significa que os bancos de dados copiados no novo servidor agora estão obsoletos e desatualizados. (Irônico, não?)
Para os bancos de dados que foram alterados, sabemos que eventualmente teremos que fazer novas cópias de backup e transferi-las para o novo servidor.
Quando chegar a hora, qual é a maneira mais inteligente de se livrar desses bancos de dados agora obsoletos no novo servidor antes de restaurar as cópias de backup mais recentes?
Preocupamo-nos que com os mesmos nomes, alguma oclusão ou eclipsação possa ocorrer se não tivermos cuidado. Queremos ter certeza de que as cópias desatualizadas no novo servidor foram realmente eliminadas antes de restaurar as versões mais recentes.
Somos uma equipe de matemáticos (ou seja, sem experiência em DBA).
Temos um grande banco de dados no SQL Server 2012. Ele tem mais de 2 TB de dados (centenas de tabelas, cada uma com milhões de linhas e centenas de colunas de largura). Todos os meses, recebemos um pacote de adições e revisões dos dados, exigindo que realizemos extensas atualizações em nosso banco de dados, excluindo, substituindo ou atualizando a maioria ou todas as tabelas.
Nosso trabalho é principalmente focado na elaboração da lógica SQL para calcular os resultados que precisamos. Não estamos executando um call center em tempo real. Aplicamos alguns índices conforme necessário e estamos muito satisfeitos com o desempenho.
O problema é o arquivo de log. Naturalmente, o arquivo de log cresce e cresce com tanta manipulação de dados. Nosso arquivo de log atualmente tem cerca de 1 TB. Temos uma boa quantidade de espaço em disco, mas não é infinito.
Pelo que lemos na Internet, entendemos que o arquivo de log é necessário para a integridade da transação, reversões e recuperação. Mas para nossos propósitos específicos, não nos importamos com nada disso. Provavelmente nunca realizaremos uma reversão, nem tentaremos uma recuperação. Pior ainda, simplesmente baixaríamos os arquivos de dados novamente e criaríamos um novo banco de dados do zero.
Nós realmente queremos que o arquivo de log desapareça e nunca mais volte.
Definimos o modo de recuperação do banco de dados como Simples, pensando ingenuamente que isso significava "sem modo de recuperação", mas fomos rapidamente curados dessas ilusões.
Também entendemos que há muitas coisas erradas a não fazer (desapegar, encolher, etc.). Só não sabemos a coisa certa a fazer.
Talvez alguém sugira que definamos um limite para o crescimento do arquivo de log. No entanto, isso deixa duas questões: (1) Como nos livramos do 1 TB que já existe? (2) Tentamos isso anteriormente e, à medida que nos aproximamos do limite especificado, começamos a receber o erro 9002 (arquivo de log cheio) aqui, ali e em todos os lugares. Então agora temos medo de aplicar um limite de tamanho.
Como podemos dizer ao banco de dados "Sem arquivo de log, por favor" sem nenhum ressentimento?