Brad's questions

Tenho uma tabela que possui uma coluna NVARCHAR que contém dados que não podem ser convertidos para BIGINT. Estou bem ciente disso e filtrei usando ISNUMERIC(BB.NVARCHARCOL) = 1. Apesar disso, ainda recebo um erro ao tentar consultar os dados informando queError converting data type nvarchar to bigint.

O seguinte funciona bem (sem erros relatados pelo SQL):

SELECT *
FROM myNormalTable AA INNER JOIN myBadTable BB ON BB.NVARCHARCOL = AA.MYBIGINTCOL
WHERE ISNUMERIC(BB.NVARCHARCOL) = 1

O seguinte lança o erro:

SELECT *
FROM (
    SELECT *
    FROM myNormalTable AA INNER JOIN myBadTable BB ON BB.NVARCHARCOL = AA.MYBIGINTCOL
    WHERE ISNUMERIC(BB.NVARCHARCOL) = 1
    ) ZZ 
WHERE ZZ.MYBIGINTCOL = 1234

Essa variação também lança o erro:

SELECT *
FROM (
    SELECT *
    FROM myNormalTable AA INNER JOIN
        (SELECT CAST(NVARCHARCOL AS BIGINT) NVARCHARCOL FROM myBadTable WHERE ISNUMERIC(NVARCHARCOL) = 1) BB
      ON BB.NVARCHARCOL = AA.MYBIGINTCOL
    ) ZZ 
WHERE ZZ.MYBIGINTCOL = 1234

Tenha em mente que isso não dá erro e retorna todos os registros com sucesso...

SELECT CAST(NVARCHARCOL AS BIGINT) NVARCHARCOL FROM myBadTable WHERE ISNUMERIC(NVARCHARCOL) = 1

Consegui encontrar uma solução, que era converter meu BIGINT para NVARCHAR na subconsulta:

SELECT *
FROM (
    SELECT *
    FROM myNormalTable AA INNER JOIN myBadTable BB ON BB.NVARCHARCOL = CAST(AA.MYBIGINTCOL AS NVARCHAR)
    WHERE ISNUMERIC(BB.NVARCHARCOL) = 1
    ) ZZ 
WHERE ZZ.MYBIGINTCOL = 1234

Se eu inserir os registros em uma tabela temporária:

SELECT CAST(NVARCHARCOL AS BIGINT) NVARCHARCOL INTO #TEMP FROM myBadTable WHERE ISNUMERIC(NVARCHARCOL) = 1

Eu posso usar essa tabela temporária em uma subconsulta com sucesso:

SELECT *
FROM (
    SELECT *
    FROM myNormalTable AA INNER JOIN #TEMP BB ON BB.NVARCHARCOL = AA.MYBIGINTCOL
    WHERE ISNUMERIC(BB.NVARCHARCOL) = 1
    ) ZZ 
WHERE ZZ.MYBIGINTCOL = 1234

O que anda acontecendo no mundo? Parece que o SQL se recusa a usar a subconsulta para obter um conjunto de resultados menor antes de executar a consulta externa, ele quer usar a tabela inteira, independentemente do que eu fizer. SQL Server 2012 Developer Edition

Estou extremamente frustrado. Estou usando o SQL Server Data Tools 2015. Tenho um projeto do Integration Services e quero implantar um único pacote dessa solução no SQL Server 2012. Configurei a solução como Deployment Target Server Version para SQL 2012. Clico com o botão direito no pacote e selecione Deploy, no entanto, na parte Select Destination do assistente, ele só me permite selecionar um nome de servidor (e não inserir nenhuma credencial). No entanto, preciso inserir um nome de usuário e senha específicos, pois minha conta de domínio não é um login válido.

Entendo que esse assistente eventualmente executará isdeploymentwizard.exe e também examinei os parâmetros e não vejo uma maneira de inserir nenhuma informação de conexão fora de um nome de servidor.

Como posso implantar este pacote no servidor usando um nome de usuário e senha em vez de uma conta confiável? Sinto que devo estar perdendo algo incrivelmente estúpido, porque não consegui encontrar alguém com um problema semelhante, mesmo depois de pesquisar no Google por uma hora. Aparentemente, todos que estão implantando no SQL Server do SSDT2015 estão usando uma conta confiável.

Editar: Em versões mais antigas do BIDS, você pode abrir o projeto e selecionar Arquivo > Salvar cópia de .dtsx e salvá-lo no servidor SQL e usar as credenciais. No entanto, no SSDT, a opção Salvar cópia de apenas permite que você salve o pacote localmente.

Temos alguns processos de carregamento de dados que são executados durante todo o dia. Esses processos estão ativando o sinalizador 610 para sua conexão e, em seguida, desativando-o quando terminarem. Como essas mensagens são colocadas no ERROR LOG, nosso ERROR LOG está crescendo bastante. Tentamos usar o parâmetro WITH NO_INFOMSGS do DBCC, mas ele ainda coloca a entrada no ERROR LOG (mesmo que não a coloque na saída da consulta).

Alguma ideia?

As mensagens ficam assim:

