swasheck's questions

Eu esperava obter uma visão granular de quais arquivos de banco de dados continham quais unidades de alocação para os vários HoBTs (alinhados e não alinhados) que viviam em um banco de dados.

A consulta que sempre usei (veja abaixo) me serviu bem até começarmos a criar vários arquivos de dados por grupo de arquivos e só consigo descobrir como obter o nível granular do grupo de arquivos.

select 
    SchemaName = sh.name, 
    TableName = t.name, 
    IndexName = i.name, 
    PartitionNumber = p.partition_number,
    IndexID = i.index_id,
    IndexDataspaceID = i.data_space_id,
    AllocUnitDataspaceID = au.data_space_id,
    PartitionRows = p.rows
from sys.allocation_units au
join sys.partitions p
    on au.container_id = p.partition_id
join sys.indexes i 
    on i.object_id = p.object_id
    and i.index_id = p.index_id
join sys.tables t 
    on p.object_id = t.object_id
join sys.schemas sh
    on t.schema_id = sh.schema_id
where sh.name != 'sys'
    and au.type = 2
union all 
select 
    sh.name, 
    t.name, 
    i.name, 
    p.partition_number,
    i.index_id,
    i.data_space_id,
    au.data_space_id,
    p.rows
from sys.allocation_units au
join sys.partitions p
    on au.container_id = p.hobt_id
join sys.indexes i 
    on i.object_id = p.object_id
    and i.index_id = p.index_id
join sys.tables t 
    on p.object_id = t.object_id
join sys.schemas sh
    on t.schema_id = sh.schema_id
where sh.name != 'sys'
    and au.type in (1,3)
order by t.name, i.index_id,p.partition_number;

No entanto, essa consulta não funcionará quando houver vários arquivos em um grupo de arquivos, pois só consigo relacionar uma unidade de alocação a um espaço de dados e, por fim, a um grupo de arquivos. Gostaria de saber se há outro DMV ou catálogo que estou perdendo e que posso usar para identificar melhor qual arquivo no grupo de arquivos contém uma unidade de alocação.

A questão por trás dessa questão é que estou tentando avaliar os efeitos reais da compactação de estruturas particionadas. Eu sei que posso fazer um antes e depois usando FILEPROPERTY(FileName,'SpaceUsed')para o arquivo e um antes e depois sys.allocation_units.used_pages/128.para obter essas informações, mas o próprio exercício me fez pensar se eu poderia identificar o arquivo específico que contém uma unidade de alocação específica.

Eu tenho brincado %%physloc%%na esperança de que isso possa ajudar, mas não me dá o que estou procurando. Os links abaixo foram fornecidos por Aaron Bertrand :

• Onde estão minhas linhas? – Usando a coluna virtual %%physloc%% (sqlity.net)
• SQL Server 2008: Nova função de localizador de linha física (não documentada) por Paul Randal

Estou testando diferentes arquiteturas para tabelas grandes e uma sugestão que vi é usar uma exibição particionada, em que uma tabela grande é dividida em uma série de tabelas "particionadas" menores.

1 , 2 , 3 , 4

Ao testar essa abordagem, descobri algo que não faz muito sentido para mim. Quando filtro "coluna de particionamento" na visualização de fatos, o otimizador busca apenas nas tabelas relevantes. Além disso, se eu filtrar essa coluna na tabela de dimensões, o otimizador eliminará tabelas desnecessárias.

No entanto, se eu filtrar algum outro aspecto da dimensão, o otimizador busca no PK/CI de cada tabela base.

Aqui estão as perguntas em questão:

select 
    od.[Year], 
    AvgValue = avg(ObservationValue)
from dbo.v_Observation o 
join dbo.ObservationDates od
    on o.ObservationDateKey = od.DateKey
where o.ObservationDateKey >= 20000101
    and o.ObservationDateKey <= 20051231
group by od.[Year];

select 
    od.[Year], 
    AvgValue = avg(ObservationValue)
from dbo.v_Observation o 
join dbo.ObservationDates od
    on o.ObservationDateKey = od.DateKey
where od.DateKey >= 20000101
    and od.DateKey <= 20051231
group by od.[Year];

select 
    od.[Year], 
    AvgValue = avg(ObservationValue)
from dbo.v_Observation o 
join dbo.ObservationDates od
    on o.ObservationDateKey = od.DateKey
where od.[Year] >= 2000 and od.[Year] < 2006
group by od.[Year];

Aqui está um link para a sessão do SQL Sentry Plan Explorer.

Na verdade, estou trabalhando no particionamento da tabela maior para ver se a eliminação da partição responde de maneira semelhante.

Eu obtenho a eliminação da partição para a consulta (simples) que filtra um aspecto da dimensão.

Enquanto isso, aqui está uma cópia somente de estatísticas do banco de dados:

