BradC's questions

Provavelmente mais uma pergunta do SQL Management Studio do que o SQL, por si só, mas quando executo a seguinte consulta simples:

SELECT results = 'Foo' + CHAR(13) + CHAR(10) + 'Bar'

Parece que recebo resultados diferentes dependendo se eu escolher "Resultados para grade" ou "Resultados para texto".

Com o SSMS definido como "Resultados para texto", recebo (como esperado):

results
--------
Foo
Bar

(1 row affected)

Mas com o SSMS definido como "Results to Grid", copie e cole os resultados, recebo

Foo  Bar

Estou no processo de adicionar o WITH CHECKSUMsinalizador em nossos backups diários de SQL, como parte de um esforço para garantir melhor a integridade dos dados.

Eu definitivamente quero saber se um erro de soma de verificação é encontrado, mas também não quero que meu trabalho pare na água no meio da noite; Eu quero que ele termine de fazer o backup do banco de dados "ruim" e continue fazendo o backup dos outros bancos de dados no servidor.

Se eu usar BACKUP WITH CHECKSUM, CONTINUE_AFTER_ERROR, ele ainda lançará o erro apropriado ( SEV 22ou Error 825qualquer outra coisa) que acionará meu alerta associado? Ou CONTINUE_AFTER_ERRORsuprime isso completamente, e eu só saberia sobre o problema se analisasse a saída da etapa do trabalho?

Eu simplesmente testaria, mas não tenho um banco de dados com CHECKSUMinconsistências conhecidas.

Descobrimos uma conta SQL "sa" sendo usada de uma forma que não deveria, então estamos alterando as senhas sa em todas as nossas instâncias SQL.

(Temos servidores SQL 2005 a 2017 em execução no modo de autenticação misto. Todos os usuários e aplicativos devem usar contas de domínio ou contas SQL não sa para se conectar. Tenho monitorado, mas não encontrei nenhum outro aplicativo, usuário ou não -spids internos usando a conta sa.)

Algumas questões:

Q1: A alteração da senha sa requer uma reinicialização do SQL?

Encontrei algumas referências que dizem que é necessário reiniciar o serviço SQL após alterar a senha da conta sa:

• DBA SE: Alterando a senha sa
• SQLAuthority: Alterar a senha do login do SA usando o Management Studio

Isso é verdade? Ou apenas se eu estiver alterando o modo de autenticação? Ou apenas se eu fizer logon rotineiramente como sa?

Esse thread do SQL Server Central sugere até mesmo que alterá-lo pode afetar os trabalhos existentes do agente SQL e outras coisas; isso é uma preocupação? Ou apenas se alguém tiver codificado a conta SA em um pacote SSIS ou algo assim?

(Caso seja importante, usamos contas de domínio para o serviço SQL e serviço de agente SQL e contas de proxy de domínio para trabalhos que chamam pacotes SSIS ou scripts do PowerShell.)

P2: Posso alterar a senha do sa da maneira "normal"?

Posso redefini-la como faria com qualquer outra conta? Usando SSMS, ou mais provavelmente via:

ALTER LOGIN sa WITH PASSWORD = 'newpass';

Ou eu teria que entrar no modo de usuário único ou algo que exigiria um tempo de inatividade planejado? (Observe que eu estaria executando isso de uma conta de domínio, não enquanto conectado como "sa".)

Q3: Devemos tentar fazer essa rotação de senha regularmente? Ou apenas quando encontramos um problema?

Esta é uma "melhor prática" recomendada?

Então, estou trabalhando em um quebra-cabeça de golfe de código e preciso adicionar uma coluna "número" INT n a um resultado, mantendo a ordem atual.

Digamos que meus dados de origem sejam:

SELECT value
FROM STRING_SPLIT('one,two,three,four,five', ',')

que retorna os itens na ordem original (desejada):

value
-----
one
two
three
four
five

