Ruud van de Beeten's questions

Prefácio

Na empresa em que trabalho, usamos instantâneos de banco de dados em nosso processo de ETL para garantir que os dados estejam em um estado consistente. Os arquivos de instantâneo são colocados em um disco separado (no nosso caso o X:).

Um dos bancos de dados de origem é um banco de dados de 3 TB com dados atualizados com frequência. Ao criar um instantâneo de banco de dados deste banco de dados, encontramos momentos em que os arquivos de instantâneo aumentaram e recebemos o erro:

"Erro do sistema operacional 112(Não há espaço suficiente no disco.) encontrado."

Esse erro estava sempre nas janelas de manutenção do índice ou quando um processo em massa era executado no banco de dados de origem. Desde então, aumentamos o espaço em disco disponível na unidade X:\ e alteramos a programação de trabalhos de manutenção de índice/dbcc checkdb. Como esperado, os erros não ocorreram mais.

Problema

De tempos em tempos precisamos de uma carga inicial de algumas tabelas grandes (600.000.000 linhas / 300GB por tabela). Esta semana, encontramos um erro diferente no carregamento dessas tabelas grandes:

O sistema operacional retornou o erro 665 (a operação solicitada não pôde ser concluída devido a uma limitação do sistema de arquivos) no SQL Server durante uma gravação no deslocamento 0x000056fb976000 no arquivo 'X:\Data\DatabaseName_snapshot.ss'.

Mensagens adicionais no log de erros do SQL Server e no log de eventos do sistema podem fornecer mais detalhes.

Este erro ocorre apenas 18 a 25 horas após a criação do instantâneo.

As coisas já tentaram

1. Desabilitado todos os trabalhos de manutenção de índice/dbcc checkdb e outros processos que alteram muitos dados (exceto entrada do usuário).
2. Monitorou o espaço disponível no disco de instantâneo (X:\400GB). Cerca de 80% do espaço disponível está livre quando ocorre o erro.
3. Procurei perguntas semelhantes no stackexchange. O instantâneo do banco de dados encontrado entra no modo SUSPECT (SQL 2014 no WIN2K8R2) que não foi respondido.
4. Olhando para o artigo https://blogs.msdn.microsoft.com/psssql/2015/06/10/operating-system-error-665-file-system-limitation-not-just-for-dbcc-anymore/ agora.

Alguém tem mais ideias para resolver este problema?

Estamos usando o SQL Server 2014 SP2 CU1, edição corporativa e o Windows Server 2012.

A empresa em que trabalho possui alguns bancos de dados SQL Server com tabelas contendo +- 500.000.000 linhas. Estamos executando as edições Enterprise do SQL Server 2008R2 e 2014.

Tipos de big data

Quando olho para os tipos de dados usados ​​na tabela maior, vejo muitas colunas BIGINT. Examinando os dados nessas colunas com um script de Thomas Larock e fazendo o script dos valores MIN() e MAX() eu mesmo, concluí que os dados nessas colunas BIGINT podem ser facilmente ajustados em colunas INT ou mesmo SMALLINT/TINYINT. (Estou ciente de que algumas colunas podem precisar do intervalo de BIGINT no futuro, portanto não estou alterando cegamente todos os tipos de dados sem falar primeiro com os desenvolvedores)

Ao comparar a possível economia ao alterar os tipos de dados, parece que a tabela poderia ter a metade do tamanho atual (sem considerar índices e outras tabelas). Esses números são sem qualquer compressão de dados.

Compressão de LINHA

Na mesa grande, a compactação ROW está habilitada. Estou me perguntando qual pode ser o impacto real de 'reduzir' os tipos de dados das colunas, tendo em mente que a compactação ROW está usando apenas os bytes necessários . Por exemplo, se um valor puder ser armazenado em 1 byte, o armazenamento levará apenas 1 byte.

pergunta real

