u23432534's questions

Eu tenho uma tabela com 45 milhões de linhas (45 GB de espaço de dados e 2 GB de espaço de índice). Eu adicionei uma nova coluna e terminou instantaneamente.

alter table T add C char(25)

Então descobri que o tamanho é muito pequeno, então executei a seguinte consulta.

alter table T alter column C varchar(2500)

E funciona uma hora e ainda está funcionando. sp_whoisactive mostra (no momento, ainda em execução)

reads: 48,000,000
writes: 5,000,000
physical reads: 3,900,000

Não deveria ser muito rápido?

Vou precisar configurar a replicação transacional para um grande banco de dados. Eu uso backup/restauração para inicializar o banco de dados porque é muito grande para usar o instantâneo em uma rede lenta. Portanto, as seguintes etapas são usadas

1. Faça backup do banco de dados
2. Copie os arquivos de backup
3. Restaurar o banco de dados no assinante
4. Configurar replicação

No entanto, e se houver alguma alteração de dados (inserir/atualizar/excluir) depois da etapa 1 e antes da etapa 4? Essas transações serão perdidas? Ou a configuração da replicação falhará? Como resolver o problema?

Deixei cair um banco de dados antigo não utilizado. Então descobri que ele foi configurado para ser o banco de dados de origem de uma configuração de logshipping. E há muitos trabalhos com falha em nosso relatório de status de execução de trabalho agora. Como remover as configurações de logshipping depois que o banco de dados já foi removido?

Configurei o envio de log usando o modo de espera (a opção "Desconectar usuários do banco de dados ao restaurar backups" está desmarcada).

Testei a execução do seguinte código no servidor/banco de dados secundário.

declare @a int
while 1=1
begin
  select @a = count(*) from ....
end

No entanto, o código para com o seguinte erro quando o trabalho de restauração de envio de logs começa a ser executado.

O banco de dados não pode ser aberto. Está no meio de uma restauração.

Como evitar o problema?

No SQL Server com Enterprise Edition, existem bancos de dados com todas as tabelas/índices compactados. Ainda faz sentido fazer backup compactado?

Eu tenho a seguinte consulta que une dados dinâmicos de várias tabelas muito grandes e é executado muito lentamente. Tentei criar a tabela temporária para cada giro e ela roda muito mais rápido. É uma maneira de forçar o spool de índice/tabela sem criar tabelas temporárias?

select ...
from T1 ....
left join (select ... from (select ... from T2....) pivot (sum(C1) on C2 in (...))) p1 
    on ...
left join (select ... from (select ... from T3....) pivot (sum(...) on ... in (...))) p2
    on ...
left join (select ... from (select ... from T4....) pivot (sum(...) on ... in (...))) p3
    on ...

Eu tenho a seguinte tabela.

create table T (K1 date, K2 int references S(Id), ....) on partitionScheme(K1)

A tabela será particionada por K1 (K1 tem baixa seletiva. os dados serão anexados na ordem por K1). Qual das seguintes chaves primárias (a ordem das colunas é diferente) é preferida?

alter table T add primary key clustered (K1, K2)
alter table T add primary key clustered (K2, K1)

Ou o PK deve ser não clusterizado e criar outro índice clusterizado?

Muitas das consultas se parecem com:

select ....
from T join S on S.Id = T.K2
where ....

Parece que o SSMS do servidor Sql 2012 não pode mais imprimir as instruções SQL com cores de sintaxe. É um bug? Tem alguma solução alternativa?

Como obter uma lista de trabalhos com falha executados na noite passada? Eu só encontro o seguinte script powershell. Qual é a equivalência SQL?

dir $psPath\Jobs | % { $_.EnumHistory() } | ? { $_.RunStatus -ne 1 }

O tempdb de um servidor (SQL Server 2008) aumenta para mais de 500 GB várias vezes por mês. É possível descobrir quais instruções SQL causaram esse problema? O problema geralmente não é causado por create table #temp...; insert into #temp...ou , select ... into #temp...mas por junções complexas.

