All perguntas(dba)

Contexto:

Digamos que, ao usar Streaming Replication/Hot Standby em um cluster Postgres 9.1, um nó de standby fica inativo. Ele permanece inativo por um dia, durante o qual ocorre uma grande quantidade de DML no mestre. O recovery.conf do standby não contém uma entrada 'restore_command' (para restauração de arquivos de diário WAL), mas contém uma string 'primary_conninfo' (para replicação de streaming).

Pergunta:

Se eu iniciar o modo de espera novamente após um dia de alterações no mestre. Ele irá "recuperar o atraso" (eventualmente entrará em um estado que espelha o mestre) usando apenas a replicação de streaming? Ou devo habilitar o arquivamento de arquivos WAL e deixá-lo aplicar os arquivos arquivados durante a interrupção para garantir a moeda?

Eu verifiquei o documento de arquivamento/replicação de streaming do WAL aqui e ele diz que você não precisa habilitar o arquivamento do WAL e a replicação de streaming, mas não está claro se o catch-up acontecerá ou não sem o arquivamento do arquivo WAL ativado.

Obrigado!

Dada uma junção simples de três tabelas, o desempenho da consulta muda drasticamente quando ORDER BY é incluído, mesmo sem nenhuma linha retornada. O cenário real do problema leva 30 segundos para retornar zero linhas, mas é instantâneo quando ORDER BY não é incluído. Por quê?

SELECT * 
FROM tinytable t                          /* one narrow row */
JOIN smalltable s on t.id=s.tinyId        /* one narrow row */
JOIN bigtable b on b.smallGuidId=s.GuidId /* a million narrow rows */
WHERE t.foreignId=3                       /* doesn't match */
ORDER BY b.CreatedUtc          /* try with and without this ORDER BY */

Entendo que poderia ter um índice em bigtable.smallGuidId, mas acredito que isso pioraria as coisas neste caso.

Aqui está o script para criar/preencher as tabelas para teste. Curiosamente, parece importante que smalltable tenha um campo nvarchar(max). Também parece importar que estou entrando na bigtable com um guid (o que eu acho que faz com que ele queira usar correspondência de hash).

CREATE TABLE tinytable
  (
     id        INT PRIMARY KEY IDENTITY(1, 1),
     foreignId INT NOT NULL
  )

CREATE TABLE smalltable
  (
     id     INT PRIMARY KEY IDENTITY(1, 1),
     GuidId UNIQUEIDENTIFIER NOT NULL DEFAULT NEWID(),
     tinyId INT NOT NULL,
     Magic  NVARCHAR(max) NOT NULL DEFAULT ''
  )

CREATE TABLE bigtable
  (
     id          INT PRIMARY KEY IDENTITY(1, 1),
     CreatedUtc  DATETIME NOT NULL DEFAULT GETUTCDATE(),
     smallGuidId UNIQUEIDENTIFIER NOT NULL
  )

INSERT tinytable
       (foreignId)
VALUES(7)

INSERT smalltable
       (tinyId)
VALUES(1)

-- make a million rows 
DECLARE @i INT;

SET @i=20;

INSERT bigtable
       (smallGuidId)
SELECT GuidId
FROM   smalltable;

WHILE @i > 0
  BEGIN
      INSERT bigtable
             (smallGuidId)
      SELECT smallGuidId
      FROM   bigtable;

      SET @i=@i - 1;
  END 

Eu testei no SQL 2005, 2008 e 2008R2 com os mesmos resultados.

Estou configurando um plano de manutenção no SQL Server 2008 R2.

Na Tarefa Reorganizar Índice tem a opção "Compactar Objetos Grandes". O que isso significa e eu quero ativá-lo?

Eu tenho esse erro InnoDB no MySQL 5.0. Mysqld foi parado de forma limpa, mas consegui perder ib_logfile0 & ib_logfile1 depois. Agora, após uma inicialização limpa, o InnoDB fez sua "recuperação de falhas". Eu passei pelo negócio innodb_force_recovery=4, consertei uma tabela MyISAM travada e agora a replicação está pronta, além disso. Grandes números comprometidos:

111116 15:49:36  InnoDB: Error: page 393457 log sequence number 111 561,760,232
InnoDB: is in the future! Current system log sequence number 70 3,946,969,851.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html
InnoDB: for more information.

Isso está em um servidor escravo. O erro acima vomita às centenas. Encontrei esta resposta: "insira e exclua > 64 GB de dados, para que o número de sequência de log seja inflado o suficiente".

http://forums.mysql.com/read.php?22,50163,50163#msg-50163

Esse número mágico de 64 GB vem de 4 GB * 16, onde o "número principal" do log innodb desse cara precisava aumentar de 0 a 15. O meu vai de 70 a 111 = 164 GB. Isso levará 5 dias. Continuarei trabalhando para acelerar meu script e executá-lo em paralelo para acelerar isso. Enquanto isso, espero que alguém tenha uma resposta melhor. Isso é bobo.

Temos uma situação em que podemos (A) implantar instâncias de um aplicativo em um banco de dados MySQL usando prefixo de tabela ou (B) usar bancos de dados MySQL diferentes para cada instância do aplicativo, por exemplo,

Configurar um":

central_database
  app1_table1
  app1_table2
  app1_tablen
...
  appn_table1
  appn_table2
  appn_tablen

O resultado final é um banco de dados grande com muitas tabelas.

Configuração "B":

app1_db
  table1
  table2
  tablen

...

appn_db
  table1
  table2
  tablen

O resultado final são muitos bancos de dados com algumas tabelas.

Todas as coisas iguais (por exemplo, quantidade de dados, número de instâncias de aplicativos etc.), quais são os prós e contras de usar qualquer uma das abordagens? O que seria prejudicial para o desempenho e a manutenção do banco de dados? O aplicativo é baseado em PHP 5, executado no Apache 2.x, e estamos executando o MySQL 5.x.

Muito obrigado pelo seu tempo e pensamentos!

Esta é uma questão puramente acadêmica, na medida em que não está causando nenhum problema e estou apenas interessado em ouvir alguma explicação para o comportamento.

Pegue uma tabela de contagem CTE de junção cruzada padrão de Itzik Ben-Gan:

USE [master]
GO

SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO

CREATE FUNCTION [dbo].[TallyTable] 
(   
    @N INT
)
RETURNS TABLE WITH SCHEMABINDING AS
RETURN 
(
    WITH 
    E1(N) AS 
    (
        SELECT 1 UNION ALL SELECT 1 UNION ALL SELECT 1 UNION ALL 
        SELECT 1 UNION ALL SELECT 1 UNION ALL SELECT 1 UNION ALL 
        SELECT 1 UNION ALL SELECT 1 UNION ALL SELECT 1 UNION ALL SELECT 1
    )                                       -- 1*10^1 or 10 rows
    , E2(N) AS (SELECT 1 FROM E1 a, E1 b)   -- 1*10^2 or 100 rows
    , E4(N) AS (SELECT 1 FROM E2 a, E2 b)   -- 1*10^4 or 10,000 rows
    , E8(N) AS (SELECT 1 FROM E4 a, E4 b)   -- 1*10^8 or 100,000,000 rows

    SELECT TOP (@N) ROW_NUMBER() OVER (ORDER BY (SELECT NULL)) AS N FROM E8 
)
GO

Emita uma consulta que criará uma tabela de número de linha de 1 milhão:

SELECT
    COUNT(N)
FROM
    dbo.TallyTable(1000000) tt

Dê uma olhada no plano de execução paralela para esta consulta:

Observe que a contagem de linha 'real' antes do operador de coleta de fluxos é 1.004.588. Após o operador de coleta de fluxos, a contagem de linhas é de 1.000.000 esperados. Mais estranho ainda, o valor não é consistente e varia de execução para execução. O resultado da CONTAGEM é sempre correto.

Emita a consulta novamente, forçando o plano não paralelo:

SELECT
    COUNT(N)
