Posso criar uma coluna na tabela de banco de dados (PostgreSQL) que possui uma string aleatória de valor padrão e como?
Se não for possível, por favor me avise.
Estou armazenando os dados do sensor em uma tabela SensorValues . A tabela e a chave primária são as seguintes:
CREATE TABLE [dbo].[SensorValues](
[DeviceId] [int] NOT NULL,
[SensorId] [int] NOT NULL,
[SensorValue] [int] NOT NULL,
[Date] [int] NOT NULL,
CONSTRAINT [PK_SensorValues] PRIMARY KEY CLUSTERED
(
[DeviceId] ASC,
[SensorId] ASC,
[Date] DESC
) WITH (
FILLFACTOR=75,
DATA_COMPRESSION = PAGE,
PAD_INDEX = OFF,
STATISTICS_NORECOMPUTE = OFF,
SORT_IN_TEMPDB = OFF,
IGNORE_DUP_KEY = OFF,
ONLINE = OFF,
ALLOW_ROW_LOCKS = ON,
ALLOW_PAGE_LOCKS = ON)
ON [MyPartitioningScheme]([Date])
No entanto, quando seleciono o valor do sensor válido para um tempo específico, o plano de execução me diz que está fazendo uma classificação. Por que é que?
Eu teria pensado que, como armazeno os valores classificados pela coluna Data, a classificação não ocorreria. Ou é porque o índice não é classificado apenas pela coluna Date, ou seja, não pode assumir que o conjunto de resultados está classificado?
SELECT TOP 1 SensorValue
FROM SensorValues
WHERE SensorId = 53
AND DeviceId = 3819
AND Date < 1339225010
ORDER BY Date DESC
Editar: posso fazer isso em vez disso?
Como a tabela está ordenada DeviceId, SensorId, Date e eu faço um SELECT especificando apenas um DeviceId e um SensorId , o conjunto de saída já deve estar ordenado por Date DESC . Então, eu me pergunto se a seguinte pergunta produziria o mesmo resultado em todos os casos?
SELECT TOP 1 SensorValue
FROM SensorValues
WHERE SensorId = 53
AND DeviceId = 3819
AND Date < 1339225010
De acordo com @Catcall abaixo, a ordem de classificação não é igual à ordem de armazenamento. Ou seja, não podemos assumir que os valores retornados já estão em uma ordem de classificação.
Editar: tentei esta solução CROSS APPLY, sem sorte
@Martin Smith sugeriu que eu tentasse OUTER APPLY meu resultado nas partições. Encontrei uma postagem no blog ( Índices não agrupados alinhados na tabela particionada ) descrevendo esse problema semelhante e tentei a solução um tanto semelhante à sugerida por Smith. No entanto, sem sorte aqui, o tempo de execução está no mesmo nível da minha solução original.
WITH Boundaries(boundary_id)
AS
(
SELECT boundary_id
FROM sys.partition_functions pf
JOIN sys.partition_range_values prf ON pf.function_id = prf.function_id
WHERE pf.name = 'PF'
AND prf.value <= 1339225010
UNION ALL
SELECT max(boundary_id) + 1
FROM sys.partition_functions pf
JOIN sys.partition_range_values prf ON pf.function_id = prf.function_id
WHERE pf.name = 'PF'
AND prf.value <= 1339225010
),
Top1(SensorValue)
AS
(
SELECT TOP 1 d.SensorValue
FROM Boundaries b
CROSS APPLY
(
SELECT TOP 1 SensorValue
FROM SensorValues
WHERE SensorId = 53
AND DeviceId = 3819
AND "Date" < 1339225010
AND $Partition.PF(Date) = b.boundary_id
ORDER BY Date DESC
) d
ORDER BY d.Date DESC
)
SELECT SensorValue
FROM Top1
Pergunta bastante simples, provavelmente respondida em algum lugar, mas não consigo formular a pergunta de pesquisa correta para o Google ...
O número de colunas em uma tabela específica afeta o desempenho de uma consulta, ao consultar um subconjunto dessa tabela?
Por exemplo, se a tabela Foo tiver 20 colunas, mas minha consulta selecionar apenas 5 dessas colunas, ter 20 (versus, digamos, 10) colunas afetará o desempenho da consulta? Para simplificar, suponha que qualquer coisa na cláusula WHERE esteja incluída nessas 5 colunas.
Estou preocupado com o uso do cache de buffer do Postgres, além do cache de disco do sistema operacional. Perco muito a compreensão do design de armazenamento físico do Postgres. As tabelas são armazenadas em várias páginas (o padrão é 8k de tamanho por página), mas não entendo muito bem como as tuplas são organizadas a partir daí. O PG é inteligente o suficiente para buscar apenas no disco os dados que compreendem essas 5 colunas?
Existem bons recursos para aprender o Service Broker? Estou procurando um guia para iniciantes.
Ocasionalmente, recebo um script que funcionará bem no SQL Developer ou no Toad, mas requer modificação para ser executado com sucesso no SQL*Plus. Aqui está um exemplo de pior caso contendo várias instruções, cada uma com linhas em branco, ponto e vírgula e barras:
INSERT INTO t1 VALUES ('a
;
/
');
INSERT INTO t1 VALUES ('b
;
/
');
DELETE FROM t1 WHERE c1 = 'c
;
/
';
Por vários motivos, essas instruções precisam ser executadas no SQL*Plus. As linhas em branco são fáceis de resolver com um simples...
set sqlblanklines on
Estou ciente de que o sqlterminatorpode ser alterado e/ou desativado, mas ambos exigiriam modificações no código, o primeiro move o problema sem resolvê-lo e nenhum deles resolve o problema da barra incorporada.
A melhor resposta seria uma maneira de permitir que essas instruções sejam executadas sem modificação alterando o ambiente de alguma forma (como o sqlblanklines faz). Se isso não for possível, talvez haja uma maneira de modificar programaticamente os scripts. Estou tentando evitar alterações manuais.
Dado que os campos de bits são apenas representações binárias de dados e precisam ser consultados de maneira um pouco "estranha".
Ele realmente fornece algum benefício usando um campo de bits para um valor booleano? Pelo que posso ver, parece sugerir que o espaço é o único benefício real.
Eu tenho um banco de dados MySQL (5.1) razoavelmente grande em execução na Amazon como uma instância RDS. Estou trabalhando para migrá-lo para fora da Amazon. Para fazer isso sem problemas, gostaria de configurar o novo hardware como uma réplica somente leitura da instância do RDS.
Eu sei que o RDS oferece suporte à replicação no RDS. Existe alguma maneira de configurá-lo para replicar para um host que não esteja no RDS?
Tenho duas consultas quase idênticas em execução na mesma instância do SQL Server 2005:
- A primeira é a
SELECTconsulta original gerada pelo LINQ (eu sei, eu sei... não sou o desenvolvedor do aplicativo, apenas o DBA :). - O segundo é exatamente igual ao primeiro, acrescido de um
OPTION (RECOMPILE)no final.
Nada mais foi alterado.
O primeiro leva 55 segundos toda vez que é executado.
O segundo leva 2 segundos.
Ambos os conjuntos de resultados são idênticos.
Por que essa dica geraria um ganho tão dramático no desempenho?
A entrada do Books Online em RECOMPILEnão oferece uma explicação muito detalhada:
Instrui o SQL Server Database Engine a descartar o plano gerado para a consulta após sua execução, forçando o otimizador de consulta a recompilar um plano de consulta na próxima vez que a mesma consulta for executada. Sem especificar RECOMPILE, o Mecanismo de Banco de Dados armazena em cache os planos de consulta e os reutiliza. Ao compilar planos de consulta, a dica de consulta RECOMPILE usa os valores atuais de quaisquer variáveis locais na consulta e, se a consulta estiver dentro de um procedimento armazenado, os valores atuais passados para quaisquer parâmetros.
RECOMPILE é uma alternativa útil para criar um procedimento armazenado que usa a cláusula WITH RECOMPILE quando apenas um subconjunto de consultas dentro do procedimento armazenado, em vez de todo o procedimento armazenado, deve ser recompilado. Para obter mais informações, consulte Recompilando procedimentos armazenados. RECOMPILE também é útil quando você cria guias de plano. Para obter mais informações, consulte Otimizando consultas em aplicativos implantados usando guias de plano.
Como minha consulta tem muitas variáveis locais, meu palpite é que o SQL Server é capaz de otimizá-la (sério) quando uso a OPTION (RECOMPILE)dica de consulta.
Onde quer que eu olhe, as pessoas estão dizendo que isso OPTION (RECOMPILE)deve ser evitado. A explicação para isso geralmente é que, usando essa dica, o SQL Server não é capaz de reutilizar esse plano de execução e, portanto, precisa perder tempo recompilando-o sempre.
(Mas) Dada a gigantesca vantagem de desempenho, estou inclinado a pensar que usar essa dica de consulta desta vez seria uma coisa boa.
Devo usá-lo? Se não, existe uma maneira de forçar o SQL Server a usar um plano de execução melhor sem essa dica e sem alterar o aplicativo?
Ao criar uma chave primária composta para duas ou mais colunas, por exemplo, PRIMARY KEY(col1, col2, col3); será que o sistema INDEXcada coluna individualmente?
A razão pela qual estou fazendo esta pergunta é que, quando usamos UNIQUE INDEX (col1, col2, col3), ele age apenas como INDEXpara a primeira coluna e precisamos criar INDEXs adicionais para outras colunas. Eu quero saber se esse é o caso da chave primária composta também.
Eu estava testando algumas coisas e adicionei um:
grant usage on statistics.* to cptnotsoawesome@localhost identified by 'password';
então agora quando eu faço
show grants for cptnotsoawesome@localhost;
Vejo que um deles é:
Grants for cptnotsoawesome@localhost
----------------------------------
GRANT USAGE ON *.* TO 'cptnotsoawesome'@'localhost' IDENTIFIED BY PASSWORD 'somePEW-PEWstring'
Agora eu quero removê-lo, pois acho que é um risco de segurança, então faço o seguinte:
REVOKE USAGE ON *.* FROM 'cptnotsoawesome'@'localhost' IDENTIFIED BY 'password';
FLUSH PRIVILEGES;
Mas ainda mostra essa concessão USAGE na lista de concessões.
Grants for cptnotsoawesome@localhost
----------------------------------
GRANT USAGE ON *.* TO 'cptnotsoawesome'@'localhost' IDENTIFIED BY PASSWORD 'somePEW-PEWstring'
Alguma idéia por quê? O que estou fazendo errado?