Derek Kromm's questions

Configurar:

• Windows Server 2008 R2
• SQL Server 2008 R2 SP1
• RAM de 240 GB
• TempDB é 8x16GB de arquivos de dados sem crescimento automático (total de 128GB)
• Servidor Físico/Autônomo

Este servidor é usado para processamento de ETL. Acabamos de instalar mais RAM neste servidor para um total de 240 GB de RAM. Os serviços do SQL Server são as únicas coisas reais em execução.

A memória aparece bem no BIOS, OpenManage e Windows.

Se eu configurar o SQL Server para usar um mínimo/máximo de 70/100 GB de memória, não teremos problemas. No entanto, depois de aumentar para 120/150 GB, recebo o seguinte erro ao executar um de nossos processos ETL:

Não foi possível alocar espaço para o objeto '<objeto de sistema temporário: 422234507706368>' no banco de dados 'tempdb' porque o grupo de arquivos 'PRIMARY' está cheio. Crie espaço em disco excluindo arquivos desnecessários, descartando objetos no grupo de arquivos, adicionando arquivos adicionais ao grupo de arquivos ou definindo o crescimento automático para arquivos existentes no grupo de arquivos. (Msg 1105, Estado 2, Procedimento Desconhecido, Linha 1)

Nunca nos deparamos com esse problema antes de alterar a configuração da memória. Depois de reconfigurar de volta para os 70/100 GB originais, não recebemos esse erro.

Coisas que eu tentei:

1. Defina os arquivos de dados TempDB para crescimento automático. Isso simplesmente resulta no crescimento automático dos arquivos até que a capacidade do disco seja atingida e, em seguida, falha.
2. Adicione mais arquivos de dados TempDB. Mesmo erro mostrado.
3. Aumente o tamanho do TempDB para 8x32 GB (total de 256 GB)

Estou sem saber o que pode estar causando esse problema.

Trabalhando no SQL Server 2008 R2, estou tentando reverter um conjunto de instruções DDL como um grupo (pense em um script de atualização para um banco de dados), mas estou tendo problemas.

Pegue o seguinte código:

begin try

begin tran

create table foo (i int)
alter table foo add x dog
insert into foo select 1,1
insert into foo select 1,1,1

commit tran

end try

begin catch

rollback tran
print @@error

end catch

Estou esperando que o try falhe na instrução alter table, vá para o catch, reverta a transação e imprima a mensagem de erro. No entanto, se você verificar seus objetos/tabelas, verá que foo ainda está lá (portanto, a criação da tabela não foi revertida corretamente).

select * from sys.objects where name = 'foo'

O que eu estou fazendo errado aqui?

Vamos supor que temos uma tabela da seguinte forma:

PK -- nonclustered primary key
Col1 -- unique clustered
Col2
Col3

Este índice é:

nonclustered index on (Col2, Col3)

diferente deste índice:

nonclustered index on (Col2, Col3) include (PK)

E se meu PK for clusterizado em vez de não clusterizado? Agora faz/não faz diferença?

Edite para adicionar:

Suponho que esta seja uma maneira indireta de perguntar: o ponteiro do índice não clusterizado está de volta à tabela com base no índice clusterizado ou na chave primária? Eu suponho que o RID de índice clusterizado é o que é usado.

Atualmente, tenho alguns SQL Servers que ficam em um subdomínio. Estamos eliminando esse subdomínio e movendo tudo para o domínio regular.

No que diz respeito à configuração do SQL Server, há algo que preciso alterar além de potencialmente usar contas de serviço diferentes?

Observe que isso é simplesmente uma mudança de domínio - o nome do servidor deve ser o mesmo.