Se eu tentar usar ROW_NUMBER()ou RANK()for forçado a especificar um ORDER BY, para o qual valueé a única opção legal:

SELECT value, n = ROW_NUMBER() OVER(ORDER BY value)
FROM STRING_SPLIT('one,two,three,four,five',',')

Mas isso (como esperado) classifica valueem ordem alfabética em vez de deixá-lo na ordem original desejada:

value   n
------ ---
five    1
four    2
one     3
three   4
two     5

A junção a uma tabela numérica não funciona, pois sem uma WHEREcláusula obterei uma junção externa completa.

O melhor que consegui foi usar uma tabela temporária com um campo de identidade:

CREATE TABLE #argg (n INT IDENTITY(1,1), v VARCHAR(99))

INSERT #argg 
SELECT value v
FROM STRING_SPLIT('one,two,three,four,five',',')

SELECT *
FROM #argg

DROP TABLE #argg

mas isso é muito longo e irritante. Alguma ideia melhor?

Estou tendo sintomas muito semelhantes aos descritos neste artigo MSSSQLTips de 2015:

O SQL Server Reporting Services (SSRS) não é compatível com o Internet Explorer 11

Você atualizou para o Internet Explorer 11, agora, quando você visualiza um relatório do SQL Server Reporting Services (SSRS), descobre que o comando de impressão não está visível no visualizador de relatórios. Além disso, às vezes, quando você altera os valores dos parâmetros, o IE11 para de responder ou leva muito tempo para carregar o relatório. Você também pode descobrir que a barra de ferramentas que exibe os controles de relatório e os recursos de exportação aparece em várias linhas quando visualizada com o IE11. Quando você visualiza o mesmo relatório do SSRS no Chrome ou no Mozilla Firefox, ele funciona bem sem nenhum problema, o que significa que é um problema de compatibilidade do navegador. Como você pode tornar o SQL Server Reporting Services (SSRS) compatível com o IE11?

Praticamente todas as discussões que posso encontrar sobre esse problema se referem a este artigo (ou a uma página do MS Connect agora indisponível).

O problema é que a correção do lado do servidor sugerida para o SSRS 2008 não funciona para o SSRS 2017 (não há <meta http-equiv="X-UA-Compatible" content="IE=5">tag no ReportServer\Pages\reportviewer.aspxarquivo).

Existe uma correção do lado do servidor equivalente para o SSRS 2017? Devo adicionar essa metatag a este ou a um arquivo ASPX diferente?

Outras postagens sugerem a atualização do SSRS, como esta pergunta sobre o SSRS 2012 , mas já estou na penúltima versão do SSRS 2017 (14.0.600.689), e o log de alterações do patch mais recente parece não conter quaisquer correções relevantes .

(Uma correção do lado do cliente não está absolutamente fora de questão, mas envolveria um push de política de grupo do AD mais difícil, então eu prefiro uma correção do lado do servidor, se houver.)

Backstory: Estou tentando restaurar cópias de vários bancos de dados SQL 2012 para um ambiente diferente, mas o aplicativo precisa que eles sejam (aproximadamente) "sincronizados" a tempo.

(Claro que a maneira ideal de fazer isso é usar o modo de recuperação FULL usando backups completos e de log e, em seguida, fazer restaurações pontuais usando o mesmo carimbo de data/hora. Mas no meu caso, não preciso deles perfeitamente sincronizados, apenas dentro de ~ 10 minutos ou mais, e eu prefiro lidar apenas com backups e restaurações completos. Eu tenho controle sobre quando os backups completos são executados, mas o problema é que os bancos de dados são de tamanhos muito diferentes, então os backups completos são executados por muito diferentes períodos de tempo.)

Então minha pergunta: devo sincronizar a hora de início dos backups completos? Ou o tempo de término ?

Em outras palavras, quando eu restaurar um backup completo, terminarei com a aparência dele quando o backup começou ou quando terminou ?

