squillman's questions

Estou usando notificações de eventos para capturar dados e registrar eventos de crescimento automático de arquivos para todos os bancos de dados em meus servidores. Estou usando os dados para análise da configuração de armazenamento do banco de dados.

Ao observar os dados, notei que a duração média do crescimento do log de transações está bem acima de qualquer coisa que eu esperaria, o que me leva a pensar que estou interpretando mal os dados ou negligenciando algo relacionado ao funcionamento do autocrescimento do log de transações.

Este é um exemplo de um evento de crescimento de arquivo de log que foi capturado hoje:

<EVENT_INSTANCE>
  <EventType>LOG_FILE_AUTO_GROW</EventType>
  <PostTime>2013-08-29T11:14:26.447</PostTime>
  <SPID>97</SPID>
  <DatabaseID>32</DatabaseID>
  <NTDomainName />
  <HostName>[cleansed]</HostName>
  <ClientProcessID>4884</ClientProcessID>
  <ApplicationName>.Net SqlClient Data Provider</ApplicationName>
  <LoginName>[cleansed]</LoginName>
  <Duration>4173000</Duration>
  <StartTime>2013-08-29T11:14:22.263</StartTime>
  <EndTime>2013-08-29T11:14:26.437</EndTime>
  <IntegerData>64000</IntegerData>
  <ServerName>[cleansed]</ServerName>
  <DatabaseName>MyDB</DatabaseName>
  <FileName>MyDB_log</FileName>
  <LoginSid>[cleansed]</LoginSid>
  <EventSequence>14637017</EventSequence>
  <IsSystem />
  <SessionLoginName>[cleansed]</SessionLoginName>
</EVENT_INSTANCE>

Como a duração é relatada em milissegundos , estou lendo isso porque leva 69,54 minutos para aumentar o arquivo. O crescimento automático para este arquivo de log é definido como 512 MB (limitado a 2 TB)

SELECT
    growth AS GrowthPages,
    growth*8/1000 AS GrowthMB,
    max_size,
    is_percent_growth
FROM MyDB.sys.database_files
WHERE type=1

GrowthPages GrowthMB        max_size        is_percent_growth
64000       512             268435456       0

Todos os bancos de dados registram no mesmo volume que está conectado a uma SAN via canal de fibra. (Eu teria que entrar em contato com nosso administrador de SAN para obter mais detalhes sobre a configuração de armazenamento, se necessário).

A instância é SQL 2012 Enterprise, o servidor é Windows 2008 R2 Enterprise.

Por que levaria mais de uma hora para aumentar o log em 512 MB? Não estamos percebendo um atraso nas operações em nenhum desses bancos de dados (a menos que estejamos apenas ignorando). Há um punhado de outros bancos de dados com duração semelhante; suas configurações de crescimento automático são as mesmas. Outros bancos de dados com configurações de autocrescimento menores têm durações proporcionalmente menores.

Tenho uma tabela com uma PK e um índice único não clusterizado, conforme abaixo:

CREATE TABLE Table1
(
    Id INT IDENTITY(1,1) NOT NULL,
    Field1 VARCHAR(25) NOT NULL,
    Field2 VARCHAR(25) NULL,
 CONSTRAINT PK_Table1 PRIMARY KEY CLUSTERED (Id ASC)
)

CREATE UNIQUE NONCLUSTERED INDEX IX_Field1_Field2 ON Table1
(
    Field1 ASC,
    Field2 ASC
)
WITH
    (
        PAD_INDEX = OFF,
        STATISTICS_NORECOMPUTE = OFF,
        SORT_IN_TEMPDB = OFF,
        IGNORE_DUP_KEY = OFF,
        DROP_EXISTING = OFF,
        ONLINE = OFF,
        ALLOW_ROW_LOCKS = ON,
        ALLOW_PAGE_LOCKS = ON
    )

Eu tenho 2 trabalhos cujos tempos de execução eu acho que estão se sobrepondo. Ambos incluem o mesmo INSERTnesta tabela e frequentemente o trabalho que começa por último falha porque tenta inserir um registro Table1com um valor de chave de índice duplicado.