https://gist.github.com/swasheck/9a22bf8a580995d3b2aa

O estimador de cardinalidade "antigo" obtém um plano mais barato, mas isso ocorre devido às estimativas de cardinalidade mais baixas em cada uma das buscas de índice (desnecessárias).

Gostaria de saber se existe uma maneira de fazer com que o otimizador use a coluna chave ao filtrar por outro aspecto da dimensão para que ele possa eliminar buscas em tabelas irrelevantes.

Versão do SQL Server:

Microsoft SQL Server 2014 - 12.0.2000.8 (X64) 
    Feb 20 2014 20:04:26 
    Copyright (c) Microsoft Corporation
    Developer Edition (64-bit) on Windows NT 6.3 <X64> (Build 9600: ) (Hypervisor)

SQL Server 2012 (11.0.5058.0) Enterprise Edition

Temos 8 grupos de disponibilidade em um cluster 2(HA)+1(DR) e nossos DMVs de monitoramento estão relatando resultados que me confundem. 6 grupos de disponibilidade são configurados para HA e DR, 1 é configurado apenas para HA e 1 é configurado apenas para DR.

Cada um dos 6 grupos de disponibilidade de HA/DR tem "SQLB" como primário e "SQLA" como réplica de HA secundária (síncrona) e "SQLC" como réplica secundária (assíncrona).

Em ambos os secundários:

SELECT dhags.group_id, dhags.synchronization_health_desc
FROM sys.dm_hadr_availability_group_states dhags

relata que todas as integridades de sincronização de replicação do Grupo de Disponibilidade são NOT_HEALTHYe

select replica_id,synchronization_health_desc
from sys.dm_hadr_availability_replica_states

relata que todas as réplicas têm uma integridade de sincronização de HEALTHY.

A réplica primária relata todos os grupos de disponibilidade e réplicas com integridade de sincronização de HEALTHY.

Embora eu entenda que um relata a integridade da sincronização da réplica e o outro relata a integridade da sincronização do AG, parece lógico para mim que, se o estado mais granular (AG) não fosse íntegro, isso afetaria a integridade geral do contexto mais amplo (réplica) . Não consigo encontrar a documentação do MSDN que descreva como a integridade é determinada em cada nível.

Por que os secundários relatam NOT_HEALTHYa integridade da sincronização do Grupo de Disponibilidade, mas HEALTHYa integridade da sincronização da réplica e por que isso difere do relatório do primário?

A menos que eu esteja entendendo mal a finalidade da coluna, o código a seguir indica que uma alteração na estrutura do índice clusterizado não altera a posição ordinal ( stats_column_id) da coluna no sys.stats_columns DMV. (Testado em AdventureWorks2014, AdventureWorks2008R2)

select i.name, c.name, ic.column_id, ic.index_column_id
from sys.indexes i 
join sys.index_columns ic
    on i.object_id = ic.object_id
    and i.index_id = ic.index_id
join sys.columns c 
    on i.object_id = c.object_id
    and ic.column_id = c.column_id
where i.name = 'PK_BusinessEntityAddress_BusinessEntityID_AddressID_AddressTypeID'
order by ic.key_ordinal;

select sh.name,s.name, c.name, c.column_id, sc.column_id, sc.stats_column_id
from sys.stats s 
join sys.stats_columns sc
    on s.object_id = sc.object_id
    and s.stats_id = sc.stats_id
join sys.columns c 
    on s.object_id = c.object_id
    and sc.column_id = c.column_id
join sys.tables t 
    on s.object_id = t.object_id
join sys.schemas sh
    on t.schema_id = sh.schema_id
where s.name = 'PK_BusinessEntityAddress_BusinessEntityID_AddressID_AddressTypeID'
order by sc.stats_column_id;

dbcc show_statistics('[Person].[BusinessEntityAddress]','PK_BusinessEntityAddress_BusinessEntityID_AddressID_AddressTypeID') with density_vector;

ALTER TABLE [Person].[BusinessEntityAddress] DROP CONSTRAINT [PK_BusinessEntityAddress_BusinessEntityID_AddressID_AddressTypeID]
GO

ALTER TABLE [Person].[BusinessEntityAddress] ADD  CONSTRAINT [PK_BusinessEntityAddress_BusinessEntityID_AddressID_AddressTypeID] PRIMARY KEY CLUSTERED 
(
    AddressID ASC,
    [BusinessEntityID] ASC, 
    [AddressTypeID] ASC
)
GO


select i.name, c.name, ic.column_id, ic.index_column_id
from sys.indexes i 
join sys.index_columns ic
    on i.object_id = ic.object_id
    and i.index_id = ic.index_id
join sys.columns c 
    on i.object_id = c.object_id
    and ic.column_id = c.column_id
where i.name = 'PK_BusinessEntityAddress_BusinessEntityID_AddressID_AddressTypeID'
order by ic.key_ordinal;

