Qual é a diferença entre clusterware Oracle e Real Application Clusters? Se tivermos 2 servidores e quisermos juntá-los em um cluster, por que existem dois produtos de software separados?
Suponha que temos um servidor que possui apenas 1 CPU com 1 núcleo, então precisamos de 1 licença de banco de dados Oracle para instalar um banco de dados nele. Agora, se precisarmos adicionar um segundo servidor, combiná-los em cluster e instalar o banco de dados nele, quantas licenças precisaremos - 2 licenças de banco de dados e 1 licença de clusterware ou 1 licença de banco de dados e 1 licença de cluster? Não tenho certeza, como o Oracle trata os servidores de cluster da Oracle - como um servidor ou ainda como servidores separados? Como precisaríamos comprar software de cluster caro da Oracle, seria lógico para a Oracle tratar os servidores associados como um só.
AFAIK, existem três tipos principais de estrutura usados para armazenar dados de índice do Oracle: B-tree, R-tree e Bitmap. Todos os índices usam uma dessas estruturas. No entanto, não tenho certeza sobre os índices de texto CONTEXT, CTXCAT e CTXRULE Oracle...
Você pode criar um índice e definir o comprimento do prefixo, para que o índice armazene apenas os primeiros símbolos iniciais de cada valor da coluna. Fica assim no MySQL:
CREATE INDEX table_idx ON emp(last_name(8));
Existe uma alternativa de como fazer isso no Oracle?
Os índices de hash são úteis quando você tem uma tabela grande com URLs e precisa consultar por eles. Portanto, uma solução seria ter uma coluna adicional "url_crc32" que será preenchida com o valor da URL com hash por meio do gatilho nas inserções. Um índice em url_crc32 seria definitivamente mais rápido do que o índice na coluna URL que é um tipo de texto.
Não é muito comum consultar dados por URL. O caso mais frequente seria consultar dados de texto por fragmento e os índices de hash são inúteis nesse caso. Então, estou curioso para saber se você usa esses índices de hash e, em caso afirmativo, quando você usa? IMHO Oracle não possui índices de hash nativos, portanto, isso deve ser feito manualmente.
É possível monitorar a função e conceder/revogar privilégios usando gatilhos? Estou ciente de fazer isso usando as ferramentas de auditoria da Oracle, no entanto, é interessante se é possível fazer isso usando gatilhos.
Podemos criar o gatilho do banco de dados em um evento de esquema concreto (ON SCOTT.SCHEMA) ou em todos os esquemas (ON SCHEMA). No entanto, também podemos usar ON DATABASE ao criar o gatilho do banco de dados. Qual a diferença entre eles? É alguma coisa herdada? ON DATABASE deve ser usado ao usar AFTER STARTUP ou AFTER STARTUP porque definitivamente está relacionado apenas ao banco de dados, mas o mesmo que é feito usando ON SCHEMA pode ser feito usando ON DATABASE, então qual é a diferença? Não consigo encontrar referências nos documentos do Oracle sobre isso.
Não podemos COMMIT/ROLLBACK em gatilhos DML porque a transação é tratada manualmente após a instrução DML. No entanto, os gatilhos de banco de dados parecem ser uma exceção. Por exemplo, suponha que haja um gatilho de banco de dados:
CREATE OR REPLACE TRIGGER user_login_as
AFTER LOGON
ON SCHEMA
BEGIN
INSERT INTO user_login_log(username, log_date, action) VALUES (user, sysdate, 'User has logged in');
END user_login_as;
O gatilho não contém um procedimento de transação autônomo com commit dentro dele, então quem está confirmando a inserção? Este gatilho funciona como um encanto e insere um novo registro na tabela de log após o logon do usuário. Cheira a funcionalidade oculta do Oracle e não consigo encontrar nenhuma referência nos documentos do Oracle sobre isso. Estou usando Oracle11g.
É (ou pelo menos era) conhecido que você não pode usar instruções DML em uma tabela mutante dentro de um gatilho. Um trecho da documentação do Oracle :
Uma tabela mutante é uma tabela que está sendo modificada por uma instrução UPDATE, DELETE ou INSERT, ou uma tabela que pode ser atualizada pelos efeitos de uma restrição DELETE CASCADE.
A sessão que emitiu a instrução de disparo não pode consultar ou modificar uma tabela mutante. Essa restrição impede que um acionador veja um conjunto inconsistente de dados.
No entanto, não consigo entender por que esse gatilho de demonstração não está falhando com um erro de "tabela mutante" quando executo um insert into empuso do SQL Developer ou do SQL*Plus:
CREATE OR REPLACE TRIGGER emp_bri
BEFORE INSERT ON emp
FOR EACH ROW
BEGIN
SELECT max(id) + 1 INTO :NEW.id FROM emp;
UPDATE emp SET salary = 5000;
END emp_bri;
A inserção é concluída com sucesso com o próximo idvalor e atualiza todos os empregistros. Estou usando o Oracle Database 11g Enterprise Edition Release 11.2.0.1.0. Eu li sobre gatilhos compostos, mas a amostra não os usa.
O uso de procedimentos Oracle PL/SQL para controlar o acesso a dados é frequentemente enfatizado em livros de PL/SQL e outras fontes como sendo uma abordagem mais segura. Já vi vários sistemas onde toda a lógica de negócio relacionada com dados é realizada através de pacotes, procedures e funções, por isso o código da aplicação torna-se bastante "burro" e fica apenas responsável pela parte de visualização. Eu até ouvi alguns desenvolvedores chamarem essas abordagens e arquitetos de direção de nazis do banco de dados :) porque todo o código lógico reside no banco de dados. Eu sei sobre os benefícios de desempenho do procedimento de banco de dados, mas agora estou interessado em uma "melhor segurança" ao usar o modelo de cliente grosso e os procedimentos de banco de dados. Presumo que esse design seja usado principalmente quando bancos de dados Oracle (e talvez MS SQL Server) são usados.
Eu concordo que tal abordagem melhora a segurança, mas apenas se não houver muitos usuários e cada usuário do sistema tiver uma conta de banco de dados, então podemos controlar e monitorar o acesso aos dados por meio da segurança padrão do usuário do banco de dados. No entanto, como tal abordagem aumenta a segurança para um sistema web médio onde o modelo de cliente grosso é usado: por exemplo, um usuário de banco de dados com concessões DML em todas as tabelas e outros usuários são tratados usando tabelas "users" e "user_rights"? Poderíamos usar procedimentos de banco de dados, salvar nomes de usuário no uso de contexto para filtragem, mas a vulnerabilidade reside na raiz - se a conta do banco de dados principal estiver comprometida, nada ajudará. É claro que em um sistema real podemos considerar pelo menos vários usuários principais (por exemplo frontend_db_user, backend_db_user).
Então, o uso de procedimentos armazenados pl/sql (todas as operações DML por meio de procedimentos) ajuda a aumentar a segurança em sistemas de modelo de cliente grosso (sistemas da web)?
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?
Quais são os casos em que o enfileiramento avançado da Oracle é o mecanismo preferencial para implementar os requisitos funcionais? Por exemplo, a transferência de dinheiro da conta bancária A para a conta bancária B pode teoricamente ser considerada como duas operações diferentes e pode ser implementada separadamente - primeiro, enfileirar a transferência de dinheiro da conta A (atualizar) e depois enfileirar a transferência de dinheiro para a conta B (atualizar) . No entanto, é óbvio que não pode ser feito assim porque essas duas operações devem ser feitas em uma operação consistente - na transação.
Talvez o enfileiramento avançado deva ser considerado apenas ao desenvolver procedimentos/funções armazenados que executam alguma lógica que é feita internamente (fazendo operações DML e chamando outro proc/fnc armazenado local) e externamente (chamando alguns webservices). Ao usar essas chamadas para webservices, não podemos envolver tudo em uma transação consistente, então a única maneira é usar algum mecanismo de enfileiramento ...
Quaisquer exemplos detalhados da vida real seriam apreciados.
O que estou curioso não são os detalhes da tecnologia em si, mas sim quais são os casos reais de uso dessas mensagens, porque nunca fiz isso antes. Tipo, por que preciso passar alguns dados (carga útil da mensagem)?
Parece que o modelo de processo de servidor compartilhado da Oracle é melhor do que o modelo de processo de servidor dedicado. Em uma configuração de servidor compartilhado, os processos de usuário do cliente se conectam a um despachante e podem suportar várias conexões de cliente simultaneamente (origem) . Além disso, o servidor compartilhado pode ser configurado para pool de conexão e multiplexação de sessão, portanto, todas essas coisas devem trazer um grande aumento de desempenho. Então, com essas vantagens, há casos em que o modelo de processo de servidor dedicado deve ser usado?
A partir do ponto de separação de dados lógicos, existem tablespaces que consistem em segmentos que consistem em extends que consistem em blocos oracle que consistem em blocos OS. Qual estrutura lógica realmente contém dados de registro concreto (onde os dados de todos os campos do mesmo registro residem lado a lado no sistema de arquivos). No mundo do MySQL, existe uma página de dados (8, 16 KB) que contém um ou mais registros no mesmo endereço físico.
Além disso, como determinar qual tamanho é o melhor? Quanto mais páginas existirem, mais fragmentação de dados aparecerá e isso pode afetar o desempenho.
Eu tenho várias perguntas:
1) Se o Oracle gerencia o High-water Mark e o Low High-water Mark no tablespace ASSM, temos que pensar nisso ao pensar em desempenho? Quero dizer, o Oracle gerencia os próprios blocos excluídos e não verifica esses blocos durante a verificação completa da tabela, ou ainda temos que reduzir essas tabelas (alter table mytable shrink space;) para limpar esses blocos excluídos e aumentar o desempenho?
2) Se o ASSM oferece automatização para este e outros itens relacionados, sem dúvida há uma compensação de desempenho ao escolher o ASSM em vez do MSSM. Quais devem ser os principais critérios na escolha de ASSM ou MSSM?
ATUALIZAÇÃO . Fiz um teste no meu notebook com o mytable (ASSM). Primeiro, inseriu 1.000.000 registros. A consulta "select count(*) from mytable" estava sendo executada em média 0,05 s. Em seguida, fez DELETE completo. A mesma consulta estava sendo executada em média 0,03 s, então talvez o Oracle ainda estivesse lendo os blocos excluídos. Somente após TRUNCATE a consulta é executada em média 0,001 s. Talvez o ASSM demore para reduzir o espaço da tabela ou ainda tenho que reduzi-lo manualmente?