FROM
    dbo.TallyTable(1000000) tt
OPTION (MAXDOP 1)

Desta vez, todos os operadores mostram as contagens de linha 'reais' corretas.

Eu tentei isso em 2005SP3 e 2008R2 até agora, mesmos resultados em ambos. Alguma ideia do que pode causar isso?

Achei que isso foi resolvido com o link abaixo - a solução alternativa funciona - mas o patch não. Trabalhando com o suporte da Microsoft para resolver.

http://support.microsoft.com/kb/2606883

Ok, tenho um problema que gostaria de enviar ao StackOverflow para ver se alguém tem uma ideia.

Observe que isso é com SQL Server 2008 R2

Problema: excluir 3.000 registros de uma tabela com 15.000 registros leva de 3 a 4 minutos quando um acionador está ativado e apenas 3 a 5 segundos quando o acionador está desativado.

Configuração da mesa

Duas tabelas chamaremos de Principal e Secundária. Secundário contém registros de itens que desejo excluir, portanto, quando executo a exclusão, ingresso na tabela Secundária. Um processo é executado antes da instrução de exclusão para preencher a tabela secundária com os registros a serem excluídos.

Excluir Declaração:

DELETE FROM MAIN 
WHERE ID IN (
   SELECT Secondary.ValueInt1 
   FROM Secondary 
   WHERE SECONDARY.GUID = '9FFD2C8DD3864EA7B78DA22B2ED572D7'
);

Esta tabela tem muitas colunas e cerca de 14 índices NC diferentes. Eu tentei um monte de coisas diferentes antes de determinar que o gatilho era o problema.