Data 23/10/2014 08:32:46 Log SQL Server (atual - 23/10/2014 08:31:00)

Fonte spid57

Mensagem DBCC TRACEON 610, ID do processo do servidor (SPID) 57. Esta é apenas uma mensagem informativa; Não é necessária nenhuma ação do usuário.

...

Data 23/10/2014 08:32:54 Log SQL Server (atual - 23/10/2014 08:31:00)

Fonte spid57

Mensagem DBCC TRACEOFF 610, ID do processo do servidor (SPID) 57. Esta é apenas uma mensagem informativa; Não é necessária nenhuma ação do usuário.

Sei que deve haver uma resposta simples para essa pergunta, mas não consigo encontrá-la em lugar nenhum. Nosso SQL 2012 FCI possui arquivos SQLDIAG .XEL em sua pasta MSSQL\LOG. Em alguns casos, esses arquivos geralmente têm exatamente 100 MB, mas quando abertos no SSMS parecem estar vazios (diz exibindo 0 eventos).

Preciso saber como gerenciar o tamanho máximo e a retenção de arquivos, se isso for possível.

Temos alguns pontos de montagem da unidade raiz que eram do SQL 2008 FCI (atualizado para SQL 2012) e esses pontos de montagem tinham apenas 1 GB. Como você pode imaginar, esses pontos de montagem estão se esgotando e preciso limitar esses logs de diagnóstico de cluster de failover, se possível, ou terei que encontrar uma solução alternativa.

O uso de WITH REPLACE quando os nomes de arquivos lógicos correspondem (para evitar o uso de WITH MOVE) falha quando o backup é de uma versão diferente do SQL? Eu tenho um backup do SQL 2008, mas quando tentei restaurá-lo usando WITH REPLACE em uma pasta do SQL 2012, apesar dos nomes de arquivos lógicos correspondentes no backup do banco de dados e no banco de dados que estou substituindo, está falhando, dando-me o erro de 'pesquisa de diretório' .

Eu tenho uma tabela heap com cerca de 700k linhas. O tamanho da linha é de 34 bytes: (1x BIGINT, 2x SMALLINT, 2x BIT, 4X INT, 1x SMALLDATETIME). Por que o Data Space Used diz que esta tabela está ocupando quase 4000000 KB (4 GB) em Object Explorer Details. Ele é compactado com compactação PAGE.

Sei que devo estar perdendo algo neste cálculo porque tenho outra tabela de heap com 12,7 milhões de linhas que ocupa apenas 1,5 GB e tem um tamanho de linha de 356 bytes. Ele também é compactado com compactação PAGE.

EDIT: acabei de fazer um SELECT * INTO para ver qual seria o tamanho desses dados em outra tabela e são apenas 28MB...

Ou você precisa atualizar cada FCI no cluster de failover? A documentação não parece ser clara.

Temos 7 instâncias em um cluster de 3 nós. Queremos atualizar apenas uma das instâncias do SQL Server 2008 para o SQL Server 2012. Podemos realizar uma atualização ou precisamos fazer o backup da instância da melhor maneira possível, desinstalá-la, instalar o SQL Server 2012 e adicioná-la novamente?

Eu sei que você pode executar o SQL Server 2008 e o SQL Server 2012 no mesmo cluster de failover...

A instalação faz parecer que você pode atualizar uma única instância, mas ainda estou apreensivo, pois não testamos e nenhuma documentação parece afirmar explicitamente que é possível.

Estou realmente tendo problemas para rastrear alguns bloqueios que estamos enfrentando.

O status do SPID de bloqueio de root é 'dormindo', o cmd é 'AWAITING COMMAND' e o sqltexté SET TRANSACTION ISOLATION LEVEL READ COMMITTED.

Quando visualizo o relatório Top Transactions by Blocked Transactions Count, a instrução SQL de bloqueio é '--'.

Já realizei um rastreamento no SQL e quando o bloqueio acontece rastreando o SPID de bloqueio de root mas não me levou a lugar nenhum. A última instrução trace é a mesma que a sqltextanterior SET TRANSACTION ISOLATION LEVEL READ COMMITTED.

Verifiquei todos os procedimentos armazenados relacionados que posso encontrar para garantir que eles tenham instruções TRY/CATCH BEGIN TRAN/COMMIT TRAN/ROLLBACK TRAN (usamos procedimentos armazenados para tudo, para que não haja instruções independentes sendo executadas). Esse problema começou a acontecer nas últimas 24 horas e ninguém está alegando ter feito alterações no sistema.

Solução: um de nossos procedimentos armazenados raramente usados ​​teve um erro com uma inserção (o número de colunas não correspondeu), mas ainda estamos confusos sobre o que exatamente estava acontecendo.

Ao examinar todas as informações de rastreamento, a instrução EXEC para esse procedimento armazenado foi listada às vezes, mas NUNCA imediatamente antes do BLOCK acontecer no SPID de bloqueio. Parecia que ao iniciar o bloqueio, o rastreamento não registrava a execução dele (ou qualquer uma das instruções dentro dele). No entanto, há outras vezes em que o rastreamento registrou sua execução e nenhum bloqueio ocorreu.