Eu tenho dois bancos de dados, ambos de propriedade do sa. Todos os objetos em ambos os bancos de dados estão no esquema dbo.

Eu tenho um usuário bobem dbSafeque precisa selecionar em uma exibição que une tabelas de dbSafee dbRestricted. Não quero conceder bobpermissão direta a essas tabelas em dbRestricted, pois elas contêm colunas que não quero bobver.

Eu concedi bob SELECTpermissão na exibição e SET DB_CHAINING ONnos dois bancos de dados, mas ainda estou recebendo um erro:

O servidor principal "bob" não pode acessar o banco de dados "dbRestricted" no contexto de segurança atual.

Estou entendendo mal o que o encadeamento entre bancos de dados faz ?

Se o objeto de origem no banco de dados de origem e os objetos de destino nos bancos de dados de destino forem de propriedade da mesma conta de logon, o SQL Server não verificará as permissões nos objetos de destino.

O encadeamento de banco de dados pode funcionar neste cenário, com o proprietário sae o esquema do banco de dados dbo? Ou tem que ser uma conta de login explícita/esquema não padrão?

A resposta aceita para essa pergunta sugere a criação de uma visualização dbRestrictede a atribuição de permissão direta a bob, isso funcionaria neste caso? E se adicionar uma visualização a esse banco de dados não for uma opção para mim (devido a restrições de desenvolvedor/fornecedor)? Não é para isso que serve o encadeamento entre bancos de dados?

Se você não ouviu, foi descoberto recentemente um conjunto de vulnerabilidades relacionadas que afetam praticamente todos os processadores vendidos na última década. Você pode encontrar mais detalhes técnicos sobre as vulnerabilidades de fusão/espectro no InfoSec.SE .

Como um DBA do SQL Server, o que preciso entender sobre isso?

Se não compartilharmos nossos SQL Servers (ou nossos farms vm) com outras empresas, isso ainda é um risco?

Isso será simplesmente um patch do sistema operacional? Ou há patches/hotfixes disponíveis para o SQL Server que são necessários para resolver essa vulnerabilidade? Quais versões do SQL Server serão corrigidas?

Alguns artigos estão prevendo um impacto de 5 a 30% no desempenho, especialmente em ambientes altamente virtualizados. Existe alguma maneira de prever qual pode ser o impacto no desempenho dos meus SQL Servers?

Estou encontrando informações contraditórias sobre como exatamente formatar SPNs (Nomes de Princípios de Serviço) para obter as conexões Kerberos adequadas e quantas preciso para cada instância SQL.

Este documento MS de 2017 contém o seguinte:

A partir do SQL Server 2008, o formato SPN é alterado para oferecer suporte à autenticação Kerberos em TCP/IP, pipes nomeados e memória compartilhada. Os formatos SPN suportados para instâncias nomeadas e padrão são os seguintes.

• Instância nomeada:MSSQLSvc/FQDN:[port|instancename]
• Instância padrão:MSSQLSvc/FQDN:port|MSSQLSvc/FQDN

O novo formato SPN não requer um número de porta . Isso significa que um servidor de várias portas ou um protocolo que não usa números de porta pode usar a autenticação Kerberos.

Eu entendi este último parágrafo para significar que eu só preciso de uma única entrada, uma das seguintes:

• Instância nomeada:MSSQLSvc/sqlbox1.mydomain.org/instance2
• Instância padrão:MSSQLSvc/sqlbox1.mydomain.org

Isso parece contradizer este documento MS mais antigo (2011) , não apenas sobre o número da porta, mas também sobre qual nome usar:

Para criar o SPN, você pode usar o nome NetBIOS ou o nome de domínio totalmente qualificado (FQDN) do SQL Server. No entanto, você deve criar um SPN para o nome NetBIOS e o FQDN .

Quando olho os SPNs que já existem no meu ambiente, vejo uma grande variedade de combinações, alguns servidores possuem até 4 entradas:

