Estou fazendo um banco de dados no sql server e mostra um erro que "CREATE DATABASE permission denied in database 'master'"
estou usando o log do administrador em si. O que eu preciso fazer? Por favor, sugira uma correção!
Eu me sinto meio envergonhado aqui, sempre usei os termos "coluna" e "campo" de forma completamente intercambiável, o que recentemente causou alguma confusão em uma discussão técnica.
Foi-me dito, no entanto, que isso não estava correto, que deveria ser (traduzindo cada termo em terminologia de planilha, ignorando tipos de dados e todas as outras coisas que tornam os bancos de dados úteis):
- Coluna de banco de dados: como uma coluna de planilha
- Registro de banco de dados: como uma linha de planilha
- Campo de banco de dados: como uma "célula" de planilha (uma coluna específica de uma linha específica)
Isto está certo? Eu poderia jurar que coluna e campo são usados de forma mais intercambiável do que isso. Eu certamente fui.
Então não adicionamos campos a uma tabela, adicionamos colunas a uma tabela, e os campos só são relevantes quando falamos de dados dentro de um registro?
Outros pensamentos sobre coluna vs campo?
Edit: para esclarecer, o contexto atual é o MS SQL Server. Meu histórico antes do SQL Server era o MS Access, o que pode influenciar no uso desses termos.
Existe uma maneira de clonar a segurança e as permissões dos usuários no Microsoft SQL Server, de preferência usando a GUI do SQL Server Management Studio?
Eu tenho meu servidor de produção (ubuntu 13.10) rodando com postgresql 9.1.
Eu quero usar alguns recursos do 9.3, portanto, quero atualizar.
Alguém poderia me ajudar a atualizar de 9.1 para 9.3 para que haja um tempo de inatividade não superior a 30 minutos. ou então?
A principal preocupação é evitar a perda de dados ou redundância de arquivos.
Estou trabalhando em um banco de dados de terceiros.
Quando tento visualizar a definição de uma visão clicando com o botão direito do mouse CREATE TOe depois em NEW QUERY EDIT WINDOW, estou recebendo um erro:
Esta propriedade pode não existir para este objeto ou pode não ser recuperável devido a direitos de acesso insuficientes. O texto é criptografado.
Eu uso o MongoDB para armazenar valores medidos periodicamente. A cada ~100 ms, um monte de valores é inserido como documento. Funciona bem, mas estou preocupado com problemas de desempenho. (Eu uso inserções seguras, parece que no PyMongo esse é o padrão.)
O que acontece se houver mais inserções por segundo do que o mongod é capaz de salvar no disco rígido? Haverá algum aviso ou simplesmente falhará silenciosamente?
Existe algum método para monitorar a carga de gravação? Eu encontrei apenas o db.serverStatus().writeBacksQueuedque é sempre definido como falso quando eu o chamo. Como posso testar quantos dados devo inserir para preencher a fila de gravação?
mongostatexibe bloqueios. Isso é algo com que eu deveria me preocupar?
insert query update delete getmore command flushes mapped vsize res faults locked db idx miss % qr|qw ar|aw netIn netOut conn repl time
*117 *0 *0 *0 0 2|0 0 17.4g 35.3g 3.76g 0 .:6.5% 0 0|0 0|0 124b 6k 2 SLV 09:58:10
*111 *0 *0 *0 0 2|0 0 17.4g 35.3g 3.76g 0 .:0.8% 0 0|0 0|0 124b 6k 2 SLV 09:58:11
*111 *0 *0 *0 0 2|0 0 17.4g 35.3g 3.76g 0 .:4.2% 0 0|0 0|0 124b 6k 2 SLV 09:58:1
Devo me preocupar com bloqueios de gravação? O que acontece com uma inserção durante um período de bloqueio de gravação? É enfileirado e armazenado posteriormente?
Estou pensando em uma configuração de replicação simples usando um mestre e um escravo. A sincronização inicial ou um processo de ressincronização bloqueia os bancos de dados?
(Estou usando a versão 2.4.3.)
Atualização: acho que respondi parcialmente à minha própria pergunta. Consegui obter até 12.000 inserções por segundo usando um loop while simples inserindo um pequeno documento de teste. Mas qr|qw ainda mostra que a fila de leitura e gravação ainda está vazia:
insert query update delete getmore command flushes mapped vsize res faults locked db idx miss % qr|qw ar|aw netIn netOut conn repl time
11234 *0 2 *0 1563 1|0 1 21.9g 44.3g 1.22g 0 testdb:58.9% 0 1|0 1|1 797k 980k 6 PRI 10:26:32
12768 *0 2 *0 1284 1|0 0 21.9g 44.3g 1.22g 0 testdb:58.0% 0 0|0 0|1 881k 1m 6 PRI 10:26:33
12839 *0 2 *0 1231 1|0 0 21.9g 44.3g 1.22g 0 testdb:60.3% 0 0|0 0|1 883k 1m 6 PRI 10:26:34
12701 *0 2 *0 910 1|0 0 21.9g 44.3g 1.22g 0 testdb:61.8% 0 0|0 0|1 858k 1m 6 PRI 10:26:35
12241 *0 2 *0 1206 1|0 0 21.9g 44.3g 1.22g 0 testdb:56.7% 0 0|0 0|0 843k 1m 6 PRI 10:26:36
11581 *0 2 *0 1406 1|0 0 21.9g 44.3g 1.22g 0 testdb:61.8% 0 0|0 0|1 811k 1m 6 PRI 10:26:37
8719 *0 2 *0 1210 1|0 0 21.9g 44.3g 1.22g 0 testdb:43.8% 0 0|0 0|1 618k 762k 6 PRI 10:26:38
11429 *0 2 *0 1469 1|0 0 21.9g 44.3g 1.22g 0 testdb:60.6% 0 0|0 0|1 804k 993k 6 PRI 10:26:39
12779 *0 2 *0 1092 1|0 0 21.9g 44.3g 1.22g 0 testdb:60.2% 0 1|0 0|1 872k 1m 6 PRI 10:26:40
12757 *0 2 *0 436 1|0 0 21.9g 44.3g 1.22g 0 testdb:59.7% 0 0|0 0|1 838k 432k 6 PRI 10:26:41
Suponho que isso signifique que as inserções sozinhas não causarão muitos problemas: "As filas tenderão a aumentar se você estiver fazendo muitas operações de gravação junto com outras operações pesadas de gravação, como remoções de longo alcance". (encontrado aqui ]
Minha pergunta em aberto: o que acontece com meus dados se a fila de gravação aumentar a longo prazo?
Eu tenho um banco de dados MySQL que contém uma grande quantidade de dados (100-200 GB - um monte de medições científicas). A grande maioria dos dados é armazenada em uma tabela Sample. Agora estou criando uma réplica escrava do banco de dados e queria aproveitar as vantagens innodb_file_per_tabledurante o processo. Então configurei innodb_file_per_tablena minha configuração slave e importei o dump do banco de dados. Para minha surpresa, falhou com
ERRO 1114 (HY000) na linha 5602: A tabela 'Sample' está cheia
Atualmente, o arquivo Sample.ibdtem cerca de 93 GB, com mais de 600 GB de espaço livre disponível na partição, portanto, não é um problema de espaço livre em disco. Nem parece estar atingindo qualquer tipo de limite do sistema de arquivos (estou usando ext4).
Eu ficaria grato por qualquer idéia do que poderia ser a causa, ou o que investigar.
Atualização: estou usando mysql Ver 14.14 Distrib 5.1.66, for debian-linux-gnu (x86_64).
SELECT @@datadir; -- returns `/home/var/lib/mysql/`
SHOW VARIABLES LIKE '%innodb_data_file_path%'; -- ibdata1:10M:autoextend
df -h /home/var/lib/mysql/
768G 31G 699G 5% /home
Existem diferenças entre Owned Schemase Role Members?
Pelo que entendi, Role Memberssão obrigatórios - o usuário precisa ter pelo menos uma das caixas de seleção Role Membersmarcadas.
No entanto, o Owned Schemasnão é obrigatório. Isso realmente me faz pensar por que há uma necessidade de ter o Owned Schemaslá.
O Tablespaceparâmetro é opcional ao criar tabelas.
Ao executar uma CREATE TABLEinstrução, o Oracle atribui o padrão caso não tenha sido definido.
No banco de dados padrão existe um tablespace "USERS". Se houvesse vários tablespaces definidos, qual deles seria atribuído?
Eu tenho uma chave composta exclusiva como fr(fromid,toid) na tabela, quando executo a consulta com explicação recebo o seguinte resultado:
Impossible WHERE noticed after reading const tables`
A consulta que fiz:
explain SELECT rid FROM relationship WHERE fromid=78 AND toid=60
Qualquer ajuda?
EDIT1:
Quando eu uso a consulta abaixo:
explain SELECT rid FROM relationship WHERE fromid=60 and toid=78 AND is_approved='s' OR is_approved='f' OR is_approved='t'
Eu vejo USING WHEREem vez da mensagem anterior, mas quando uso a consulta abaixo:
explain SELECT rid FROM relationship WHERE fromid=60 and toid=78 AND (is_approved='s' OR is_approved='f' OR is_approved='t')
Eu novamente recebo a primeira impossible ...mensagem! O que esses parênteses fazem aqui?
EDIT2:
CREATE TABLE `relationship` (
`rid` int(10) unsigned NOT NULL AUTO_INCREMENT,
`fromid` mediumint(8) unsigned NOT NULL,
`toid` mediumint(8) unsigned NOT NULL,
`type` tinyint(3) unsigned NOT NULL,
`is_approved` char(1) NOT NULL,
PRIMARY KEY (`rid`),
UNIQUE KEY `fromid` (`fromid`,`toid`),
KEY `toid` (`toid`),
CONSTRAINT `relationship_ibfk_1` FOREIGN KEY (`fromid`) REFERENCES `user` (`uid`) ON DELETE CASCADE ON UPDATE CASCADE,
CONSTRAINT `relationship_ibfk_2` FOREIGN KEY (`toid`) REFERENCES `user` (`uid`) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB
EDIT3:
Como o site mysql diz:
Impossível ONDE notado depois de ler as tabelas const
O MySQL leu todas as tabelas const (e do sistema) e notou que a cláusula WHERE é sempre falsa.
Mas na consulta recebo o resultado que quero, a WHEREparte não é false. Existe alguém que poderia explicar isso e lançar alguma luz sobre o assunto?