INSERT Table1
SELECT Field1, Field2
FROM SomeOtherTable sot WITH (NOLOCK)
WHERE NOT EXISTS (
    SELECT 1
    FROM Table1 t1
    WHERE sot.Field1 = t1.Field1
    AND sot.Field2 = t1.Field2
)

Pelo que pude discernir, o INSERTin Job1 ainda está em execução quando o NOT EXISTSfrom Job2 é avaliado, resultando em Job2 tentando inserir um valor de chave duplicado. Me parece que o locking Table1for não está acontecendo conforme o esperado.

Não sei por que isso está acontecendo. Isso teria algo a ver com a NOLOCKdica usada no INSERT? Não pensei que essa dica incluiria Table1em seu escopo, apenas arquivos SomeOtherTable.

Sei que posso atenuar o erro de chave duplicada definindo IGNORE_DUP_KEYpara ONo índice, e isso seria bom para nós nessa situação. Gostaria de saber, porém, por que a duplicata está aparecendo no 2º INSERT.

Digamos que eu tenha um procedimento armazenado como este (suponha que os esquemas da tabela estejam corretos):

CREATE PROCEDURE p_MyProc
AS

INSERT MyTable SELECT Col1 FROM Table1

INSERT MyTable SELECT Col2 FROM Table2

INSERT MyTable SELECT Col3 FROM Table3

Assumindo que acabam sendo grandes inserções que podem levar vários minutos cada, é possível determinar qual delas está sendo executada no contexto de um procedimento armazenado?

Eu sei como encontrar qual procedimento armazenado está em execução, estou apenas procurando ver se há uma maneira de obter mais granular sem ter que adicionar PRINT ou outras instruções de rastreamento lá. Existe talvez uma maneira de fazer as declarações aparecerem em um rastreamento?

Qual é a maneira segura de remover um endereço IP antigo da configuração do SQL Server?

O cenário é que eu tenho um servidor com 2 NICs que deveriam ter sido configurados para agrupamento, mas não estavam no momento em que o SQL foi instalado. Cada um tinha um IP diferente, então o SQL pegou isso e adicionou cada IP à sua configuração.

Os NICs agora estão agrupados e a caixa está reduzida a um único IP. Desejo retirar da configuração do SQL o IP que não está mais atribuído ao servidor. Não quero apenas desativá-lo, mas sim removê-lo completamente.

Existe uma maneira segura de fazer isso? Ou basta excluir as chaves HKLM\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL10_50.[Instance Name]\MSSQLServer\SuperSocketNetLib\Tcp\relacionadas ao IP em questão e reiniciar?

Estou tentando visualizar (graficamente) um grande plano de consulta que está no cache do plano e estou tendo problemas em que o XML é truncado nos resultados da consulta. Esta é a consulta que estou usando:

SELECT TOP 1
    size_in_bytes,
    query_plan
FROM sys.dm_exec_cached_plans cp
CROSS APPLY sys.dm_exec_query_plan(cp.plan_handle) qp
ORDER BY size_in_bytes DESC

Eu tentei no SSMS e quando clico no XML na grade de resultados, recebo o Unable to show XML. Unexpected end of file when parsing Name has occurred. Line 1, position 2097154.Se eu copiar e colar o XML, ele está realmente truncado.

Eu tentei manualmente usando SET TEXTSIZE 2147483647apenas porque, e isso não fez nada. (Eu sei que esse é o valor padrão para os provedores SQL Native Client, estava apenas tentando forçar o problema).

Tentei executar a instrução por meio SQLCMDde um arquivo .sql e enviar para um arquivo de texto, mas isso me dá ainda menos.

Eu tentei usar SQLCMDinterativamente, com :XML ONe recebi este erro:

<?MSSQLError HResult="0x80004005" Source="Microsoft XML Extensions to SQL Server" Description="No description provided"?>

O plano é de 157 MB.

Existe alguma maneira de obter o plano completo para que eu possa vê-lo?