Ajudaria a reduzir os tipos de dados, de modo que a compactação ROW usasse menos recursos? Ou é salvo dizer 'porque a compactação ROW está habilitada, não há diferença entre os tipos de dados BIGINT, INT ou SMALLINT'?

Criei vários pacotes SSIS no Visual Studio 2012 e eles podem ser executados sem problemas.

Para um projeto em que estou trabalhando, gero pacotes usando BIML. No meu script BIML, crio um pacote para cada exibição de banco de dados em dois esquemas de banco de dados definidos. Por exemplo:

• [crm].[contato]
• [crm].[conta]
• [navisão].[fornecedor]
• [navisão].[cliente]

O nome dos pacotes será [schemaname] viewname, e "[crm] contact".

Quando inicio um pacote no Visual Studio, recebo a mensagem "Falha ao iniciar o projeto", veja abaixo.

"Exceção ao desserializar o pacote. "A parte especificada não existe no pacote".

Por que esse erro está ocorrendo?

Como estou trabalhando em um projeto de pós-graduação (Textmining com SQL Server 2012 Semantic Search) , me deparo com uma situação em que preciso postar uma pergunta neste site, esperando que alguém possa me ajudar.

Esta pergunta é sobre stoplists e stopwords no SQL Server 2012. Eu configurei uma prova de conceito onde estou tentando indexar documentos e listar frases-chave estatisticamente relevantes com a nova funcionalidade de pesquisa semântica . Como não quero que algumas palavras sejam indexadas e, portanto, frases-chave estatisticamente relevantes, estou criando uma lista de palavras irrelevantes para excluir essas palavras.

Stoplist/stopwords para o idioma inglês ( lcid 1033 ):

/* Create stoplist and add words */ 
CREATE FULLTEXT STOPLIST [naam van de stoplist];
   ALTER FULLTEXT STOPLIST [naam van de stoplist] ADD 'beeten' LANGUAGE 'English';
   ALTER FULLTEXT STOPLIST [naam van de stoplist] ADD 'centimeter' LANGUAGE 'English';
   ALTER FULLTEXT STOPLIST [naam van de stoplist] ADD 'info' LANGUAGE 'English';
   ALTER FULLTEXT STOPLIST [naam van de stoplist] ADD 'ruud' LANGUAGE 'English';
GO

Criando um Catálogo de Texto Completo, Índice de Texto Completo com a lista personalizada e semântica:

/* Full-Text catalog */
CREATE FULLTEXT CATALOG [ft] WITH ACCENT_SENSITIVITY = ON AS DEFAULT;
GO

/* Full-Text Index */
CREATE FULLTEXT INDEX ON [dbo].[Documents]
    (   file_stream Language 1033 STATISTICAL_SEMANTICS )
    KEY INDEX DocumentsFt
    WITH STOPLIST = [naam van de stoplist];
GO

Eu tentei tudo o que posso pensar para verificar se eu perdi alguma coisa:

    /*Select all words in the stoplist, with some debug information*/
    SELECT sys.fulltext_stoplists.stoplist_id AS [Stoplist id]
        ,  sys.fulltext_stoplists.name AS [Stoplist]
        ,  sys.database_principals.name AS [Owner]
        ,  sys.fulltext_languages.lcid AS [LCID]
        ,  sys.fulltext_languages.name AS [Taal]
        ,  sys.fulltext_stopwords.stopword AS [Stopwoord] 
    FROM sys.fulltext_languages
    INNER JOIN sys.fulltext_stopwords 
        ON sys.fulltext_stopwords.language_id = sys.fulltext_languages.lcid
    INNER JOIN sys.fulltext_stoplists 
        ON sys.fulltext_stopwords.stoplist_id = sys.fulltext_stoplists.stoplist_id
    INNER JOIN sys.database_principals ON sys.database_principals.principal_id = sys.fulltext_stoplists.principal_id
    WHERE sys.fulltext_stoplists.name = 'naam van de stoplist';