• Ative o bloqueio de página (desativamos por padrão)
• Estatísticas coletadas manualmente
• Coleta automática de estatísticas desativada
• Integridade e fragmentação do índice verificado
• Descartou o índice clusterizado da tabela
• Examinou o plano de execução (nada aparecendo como índices ausentes e o custo foi de 70 por cento para a exclusão real com cerca de 28 por cento para a junção / mesclagem dos registros

Gatilhos

A tabela tem 3 gatilhos (um para operações de inserção, atualização e exclusão). Modifiquei o código para que a trigger delete apenas retorne, depois selecione uma para ver quantas vezes ela é disparada. Ele dispara apenas uma vez durante toda a operação (como esperado).

ALTER TRIGGER [dbo].[TR_MAIN_RD] ON [dbo].[MAIN]
            AFTER DELETE
            AS  
                SELECT 1
                RETURN

Para recapitular

• Com o Trigger ativado - a instrução leva de 3 a 4 minutos para ser concluída
• Com o gatilho desligado - a instrução leva de 3 a 5 segundos para ser concluída

Alguém tem alguma ideia do porquê?

Observe também - não procurando alterar essa arquitetura, adicionar índices de remoção, etc. como uma solução. Esta tabela é a peça central para algumas das principais operações de dados e tivemos que ajustá-la e ajustá-la (índices, bloqueio de página etc.)

Aqui está o xml do plano de execução (os nomes foram alterados para proteger os inocentes)

<?xml version="1.0" encoding="utf-16"?>
<ShowPlanXML xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" Version="1.1" Build="10.50.1790.0" xmlns="http://schemas.microsoft.com/sqlserver/2004/07/showplan">
  <BatchSequence>
    <Batch>
      <Statements>
        <StmtSimple StatementCompId="1" StatementEstRows="185.624" StatementId="1" StatementOptmLevel="FULL" StatementOptmEarlyAbortReason="GoodEnoughPlanFound" StatementSubTreeCost="0.42706" StatementText="DELETE FROM MAIN WHERE ID IN (SELECT Secondary.ValueInt1 FROM Secondary WHERE Secondary.SetTMGUID = '9DDD2C8DD3864EA7B78DA22B2ED572D7')" StatementType="DELETE" QueryHash="0xAEA68D887C4092A1" QueryPlanHash="0x78164F2EEF16B857">
          <StatementSetOptions ANSI_NULLS="true" ANSI_PADDING="true" ANSI_WARNINGS="true" ARITHABORT="false" CONCAT_NULL_YIELDS_NULL="true" NUMERIC_ROUNDABORT="false" QUOTED_IDENTIFIER="true" />
          <QueryPlan CachedPlanSize="48" CompileTime="20" CompileCPU="20" CompileMemory="520">
            <RelOp AvgRowSize="9" EstimateCPU="0.00259874" EstimateIO="0.296614" EstimateRebinds="0" EstimateRewinds="0" EstimateRows="185.624" LogicalOp="Delete" NodeId="0" Parallel="false" PhysicalOp="Clustered Index Delete" EstimatedTotalSubtreeCost="0.42706">
              <OutputList />
              <Update WithUnorderedPrefetch="true" DMLRequestSort="false">
                <Object Database="[MyDatabase]" Schema="[dbo]" Table="[MAIN]" Index="[IX_MAIN_02]" IndexKind="Clustered" />
                <Object Database="[MyDatabase]" Schema="[dbo]" Table="[MAIN]" Index="[PK_MAIN_ID]" IndexKind="NonClustered" />
                <Object Database="[MyDatabase]" Schema="[dbo]" Table="[MAIN]" Index="[UK_MAIN_01]" IndexKind="NonClustered" />
                <Object Database="[MyDatabase]" Schema="[dbo]" Table="[MAIN]" Index="[IX_MAIN_03]" IndexKind="NonClustered" />
                <Object Database="[MyDatabase]" Schema="[dbo]" Table="[MAIN]" Index="[IX_MAIN_04]" IndexKind="NonClustered" />
                <Object Database="[MyDatabase]" Schema="[dbo]" Table="[MAIN]" Index="[IX_MAIN_05]" IndexKind="NonClustered" />
                <Object Database="[MyDatabase]" Schema="[dbo]" Table="[MAIN]" Index="[IX_MAIN_06]" IndexKind="NonClustered" />
                <Object Database="[MyDatabase]" Schema="[dbo]" Table="[MAIN]" Index="[IX_MAIN_07]" IndexKind="NonClustered" />
                <Object Database="[MyDatabase]" Schema="[dbo]" Table="[MAIN]" Index="[IX_MAIN_08]" IndexKind="NonClustered" />
                <Object Database="[MyDatabase]" Schema="[dbo]" Table="[MAIN]" Index="[IX_MAIN_09]" IndexKind="NonClustered" />
                <Object Database="[MyDatabase]" Schema="[dbo]" Table="[MAIN]" Index="[IX_MAIN_10]" IndexKind="NonClustered" />
                <Object Database="[MyDatabase]" Schema="[dbo]" Table="[MAIN]" Index="[IX_MAIN_11]" IndexKind="NonClustered" />
                <Object Database="[MyDatabase]" Schema="[dbo]" Table="[MAIN]" Index="[UK_MAIN_12]" IndexKind="NonClustered" />
                <Object Database="[MyDatabase]" Schema="[dbo]" Table="[MAIN]" Index="[IX_MAIN_13]" IndexKind="NonClustered" />
                <RelOp AvgRowSize="15" EstimateCPU="1.85624E-05" EstimateIO="0" EstimateRebinds="0" EstimateRewinds="0" EstimateRows="185.624" LogicalOp="Top" NodeId="2" Parallel="false" PhysicalOp="Top" EstimatedTotalSubtreeCost="0.127848">
                  <OutputList>
                    <ColumnReference Column="Uniq1002" />
                    <ColumnReference Database="[MyDatabase]" Schema="[dbo]" Table="[MAIN]" Column="RelationshipID" />
                  </OutputList>
                  <Top RowCount="true" IsPercent="false" WithTies="false">
                    <TopExpression>
                      <ScalarOperator ScalarString="(0)">
                        <Const ConstValue="(0)" />
                      </ScalarOperator>
                    </TopExpression>
                    <RelOp AvgRowSize="15" EstimateCPU="0.0458347" EstimateIO="0" EstimateRebinds="0" EstimateRewinds="0" EstimateRows="185.624" LogicalOp="Left Semi Join" NodeId="3" Parallel="false" PhysicalOp="Merge Join" EstimatedTotalSubtreeCost="0.12783">
                      <OutputList>
                        <ColumnReference Column="Uniq1002" />
                        <ColumnReference Database="[MyDatabase]" Schema="[dbo]" Table="[MAIN]" Column="RelationshipID" />
                      </OutputList>
                      <Merge ManyToMany="false">
                        <InnerSideJoinColumns>
                          <ColumnReference Database="[MyDatabase]" Schema="[dbo]" Table="[Secondary]" Column="ValueInt1" />
                        </InnerSideJoinColumns>
                        <OuterSideJoinColumns>
                          <ColumnReference Database="[MyDatabase]" Schema="[dbo]" Table="[MAIN]" Column="ID" />
                        </OuterSideJoinColumns>
                        <Residual>
                          <ScalarOperator ScalarString="[MyDatabase].[dbo].[MAIN].[ID]=[MyDatabase].[dbo].[Secondary].[ValueInt1]">
                            <Compare CompareOp="EQ">
                              <ScalarOperator>
                                <Identifier>
                                  <ColumnReference Database="[MyDatabase]" Schema="[dbo]" Table="[MAIN]" Column="ID" />
                                </Identifier>
                              </ScalarOperator>
                              <ScalarOperator>
                                <Identifier>
                                  <ColumnReference Database="[MyDatabase]" Schema="[dbo]" Table="[Secondary]" Column="ValueInt1" />
                                </Identifier>
                              </ScalarOperator>
                            </Compare>
                          </ScalarOperator>
                        </Residual>
                        <RelOp AvgRowSize="19" EstimateCPU="0.0174567" EstimateIO="0.0305324" EstimateRebinds="0" EstimateRewinds="0" EstimateRows="15727" LogicalOp="Index Scan" NodeId="4" Parallel="false" PhysicalOp="Index Scan" EstimatedTotalSubtreeCost="0.0479891" TableCardinality="15727">
                          <OutputList>
                            <ColumnReference Column="Uniq1002" />
                            <ColumnReference Database="[MyDatabase]" Schema="[dbo]" Table="[MAIN]" Column="ID" />
                            <ColumnReference Database="[MyDatabase]" Schema="[dbo]" Table="[MAIN]" Column="RelationshipID" />
                          </OutputList>
                          <IndexScan Ordered="true" ScanDirection="FORWARD" ForcedIndex="false" ForceSeek="false" NoExpandHint="false">
                            <DefinedValues>
                              <DefinedValue>
                                <ColumnReference Column="Uniq1002" />
                              </DefinedValue>
                              <DefinedValue>
                                <ColumnReference Database="[MyDatabase]" Schema="[dbo]" Table="[MAIN]" Column="ID" />
                              </DefinedValue>
                              <DefinedValue>
                                <ColumnReference Database="[MyDatabase]" Schema="[dbo]" Table="[MAIN]" Column="RelationshipID" />
                              </DefinedValue>
                            </DefinedValues>
                            <Object Database="[MyDatabase]" Schema="[dbo]" Table="[MAIN]" Index="[PK_MAIN_ID]" IndexKind="NonClustered" />
                          </IndexScan>
                        </RelOp>
                        <RelOp AvgRowSize="11" EstimateCPU="0.00392288" EstimateIO="0.03008" EstimateRebinds="0" EstimateRewinds="0" EstimateRows="3423.53" LogicalOp="Index Seek" NodeId="5" Parallel="false" PhysicalOp="Index Seek" EstimatedTotalSubtreeCost="0.0340029" TableCardinality="171775">
                          <OutputList>
                            <ColumnReference Database="[MyDatabase]" Schema="[dbo]" Table="[Secondary]" Column="ValueInt1" />
                          </OutputList>
                          <IndexScan Ordered="true" ScanDirection="FORWARD" ForcedIndex="false" ForceSeek="false" NoExpandHint="false">
                            <DefinedValues>
                              <DefinedValue>
                                <ColumnReference Database="[MyDatabase]" Schema="[dbo]" Table="[Secondary]" Column="ValueInt1" />
                              </DefinedValue>
                            </DefinedValues>
                            <Object Database="[MyDatabase]" Schema="[dbo]" Table="[Secondary]" Index="[IX_Secondary_01]" IndexKind="NonClustered" />
                            <SeekPredicates>
                              <SeekPredicateNew>
                                <SeekKeys>
                                  <Prefix ScanType="EQ">
                                    <RangeColumns>
                                      <ColumnReference Database="[MyDatabase]" Schema="[dbo]" Table="[Secondary]" Column="SetTMGUID" />
                                    </RangeColumns>
                                    <RangeExpressions>
                                      <ScalarOperator ScalarString="'9DDD2C8DD3864EA7B78DA22B2ED572D7'">
                                        <Const ConstValue="'9DDD2C8DD3864EA7B78DA22B2ED572D7'" />
                                      </ScalarOperator>
                                    </RangeExpressions>
                                  </Prefix>
                                </SeekKeys>
                              </SeekPredicateNew>
                            </SeekPredicates>
                          </IndexScan>
                        </RelOp>
                      </Merge>
                    </RelOp>
                  </Top>
                </RelOp>
              </Update>
            </RelOp>
          </QueryPlan>
        </StmtSimple>
      </Statements>
    </Batch>
  </BatchSequence>
</ShowPlanXML>

Eu tenho uma pergunta geral sobre o design de tabelas do SQL Server 2008. Atualmente, temos uma mesa com mais de 600 GB e que cresce cerca de 3 GB por dia. Esta tabela tem os indecis apropriados, mas está se tornando um grande problema ao executar consultas e apenas por causa de seu tamanho. A questão é se devo dividir a tabela em várias tabelas por ano e mês (isso se encaixaria em como outros departamentos dividem seus grandes conjuntos de dados) ou devemos aproveitar o particionamento integrado ao SQL Server. Parece que usar o particionamento exigiria menos alterações de código. Pelo que li ao particionar, você ainda consulta apenas uma tabela e o servidor lida com como obter os dados. Se seguíssemos a rota de várias tabelas, teríamos que lidar com a extração de dados de várias tabelas.

Estou usando o Microsoft SQL Server 2008. Minha pergunta é: Como descartar várias tabelas com prefixo comum em uma consulta?

algo como esses nomes de tabela:

LG_001_01_STLINE, 
LG_001_02_STFICHE

Eu tenho um requisito para criar um procedimento armazenado que emule uma sequência TSQL. Ou seja, sempre fornece um valor inteiro distinto crescente em cada chamada. Além disso, se um inteiro for passado, ele deve retornar esse valor se nunca houver um resultado maior ou o próximo inteiro mais alto disponível. Escusado será dizer que pode haver vários clientes ligando para este SP ao mesmo tempo.

Dada uma tabela MetaInfo com colunas MetaKey varchar(max) e MetaValueLong bigInt. Espera-se que a linha com a MetaKey de 'Internal-ID-Last' contenha o último valor mais alto atribuído. Eu criei o seguinte procedimento armazenado:

CREATE PROCEDURE [dbo].[uspGetNextID]
(
  @inID bigInt 
)
AS
BEGIN
    SET NOCOUNT ON;

    BEGIN TRANSACTION

    UPDATE MetaInfo WITH (ROWLOCK) 
      SET MetaValueLong = CASE 
                            WHEN ISNULL(MetaValueLong,0) > @inID THEN MetaValueLong+1 
                            ELSE @inID+1
                          END 
    WHERE MetaKey = 'Internal-ID-Last'

    SELECT MetaValueLong 
    FROM MetaInfo
    WHERE MetaKey = 'Internal-ID-Last'

    COMMIT TRANSACTION 

END

Minha pergunta é simples: esse procedimento armazenado funciona conforme o esperado (todos os chamadores receberão um resultado exclusivo)?