• MSSQLSvc/sqlbox1
• MSSQLSvc/sqlbox1:1433
• MSSQLSvc/sqlbox1.mydomain.org
• MSSQLSvc/sqlbox1.mydomain.org:1433

Até o próprio gerenciador de configuração Kerberos da MS parece querer gerar as duas últimas versões (com ofuscação apropriada):

Da mesma forma, para instâncias nomeadas existentes, vejo uma mistura estranha, algumas delas quase certamente inválidas:

• MSSQLSvc/sqlbox1:1522
• MSSQLSvc/sqlbox1:instance2
• MSSQLSvc/sqlbox1.mydomain.org:1522
• MSSQLSvc/sqlbox1.mydomain.org:instance2
• MSSQLSvc/sqlbox1.mydomain.org/instance2
• MSSQLSvc/sqlbox1.mydomain.org:1522:instance2

Então, como devem ser meus DSNs, para instâncias padrão e nomeadas, se eu usar apenas TCP em meu ambiente?

Devo incluir a porta, ou não? Ou incluir um com a porta e outro sem?

Use apenas o FQDN ou preciso das entradas apenas com o nome Netbios? Ou isso seria apenas se estivéssemos usando pipes nomeados (o que não estamos)?

(Para contextualizar, executamos o SQL 2005 a 2014, alguns em cluster, outros autônomos. A conectividade é apenas via TCP, os pipes nomeados estão desabilitados no gerenciador de configuração. Estaremos corrigindo/criando esses manualmente em vez de permitir que a conta de serviço SQL os crie após início do servidor.)

Uma de nossas instâncias SQL tem um grande banco de dados MDS e praticamente 100% do tamanho se deve a uma tabela de mais de 300 milhões de linhas chamada stg.Stg_Project_Leaf. Recentemente, começou a explodir nossas reconstruções de índice semanais, então preciso descobrir isso.

Pelo que posso dizer, esta é uma Tabela de Preparação de Membros Folha para uma entidade "Projeto", configurada e automatizada (por um consultor anterior) como parte de um processo ETL que cria cubos/relatórios de BI.

Parece que ele vem processando cerca de 10 mil linhas por meia hora nos últimos anos e nunca foi purgado. Quando eu verifico o ImportStatus_ID, porém, vejo 0 linhas esperando para serem processadas. (A maioria é 1 - com sucesso, menos de 1% são 2 - com falha.)

Posso só TRUNCATEesta mesa?

Este sistema está sendo usado de forma automatizada, não é como se as pessoas estivessem entrando no console do MDS e monitorando individualmente e revertendo as alterações. Encontrei algumas referências a procedimentos armazenados que limpam essas tabelas ( mdm.udpStagingClearou talvez mdm.udpDeletedMembersPurge), mas não tenho certeza de qual delas é a que eu preciso, nem sei se eles explodiriam o log se tentassem fazer 300m fileiras de uma vez.

Eu tenho um servidor SQL 2012 ocupado em que as conexões com um banco de dados específico (usando o mesmo login SQL) não mostram um "nome de host" e preciso descobrir de qual caixa (de várias) essas conexões estão vindo.

Eu tentei todas as ferramentas normais internas e de terceiros ( master.sys.processes, sys.dm_exec_sessions, sp_who2, sp_WhoIsActive, o SSMS Activity Monitor, mesmo SQL Profiler e Idera Diagnostic Manager), nenhuma delas pode me fornecer o nome do host do servidor/cliente por trás dessas conexões , presumivelmente porque todos eles usam as mesmas tabelas/visualizações de sistema subjacentes.

Eu ficaria bem com um endereço IP também, mas também não vejo nenhuma maneira de determinar isso de dentro do SQL.

Caso isso seja de alguma ajuda:

• sys.dm_exec_sessionsmostra o client_interface_nameé ODBC
• Nada capturado para program_namequalquer um
• O usuário é uma conta SQL que por acaso é um SYSADMIN (sim, eu sei...)