/* List with all Full-Text Indexes (with statistical_semantics) */
SELECT sys.fulltext_catalogs.name [Full-Text catalog]   
    , sys.indexes.name AS [Index] 
    , sys.indexes.type_desc AS [Index type]
    , sys.fulltext_indexes.is_enabled AS [Index in use]
    , sys.fulltext_stoplists.name AS [Stoplist]
    , sys.tables.name AS [Table]
    , sys.columns.name AS [Column]
    , sys.fulltext_index_columns.language_id AS [LCID]
    , sys.fulltext_languages.name AS [Language]
    , sys.fulltext_index_columns.statistical_semantics [Semantic]
FROM sys.fulltext_catalogs
INNER JOIN sys.fulltext_indexes 
    ON sys.fulltext_catalogs.fulltext_catalog_id = sys.fulltext_indexes.fulltext_catalog_id
INNER JOIN sys.fulltext_index_columns 
    ON sys.fulltext_indexes.object_id = sys.fulltext_index_columns.object_id
INNER JOIN sys.indexes 
    ON sys.fulltext_indexes.object_id = sys.indexes.object_id 
    AND sys.fulltext_indexes.unique_index_id = sys.indexes.index_id
INNER JOIN sys.index_columns 
    ON sys.indexes.object_id = sys.index_columns.object_id 
    AND sys.indexes.index_id = sys.index_columns.index_id
INNER JOIN sys.columns 
    ON sys.index_columns.object_id = sys.columns.object_id 
    AND sys.index_columns.column_id = sys.columns.column_id
INNER JOIN sys.tables 
    ON sys.fulltext_indexes.object_id = sys.tables.object_id
INNER JOIN sys.fulltext_languages 
    ON sys.fulltext_index_columns.language_id = sys.fulltext_languages.lcid
LEFT JOIN sys.fulltext_stoplists 
    ON sys.fulltext_indexes.stoplist_id = sys.fulltext_stoplists.stoplist_id    
WHERE sys.fulltext_index_columns.statistical_semantics = 1
ORDER BY sys.fulltext_catalogs.name
        ,sys.indexes.name
        ,sys.index_columns.key_ordinal;

/* Rebuild catalog */
ALTER FULLTEXT CATALOG [ft] REBUILD;
GO

/* Check status of the catalog rebuild */
/*  0 = Idle.
1 = Full population is in progress.
2 = Incremental population is in progress.
3 = Propagation of tracked changes is in progress.
4 = Background update index is in progress, such as automatic change tracking.
5 = Full-text indexing is throttled or pause    
*/
SELECT FULLTEXTCATALOGPROPERTY('ft', 'PopulateStatus') AS Status;
GO

/* Repopulate Full-Text Index */
ALTER FULLTEXT INDEX ON dbo.Documents START UPDATE POPULATION;
GO

Todos os comandos acima indicam que as coisas estão configuradas corretamente.

Quando olho para as palavras indexadas, ainda vejo as palavras na lista de palavras irrelevantes, por exemplo, 'beeten'.

SELECT * 
FROM sys.dm_fts_index_keywords(DB_ID('SQLServerArticles'), OBJECT_ID('Documents'))
WHERE display_term = 'beeten';

Eu até tentei se o analisador de texto completo não está funcionando corretamente com a seguinte declaração.

SELECT special_term, display_term
FROM sys.dm_fts_parser
(' "testing for fruit and nuts centimeter, any type of Beeten" ', 1033, 8, 0)

Esta instrução retorna o seguinte resultado:

Exact Match testing
Exact Match for
Exact Match fruit
Exact Match and
Exact Match nuts
Noise Word  centimeter
Exact Match any
Exact Match type
Exact Match of
Noise Word  beeten

Este resultado indica que a palavra 'beeten' é uma palavra de ruído. Essa palavra deve ser ignorada durante a indexação? O que eu perdi?

Novamente : como não quero que algumas palavras sejam indexadas e, portanto, frases-chave estatisticamente relevantes, estou criando uma lista de palavras irrelevantes para excluir essas palavras.