Tim Schmelter's questions

Eu tenho que manter e estender um sistema legado antigo que contém métodos de webservice e tabelas de banco de dados que não são mais usados. Como não tenho certeza absoluta de que as tabelas são realmente redundantes, tenho medo de abandoná-las.

Existe alguma outra maneira de obter o mesmo efeito (as tabelas não podem mais ser usadas) sem soltá-las? Minha ideia era transferi-los para um esquema diferente (por exemplo, Deleted) do padrão atual, dbo.

IF NOT EXISTS (SELECT * FROM sys.schemas WHERE name = 'Deleted')
BEGIN
   EXEC('CREATE SCHEMA Deleted')
END

ALTER SCHEMA Deleted TRANSFER dbo.TableName;

Existe alguma outra opção ou há alguma desvantagem na abordagem do esquema?

Como o MSDN não diz muito, o que acontece exatamente se eu executar a seguinte consulta?

update claims set status='Awaiting Auth.'
where status = 'Approved' 

Posso usar a ClaimStatusNamecoluna da tabela vinculada dimClaimStatuspara atualizar a tabela principal referenciada por chave estrangeira?

A visualização em si consulta várias tabelas, a tabela principal é tabData, que também desejo atualizar com a consulta acima. Eu quero mudar fiClaimStatusdo tabDataFK que significa Approved na tabela referenciada dimClaimStatuspara Awaiting Auth.. Funciona assim?

Apenas uma linha de exibição é possível para cada linha em tabData.

Aqui está a vista:

CREATE VIEW [dbo].[Claims] 
AS 
  SELECT mu.MarketUnitName AS MarketUnit, 
         c.CountryName     AS Country, 
         gsp.GSPName       AS GSP, 
         gsp.WCMSKeyNumber AS GspNumber, 
         sl.SLName         AS SL, 
         sl.WCMSKeyNumber  AS SlNumber, 
         m.ModelName       AS Model, 
         m.SalesName       AS [Model-Salesname], 
         s.ClaimStatusName AS [Status], 
         d.Work_Order      AS [Work Order], 
         d.SSN_Number      AS IMEI, 
         .... more columns ....
         idData,         -- PK of main table tabData
         fiSL, 
         fiModel, 
         fiClaimStatus  -- FK to dimClaimStatus
  FROM   tabData AS d 
         INNER JOIN locSL AS sl 
                 ON d.fiSL = sl.idSL 
         INNER JOIN locGSP AS gsp 
                 ON sl.fiGSP = gsp.idGSP 
         INNER JOIN locCountry AS c 
                 ON gsp.fiCountry = c.idCountry 
         INNER JOIN locMarketUnit AS mu 
                 ON c.fiMarketUnit = mu.idMarketUnit 
         INNER JOIN modModel AS m 
                 ON d.fiModel = m.idModel 
         INNER JOIN dimClaimStatus AS s 
                 ON d.fiClaimStatus = s.idClaimStatus 
         INNER JOIN tdefProductType 
                 ON d.fiProductType = tdefProductType.idProductType 
         LEFT OUTER JOIN tdefServiceLevel 
                      ON d.fimaxServiceLevel = tdefServiceLevel.idServiceLevel 
         LEFT OUTER JOIN tdefActionCode AS ac 
                      ON d.fimaxActionCode = ac.idActionCode 

Atualizar

Como a tabela contém 20 milhões de registros de clientes, queria saber primeiro o que vai acontecer antes de executá-la. Após os comentários e respostas, eu o executei agora. O resultado imediato foi:

(1 row(s) affected)

O que é surpreendente, porque havia vários milhares de registros neste status que parecem estar atualizados agora.

Atualização 2

Na verdade não funcionou como esperado e o suspeito (1 row(s) affected)estava certo. Apenas a tabela referenciada foi atualizada. Então agora o status Approvedmudou para Awaiting Auth..

Conclusão:

Parece ser a melhor maneira de evitar o uso de uma exibição para fazer atualizações. Isso funciona no meu caso:

UPDATE tabData 
SET fiClaimStatus = (SELECT idClaimStatus
                     FROM dimClaimStatus
                     WHERE ClaimStatusName = 'Awaiting auth.')
WHERE fiClaimStatus=(SELECT idClaimStatus
                     FROM dimClaimStatus
                     WHERE ClaimStatusName = 'Approved')

Eu queria saber qual das duas abordagens a seguir é mais rápida:

1) Três COUNT:

 SELECT Approved = (SELECT COUNT(*) FROM dbo.Claims d
                  WHERE d.Status = 'Approved'),
        Valid    = (SELECT COUNT(*) FROM dbo.Claims d
                    WHERE d.Status = 'Valid'),
        Reject   = (SELECT COUNT(*) FROM dbo.Claims d
                    WHERE d.Status = 'Reject')

