S3S's questions

Eu tenho um VLDB de produção que estou usando a orientação de Paul Randal para distribuir a DBCC CHECKDBcarga de trabalho por uma semana. Estou registrando os resultados de DBCC CHECKTABLE WITH TABLERESULTSe DBCC CHECKALLOC WITH TABLERESULTSpara uma tabela e notei que DBCC CHECKTABLE WITH TABLERESULTSestava retornando apenas uma única linha por tabela em tabelas não corrompidas. Aqui estão as primeiras colunas.

Error   Level   State   MessageText      
2593    10      1       There are 57 rows in 1 pages for object "SmallTable".

Mas quando executo DBCC CHECKTABLE WITH TABLERESULTSem uma tabela corrompida em um banco de dados de teste, que corrompi com este método , recebo o seguinte:

Error   Level   State   MessageText
8939    16      98      Table error: Object ID 565577053, index ID 1, partition ID 72057594041335808, alloc unit ID 72057594046971904 (type In-row data), page (1:312). Test (IS_OFF (BUF_IOERR, pBUF->bstat)) failed. Values are 133129 and -4.
8928    16      1       Object ID 565577053, index ID 1, partition ID 72057594041335808, alloc unit ID 72057594046971904 (type In-row data): Page (1:312) could not be processed.  See other errors for details.
8980    16      1       Table error: Object ID 565577053, index ID 1, partition ID 72057594041335808, alloc unit ID 72057594046971904 (type In-row data). Index node page (0:0), slot 0 refers to child page (1:312) and previous child (0:0), but they were not encountered.
2593    10      1       There are 0 rows in 0 pages for object "tblWhoops".
8990    10      1       CHECKTABLE found 0 allocation errors and 3 consistency errors in table 'tblWhoops' (object ID 565577053).

Estou curioso para saber por que o erro 8990 não retornou com a tabela não corrompida? DBCC CHECALLOC WITH TABLERESULTSe DBCC CHECKDB WITH TABLERESULTSretorne esta linha quando não houver erros de alocação ou consistência para relatar.

Pergunta bônus, por que não DBCC CHECKCATALOGtem uma WITH TABLERESULTdiscussão?

Existe uma maneira de pular índices "não usados" com base no total de leituras desse índice durante uma manutenção de índice com os scripts do Ola?

Eu entendi aquilo

• As estatísticas do índice são apenas desde a última reinicialização, portanto, o monitoramento de um ciclo de negócios é importante
• Ignorar uma reorganização ou reconstrução em um índice "não utilizado" que pode ser necessário mais tarde, mesmo uma vez, no ciclo de negócios pode causar problemas de desempenho
• Todo mundo está pensando "por que você não remove isso"

Para responder ao último, é um aplicativo fornecido pelo fornecedor com um banco de dados OLTP de ~ 2 TB. Para manter a conformidade, não podemos mudar muito e não posso descartar seus índices, entre outras coisas. Assim, pensei que seria benéfico reduzir o tempo de manutenção ignorando esses índices depois de confirmar que eles nunca são usados. Isso seria benéfico para situações em que, como esta, minhas mãos estão principalmente atadas.

Seguir para comentários seria se isso não puder ser feito, vale a pena jogar para Ola como um aprimoramento?

Estou procurando uma maneira de consultar as configurações da sessão de correio em Agente > Sistema de alertas > Sessão de correio. Semelhante à forma como sp_MSgetalertinfo retorna informações sobre o operador Fail-safe, gostaria de determinar se o perfil de email Habilitar está marcado e como o sistema de email e o perfil de email estão definidos. Eu entendo que eles podem estar contidos apenas nas configurações do registro.

A razão pela qual eu quero consultá-los é porque nós os habilitamos ... O Database Mail não está habilitado para notificações do agente. Não é possível enviar email para" erro no log do agente. Este é um banco de dados de terceira parte ao qual o suporte tem acesso total. Não tenho certeza se eles acidentalmente (ou propositalmente) o desabilitaram, ou se ele pode ser desabilitado por algum outro sistema que não seja feito por um usuário.

Para não tornar isso uma pergunta XY, estou aberto a sugestões sobre como auditar essas alterações com uma especificação de auditoria de servidor.

Estou tentando determinar por que DBCC DBINFOestá retornando resultados diferentes do que está contido no log de erros. Aqui está a configuração:

Réplica secundária (acesso somente leitura -- Confirmação assíncrona AlwaysOn HA AG)