select sh.name,s.name, c.name, c.column_id, sc.column_id, sc.stats_column_id
from sys.stats s 
join sys.stats_columns sc
    on s.object_id = sc.object_id
    and s.stats_id = sc.stats_id
join sys.columns c 
    on s.object_id = c.object_id
    and sc.column_id = c.column_id
join sys.tables t 
    on s.object_id = t.object_id
join sys.schemas sh
    on t.schema_id = sh.schema_id
where s.name = 'PK_BusinessEntityAddress_BusinessEntityID_AddressID_AddressTypeID'
order by sc.stats_column_id;

dbcc show_statistics('[Person].[BusinessEntityAddress]','PK_BusinessEntityAddress_BusinessEntityID_AddressID_AddressTypeID') with density_vector;

No entanto, os vetores de densidade indicam uma alteração na coluna inicial do objeto de índice/estatística. Isso é um mal-entendido fundamental da minha parte? Em caso afirmativo, como encontraria a coluna inicial de um objeto de estatísticas usando DMVs?

Versões testadas do SQL Server: 2008R2, 2014

Dado o seguinte

-- table ddl
create table dbo.f_word(
    sentence_id int NULL,
    sentence_word_id int NULL,
    word_id int NULL,
    lemma_id int NULL,
    source_id int NULL,
    part_of_speech_id int NULL,
    person_id int NULL,
    gender_id int NULL,
    number_id int NULL,
    tense_id int NULL,
    voice_id int NULL,
    mood_id int NULL,
    case_id int NULL,
    degree_id int NULL,
    citation nvarchar(100) NULL
);
-- create partition function
create partition function pf_f_word_source_id (int)
as range left for values 
(
    1,2,3,4,5,6,7,8,9,10,11,12,13,14,
    15,16,17,18,19,20,21,22,23
);

-- create the partition scheme
create partition scheme ps_f_word as partition pf_f_word_source_id to 
(
    [primary],[primary],[primary],[primary],[primary],[primary],[primary],[primary],[primary],
    [primary],[primary],[primary],[primary],[primary],[primary],[primary],[primary],[primary],
    [primary],[primary],[primary],[primary],[primary],[primary]
);

-- partition the index
create unique clustered index cix_fword on dbo.f_word 
(
    source_id,
    sentence_id,
    sentence_word_id,
    word_id,
    lemma_id,
    part_of_speech_id,
    person_id,
    gender_id,
    number_id,
    tense_id,
    voice_id,
    mood_id,
    case_id,
    degree_id 
)
on ps_f_word (source_id);

-- swapin table ddl

create table dbo.f_word_swapin(
    sentence_id int NULL,
    sentence_word_id int NULL,
    word_id int NULL,
    lemma_id int NULL,
    source_id int NULL,
    part_of_speech_id int NULL,
    person_id int NULL,
    gender_id int NULL,
    number_id int NULL,
    tense_id int NULL,
    voice_id int NULL,
    mood_id int NULL,
    case_id int NULL,
    degree_id int NULL,
    citation nvarchar(100) NULL
) on [primary];

-- create the same index on the swapin table
create unique clustered index cix_fword_swapin on dbo.f_word_swapin 
(
    source_id,
    sentence_id,
    sentence_word_id,
    word_id,
    lemma_id,
    part_of_speech_id,
    person_id,
    gender_id,
    number_id,
    tense_id,
    voice_id,
    mood_id,
    case_id,
    degree_id 
);

-- add check constraints WITH CHECK
ALTER TABLE dbo.f_word_swapin
WITH CHECK
ADD CONSTRAINT ck_f_word_swapin_lb
CHECK ( source_id > 12);

ALTER TABLE dbo.f_word_swapin
WITH CHECK
ADD CONSTRAINT ck_f_word_swapin_ub
CHECK ( source_id <= 13);

Em seguida, mova os dados:

-- switch data OUT of the partitioned table
ALTER TABLE dbo.f_word
SWITCH PARTITION 13 TO dbo.f_word_swapin;

-- attempt to switch data back IN 
ALTER TABLE dbo.f_word_swapin
SWITCH TO dbo.f_word PARTITION 13;

Abaixo está o DDL "Script Table As ... CREATE" apenas para verificar as mesmas estruturas da tabela.

/****** Object:  Table [dbo].[f_word_swapin]    Script Date: 9/10/2014 10:01:01 AM ******/
SET ANSI_NULLS ON
GO

SET QUOTED_IDENTIFIER ON
GO