O tamanho inicial de alguns dos arquivos tempdb também é definido automaticamente para valores muito maiores todas as vezes. Como prevenir?

Às vezes, os planos em cache impedem o redimensionamento/encolhimento dos arquivos. Como descobrir qual deles contém o tempdb?

Eu tenho a seguinte tabela particionada

create table T (Month char(6), ID int, .... primary key (ID, Month)) on psMonth(Month)

A função de partição é

CREATE PARTITION FUNCTION [pfMonth](char(6)) AS 
RANGE RIGHT FOR VALUES (N'200001', .... N'200705', N'200706', N'200707', ....)

No entanto, a contagem real de partições da consulta a seguir é 260 em vez de 1?

select count(*)
from T (nolock)
where Month = '200706'

O plano de execução é

  |--Calcular escalar(DEFINE:([Expr1004]=CONVERT_IMPLICIT(int,[globalagg1006],0)))
       |--Stream Aggregate(DEFINE:([globalagg1006]=SUM([partialagg1005])))
            |--Paralelismo(Gather Streams)
                 |--Stream Aggregate(DEFINE:([partialagg1005]=Contagem(*)))
                      |--Clustered Index Scan(OBJECT:([DB].[dbo].[T].[PK_T]), WHERE:([DB].[dbo].[T].[Mês]=[@1] ))

Atualização:
a consulta é executada rapidamente e a contagem real de partições é 1 se eu executar a consulta a seguir.

select count(*), $partition.pfMonth(Month)
from T with (nolock)
where Month = '200706'
group by $partition.pfMonth(Month)

Atualização 2:
A consulta a seguir também verifica apenas uma partição.

select count(*), min($partition.pfByMonth(Month))
from T 
where Month = '200707'

Atualização 3:
o SQL original verifica apenas uma partição agora. Não faço ideia do que aconteceu. A única diferença é que mais dados foram inseridos na tabela.
Resposta: Usei um CTE que envolveu a tabela. E resolveu o problema causado pela precedência de tipo. (No entanto, o CTE não resolveu o problema no início, a coisa toda é estranha e imprevisível.)

Eu tenho uma grande tabela particionada (mais de 300 milhões de linhas, 70 partições ativas). A tabela tem PK agrupado de (K0, K1) e é particionada na coluna K1. E K1 tem seletividade muito baixa.

No entanto, a consulta a seguir leva meio minuto e a contagem de varredura é 170 e a leitura lógica é 603K.

select max(K1) from table

No entanto, a consulta semelhante na tabela não particionada com índice em K1 não leva tempo e a contagem de varredura é 1 e a leitura lógica é 5.

Um índice não particionado deve ser criado em K1?

Editar:
planeje o texto para a tabela particionada sem índice no K1. Com PK clusterizado em K0,K1, antes de criar um índice em C1.

  |--Stream Aggregate(DEFINE:([Expr1004]=MAX([partialagg1005])))
       |--Paralelismo(Gather Streams)
            |--Stream Aggregate(DEFINE:([partialagg1005]=MAX([DB1].[dbo].[table1].[K1])))
                 |--Clustered Index Scan(OBJECT:([DB1].[dbo].[table1].[PK_dbo_tabl1]))

Planeje o texto para tabela não particionada com índice em K1.

  |--Stream Aggregate(DEFINE:([Expr1003]=MAX([DB1].[dbo].[table2].[K1])))
       |--Início(EXPRESSÃO SUPERIOR:((1)))
            |--Index Scan(OBJECT:([Db1].[dbo].[table2].[idx_K1]), ORDERED BACKWARD)

Planeje o texto para a tabela particionada com PK clusterizado em K0, K1 e índice em C1.

  |--Stream Aggregate(DEFINE:([Expr1004]=MAX([partialagg1005])))
       |--Paralelismo(Gather Streams)
            |--Stream Aggregate(DEFINE:([partialagg1005]=MAX([db1].[dbo].[table1].[K1])))
                 |--Index Scan(OBJECT:([db1].[dbo].[table1].[IX_C1]))