Eu li sobre o MySQL. Na minha opinião, vejo dois tipos de log muito semelhantes. O MySQL salva como e quando os dados são alterados no log. As informações são usadas para recuperação do MySQL. Estou confundindo a função de dois tipos de log.
Eu tenho cerca de 40 milhões de linhas em uma tabela MySQL e quero copiar essa tabela para outra tabela no mesmo banco de dados. Qual é a maneira mais eficiente de fazer isso? Quanto tempo levará (aprox.)?
Estou tentando solucionar um logon que não consegue visualizar determinadas tabelas em um banco de dados SQL Server 2012. Ao fazer isso, acho que não entendo muito bem o que a participação na db_ownerfunção permite. Eu posso entender os outros papéis, db_datareader and db_datawritermas continuo confuso quanto ao que db_ownerpermite.
Tentando adicionar uma NOT NULLrestrição a uma tabela com 1 bilhão de linhas. Não posso permitir um bloqueio de mesa por mais de alguns segundos. Existe uma maneira de evitar uma verificação completa da tabela durante a instrução alter table? Criei um índice na coluna esperando que fosse usado, mas isso não parece funcionar. Pode ser uma restrição de verificação? Outras opções? Obrigada!
Estou testando um aplicativo de monitoramento em uma instância do SQL Server 2000. Como posso escrever uma consulta T-SQL que leva um tempo especificado por mim? Por exemplo, a maioria das linguagens de script tem algo como o SLEEPcomando que permite pausar a execução do script por um período de tempo especificado. Estou procurando algo semelhante que seja compatível com o SQL Server 2000. O objetivo é testar as configurações de limite de consulta de execução longa do aplicativo de monitoramento.
Vamos supor que você tenha uma nodestabela como esta:
CREATE TABLE nodes (
node serial PRIMARY KEY,
parent integer NULL REFERENCES nodes(node),
ts timestamp NOT NULL DEFAULT now()
);
Ele representa uma estrutura de árvore semelhante a um nó padrão com nós raiz no topo e vários nós filhos pendurados nos nós raiz ou outros nós filhos.
Vamos inserir alguns valores de exemplo:
INSERT INTO nodes (parent) VALUES
(NULL), (NULL), (NULL), (NULL)
, (1), (1), (1), (1), (6), (1), (6)
, (9), (6), (6), (3), (3), (3), (15);
Agora eu quero recuperar os primeiros 10 nós raiz e todos os seus filhos até uma profundidade de 4:
WITH RECURSIVE node_rec AS (
(SELECT 1 AS depth, * FROM nodes WHERE parent IS NULL LIMIT 10)
UNION ALL
SELECT depth + 1, n.*
FROM nodes AS n JOIN node_rec ON (n.parent = node_rec.node)
WHERE depth < 4
)
SELECT * FROM node_rec;
Isso funciona muito bem e me dá o seguinte resultado:
depth | node | parent
-------+------+--------
1 | 1 |
1 | 2 |
1 | 3 |
1 | 4 |
2 | 5 | 1
2 | 6 | 1
2 | 7 | 1
2 | 8 | 1
2 | 10 | 1
2 | 15 | 3
2 | 16 | 3
2 | 17 | 3
3 | 9 | 6
3 | 11 | 6
3 | 13 | 6
3 | 14 | 6
3 | 18 | 15
4 | 12 | 9
Como você deve ter notado, não há ORDER BYcláusula, então a ordem não é definida. A ordem que você vê aqui é de nós raiz para nós mais profundos.
Como eu ordenaria os resultados como eles apareceriam em uma exibição em árvore expandida, como você pode ver na imagem de exemplo abaixo?
Basicamente, quero que os nós filhos sejam colocados logo após o nó pai correspondente. Se dois ou mais nós filhos tiverem o mesmo nó pai, quero que eles sejam classificados por seu carimbo de data/hora. Com base no exemplo acima, aqui está a ordem de saída desejada que estou tentando alcançar:
depth | node | parent | ts
-------+------+--------+---------
1 | 1 | | 2014-01-01 00:00:00
2 | 5 | 1 | 2014-01-01 00:10:00
2 | 6 | 1 | 2014-01-01 00:20:00
3 | 9 | 6 | 2014-01-01 00:25:00
4 | 12 | 9 | 2014-01-01 00:27:00
3 | 11 | 6 | 2014-01-01 00:26:00
3 | 13 | 6 | 2014-01-01 00:30:00
3 | 14 | 6 | 2014-01-01 00:36:00
2 | 7 | 1 | 2014-01-01 00:21:00
2 | 8 | 1 | 2014-01-01 00:22:00
2 | 10 | 1 | 2014-01-01 00:23:00
1 | 2 | | 2014-01-01 00:08:00
1 | 3 | | 2014-01-01 00:09:00
2 | 15 | 3 | 2014-01-01 10:00:00
3 | 18 | 15 | 2014-01-01 11:05:00
2 | 16 | 3 | 2014-01-01 11:00:00
2 | 17 | 3 | 2014-01-01 12:00:00
1 | 4 | | 2014-01-01 00:10:00
Na minha aplicação, com um banco de dados rodando no SQL Server 2012, tenho um trabalho (tarefa agendada) que executa periodicamente uma consulta cara e grava os resultados em uma tabela que pode ser consultada posteriormente pelo aplicativo.
Idealmente, eu gostaria de executar essa consulta cara apenas se algo mudou desde que a consulta foi executada pela última vez. Como as tabelas de origem são muito grandes, não posso simplesmente selecionar uma soma de verificação sobre todas as colunas candidatas ou algo assim.
Tenho as seguintes ideias:
- Escreva explicitamente um carimbo de data/hora da última alteração, um sinalizador "deve haver consultas" ou algo assim em uma tabela de rastreamento sempre que eu alterar algo em uma tabela de origem.
- Use um gatilho para fazer o mesmo.
No entanto, eu realmente gostaria de saber se existe uma maneira leve de detectar alterações em uma tabela sem que eu rastreie explicitamente as gravações. Posso, por exemplo, pegar o "atual" ROWVERSIONde uma tabela ou algo assim?
O SQL Server Engine Express Edition pode ser instalado no OS X? Eu uso um MacBook em casa e gostaria de usá-lo como plataforma de teste/aprendizagem para SQL Server.
Estou muito incomodado com esse comportamento estranho que estou vendo no auto_incrementvalor registrado no bidID de uma tabela de Bids após realizar a inserção em massa usando um procedimento armazenado:
INSERT INTO Bids (itemID, buyerID, bidPrice)
SELECT itemID, rand_id(sellerID, user_last_id), FLOOR((1 + RAND())*askPrice)
FROM Items
WHERE closing BETWEEN NOW() AND NOW() + INTERVAL 1 WEEK ORDER BY RAND() LIMIT total_rows;
Por exemplo, se o auto_incrementvalor bidID for 101 no início e eu inserir 100 linhas, o valor final se tornará 213 em vez de 201. No entanto, os bidIDs dessas linhas inseridas são executados sequencialmente até um máximo de 201.
Verificando o seguinte,
SHOW VARIABLES LIKE 'auto_inc%';
+--------------------------+-------+
| Variable_name | Value |
+--------------------------+-------+
| auto_increment_increment | 1 |
| auto_increment_offset | 1 |
+--------------------------+-------+
Eu não tenho idéia por que isso está acontecendo. O que poderia estar causando o salto no auto incrementvalor?
Eu tenho uma tabela com 50 mil linhas. Na verdade, é uma tabela PostGIS.
A consulta tem 4 partes (1 obrigatória) (3 opcionais)
- caixa de interseção (um retângulo de geografia) com 4 lat,long (eu uso st_intersects) [Obrigatório]
- Intervalo de datas (min, max) em um campo de data
- Tipo de arquivo (um conjunto de até 8 valores de texto) atualmente usando IN( .....), mas posso fazer disso uma tabela temporária, se necessário. Vejo que muita gente não gosta do IN.
- País (um valor de texto).
Espero cerca de 100 a 4.000 linhas retornadas
Se eu criar um índice composto na tabela, qual coluna devo usar primeiro. O mais refinado é provavelmente o local (os dados estão espalhados pelo mundo). Atualmente, tenho-o como índice GIST.
Os outros índices seriam BTREE.
Minha intuição diz que use grãos finos e claro por último. Por exemplo, existem apenas cerca de 12 tipos de arquivo, portanto, seriam baldes muito grandes para o índice.
O que dizem os gurus PostgreSQL e PostGIS (que conhecem as partes internas do sistema)?
ATUALIZAR:
Deixe-me aguçar esta questão.
- Não quero que ninguém tenha que fazer o trabalho que devo fazer. Respeito demais o seu tempo. Então, irei explicar a análise mais tarde.
- Tudo o que eu estava procurando eram alguns indicadores, dicas e diretrizes.
- Eu li esta pequena postagem excelente: https://devcenter.heroku.com/articles/postgresql-indexes#managing-and-maintaining-indexes sobre índices
- O que eu normalmente faço é criar 4 índices separados (caixa geográfica, nome do país, tipo_de_arquivo e data), mas o que quero ver é o que uma consulta composta faria.
Diga-me se alguma dessas suposições está errada. (Sou muito novo na ideia de índices compostos)
- A ordem é importante. Escolha como primeiro índice aquele que reduzirá mais as linhas (no meu caso, a localização (geografia), que é um polígono simples ou multipolígono, seria o melhor).
- Às vezes, as consultas ignoram os índices. Mas se eu criar uma consulta composta com a chave (#1, #2, #3, #4), mesmo que o usuário crie algo que peça #1, #3, o planejador ainda usará a consulta composta única, pois eles solicitam é mantido.
- Normalmente, eu criaria três consultas BTREE e uma GIST (para o tipo de geografia). O PostGIS não suporta a criação de um composto de vários tipos de índice. Então terei que usar GIST o índice composto. Mas isso não deve prejudicar as coisas.
- Se eu criar alguns índices adicionais compostos ou de valor único, o planejador é inteligente o suficiente para escolher o mais inteligente.....
- O nome do país pode ter cerca de 250 valores diferentes e está obviamente fortemente vinculado ao local (geobox), mas se o próximo melhor índice para reduzir o tamanho da linha for file_type, devo usá-lo a seguir. Não espero que os usuários usem país ou data com frequência em seus conjuntos de consulta.
- NÃO preciso me preocupar em criar um índice composto de 4 chaves aumentará muito o tamanho dos dados do índice. Ou seja, se um índice de uma chave for 90% do aumento de desempenho, não custa nada adicionar mais 3 itens para torná-lo composto. Por outro lado, eu realmente deveria criar ambos os índices. Um índice de geografia única, e também um índice composto, e deixe o planejador descobrir qual é o melhor, e ele levará em consideração o tamanho da tabela de índices.
Mais uma vez, não estou pedindo a ninguém para projetar minha solução, não perco o trabalho dos outros. Mas preciso de coisas que a documentação do PostGreSQL não me informa sobre implementação
[O motivo pelo qual ainda não tenho um resultado EXPLAIN para mostrar é que preciso criar essa tabela de 25 mil linhas a partir de uma tabela de 24 milhões de linhas. Está demorando mais do que eu pensava. Estou agrupando as coisas em 1.000 grupos de itens e permitindo que o usuário consulte a tabela de 25 mil linhas. Mas minha próxima pergunta envolverá o uso dos resultados dessa consulta para ir para a tabela de linhas MASTER 25M e retirar as coisas, e é aí que o desempenho do índice composto realmente ACERTARÁ].
exemplo de consulta abaixo:
SELECT
public.product_list_meta_mv.cntry_name AS country,
public.product_list_meta_mv.product_producer AS producer,
public.product_list_meta_mv.product_name AS prod_name,
public.product_list_meta_mv.product_type AS ptype,
public.product_list_meta_mv.product_size AS size,
ST_AsGeoJSON(public.product_list_meta_mv.the_geom, 10, 2) AS outline
FROM
public.product_list_meta_mv
WHERE
public.product_list_meta_mv.cntry_name = 'Poland'
AND
ST_Intersects(public.product_list_meta_mv.the_geom,
st_geogfromtext('SRID=4326;POLYGON((21.23107910156250 51.41601562500000,
18.64379882812500 51.41601562500000,
18.64379882812500 48.69415283203130,
21.23107910156250 48.69415283203130,
21.23107910156250 51.41601562500000))'))
AND (date >= '1/2/1900 5:00:00 AM'
AND date <= '2/26/2014 10:26:44 PM')
AND (public.product_list_meta_mv.product_type in
('CIB10','DTED0','DTED1','DTED2','CIB01','CIB05')) ;
EXPLICAR ANALISAR resultados (não coloquei nenhum índice composto, e pela velocidade que estou vendo não sei se preciso).
"Bitmap Heap Scan on catalog_full cat (cost=4.33..37.49 rows=1 width=7428) (actual time=1.147..38.051 rows=35 loops=1)"
" Recheck Cond: ('0103000020E61000000100000005000000000000005838354000000000AEB0494000000000A0A7324000000000AEB0494000000000A0A73240000000006C5D48400000000058383540000000006C5D4840000000005838354000000000AEB04940'::geography && outline)"
" Filter: (((type)::text = ANY ('{CADRG,CIB10,DTED1,DTED2}'::text[])) AND (_st_distance('0103000020E61000000100000005000000000000005838354000000000AEB0494000000000A0A7324000000000AEB0494000000000A0A73240000000006C5D48400000000058383540000000006C5D4840000000005838354000000000AEB04940'::geography, outline, 0::double precision, false) < 1e-005::double precision))"
" Rows Removed by Filter: 61"
" -> Bitmap Index Scan on catalog_full_outline_idx (cost=0.00..4.33 rows=8 width=0) (actual time=0.401..0.401 rows=96 loops=1)"
" Index Cond: ('0103000020E61000000100000005000000000000005838354000000000AEB0494000000000A0A7324000000000AEB0494000000000A0A73240000000006C5D48400000000058383540000000006C5D4840000000005838354000000000AEB04940'::geography && outline)"
"Total runtime: 38.109 ms"
EXPLAIN ANALYZE SELECT pid,product_name,type,country,date,size,cocom,description,egpl_date,ST_AsGeoJSON(outline, 10, 2) AS outline
FROM portal.catalog_full AS cat
WHERE ST_Intersects(st_geogfromtext('SRID=4326;POLYGON((21.2200927734375 51.38031005859375, 18.65478515625 51.38031005859375, 18.65478515625 48.7298583984375, 21.2200927734375 48.7298583984375, 21.2200927734375 51.38031005859375))'), cat.outline)
AND (cat.type in ('CADRG','CIB10','DTED1','DTED2'))