Encontrei uma pergunta relacionada aqui (embora do outro lado), mas que ficou sem resposta.

Neste ponto, estou tentado a desabilitar o usuário para que eu possa capturar alguns logins com falha no log de erros do SQL, mas não imagino que a equipe do aplicativo ficará feliz com isso.

Eu tenho uma tabela muito grande (88 milhões de linhas, quase 300 GB de tamanho) que possui um índice clusterizado mal planejado. Eu quero adicionar um BIGINTcampo de identidade e torná-lo o novo índice clusterizado (tendo os atributos desejáveis ​​de unique, narrow, static e sempre crescente ).

O problema é que também quero que esse novo campo de identidade seja ordenado de uma certa maneira nos registros atuais (com base em um campo de data existente que não seja o cluster atual). Assim, quando limparmos os registros mais antigos, todos eles ficarão contíguos no disco. (O campo de data não é exclusivo, portanto, não é um bom candidato para o cluster por si só.)

Como posso obter os valores desse novo campo de identidade ordenados da maneira que desejo?

A primeira ideia que tive foi fazer uma nova tabela com o campo de identificação, e apenas INSERT INTOas linhas da tabela atual ORDER BYo campo de data? Isso funcionaria?

Se eu não tiver espaço em disco suficiente para fazer isso, existe alguma maneira de fazer isso "no local"? Talvez alterando o índice clusterizado para o campo de data (aguarde muito tempo) e adicione a identidade (e aguarde muito tempo novamente)? Os valores da identidade são garantidos para serem ordenados pelo cluster atual?

Ajuda! Meu banco de dados mestre está corrompido, não consigo nem colocar a instância SQL online! Quais são minhas opções para recuperar meu servidor?

Eu tenho um backup do mestre, mas a página do MSDN "Restaurando o banco de dados mestre" me pede para iniciar a instância no modo de usuário único, o que não posso fazer!

(Nota: estou deixando esta pergunta não especificada quanto à versão do SQL, para ser uma referência mais amplamente aplicável. Existem algumas perguntas semelhantes no DBA.SE, mas nenhuma que envolva o servidor incapaz de iniciar.)

Sempre presumi que os números de patch mais altos eram necessariamente lançamentos posteriores, mas agora não tenho tanta certeza.

Observando a lista de compilação do SQL Server para SQL Server 2008 R2 SP3, há duas maneiras possíveis de aplicar a atualização de segurança MS15-058, uma rotulada como "GDR" e outra rotulada como "QFE".

Qual é a diferença entre estes?

De acordo com esta entrada do blog , o GDR (versão de distribuição geral) é o que todos devemos instalar, e os QFEs são os lançamentos "somente se você tiver esse problema específico" ou algo assim?

Se eu não precisar de suporte TLS1.2, devo aplicar o patch 10.50.6220? Ou o patch 10.50.6529?

Existe alguma maneira de recuperar um banco de dados SQL do modo Standby/Read-Only se o "arquivo standby" estiver faltando?

(Vejo algumas referências chamando isso de arquivo TUF em um cenário de envio de logs, mas, no meu caso, foi apenas uma restauração manual e o arquivo de espera tinha uma extensão BAK.)

Fazer um "RESTORE DATABASE foo WITH RECOVERY" resulta em um erro fatal:

During startup of warm standby database 'foo', its standby file
('path\filename.bak') was inaccessible to the RESTORE statement.
The operating system error was '5(Access is denied.)'. Diagnose the
operating system error, correct the problem, and retry startup.

A restauração foi feita há algum tempo e, infelizmente, o arquivo em espera estava na pasta de backup e foi removido por nossa rotina de limpeza de pasta. Nenhuma cópia do arquivo existe em nenhuma outra mídia. Os backups originais que foram usados ​​para restaurar até este ponto também já se foram.

