Eu estou querendo saber se é possível atualizar uma definição de gatilho no MySQL. Por exemplo, eu tenho um gatilho T e quero adicionar algumas novas funcionalidades a ele.
Minha suposição é que eu preciso largar e recriá-lo.
Quais são as melhores práticas na administração de banco de dados para tais cenários?
Tenho apenas 2 GB restantes, então preciso remover essa tabela de histórico. Esta tabela agora está vazia, mas o espaço em disco do banco de dados não foi liberado. E o arquivo de banco de dados é de 320 GB.
Aqui está parte do meu registro de ponto de verificação:
2014-03-26 11:51:29.341 CDT,,,18682,,532854fc.48fa,4985,,2014-03-18 09:15:24 CDT,,0,LOG,00000,"checkpoint complete: wrote 15047 buffers (1.4%); 0 transaction log file(s) added, 0 removed, 30 recycled; write=68.980 s, sync=1.542 s, total=70.548 s; sync files=925, longest=0.216 s, average=0.001 s",,,,,,,,,""
2014-03-26 11:56:05.430 CDT,,,18682,,532854fc.48fa,4987,,2014-03-18 09:15:24 CDT,,0,LOG,00000,"checkpoint complete: wrote 16774 buffers (1.6%); 0 transaction log file(s) added, 0 removed, 31 recycled; write=72.542 s, sync=17.164 s, total=89.733 s; sync files=885, longest=3.812 s, average=0.019 s",,,,,,,,,""
2014-03-26 12:01:21.650 CDT,,,18682,,532854fc.48fa,4989,,2014-03-18 09:15:24 CDT,,0,LOG,00000,"checkpoint complete: wrote 14436 buffers (1.4%); 0 transaction log file(s) added, 0 removed, 33 recycled; write=122.350 s, sync=5.212 s, total=127.676 s; sync files=924, longest=3.740 s, average=0.005 s",,,,,,,,,""
2014-03-26 12:06:25.028 CDT,,,18682,,532854fc.48fa,4991,,2014-03-18 09:15:24 CDT,,0,LOG,00000,"checkpoint complete: wrote 13277 buffers (1.3%); 0 transaction log file(s) added, 0 removed, 29 recycled; write=126.217 s, sync=5.733 s, total=131.991 s; sync files=894, longest=1.859 s, average=0.006 s",,,,,,,,,""
2014-03-26 12:10:41.958 CDT,,,18682,,532854fc.48fa,4993,,2014-03-18 09:15:24 CDT,,0,LOG,00000,"checkpoint complete: wrote 20765 buffers (2.0%); 0 transaction log file(s) added, 0 removed, 28 recycled; write=88.015 s, sync=10.818 s, total=98.872 s; sync files=881, longest=2.690 s, average=0.012 s",,,,,,,,,""
Percebi que às vezes nosso banco de dados é muito lento - você pode ver um número muito grande de consultas normalmente curtas travadas por muito mais tempo do que agora. Acontece regularmente sem um culpado claro.
Pergunta: O ponto de verificação pode causar isso? O que acontece na fase de "sincronização" do ponto de verificação?
Eu tenho uma coluna computada persistente em uma tabela que é simplesmente composta de colunas concatenadas, por exemplo
CREATE TABLE dbo.T
(
ID INT IDENTITY(1, 1) NOT NULL CONSTRAINT PK_T_ID PRIMARY KEY,
A VARCHAR(20) NOT NULL,
B VARCHAR(20) NOT NULL,
C VARCHAR(20) NOT NULL,
D DATE NULL,
E VARCHAR(20) NULL,
Comp AS A + '-' + B + '-' + C PERSISTED NOT NULL
);
Isso Compnão é exclusivo e D é a data de início válida de cada combinação de A, B, C, portanto, uso a seguinte consulta para obter a data final de cada uma A, B, C(basicamente a próxima data inicial para o mesmo valor de Comp):
SELECT t1.ID,
t1.Comp,
t1.D,
D2 = ( SELECT TOP 1 t2.D
FROM dbo.T t2
WHERE t2.Comp = t1.Comp
AND t2.D > t1.D
ORDER BY t2.D
)
FROM dbo.T t1
WHERE t1.D IS NOT NULL -- DON'T CARE ABOUT INACTIVE RECORDS
ORDER BY t1.Comp;
Em seguida, adicionei um índice à coluna computada para auxiliar nesta consulta (e também em outras):
CREATE NONCLUSTERED INDEX IX_T_Comp_D ON dbo.T (Comp, D) WHERE D IS NOT NULL;
O plano de consulta, no entanto, me surpreendeu. Eu teria pensado que, como tenho uma cláusula where informando isso D IS NOT NULLe estou classificando por Comp, e não fazendo referência a nenhuma coluna fora do índice, que o índice na coluna computada poderia ser usado para digitalizar t1 e t2, mas vi um índice agrupado Varredura.
Então forcei o uso desse índice para ver se dava um plano melhor:
SELECT t1.ID,
t1.Comp,
t1.D,
D2 = ( SELECT TOP 1 t2.D
FROM dbo.T t2
WHERE t2.Comp = t1.Comp
AND t2.D > t1.D
ORDER BY t2.D
)
FROM dbo.T t1 WITH (INDEX (IX_T_Comp_D))
WHERE t1.D IS NOT NULL
ORDER BY t1.Comp;
Que deu este plano
Isso mostra que uma pesquisa de chave está sendo usada, cujos detalhes são:
Agora, de acordo com a documentação do SQL-Server:
Você pode criar um índice em uma coluna computada definida com uma expressão determinística, mas imprecisa, se a coluna estiver marcada como PERSISTED na instrução CREATE TABLE ou ALTER TABLE. Isso significa que o Mecanismo de Banco de Dados armazena os valores calculados na tabela e os atualiza quando quaisquer outras colunas das quais a coluna calculada depende são atualizadas. O Mecanismo de Banco de Dados usa esses valores persistentes ao criar um índice na coluna e quando o índice é referenciado em uma consulta. Essa opção permite criar um índice em uma coluna computada quando o Mecanismo de Banco de Dados não puder provar com precisão se uma função que retorna expressões de coluna computada, particularmente uma função CLR criada no .NET Framework, é determinística e precisa.
Portanto, se, como os documentos dizem "o mecanismo de banco de dados armazena os valores calculados na tabela" , e o valor também está sendo armazenado em meu índice, por que é necessária uma pesquisa de chave para obter A, B e C quando eles não são referenciados em a consulta em tudo? Eu suponho que eles estão sendo usados para calcular o Comp, mas por quê? Além disso, por que a consulta pode usar o índice em t2, mas não em t1?
NB, marquei o SQL Server 2008 porque esta é a versão em que meu principal problema está, mas também recebo o mesmo comportamento em 2012.
No próximo ano, estou ajudando em um esforço para limpar vários ambientes do SQL Server.
Temos cerca de 10.000 procedimentos armazenados e estimamos que apenas cerca de 1.000 deles são usados regularmente, e outros 200 ou mais são usados em raras ocasiões, o que significa que temos muito trabalho a fazer.
Como temos vários departamentos e equipes que podem acessar esses bancos de dados e procedimentos, nem sempre somos nós que chamamos os procedimentos, o que significa que devemos determinar quais procedimentos estão sendo chamados. Além disso, queremos determinar isso em alguns meses, não em alguns dias (o que elimina algumas possibilidades).
Uma abordagem para isso é usar o SQL Server Profilere rastrear quais procedimentos estão sendo chamados e compará-los com a lista de quais procedimentos temos, enquanto marcamos se os procedimentos são usados ou não. A partir daí, poderíamos mover os procedimentos para um esquema diferente, caso um departamento viesse gritar.
Está usando a Profilerabordagem mais eficaz aqui? E/ou algum de vocês fez algo semelhante e encontrou outra maneira/melhor maneira de fazer isso?
Dada uma tabela com apenas uma coluna IDENTITY, como você insere uma nova linha? Eu tentei o seguinte:
INSERT INTO TABLE
(Syntax error)
INSERT INTO TABLE VALUES()
(Syntax error)
INSERT INTO TABLE (Id) VALUES()
(Syntax error)
Estou testando algo e só preciso da coluna IDENTITY. Não é para produção. Caso contrário, tal tabela pode ser usada como um gerador de sequência, onde nenhuma outra coluna é necessária.
Recentemente, assumi um projeto e descobri que na maioria das tabelas a chave primária tem a propriedade " NOT FOR REPLICATION".
Não sou DBA, mas certamente na maioria dos bancos de dados, um registro sem chave primária seria considerado corrompido. A chave primária da maioria desses registros quase certamente seria usada como chave estrangeira em algum lugar.
Isso foi um erro por parte do desenvolvedor anterior (que não trabalha mais para a empresa) ou há alguma outra lógica envolvida? Nós nem usamos replicação no ambiente de produção, então isso não afeta nada sério de qualquer maneira, mas eu queria saber se existem outros efeitos colaterais de remover todas essas diretivas que eu não conheço.
Não encontrei muitos resultados úteis para vários termos de pesquisa relacionados a esse tópico, então tenho certeza de que esse é apenas um erro bobo que preciso reverter, então essa pergunta é realmente para aliviar minha paranóia.
Isenção de responsabilidade: admito que ainda não tentei isso, mas não tenho certeza se saberia se não estivesse funcionando corretamente, então gostaria de perguntar.
Eu gostaria de executar um trabalho de backup noturno (via pg_dumpall) de um servidor de espera ativa executando a replicação de streaming, para evitar colocar essa carga no primário. Eu só vi menção de algumas pegadinhas que as pessoas encontraram, por exemplo, aqui e aqui , mas muito pouca orientação. Tudo bem se o backup ficar um pouco atrás do primário, desde que seja consistente (o que deveria ser).
Minhas perguntas são:
Eu realmente quero fazer isso ou o backup deve ser feito no servidor principal? Por quê?
Ao fazer um dump no standby, quais configurações eu preciso e procedimento devo usar para fazer isso corretamente? por exemplo, devo interromper a replicação durante o backup?
Mensagem que o SQL Server Log File Viewer mostra:
Login failed for user [User]
Error: 18456, Severity: 14, State 38
O que realmente significa:
Failed to open the explicitly specified database
Minha pergunta:
Existe uma lista em algum lugar de todas as variações dos erros 18456 (Falha no login), para cada combinação de gravidade e estado, com o texto de descrição útil?
Eu tive um Google, mas não consigo encontrar nada além de combinações específicas.
Inspirado por uma questão de modelagem Django: Modelagem de banco de dados com múltiplas relações muitos-para-muitos em Django . O db-design é algo como:
CREATE TABLE Book
( BookID INT NOT NULL
, BookTitle VARCHAR(200) NOT NULL
, PRIMARY KEY (BookID)
) ;
CREATE TABLE Tag
( TagID INT NOT NULL
, TagName VARCHAR(50) NOT NULL
, PRIMARY KEY (TagID)
) ;
CREATE TABLE BookTag
( BookID INT NOT NULL
, TagID INT NOT NULL
, PRIMARY KEY (BookID, TagID)
, FOREIGN KEY (BookID) REFERENCES Book (BookID)
, FOREIGN KEY (TagID) REFERENCES Tag (TagID)
) ;
CREATE TABLE Aspect
( AspectID INT NOT NULL
, AspectName VARCHAR(50) NOT NULL
, PRIMARY KEY (AspectID)
) ;
CREATE TABLE TagAspect
( TagID INT NOT NULL
, AspectID INT NOT NULL
, PRIMARY KEY (TagID, AspectID)
, FOREIGN KEY (TagID) REFERENCES Tag (TagID)
, FOREIGN KEY (AspectID) REFERENCES Aspect (AspectID)
) ;
e a questão é como definir a BookAspectRatingtabela e reforçar a integridade referencial, de modo que não se possa adicionar uma classificação para uma (Book, Aspect)combinação inválida.
CHECKAFAIK, restrições complexas (ou ASSERTIONS) que envolvem subconsultas e mais de uma tabela, que possivelmente poderiam resolver isso, não estão disponíveis em nenhum SGBD.
Outra ideia é usar (pseudocódigo) uma visão:
CREATE VIEW BookAspect_view
AS
SELECT DISTINCT
bt.BookId
, ta.AspectId
FROM
BookTag AS bt
JOIN
Tag AS t ON t.TagID = bt.TagID
JOIN
TagAspect AS ta ON ta.TagID = bt.TagID
WITH PRIMARY KEY (BookId, AspectId) ;
e uma tabela que possui uma Chave Estrangeira para a View acima:
CREATE TABLE BookAspectRating
( BookID INT NOT NULL
, AspectID INT NOT NULL
, PersonID INT NOT NULL
, Rating INT NOT NULL
, PRIMARY KEY (BookID, AspectID, PersonID)
, FOREIGN KEY (PersonID) REFERENCES Person (PersonID)
, FOREIGN KEY (BookID, AspectID)
REFERENCES BookAspect_view (BookID, AspectID)
) ;
Três perguntas:
Existem DBMS que permitem um (possivelmente materializado) VIEWcom um PRIMARY KEY?
Existem SGBDs que permitem um FOREIGN KEYque REFERENCESum VIEW(e não apenas um base TABLE)?
Esse problema de integridade poderia ser resolvido de outra forma - com recursos de DBMS disponíveis?
Esclarecimento:
Já que provavelmente não existe uma solução 100% satisfatória - e a questão do Django nem é minha! - Estou mais interessado em uma estratégia geral de possível ataque ao problema, não em uma solução detalhada. Portanto, uma resposta como "no DBMS-X isso pode ser feito com triggers na tabela A" é perfeitamente aceitável.