CREATE TABLE [dbo].[f_word_swapin](
    [sentence_id] [int] NULL,
    [sentence_word_id] [int] NULL,
    [word_id] [int] NULL,
    [lemma_id] [int] NULL,
    [source_id] [int] NULL,
    [part_of_speech_id] [int] NULL,
    [person_id] [int] NULL,
    [gender_id] [int] NULL,
    [number_id] [int] NULL,
    [tense_id] [int] NULL,
    [voice_id] [int] NULL,
    [mood_id] [int] NULL,
    [case_id] [int] NULL,
    [degree_id] [int] NULL,
    [citation] [nvarchar](100) NULL
) ON [PRIMARY]

/****** Object:  Table [dbo].[f_word]    Script Date: 9/10/2014 10:09:43 AM ******/
SET ANSI_NULLS ON
GO

SET QUOTED_IDENTIFIER ON
GO

CREATE TABLE [dbo].[f_word](
    [sentence_id] [int] NULL,
    [sentence_word_id] [int] NULL,
    [word_id] [int] NULL,
    [lemma_id] [int] NULL,
    [source_id] [int] NULL,
    [part_of_speech_id] [int] NULL,
    [person_id] [int] NULL,
    [gender_id] [int] NULL,
    [number_id] [int] NULL,
    [tense_id] [int] NULL,
    [voice_id] [int] NULL,
    [mood_id] [int] NULL,
    [case_id] [int] NULL,
    [degree_id] [int] NULL,
    [citation] [nvarchar](100) NULL
)

GO

SWITCHING OUT funciona muito bem. SWITCHing IN produz o seguinte erro:

Msg 4972, Nível 16, Estado 1, Linha 1 Falha na instrução ALTER TABLE SWITCH. Verificar restrições ou função de partição da tabela de origem 'greek.dbo.f_word_swapin' permite valores que não são permitidos por restrições de verificação ou função de partição na tabela de destino 'greek.dbo.f_word'.

Corrida:

select target_partition_id = $PARTITION.pf_f_word_source_id(source_id), 
    *
from dbo.f_word_swapin;

verifica se todos os dados devem voltar para a partição 13.

Sou muito novo em particionamento, então tenho certeza de que estou fazendo as coisas incorretamente, só não sei o que é.

Versão: SQL Server 2008 R2 Enterprise Edtn. (10.50.4000)

Na tentativa de avaliar nossa estratégia de particionamento, escrevi esta consulta para obter os métodos de acesso em relação aos índices nas partições (no sentido mais amplo do termo, embora esteja eliminando heaps). Ao restringir meu foco às tabelas particionadas, acredito que preciso estar olhando, range_scan_countmas singleton_lookup_countestou tendo dificuldade em conceituar.

SELECT 
    t.name AS table_name,
    i.name AS index_name,
    ios.partition_number, 
    leaf_insert_count,
    leaf_delete_count,
    leaf_update_count,
    leaf_ghost_count,
    range_scan_count,
    singleton_lookup_count,
    page_latch_wait_count ,
    page_latch_wait_in_ms,
    row_lock_count ,
    page_lock_count,
    row_lock_wait_in_ms ,
    page_lock_wait_in_ms,
    page_io_latch_wait_count ,
    page_io_latch_wait_in_ms
FROM sys.dm_db_partition_stats ps
    JOIN sys.tables t 
        ON ps.object_id = t.object_id
    JOIN sys.schemas s 
        ON t.schema_id = s.schema_id
    JOIN sys.indexes i 
        ON t.object_id = i.object_id
    AND ps.index_id = i.index_id
OUTER APPLY sys.dm_db_index_operational_stats(DB_ID(), NULL, NULL, NULL) ios                            
WHERE   
    ps.object_id = ios.object_id
    AND ps.index_id = ios.index_id
    AND ps.partition_number = ios.partition_number
    and ps.index_id = ios.index_id
    and ps.partition_number = ios.partition_number                                  
    and s.name <> 'sys'     
    and ps.index_id <> 0 ;

Saída relevante (dada a lacuna na formatação de tabelas do SO, esta é uma amostra das primeiras 9 colunas da consulta acima com as duas últimas colunas sendo range_scan_counte singleton_lookup_count, respectivamente):