• Job foi executado em com 02/05/2018 09:00:00 PMsucesso, com uma duração de02:22:21
• O único passo no trabalho éDBCC CHECKDB(myDB)
• Quando eu corro DBCC DBINFO('myDB') WITH TABLERESULTSeu vejo dbi_dbccLastKnownGood 02/05/2018 00:00:40.113. Isso deve ser 02/05/2018 11:22 PM.
• Quando verifico o log de erros, vejo02/05/2018 11:22:09 PM DBCC CHECKDB(myDB) executed by myAccount found 0 errors and repaired 0 errors. Elapsed time : 2 hours 22 minutes 9 seconds. Internal database snapshot has split point LSN ... and first LSN ...

Resolvi verificar a PRIMARY REPLICA onde o DBCC CHECKDB também está sendo executado (tudo isso é configurado pelo fornecedor).

• O subplano funcionou com 02/05/2018 00:00:00 AMsucesso, com uma duração de02:14:40
• Quando eu corro DBCC DBINFO('myDB') WITH TABLERESULTS, vejo dbi_dbccLastKnownGood 02/05/2018 00:00:40.113qual é o mesmo que o RoR, mas deve ser 02/05/2018 02:15 AM.
• Quando verifico o log de erros, vejo02/05/2018 02:15:12 AM DBCC CHECKDB(myDB) WITH no_infomsgs exextued by myAccount found 0 error and repaired 0 errors. Elapsed time : 2 hours 14 minutes 40 seconds. Internal database snapshot has split point LSN ... and first LSN ...

Não consigo descobrir de onde DBCC DBINFOvem esses resultados e por que não corresponde aos logs do SQL. Configurei um trabalho para me enviar um alerta quando dbi_dbccLastKnownGood for > 24 horas.

Alguma ideia? Deixe-me saber se mais informações são necessárias.

Ao investigar uma pergunta no Stackoverflow , descobri que sp_columns, que usa sys.spt_columns_odbc_view, está retornando o errado/inesperado DATA_TYPE & TYPE_NAMEpara NVARCHAR(MAX). Está retornando NTEXTpara NVARCHARcolunas e não consigo descobrir o porquê. Alguém tem alguma idéia?

DEMO

CREATE TABLE [dbo].[deleteTable](
    [v] [nvarchar](max) NULL,
    [t] [ntext] NULL
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]

GO

select 
    c.name
    ,c.system_type_id
    ,ty.name
    ,ty.precision
    ,t.name
from 
    sys.columns c
inner join 
    sys.tables t on t.object_id = c.object_id
inner join 
    sys.types ty on ty.system_type_id = c.system_type_id
where
t.name = 'deleteTable'

exec sp_columns @table_name = 'deleteTable'

Após cerca de 3 dias de tentativas, não consigo criar um servidor vinculado do SQL Server 2016 para o Informix 11.5. Eu não tentei isso com outras versões (2008R2, etc) desde que eu queria configurar a conexão em um ambiente de teste primeiro.

O que eu fiz

• Instalou o driver OLE DB Informix mais recente na máquina host do SQL Server
• Configurou um DSN do sistema para a configuração do driver ODBC do IBM Informix
• Testou a conectividade das configurações de DSN (o teste é bom) depois de alterar as configurações de localidade para que o cliente e o servidor correspondam e o servidor esteja correto.
• Tentativa de criar o servidor vinculado de duas maneiras abaixo.
• Pesquisei e li tudo o que pude para resolver isso sem sucesso.

1) Usando as instruções do IBM Informix com o OLE DB Provider em que recebo o seguinte erro (independentemente de eu usar um DNS na string do provedor):

Não é possível inicializar o objeto de fonte de dados do provedor OLE DB "Ifxoledbc" para o servidor vinculado "UCCX". O provedor OLE DB "Ifxoledbc" para o servidor vinculado "UCCX" retornou a mensagem "EIX000: (-23197)" Incompatibilidade de informações de localidade do banco de dados" (Microsoft SQL Server, erro: 7303)

A localidade do banco de dados é en_US.57372

2) Usando o Microsoft OLE DB Provider for SQL Server conforme explicado neste blog que retorna o erro:

Provedor de pipes nomeados: não foi possível abrir uma conexão com o SQL Server. O provedor OLE DB SQLNCLI11 para servidor vinculado UCCX retornou a mensagem "Tempo limite de login expirado" O provedor OLE DB SQLNCLI11 para servidor vinculado UCCX retornou uma mensagem "Ocorreu um erro relacionado à rede ou específico da instância ao estabelecer uma conexão com o SQL Server. O servidor não foi encontrado ou não acessível. Verifique se o nome da instância está correto e se o SQL Server está configurado para permitir conexões remotas. SQLNCLI11 para servidor vinculado UCCX retornou a mensagem "Atributo de string de conexão inválido"

Eu tenho muito pouca experiência com o Informix, o que deve ser aparente e esta não é uma instalação local, é uma instância da Cisco, como você provavelmente aprendeu nos blogs que eu estava usando. Qualquer conselho seria apreciado.