O relatório de erro do procedimento armazenado veio de um usuário e consegui encontrar várias instruções EXEC em rastreamentos e executá-las no SSMS. Em nenhum momento, quando eu os executei, tivemos algum bloqueio ou eles travaram. Eles foram executados conforme o esperado (o bloco catch foi acionado e reverteu a transação após o erro). Depois de resolver a correção do procedimento armazenado, não vimos o problema novamente.

Eu tenho um pacote SSIS simples que carrega um arquivo fictício que contém 100.000 linhas. Cada linha tem cerca de 4k de comprimento, uma coluna int e uma coluna de texto longo. Estou tentando testar o TF610 ao carregar esses dados em uma tabela com um índice clusterizado.

No meu pacote SSIS, meu fluxo de controle tem uma tarefa Executar SQL para habilitar o TF610 e, em caso de sucesso, vá para minha tarefa de fluxo de dados que carrega o arquivo simples na tabela. Ambos os Destinos Executar SQL e OLE DB usam a mesma Conexão.

Se eu iniciar um perfil durante a execução do pacote SSIS e observar os comandos, posso ver DBCC TRACEON(610) executado e as operações INSERT BULK começam a ser disparadas. Ambos estão usando o mesmo PID, então estou assumindo que é a mesma sessão.

Porém, quando verifico o comprimento do registro de log, a inserção NÃO está sendo minimamente registrada.

Se eu habilitar o TF610 globalmente e executar o mesmo pacote SSIS, embora a transação seja minimamente registrada.

Devo estar fazendo algo errado ao ligar o TF610 no meu pacote SSIS mas não consigo descobrir o que...

Estou tentando configurar um cenário de recuperação de desastre e estou preso neste ponto específico. Aqui está o que eu fiz até agora:

A) Banco de dados principal criado no Servidor A e espelho no Servidor B

B) Configure o banco de dados de distribuição no servidor C e modifique os perfis do agente com –PublisherFailoverPartner para o servidor B.

C) Criou dois editores de replicação no principal.

D) Configure um assinante no Servidor D para as duas assinaturas.

E) Verifiquei que meu assinante estava recebendo atualizações.

Neste ponto, desligo o Servidor A que hospeda meu banco de dados principal. Em seguida, executei ALTER DATABASE SET PARTNER FORCE_SERVICE_ALLOW_DATA_LOSS no servidor B para obter meu banco de dados espelho online. Com o antigo servidor principal A ainda offline, modifiquei um registro em uma tabela publicada. A alteração nunca chegou ao Servidor D, meu assinante.

Eu verifiquei o monitor de replicação e não mostra erros. Mas no Histórico do Editor para Distribuidor está escrito 'As transações replicadas estão esperando pelo próximo backup de log ou pelo parceiro de espelhamento para alcançá-las.'

Entendo que, quando executei o FORCE_SERVICE_ALLOW_DATA_LOSS, meu espelho tornou-se meu principal e meu antigo principal tornou-se o espelho (que será sincronizado com meu novo principal quando colocado online).

O que eu gostaria que acontecesse é a função de replicação normal, mesmo quando o Servidor A está inoperante. Então, quando ele voltar, desligue o Servidor B e execute novamente o comando FORCE_SERVICE_ALLOW_DATA_LOSS no Servidor A e tenha meu servidor principal original de volta sem muito trabalho.

Isso é possível? Alguém tem algum conselho além de remover o espelhamento de banco de dados após o failover inicial (para fazer a replicação funcionar)? Alguma solução alternativa? O que acontece quando o Servidor A volta a ficar online (independentemente de o espelhamento ter sido mantido intacto) em relação à opção –PublisherFailoverPartner. A replicação volta automaticamente para o Servidor A?

Tenho usuários de AD ID em um servidor SQL 2008 que não pode editar seus próprios trabalhos. Eles podem criá-los, mas para editá-los, eles devem excluí-los e adicioná-los novamente. O problema é explicado aqui: Link

Pesquisei mais e descobri que, no meu caso particular, é porque adicionei usuários AD ID usando a sintaxe CREATE LOGIN [domínio\usuário]. Usando esse método, o caso do ID do AD é o que você especifica entre colchetes.

Existe alguma maneira de criar usuários com os casos corretos de ID do AD do Windows para que eu não precise descobrir e modificar os logins para cada usuário de ID do AD?

Além disso, eu estava usando este script para obter a capitalização correta para um usuário específico:

execute as login = 'usa\johndoe'
SELECT SUSER_SNAME()
revert;

Mas estava retornando tudo em minúsculas para mim, mas tudo em maiúsculas quando pedi ao usuário para executar SELECT SUSER_SNAME() e me dar o resultado. O correto é todo maiúsculo (bem, para que o usuário possa editar trabalhos).

Estou perdida e muito frustrada.

-- Descobri que a melhor (única?) maneira de obter o caso correto é usar a interface SQL para adicionar um usuário, clicar em pesquisar, digitar o ID do AD e clicar em verificar nomes. Para o exemplo acima, ele retorna tudo em maiúsculas, apesar desse exemplo de script retornar tudo em minúsculas.