╔════════╦═════════════════╦════╦═══╦═══╦═══╦═══╦════════╦══════════╗
║ datetb ║ idx_datetb_col  ║  1 ║ 0 ║ 0 ║ 0 ║ 0 ║ 205740 ║  3486408 ║
║ datetb ║ idx_datetb_col  ║  2 ║ 0 ║ 0 ║ 0 ║ 0 ║  29617 ║  1079649 ║
║ datetb ║ idx_datetb_col  ║  3 ║ 0 ║ 0 ║ 0 ║ 0 ║  29617 ║  1174547 ║
║ datetb ║ idx_datetb_col  ║  4 ║ 0 ║ 0 ║ 0 ║ 0 ║  29617 ║  2952991 ║
║ datetb ║ idx_datetb_col  ║  5 ║ 0 ║ 0 ║ 0 ║ 0 ║  29617 ║  3974886 ║
║ datetb ║ idx_datetb_col  ║  6 ║ 0 ║ 0 ║ 0 ║ 0 ║  29617 ║  2931450 ║
║ datetb ║ idx_datetb_col  ║  7 ║ 0 ║ 0 ║ 0 ║ 0 ║  29617 ║  3316960 ║
║ datetb ║ idx_datetb_col  ║  8 ║ 0 ║ 0 ║ 0 ║ 0 ║  29617 ║  3393439 ║
║ datetb ║ idx_datetb_col  ║  9 ║ 0 ║ 0 ║ 0 ║ 0 ║  29617 ║  3735495 ║
║ datetb ║ idx_datetb_col  ║ 10 ║ 0 ║ 0 ║ 0 ║ 0 ║  29617 ║  4803804 ║
║ datetb ║ idx_datetb_col  ║ 11 ║ 0 ║ 0 ║ 0 ║ 0 ║  29617 ║  7655091 ║
║ datetb ║ idx_datetb_col  ║ 12 ║ 1 ║ 0 ║ 0 ║ 0 ║ 174326 ║ 47377226 ║
╚════════╩═════════════════╩════╩═══╩═══╩═══╩═══╩════════╩══════════╝

Vejo algumas possibilidades diferentes, mas preciso de alguma orientação sobre como pensar sobre isso (claro que estou colocando isso em " pode " porque sei que "depende", mas também estou procurando compreensão conceitual):

1. Valores semelhantes para todas as partições range_scan_count podem indicar que não estamos obtendo uma boa eliminação de partição porque estamos verificando todas as partições aproximadamente o mesmo número de vezes.
2. Valores variados para todas as partições de singleton_lookup_countacompanhados de valores significativamente mais baixos para range_scan_count podem indicar uma boa eliminação frequente de partições porque estamos verificando menos do que procuramos.
3. ?

Esses são meus pensamentos até agora. Eu esperava que alguém avaliasse como eu poderia usar isso, ou outro conjunto de informações, para determinar quais tabelas provavelmente se beneficiariam com a eliminação do particionamento em favor de índices.

EDITAR

Aqui está um DDL recortado:

CREATE TABLE [dbo].[date_table](
    [date_id] [int] NOT NULL,
    [calendar_date] [datetime] NULL,
    [valdate] [datetime] NULL,
        CONSTRAINT [PK_datedb] PRIMARY KEY CLUSTERED 
        (
            [date_id] ASC
        ) ON [partschm]([date_id]);

CREATE UNIQUE NONCLUSTERED INDEX [idx_datetb_col] ON [dbo].[date_table]
(
    [calendar_date] DESC,
    [date_id] ASC
) ON [partschm]([date_id])
GO

Fui informado de que nossa SAN (Hitachi) lida com dados em blocos de 42 MB. É um armazenamento em camadas, de modo que cada bloco é avaliado quando o diretor toma decisões sobre quando deve promover/rebaixar o armazenamento para um armazenamento mais rápido/mais lento. Na ausência de peso político para "fixar" determinados LUNs em determinados níveis, estou tentando fazer tudo o que posso para configurar minha instância do SQL Server (2008 R2 Enterprise) para obter sucesso.

Como tal, eu queria saber se haveria algum benefício/prejuízo em alterar meus tamanhos de arquivo e tamanhos de crescimento de arquivo para múltiplos de 42? Um banco de dados de exemplo seria SIZE=57886MBcom um arquivo FILEGROWTH=5124MB.

Vejo o potencial para leituras extras (já que (42*1024)/8 = 8601,6, mas (42*1024)/64 = 672), mas não tenho certeza se estou compreendendo totalmente todos os conceitos aqui.

Quando executo as duas consultas abaixo,

SELECT 
    session_id, transaction_id
    FROM sys.dm_tran_session_transactions;

E

SELECT 
    session_id, request_id, at.transaction_id
    FROM sys.dm_tran_active_transactions at
        JOIN sys.dm_exec_requests r
            ON r.transaction_id = at.transaction_id;

Eu li o BOL para 1 e 2 , mas não vejo nenhuma explicação clara de por que a diferença ocorreria.

Eu obtenho resultados diferentes. A primeira consulta não retorna resultados, mas a última retorna transações ativas com IDs de sessão e transação. O request_idé 0, o que, creio, significa que é a única solicitação feita pela sessão. Alguém poderia me ajudar a entender por que existe uma diferença entre os dois conceitos que perguntei acima?

EDITAR

Acabei de reexecutar as consultas e agora obtenho um resultado para o primeiro DMV que possui um session_idque não está realmente contido no segundo conjunto de resultados.

Comecei a solucionar um tempdbproblema que estamos tendo no SQL Server 2005 Enterprise Edition. Um desenvolvedor está recebendo um erro tempdbde falta de espaço. Tecnicamente, o erro é:

A transação foi interrompida ao acessar a linha com versão na tabela 'dbo.inserted' no banco de dados 'dbname'. A linha com versão solicitada não foi encontrada. Seu tempdb provavelmente está sem espaço. Consulte BOL sobre como configurar o tempdb para controle de versão

Eu olhei para a configuração do banco de dados sys.databasese encontrei as seguintes configurações:

snapshot_isolation_state: 0

snapshot_isolation_state_desc: OFF

is_read_committed_snapshot_on: 1

Pesquisei o que isso significava no BOL e as informações importantes são as seguintes:

snapshot_isolation_state

Estado das transações de isolamento de instantâneo permitidas, conforme definido pela opção ALLOW_SNAPSHOT_ISOLATION:

0 = O estado de isolamento do instantâneo está DESLIGADO (padrão). O isolamento de instantâneo não é permitido.

1 = Estado de isolamento de instantâneo LIGADO. O isolamento de instantâneo é permitido.

2 = O estado de isolamento do instantâneo está em transição para o estado DESLIGADO. Todas as transações têm suas modificações versionadas. Não é possível iniciar novas transações usando isolamento de instantâneo. O banco de dados permanece na transição para o estado OFF até que todas as transações que estavam ativas quando ALTER DATABASE foi executado possam ser concluídas.

3 = O estado de isolamento do instantâneo está em transição para o estado ON. Novas transações têm suas modificações versionadas. As transações não podem usar isolamento de instantâneo até que o estado de isolamento de instantâneo se torne 1 (ON). O banco de dados permanece na transição para o estado ON até que todas as transações de atualização que estavam ativas quando ALTER DATABASE foi executado possam ser concluídas.

snapshot_isolation_state_desc

Descrição do estado das transações de isolamento de instantâneo permitidas, conforme definido pela opção ALLOW_SNAPSHOT_ISOLATION:

• DESLIGADO
• SOBRE
• IN_TRANSITION_TO_ON
• IN_TRANSITION_TO_OFF

is_read_committed_snapshot_on

1 = A opção READ_COMMITTED_SNAPSHOT está ATIVADA. As operações de leitura no nível de isolamento de confirmação de leitura são baseadas em varreduras de instantâneo e não adquirem bloqueios.

0 = a opção READ_COMMITTED_SNAPSHOT está DESLIGADA (padrão). As operações de leitura no nível de isolamento de confirmação de leitura usam bloqueios de compartilhamento.

Se estou entendendo isso corretamente, snapshot_isolation_stateestá DESLIGADO e não permitido. No entanto, o 1 is_read_committed_snapshot_onindica que o banco de dados está usando isolamento de instantâneo. Como isso é possível se é proibido?

Esta é a pergunta 2 de 2 relacionada à FASTdica de consulta. Informações básicas (como um aparte, não estou tentando obter mais representantes, estou tentando ser fiel em fazer apenas uma pergunta por pergunta).

Nosso ERP legado estava rodando no SQL Server 2000 EE e agora está no 2008 R2 EE. Estamos percebendo muito mais comandos bloqueados no ambiente 2008R2. O ambiente 2008R2 está sendo executado com o sinalizador de rastreamento 4199 e 1119.

Percebi uma diferença entre a documentação do MSDN sobre dicas em 2000 ) e 2008R2 , onde a FASTdica é expandida para observar que o resultado continuará a ser processado depois que as nlinhas especificadas forem retornadas. Este é apenas um documento mais robusto, é uma mudança no comportamento desta dica ao longo dos anos ou algo diferente?

Esta é a pergunta 1 de 2 relacionada aOPTION (FAST 1);

Acabamos de atualizar nosso banco de dados ERP de SQL 2000 EE para 2008 R2 EE e notamos um aumento no bloqueio do banco de dados. Reduzi ao que acredito ser a declaração ofensiva no código do fornecedor, que é:

SELECT MAX(column)
FROM [table] 
WHERE <condition> 
OPTION (FAST 1);

O spid deixa uma transação aberta e trava na mesa, bloqueando todos os outros clientes. No entanto, o cliente chamador não parece mais estar interagindo com o servidor para informar ao servidor que recebeu os dados para encerrar a sessão.

Lendo a documentação sobre Query Hints , vi esta declaração

FAST number_rows

Especifica que a consulta é otimizada para recuperação rápida das primeiras number_rows. Este é um número inteiro não negativo. Depois que os primeiros number_rows são retornados, a consulta continua a execução e produz seu conjunto de resultados completo.

Isso me faz pensar se o cliente quebrou a comunicação de alguma forma, o servidor manteria a transação aberta, processando o conjunto de resultados completo após as primeiras nlinhas serem retornadas e deixando a transação aberta? O processo é um processo interno, então não posso realmente assistir a um usuário final executar a sessão para fazer isso, e isso não é algo que acontece toda vez que o processo interno ocorre. No entanto, ele é usado apenas pelo processo interno.