2) SUMcom FROMcláusula -:

SELECT  Approved = SUM(CASE WHEN Status = 'Approved' THEN 1 ELSE 0 END),
        Valid    = SUM(CASE WHEN Status = 'Valid'    THEN 1 ELSE 0 END),
        Reject   = SUM(CASE WHEN Status = 'Reject'   THEN 1 ELSE 0 END)
FROM dbo.Claims c;

Fiquei surpreso que a diferença é tão grande. A primeira consulta com três subconsultas retorna o resultado imediatamente, enquanto a segunda SUMabordagem precisa de 18 segundos.

Claimsé uma exibição que seleciona de uma tabela contendo aproximadamente 18 milhões de linhas. Há um índice na coluna FK para a ClaimStatustabela que contém o nome do status.

Por que faz uma diferença tão grande se eu uso COUNTou SUM?

Planos de execução:

• COUNT
• SUM

Existem 12 status no total. Esses três status pertencem a 7% de todas as linhas.

Esta é a visão real, não tenho certeza se é relevante:

CREATE VIEW [dbo].[Claims]
AS
SELECT 
   mu.Marketunitname AS MarketUnit, 
   c.Countryname     AS Country, 
   gsp.Gspname       AS GSP, 
   gsp.Wcmskeynumber AS GspNumber, 
   sl.Slname         AS SL, 
   sl.Wcmskeynumber  AS SlNumber, 
   m.Modelname       AS Model, 
   m.Salesname       AS [Model-Salesname], 
   s.Claimstatusname AS [Status], 
   d.Work_order      AS [Work Order], 
   d.Ssn_number      AS IMEI, 
   d.Ssn_out, 
   Remarks, 
   d.Claimnumber     AS [Claim-Number], 
   d.Rma_number      AS [RMA-Number], 
   dbo.ToShortDateString(d.Received_Date, 1) AS [Received Date], 
   Iddata, 
   Fisl, 
   Fimodel, 
   Ficlaimstatus 
FROM Tabdata AS d 
   INNER JOIN Locsl AS sl 
           ON d.Fisl = sl.Idsl 
   INNER JOIN Locgsp AS gsp 
           ON sl.Figsp = gsp.Idgsp 
   INNER JOIN Loccountry AS c 
           ON gsp.Ficountry = c.Idcountry 
   INNER JOIN Locmarketunit AS mu 
           ON c.Fimarketunit = mu.Idmarketunit 
   INNER JOIN Modmodel AS m 
           ON d.Fimodel = m.Idmodel 
   INNER JOIN Dimclaimstatus AS s 
           ON d.Ficlaimstatus = s.Idclaimstatus 
   INNER JOIN Tdefproducttype 
           ON d.Fiproducttype = Tdefproducttype.Idproducttype 
   LEFT OUTER JOIN Tdefservicelevel 
                ON d.Fimaxservicelevel = Tdefservicelevel.Idservicelevel 
   LEFT OUTER JOIN Tdefactioncode AS ac 
                ON d.Fimaxactioncode = ac.Idactioncode 

Estou tentando vincular meu SQL-Server 2005 no Windows Server 2008 R2 com o MySQL 5.5.40 em um computador diferente. Eu segui este guia:

http://www.ideaexcursion.com/2009/02/25/howto-setup-sql-server-linked-server-to-mysql/

No entanto, quando tento testar a conexão em "Servidores vinculados", como você pode ver nesta captura de tela:

estou recebendo este erro:

A fonte de dados ODBC foi adicionada conforme mostrado no link acima, como você pode ver aqui:

Qual pode ser a razão para isso? Observe que o Server2008 é um sistema operacional de 64 bits, se isso for importante.

Preciso de ajuda para identificar o motivo de um problema de desempenho.

Na verdade, a consulta a seguir fica em uma função de valor escalar, mas esse não é o motivo do problema, pois precisa do mesmo tempo que a consulta:

SELECT TOP (1) dd.gsp_part_price 
FROM  tabdata 
       INNER JOIN locsl 
               ON tabdata.fisl = locsl.idsl 
       INNER JOIN locgsp 
               ON locsl.figsp = locgsp.idgsp 
       INNER JOIN tabdatadetail dd
               ON dd.fidata = tabdata.iddata 
       INNER JOIN tabsparepart sp 
               ON dd.fisparepart = sp.idsparepart 
WHERE  sp.sparepartname = '1270-3132' 
       AND dd.gsp_part_price IS NOT NULL 