Felizmente, isso não é grande coisa para nós (foi uma restauração temporária), mas não consegui encontrar nenhuma outra referência útil sobre essa questão, além de "não remova esse arquivo".

Se fosse necessário, suponho que poderia fazer o script de todo o banco de dados ou usar o SSIS para copiar todos os objetos para um novo contêiner de banco de dados, já que tenho uma cópia somente leitura do banco de dados à minha frente.

Alguma maneira de corrigir esse problema? Certamente não espero ser capaz de voltar a "restaurar" e continuar fazendo restaurações subsequentes ou qualquer coisa, gostaria apenas de forçá-lo ao modo online normal em seu estado atual, para que eu possa fazer coisas como alterar permissões ou alterar o modo de recuperação ou fazer um novo backup completo ou algo assim.

Atualmente usamos planos de manutenção padrão para backups nos servidores SQL Server 2005/2008/2008R2/2012 em nosso ambiente, e a caixa "Verificar integridade do backup" sempre foi marcada.

Alguns dos backups são muito demorados, por isso recomendei desativar essa opção, mas o gerenciamento precisa que eu documente o impacto e os riscos dessa alteração.

Entendo o uso e o histórico dessa opção, apenas me parece desnecessário dobrar o tempo para a tarefa de backup quando (na minha opinião) qualquer erro que possa ocorrer ocorreria durante a etapa de backup , não durante a verificação.

Estou errado? É um risco mínimo desligar isso, se eu estiver fazendo backup em disco e não em fita de streaming ou algo assim? (Fazemos backup pela rede para um dispositivo de backup EMC DD-800, se for relevante.)

Existe alguma recomendação oficial da MS para quando é seguro desligar isso?

Você executa "verificar" em cada backup em seu ambiente? Você os verifica?

EDIT : Para esclarecer, quando você verifica "verificar a integridade do backup" no plano de manutenção, o SQL fará uma RESTORE VERIFYONLY completa em cada banco de dados imediatamente após cada backup. Isso é tão intensivo em dados/IO quanto o backup original e (basicamente) dobra o tempo total da tarefa de backup. Isso não é o mesmo que habilitar a opção "soma de verificação" no backup (o que não pode ser feito no assistente, até onde eu sei).

Eu me sinto meio envergonhado aqui, sempre usei os termos "coluna" e "campo" de forma completamente intercambiável, o que recentemente causou alguma confusão em uma discussão técnica.

Foi-me dito, no entanto, que isso não estava correto, que deveria ser (traduzindo cada termo em terminologia de planilha, ignorando tipos de dados e todas as outras coisas que tornam os bancos de dados úteis):

• Coluna de banco de dados: como uma coluna de planilha
• Registro de banco de dados: como uma linha de planilha
• Campo de banco de dados: como uma "célula" de planilha (uma coluna específica de uma linha específica)

Isto está certo? Eu poderia jurar que coluna e campo são usados ​​de forma mais intercambiável do que isso. Eu certamente fui.

Então não adicionamos campos a uma tabela, adicionamos colunas a uma tabela, e os campos só são relevantes quando falamos de dados dentro de um registro?

Outros pensamentos sobre coluna vs campo?

Edit: para esclarecer, o contexto atual é o MS SQL Server. Meu histórico antes do SQL Server era o MS Access, o que pode influenciar no uso desses termos.

Estou trabalhando na implementação do método de Paul Randal de espalhar manualmente o DBCC CHECKDB por vários dias para bancos de dados muito grandes, que consiste basicamente em:

• Dividindo as tabelas no banco de dados aproximadamente igualmente entre 7 baldes
• Executando um DBCC CHECKALLOC duas vezes por semana
• Executando um DBCC CHECKCATALOG uma vez por semana
• Executando um DBCC CHECKTABLE em um balde a cada dia da semana

Alguém já usou essa técnica? Algum script existente por aí?