Depois de ler a resposta de Remus no SO, parece um exagero pela simplicidade da consulta. Olhando para a consulta, se eles estão recebendo mais de um resultado de um desagrupado MAX, então algo é muito suspeito.

Portanto, enquanto me preparo para trabalhar com o fornecedor, gostaria de saber se poderia começar a atribuir com precisão nossos problemas de bloqueio ao fato de que essa dica de consulta está sendo usada.

Sinta-se à vontade para editar/solicitar edições, pois sei que isso pode não estar claro.

Acabei de migrar meu servidor de banco de dados ERP do SQL Server 2000 para o SQL Server 2008 R2 (ambos Enterprise Edition) e essa migração ocorreu sem problemas.

No entanto, agora que estou tentando recriar a replicação do ERP para o ambiente de relatórios, tenho duas publicações que estão tentando criar uma série de MSFixupNonUniqueIndex_{{datetimestamp}}índices não exclusivos. Os processos que criam esses índices estão todos suspensos, mas estão bloqueando outros processos SQL que os usuários finais estão executando.

O que está causando essa criação de índice de correção e posso evitá-la?

• Usando sp_whoisactivethere is no wait_infopara a tarefa de criação de índice.
• Não descartei o banco de dados replicado no ambiente Reporting.
• O "Ambiente de relatórios" também é SQL Server 2008 R2 Enterprise.
• Esta é a replicação de 2008 R2 para 2008 R2, agora.
• sysprocessesmostra dois procs bloqueados pelo spid tentando criar o índice. O próprio spid tem um waittypede 0x0000e um lastwaittypede MISCELLANEOUS.
• sys.locksmostra que existem 777 bloqueios: 7 Intent, 761 Exclusive, 6 Shared, 2 Schema Mod, 1 Schema Stability. Os recursos são: 1 ALLOCATION_UNIT, 9 OBJECT, 3 DATABASE, 2 METADATA, 677 PAGE, 11 KEY, 1 HOBT, 73 EXTENT.
• select * from sysprocesses where open_tran > 0retorna o spid com uma transação aberta
• DBCC OPENTRANnão tem transações abertas.
• MAXDOPestá desconfigurado

Estamos desativando nosso antigo SQL Server 2000 Ent. instância em favor do SQL Server 2008 R2 Ent. Meu caminho de migração planejado é:

1. Encerrar conexões de cliente (2000)
2. Backup completo (2000)
3. Restaurar (2008 R2)

Estou sendo solicitado a fornecer provas conclusivas de que cada transação "conseguiu" e que os dados são uma replicação exata do que existia na instância 2000.

Espero poder usar a seguinte documentação como evidência:

• Backups completos do banco de dados
• Executando uma restauração completa do banco de dados (modelo de recuperação completa)

No entanto, se isso não for suficiente, a única coisa em que consigo pensar é percorrer todas as linhas de todas as tabelas de todos os bancos de dados e calcular uma soma de verificação (em ambas as instâncias), bem como obter contagens de linhas para todas as tabelas em todos os bancos de dados.

Existe alguma maneira melhor de satisfazer os critérios de verificação de "réplica exata"? Também estou aberto a uma melhor documentação.

Estou solucionando os pedaços de um procedimento armazenado com baixo desempenho. Esta seção do procedimento está lançando um aviso NO JOIN PREDICATE

select
    method = 
        case methoddescription 
            when 'blah' then 'Ethylene Oxide'
            when NULL then 'N/A'
            else methoddescription
        end,
    testmethod = 
        case methoddescription 
            when 'blah' then 'Biological Indicators'
            when NULL then 'N/A'
            else 'Dosimeter Reports'
        end,
    result = 
        case when l.res is null or l.res <> 1 then 'Failed'
        else 'Passed'
        end,
    datecomplete = COALESCE(CONVERT(varchar(10), NULL, 101),'N/A')
from db2.dbo.view ls
    join db1.dbo.table l
        on ls.id = l.id
    where item = '19003'
        and l.id = '732820'

A exibição ( [ls]) chama um servidor remoto (a consulta remota %41 à direita do plano).

Aqui está uma imagem do plano:

Eu só faço essa pergunta por causa desta postagem no blog e quero ter certeza de que isso não voltará a me incomodar mais tarde.

Houve uma pergunta bastante inócua sobre a adição de datas e horas no SQL Server que desencadeou um debate taxonômico bastante fascinante.

Então, como diferenciamos esses termos relacionados e como os usamos corretamente?

Fileira

Registro

Estou no processo de mover um projeto de estimação do PostgreSQL (9.2.2) para o SQL Server (2012 Standard).