ORDER BY Claim_Submitted_Date DESC 

Esta consulta retorna o preço imediatamente para a maioria das peças sobressalentes, mas algumas peças precisam de vários minutos para serem devolvidas NULL. Portanto, esta consulta retorna 940 linhas imediatamente para a mesma parte acima, onde cada gsp_part_priceé NULLo motivo do NULLacima:

SELECT dd.*, sp.* 
FROM tabdatadetail dd 
INNER JOIN tabsparepart sp 
    on dd.fisparepart=sp.idsparepart
WHERE sp.sparepartname='1270-3132' 

Por que a primeira consulta precisa de 3 minutos para retornar NULLenquanto a consulta abaixo retorna imediatamente as 940 linhas? Devo admitir que ainda tenho problemas para interpretar os planos de execução.

Observe que a primeira consulta também retorna imediatamente se eu remover o IS NOT NULL CHECK:

dd.gsp_part_price IS NOT NULL 

Todas as tabelas envolvidas estão vinculadas por meio de chaves estrangeiras, tentei adicionar um índice no gsp_part_pricequal não teve efeito.

Aqui está o plano de execução da consulta:

EdittabData : Aqui estão as estatísticas nos índices PK e FK (para a tabela pai ):

DBCC SHOW_STATISTICS('dbo.tabDataDetail','PK_tabDataDetail') WITH STAT_HEADER;
PK_tabDataDetail    Nov  6 2013 10:04AM 64327191    387089  183 1   8   NO 

DBCC SHOW_STATISTICS('dbo.tabDataDetail','IX_fiData') WITH STAT_HEADER;
IX_fiData   Nov  6 2013 10:04AM 64327191    378150  198 0,2441889   4   NO 

DBCC SHOW_STATISTICS('dbo.tabDataDetail','IX_GspPartPrice') WITH STAT_HEADER;
IX_GspPartPrice Dez  3 2013 12:17PM 64788799    64788799    200 0,0002433512    7,065503    NO 

O último índice foi adicionado agora, conforme mencionado acima. Portanto, as linhas reais são 64788799, por que a grande diferença entre as linhas estimadas e reais, também, por que há uma diferença entre as linhas reais do plano de consulta e as linhas reais "reais"?

Aqui está o plano completo: http://s000.tinyupload.com/index.php?file_id=86912774678831839436

Editar : do comentário de Mikael Eriksson:

Eu acho que o seu top(1)e order byé o culpado aqui. A varredura de índice está usando o índice Claim_Submitted_Datepara localizar a primeira ocorrência de um valor o mais rápido possível. O SQL Server acredita que você encontrará esse valor após verificar 3.000 linhas. Talvez essa estimativa faça sentido se você tiver 5.000 linhas tabSpareParte quiser apenas uma. O problema é que, se não houver linhas encontradas ou se você tiver uma peça sobressalente que foi enviada recentemente, o SQL Server terá que verificar todo o índice antes de descobrir que não há linhas a serem encontradas.

Embora eu ainda não entenda o porquê, parece que isso é verdade. Se eu remover TOP 1ou alterar para dizer que TOP 1000o resultado vem imediatamente. Alguém tem alguma ideia do que posso fazer? Porque, se várias linhas forem retornadas, só preciso do último preço enviado.

Eu só queria saber se há uma diferença no custo (memória, cpu) de um EXISTSou NOT EXISTSnas seguintes consultas. Faz diferença se eu selecionar ou colunas NULL?1

1)

SELECT id 
FROM Parent p
WHERE NOT EXISTS
(
   SELECT NULL FROM Child c
   WHERE c.parent_Id = p.id
   AND c.x <> c.y
)

2)

SELECT id 
FROM Parent p
WHERE NOT EXISTS
(
   SELECT 1 FROM Child c
   WHERE c.parent_Id = p.id
   AND c.x <> c.y
)

3)

SELECT id 
FROM Parent p
WHERE NOT EXISTS
(
   SELECT * FROM Child c
   WHERE c.parent_Id = p.id
   AND c.x <> c.y
)

A opção 1 é o que eu uso normalmente, há alguma diferença ou é otimizado para o mesmo?

Estou fazendo esta pergunta porque estou planejando reservar um seminário, mas o provedor me disse que eles oferecem apenas treinamentos para SSAS 2008 ou como treinamento individual que são caros.

Então, minha pergunta: valeria a pena reservar o seminário SSAS 2008, embora estejamos usando o SSAS 2005 ou as diferenças são muito grandes?

Não tenho certeza se devo perguntar isso no ServerFault ou aqui.

Periodicamente, o seguinte erro é registrado nos eventos administrativos do Windows Server 2008:

O certificado recebido do servidor remoto foi emitido por uma autoridade de certificação não confiável. Devido a isso, nenhum dos dados contidos no certificado pode ser validado. A solicitação de conexão SSL falhou. Os dados anexados contêm o certificado do servidor.

Log Name: System
Source: Schannel

Seguido por:

O seguinte alerta fatal foi gerado: 48. O estado de erro interno é 552.

Log Name: System
Source: Schannel

Se eu alterar a propriedade Force Encryptionna configuração do SQL-Server de "No" para "Yes" (veja a imagem abaixo), o erro não será mais registrado.

Mas eu realmente não preciso de criptografia SSL, pois todas as conexões são confiáveis ​​(da intranet) e as portas 1333 e 1334 são protegidas por firewall da Internet.

Seria um impacto no desempenho se eu forçasse a criptografia e gerasse um certificado de servidor, isso é recomendado na minha situação? Não quero impor a criptografia apenas para evitar alguns logs de eventos, se nem mesmo causar sérios problemas de conexão (onde posso ver qual conexão o causou?).

P: Alguém pode explicar por que esses erros são gerados e de onde ?

Esta é uma pergunta de acompanhamento de: https://stackoverflow.com/questions/7684477/is-it-possible-to-set-transaction-isolation-level-snapshot-automatically

Ainda estou tendo situações de impasse/tempo limite no aplicativo ASP.NET ao executar grandes relatórios simultaneamente, embora READ_COMMITTED_SNAPSHOT ON.

Então eu tenho duas perguntas:

1. Como posso verificar se o Instantâneo do Nível de Isolamento da Transação está funcionando conforme o esperado?
2. Estou assumindo que as chaves estrangeiras (nas tabelas da Web-Application para as tabelas-relatório) são as responsáveis ​​pelos deadlocks. Achei este artigo interessante :

Observação SQL Server adquire bloqueios compartilhados ao validar chaves estrangeiras, mesmo se a transação estiver usando instantâneo de leitura confirmada (leitura confirmada usando controle de versão de linha) ou nível de isolamento de instantâneo. Lembre-se disso ao examinar gráficos de deadlock de transações quando esses níveis de isolamento de transação são usados. Se você vir bloqueios compartilhados, verifique se os bloqueios são obtidos em um objeto referenciado por uma chave estrangeira.

Como posso verificar se o FK é realmente responsável pelas situações de Deadlock/Timeout, isso significa que eu poderia excluir essas chaves estrangeiras para evitar deadlocks (o que seria um esforço aceitável)?

Nota : Estou apenas lendo as tabelas que causam impasses.

Quaisquer pensamentos sobre este tópico são muito apreciados.

Editar Aqui está um Gráfico de Deadlock . Talvez alguém possa me ajudar a entender o que causa o impasse. Parece que ocorreu sem nenhum relatório em execução causado apenas pelo aplicativo da web, quando duas transações desejam gravar a mesma tabela (uma atualização e uma inserção, a inserção é como procedimento armazenado). Por que ele adquire bloqueios de página e como habilitar apenas os bloqueios de linha? A Insert-SP já usa TRANSACTION ISOLATION LEVEL REPEATABLE READ.

Tenho uma forte suspeita de que dois gatilhos (um update e um insert) são os responsáveis ​​pelos impasses. Aqui está o gatilho de inserção:

CREATE TRIGGER [dbo].[CreateRMAFiDates] 
   ON  [dbo].[RMA] 
   AFTER INSERT
AS 
BEGIN
    SET NOCOUNT ON;

    UPDATE RMA 
    SET [fiCreationDate]=(SELECT idDate FROM tdefDate 
        WHERE CONVERT(VARCHAR, INSERTED.Creation_Date, 112) = tdefDate.Text),
        [fiPopDate]=(SELECT idDate FROM tdefDate 
        WHERE CONVERT(VARCHAR, INSERTED.POP_Date, 112) = tdefDate.Text),
        [fiManufactureDate]=(SELECT idDate FROM tdefDate 
        WHERE CONVERT(VARCHAR, INSERTED.Manufacture_Date, 112) = tdefDate.Text)
    FROM INSERTED;
END

Portanto, esse gatilho atualiza a RMA-Table, o que faz com que o gatilho de atualização seja acionado (o que é semelhante). O gráfico de impasse confirma minha suposição? Acho que vou deletar esses gatilhos e criar um SP que está sendo executado uma vez por dia, o que seria perfeitamente suficiente, porque essas colunas são apenas para um SSAS-Cube (Molap).

Editar : A propósito, não houve mais impasse desde que excluí esses gatilhos :)