Estou preocupado que isso não cubra realmente tudo o que CHECKDB faz; a documentação do Books Online para CHECKDB diz que além de CHECKALLOC, CHECKCATALOG e CHECKTABLE, também:

• Valida o conteúdo de cada exibição indexada no banco de dados.
• Valida a consistência no nível do link entre os metadados da tabela e os diretórios e arquivos do sistema de arquivos ao armazenar dados varbinary(max) no sistema de arquivos usando FILESTREAM. (somente SQL 2008)
• Valida os dados do Service Broker no banco de dados.

Então, aqui estão as minhas questões:

1. Essas verificações adicionais são necessárias/importantes? (As exibições indexadas provavelmente são um pouco mais preocupantes para mim, acho que ainda não estamos usando o Service Broker ou o FILESTREAM.)

2. Em caso afirmativo, existem maneiras de realizar essas verificações adicionais separadamente?

3. CHECKALLOC e CHECKCATALOG parecem rodar muito rapidamente, mesmo em dbs grandes. Algum motivo para não executá-los todos os dias?

(Observação: esta será uma rotina padrão para milhares de bancos de dados existentes em centenas de servidores, ou pelo menos todos os bancos de dados de um determinado tamanho. Isso significa que opções como reestruturar todos os bancos de dados para usar CHECKFILEGROUP não são realmente práticas para nós.)

Estou tentando obter uma lista de trabalhos e sua etapa concluída mais recentemente do banco de dados MSDB. Para um único trabalho, isso é bastante direto, algo como:

 SELECT TOP 1 j.job_id, j.name, h.step_name, h.run_date, h.run_time, h.step_id
 FROM msdb.dbo.sysjobs j
 INNER JOIN msdb.dbo.sysjobhistory h ON j.job_id = h.job_id
 WHERE j.name = 'my favorite job'
 ORDER BY h.run_date DESC, h.run_time DESC, h.step_id DESC

Mas como posso obter uma lista de TODOS os trabalhos e sua etapa concluída mais recentemente?

Observe que este é SQL 2000, então não posso usar PARTITION OVER. Também não consigo fazer um SELECT MAX() porque não é um único campo RunDateTime, tenho que classificar de forma descendente por dois campos (OrderDay, OrderTime).

Edit: Provavelmente não é possível, mas eu adoraria poder fazer algo como:

SELECT j.job_id, ...
FROM msdb.dbo.sysjobs j
INNER JOIN (SELECT TOP 1 step_name, run_date, run_time, step_id
            FROM msdb.dbo.sysjobhistory
            WHERE job_id = j.job_id
            ORDER BY run_date desc, run_time desc, step_id desc) as H

ou algo assim, mas não parece gostar de sintaxe assim...

Eu tenho um banco de dados SQL 2008 de 50 GB (apenas 36 são dados) com um cubo do Analysis Server de 24 GB que é reconstruído todas as noites.

As reconstruções do cubo têm usado cada vez mais TempDB no servidor SQL todas as noites. Ontem à noite, os arquivos de dados TempDB cresceram para cerca de 100 GB antes de usar todo o espaço na unidade TempDB.

Posso adicionar mais espaço, mas me sentiria melhor se entendesse mais sobre o que está acontecendo aqui:

• Como/por que as reconstruções do cubo usam o espaço TempDB no servidor SQL?
• Existe alguma maneira de reduzir a quantidade de TempDB que ele usa ou forçá-lo a "liberar" o tempdb entre as etapas ou algo assim?
• Existe alguma maneira de estimar a quantidade de espaço que pode continuar a usar à medida que meus dados continuam a crescer? (com base no tamanho de certas tabelas-chave em meu banco de dados ou algo assim?)

Edit : A única diferença significativa neste banco de dados em particular que posso pensar é que eles usam algumas exibições aninhadas muito grandes e complicadas para o conjunto de dados final. Se essas visualizações complexas são as que estão sendo usadas para construir o cubo, isso poderia explicar o alto uso do tempDB?