Percebi um fenômeno interessante ao consultar palavras unicode. Dada a definição:

CREATE TABLE [word](
    [id] [int] IDENTITY(0,1) NOT NULL,
    [value] [nvarchar](255) NULL    
 );

e os dados:

insert into word (value) values (N'ῥύπῳ');
insert into word  (value) values (N'ἀπὸ');
insert into word  (value) values (N'ἀπό');
insert into word (value) values  (N'ἐπὶ');
insert into word (value) values  (N'ἐπί');
insert into word (value) values  (N'ὑπὸ');
insert into word (value) values  (N'ὑπό');
insert into word (value) values  (N'πίῃ');

insert into word  (value) values (N'λόγους');
insert into word  (value) values (N'λόγχῃ');
insert into word (value) values  (N'λόγων');
insert into word  (value) values (N'ἀλόης');

uma consulta para uma palavra específica retornará correspondências próximas. Por exemplo:

select * from word where value = N'ἀπὸ'

retorna:

id  value
102137  ῥύπῳ
102141  ἀπὸ
102142  ἀπό
102143  ἐπὶ
102144  ἐπί
102145  ὑπὸ
102146  ὑπό
102147  πίῃ

http://sqlfiddle.com/#!6/1ab66/1

No entanto, o mesmo padrão no PostgreSQL retorna apenas a correspondência exata. Como posso obter o SQL Server para fazer o mesmo?

(link do violino PostgreSQL): http://sqlfiddle.com/#!12/c57a6/1

Tenho a nítida sensação de que estou perdendo alguma coisa, mas não consigo descobrir o que é.

O agrupamento do banco de dados é SQL_Latin1_General_CP1_CI_AS(que também é o agrupamento do servidor) em uma instalação local.

Nossos usuários finais têm muitas maneiras de enviar produtos para nossos clientes. Eles podem usar o endereço do cliente em uma tabela ( [customer]), um endereço de entrega específico em outra ( [dropship]) ou ainda outro endereço de entrega em outra tabela (para clientes com vários locais) ( [delivery]). Todos eles têm aproximadamente a mesma estrutura, com os mesmos nomes de coluna para os mesmos pontos de dados (por exemplo [address], é o endereço em todas as tabelas).

Atualmente, nossa lógica para encontrar o endereço de entrega de um pedido é a seguinte:

SELECT
    Address = COALESCE(r.address, d.address, c.address) 
FROM [order] o 
JOIN customer c
    ON o.customerid = c.customerid
LEFT JOIN delivery d
    ON o.customerid = d.customerid
    AND o.delivaddressid = d.delivaddress
LEFT JOIN dropship r
    ON o.orderid = r.orderid;

Com base em conversas e não em algumas postagens de blog , EXISTSparece ser o preferido.

No entanto, este é um novo paradigma para mim e estou tentando entender isso. Acabei de substituir o LEFT JOINs por

WHERE EXISTS 
    (select 1 from delivery d
        where o.customerid = d.customerid 
        and o.delivaddressid = d.delivaddress)

Isso não me permitirá usar os dados de [delivery], a menos que eu os jogue na FROMcláusula e crie um produto cartesiano, certo?

Dada a definição existente para o LocalDB do SQL Server 2012 como

O SqlLocalDB é um mecanismo de banco de dados local e de baixa sobrecarga do SQL Server 2012 (e versões futuras) que permite que os desenvolvedores se concentrem no desenvolvimento em vez da configuração ou segurança da instância.

Eu estava curioso para saber como seria o caminho do desenvolvimento no LocalDB para uma instância de produção, especialmente à luz dos problemas com instâncias de usuário (ca. SQL 2005) e tentar promover um deles para produção e os desenvolvedores perderiam a noção de qual instância eles estavam realmente tentando promover. Uma pesquisa rápida no StackOverflow denuncia esses problemas de várias formas. O LocalDB melhora/simplifica a implantação em tais circunstâncias?

Dada a string:

'Eu acho que o PostgreSQL é bacana'

Eu gostaria de operar nas palavras individuais encontradas dentro dessa string. Essencialmente, tenho um separado do qual posso obter detalhes da palavra e gostaria de ingressar em uma matriz não aninhada dessa string neste dicionário.

Até agora eu tenho:

select word, meaning, partofspeech
from unnest(string_to_array('I think that PostgreSQL is nifty',' ')) as word
from table t
join dictionary d
on t.word = d.wordname;

Isso cumpre os fundamentos do que eu esperava fazer, mas não preserva a ordem original das palavras.

Questão relacionada:
PostgreSQL unnest() com número de elemento

Recentemente, descobri que grande parte do departamento financeiro está usando o Excel para se conectar à minha instância do SQL Server 2000 com uma conta na função sysadmin. Quais são os meus riscos atuais que devo comunicar imediatamente aos poderes constituídos?