Ao construir um novo banco de dados em espera, é possível que ele comece a enviar logs de arquivo do primário sem ter os arquivos de dados em espera ainda?
Para quase todos os meus bancos de dados, quando executo uma SELECTinstrução, o comprimento da coluna exibida é dimensionado para a largura dos dados que estão sendo consultados. No entanto, tenho dois bancos de dados (Dev e Prod para o mesmo aplicativo) que parecem padronizar todos os tamanhos de coluna para 32 caracteres de largura. Se os dados tiverem mais de 32 caracteres ou um alias de coluna for usado, o padrão da coluna será de 128 caracteres.
Aqui estão alguns exemplos de um dos muitos bons sistemas:
>select '1234567890' XX_Identifier from dual;
XX_IDENTIF
----------
1234567890
>select '12345678901234567890' XX_Identifier from dual;
XX_IDENTIFIER
--------------------
12345678901234567890
Aqui estão alguns exemplos de um dos sistemas ruins:
>select '1234567890' XX_Identifier from dual;
XX_IDENTIFIER
--------------------------------
1234567890
>select '12345678901234567890' XX_Identifier from dual;
XX_IDENTIFIER
--------------------------------
12345678901234567890
Já verifiquei as configurações do sqlplus e estão todas iguais. Não vi nenhum parâmetro de banco de dados que parecesse fora do comum e ambos têm parâmetros NLS idênticos. Ambos os bancos de dados usam o mesmo conjunto de caracteres.
Sei que poderia definir um formato para cada coluna consultada, mas isso não deveria ser necessário, pois não está em nenhum outro banco de dados.
O banco de dados com esse problema é 11.2.0.1, enquanto todos os nossos outros são 11.2.0.4, então talvez haja um bug que não consegui encontrar. O cliente sqlplus que estou usando é 12.1.0.1 em ambos os casos.
Atualização: Os sintomas não correspondem exatamente, mas o Doc ID 330717.1 fala sobre larguras de coluna no sqlplus e basicamente diz que você não pode garantir nada sem definir o formato. Posso aceitar isso, mas como o comportamento é consistente, parece que uma causa pode ser determinada.
No Oracle, quando você tenta descartar uma tabela temporária global que está em uso, obtém a seguinte exceção:
ORA-14452: tentativa de criar, alterar ou descartar um índice na tabela temporária já em uso
Isso é causado por uma sessão que está usando o GTT em uma transação atual. Existe uma maneira de consultar o dicionário de dados para determinar quais sessões estão bloqueando a queda? Sei que posso obter as sessões com transações em andamento com algo assim, mas gostaria de restringir ainda mais.
select * from v$session
where session_id in (select session_id from dba_locks where lock_type='Transaction');
Eu tenho um bloco pl/sql no meu arquivo glogin.sql para mostrar informações de v$instance quando me conecto ao servidor de banco de dados. Existe uma maneira de suprimir o ORA-01034 que obtemos naturalmente quando a instância está ociosa? Uma instância inativa relata que está inativa quando você se conecta, portanto, qualquer coisa adicional não é necessária e pode ser confusa.
Ao fazer um RMAN DUPLICATEbackup conectado ao destino, quão atual a duplicação torna o banco de dados quando nenhum until timeé definido?
A coisa mais próxima que posso encontrar na documentação é a seguinte declaração:
Restaura e copia os arquivos de dados duplicados e os recupera com backups incrementais e arquivos de redo log arquivados para um ponto não atual no tempo.
Quão atual é esse ponto não atual no tempo? Ele se aplica a todos os logs de arquivo disponíveis no início da duplicata ou talvez eles estejam disponíveis apenas quando atingir a parte de recuperação da duplicata?
Eu tenho um procedimento que gera um XMLTYPE e quero validá-lo em um esquema. O problema é que parece haver um problema de permissão executando createSchemaBasedXML porque quando executo o procedimento como AUTHID DEFINER ele dá o erro "ORA-31050: Acesso negado", mas quando executo como AUTHID CURRENT_USER ele realmente retorna um erro específico de validação (Vou lidar com isso separadamente). CURRENT_USER não é uma solução aceitável.
Minha suposição é que CURRENT_USER funciona porque o usuário tem a função XMLADMIN. Conceder as permissões incluídas na função não resolve o problema, portanto, deve ser a capacidade das funções ignorar as ACLs.
O problema é que consultar RESOURCE_VIEW para a ACL que protege o recurso mostra que ele é protegido por /sys/acls/all_owner_acl.xml. DBMS_XDB.getPrivilegesmostra que o xsd tem todas as seguintes permissões:
<read-properties/>
<read-contents/>
<write-config/>
<link/>
<unlink/>
<read-acl/>
<write-acl-ref/>
<update-acl/>
<resolve/>
<link-to/>
<unlink-from/>
<dav:lock/>
<dav:unlock/>
<dav:write-properties/>
<dav:write-content/>
<dav:execute/>
<dav:take-ownership/>
<dav:read-current-user-privilege-set/>
O uso DBMS_XDB.getAclDocumentmostra que um principal dav:ownertem todos os privilégios, portanto, isso não deve ser suficiente para permitir que o proprietário do esquema crie XML baseado em esquema. Pensando nisso criei um bloco para rodar DBMS_XDB.createResourcecriando uma nova ACL. Posso criar a ACL com êxito e, a partir do SQLDeveloper, posso ver que ela existe no local em que a criei.
Há uma série de lugares em que posso estar errado neste processo, então o núcleo do que estou procurando é o seguinte:
O que deve estar em vigor para validar um XMLTYPE em um esquema?
=== Atualização 03/04/2013 ===
Posso definir o acl para meu arquivo xsd para /sys/acls/all_all_acl.xmle voltar para /sys/acls/all_owner_acl.xml. Como antes, nenhum deles resolve o problema de permissões. Eu também tentei um createResource usando a definição acl copiada de all_owner_acl.xl e usando o mesmo caminho daqueles arquivos de /sys/acls/. Isso pelo menos define com êxito a ACL. Eu o executei para todos os meus XSDs e consultei RESOURCE_VIEW para confirmar se eles estão configurados para a nova ACL. Depois de tudo isso, createSchemaBasedXML ainda fornece um erro de acesso negado. Minha ACL está correta ou pode haver outro problema?
<acl xmlns="http://xmlns.oracle.com/xdb/acl.xsd"
xmlns:dav="DAV:"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.oracle.com/xdb/acl.xsd
http://xmlns.oracle.com/xdb/acl.xsd" shared="true">
<ace>
<grant>true</grant>
<principal>MY_ORACLE_USER</principal>
<privilege>
<all/>
</privilege>
</ace>
</acl>
=== Atualização 09/04/2013 ===
Eu tenho um bloco anônimo que pode validar XML com sucesso com base em um esquema. Isso aponta novamente para um problema de permissão que permite que isso funcione quando as funções estão habilitadas, mas não quando não estão disponíveis.
== Atualização 12/04/2013 ===
Todas as evidências que recebo parecem indicar que há algo errado com minha ACL ou talvez mais provável com a maneira como configuro a ACL. Retirar a função XDBADMIN do usuário faz com que o bloco anônimo falhe com um erro de acesso negado, embora eu tenha concedido todas as permissões que a função fornece de acordo com dba_tab_privs. Meu setACL segue este formulário:
DBMS_XDB.setACL('/sys/schemas/MY_ORACLE_USER/account.xsd', '/sys/acls/acl_acc.xml');
Um caso de teste completo pode ser encontrado no Oracle Communities .
Um teste de unidade requer que um trabalho dbms_scheduler seja executado no mesmo nó RAC a partir do qual o teste de unidade está sendo executado. Sei que, com um banco de dados gerenciado por administrador, isso pode ser feito criando um serviço que limita as instâncias disponíveis e, em seguida, usando esse serviço em uma classe de trabalho que o trabalho usa. Minha pergunta é: como isso pode ser feito em 11.2 com gerenciamento de políticas?
Os pools podem ser criados com apenas um único servidor e os bancos de dados podem ser atribuídos a vários pools, mas, pelo que entendi, um servidor só pode ser atribuído a um único pool. Portanto, não pode ser criado um serviço que usa um único servidor e ainda ter outros serviços que usam um pool definido com vários servidores incluindo aquele.
Também sei que os serviços podem ser criados como SINGLETON ou UNIFORM, mas como o SIGNLETON não fornece servidores permitidos ou mesmo servidores preferenciais, não tenho certeza de como isso ajudaria.
Certamente estou perdendo algo que torna tudo isso possível.
Eu tenho algumas definições de esquema XML que foram registradas usando DBMS_XMLSCHEMA. Eu criei tabelas usando os XMLTypes gerados. Posso criar XML usando XMLQuery e se bem entendi, os resultados da consulta podem ser inseridos na tabela se a definição estiver correta.
Em última análise, o XML precisa ser gravado em um arquivo, mas a parte que não tenho certeza é se escrever XMLQueries do zero é a melhor maneira de gerar o XML. Existe alguma maneira de fazer com que o esquema XML gere um esboço XML para um guia ou gere XMLQuery de modelo? Os dados estão atualmente em tabelas regulares do Oracle, mas organizados de maneira bastante diferente, portanto, qualquer informação sobre como facilitar a exportação para XML com base em um conjunto específico de esquema registrado seria útil.
Quando um pacote tem estado e o cabeçalho é alterado, a primeira chamada recebe uma pilha de erros mais ou menos assim:
ORA-04068: existing state of packages has been discarded
ORA-04061: existing state of package "LRIFFEL.PKG1" has been invalidated
ORA-04065: not executed, altered or dropped package "LRIFFEL.PKG1"
ORA-06508: PL/SQL: could not find program unit being called: "LRIFFEL.PKG1"
ORA-06512: at "LRIFFEL.PKG2", line 7
ORA-06512: at line 1
Uma chamada subseqüente da mesma sessão reinicializa o estado do pacote e, portanto, é executado com êxito. O interessante é que esse comportamento parece mudar quando o chamador captura a exceção e faz um raise_application_error. Como esperado, o raise_application_error está incluído na pilha, mas ao contrário das expectativas, o ORA-04068 não está. Aqui está um exemplo de pilha de erros:
ERROR at line 1:
ORA-20001: Failed
ORA-06512: at "LRIFFEL.PKG2", line 7
ORA-04061: existing state of package "LRIFFEL.PKG1" has been invalidated
ORA-04065: not executed, altered or dropped package "LRIFFEL.PKG1"
ORA-06508: PL/SQL: could not find program unit being called: "LRIFFEL.PKG1"
ORA-06512: at line 1
Isso não parece ser apenas um problema de exibição, pois chamadas repetidas para o procedimento continuam obtendo o mesmo erro. Somente ao converter o raise_application_error de volta para um aumento simples (ou eliminar totalmente o bloco de exceção) a próxima execução inclui o ORA-04068 e a execução seguinte é bem-sucedida.
Alguém pode confirmar e/ou explicar esse comportamento? Aqui está uma receita para reproduzir o comportamento:
--Session 1 - Create Objects
create or replace package pkg1 as
vInteger Integer := 7;
procedure procA;
end;
/
create or replace
package body pkg1 as
procedure procA is
begin
DBMS_Output.Put_Line('ProcA');
end;
end;
/
create or replace
package pkg2 as
procedure procB;
end;
/
create or replace
package body pkg2 as
procedure procB is
begin
pkg1.procA;
exception
when others then
raise;
end;
end;
/
--Session 2 - Test execution.
execute pkg2.procB;
--Session 1 - Change package header and thus invalidate package state.
create or replace package pkg1 as
vInteger Integer := 8;
procedure procA;
end;
/
--Session 2 - Observe failure due to changed package state.
execute pkg2.procB;
--Session 2 - Observe success due to re-initialized package state.
execute pkg2.procB;
--Session 1 - Change Raise to Raise_Application_Error.
create or replace
package body pkg2 as
procedure procB is
begin
pkg1.procA;
exception
when others then
raise_application_error(-20001,'Failed',True);
end;
end;
/
--Session 1 - Change package header and thus invalidate package state.
create or replace package pkg1 as
vInteger Integer := 9;
procedure procA;
end;
/
--Session 2 - Observe failure due to changed package state.
execute pkg2.procB;
--Session 2 - Observe unexpected continued failures.
execute pkg2.procB;
execute pkg2.procB;
execute pkg2.procB;
execute pkg2.procB;
execute pkg2.procB;
execute pkg2.procB;
execute pkg2.procB;
--Session 1 - Change back to raise.
create or replace
package body pkg2 as
procedure procB is
begin
pkg1.procA;
exception
when others then
raise;
end;
end;
/
--Session 2 - Observe failure on the first execution.
execute pkg2.procB;
--Session 2 - Observe success.
execute pkg2.procB;
O bug 229349 parece semelhante, exceto que um gatilho está envolvido.
A documentação do Oracle tem uma seção no Guia de Ajuste de Desempenho 11.2 com o título Determinando Quais Segmentos Têm Muitos Buffers no Conjunto . A seção lista a seguinte consulta:
SELECT o.OBJECT_NAME, COUNT(*) NUMBER_OF_BLOCKS
FROM DBA_OBJECTS o, V$BH bh
WHERE o.DATA_OBJECT_ID = bh.OBJD AND o.OWNER != 'SYS'
GROUP BY o.OBJECT_NAME
ORDER BY COUNT(*);
Se alterarmos isso para uma junção à direita, obteremos linhas de v$bh, independentemente de haver ou não um object_id correspondente em dba_objects.
SELECT o.OBJECT_NAME, COUNT(*) NUMBER_OF_BLOCKS
FROM DBA_OBJECTS o, V$BH bh
WHERE o.DATA_OBJECT_ID(+) = bh.OBJD AND o.DATA_OBJECT_ID IS NULL
GROUP BY o.OBJECT_NAME
ORDER BY COUNT(*);
Minha pergunta é o que essas linhas representam? Eles têm colunas file#, block# e objd, mas os valores objd não existem em dba_objects. Despejei um dos blocos e parecia conter um índice, mas não consegui dizer mais nada sobre isso. Há muitas linhas em v$bh que correspondem a índices em dba_objects, portanto, as linhas v$bh não correspondentes não podem ser não correspondentes apenas porque são blocos de índices. Algo mais deve estar acontecendo.
Existem mais objetos não correspondentes em um dos meus sistemas, mas todos eles têm objetos não correspondentes, incluindo o sistema 11.2.0.2.6.
Atualizar:
Para o sistema com o maior número de objetos sem correspondência, a maioria pode ser correspondida ao comparar o bh.objd com o campo dataobj# de obj$. Não sei por que esses objetos não são refletidos em dba_objects, mas talvez um exame da exibição (ou uma pergunta separada) responda a isso.
Para as 391 entradas não identificadas restantes, aqui estão algumas outras informações de interesse.
SELECT class#, count(class#) FROM v$bh bh
WHERE NOT EXISTS (SELECT 1 FROM obj$ o2 WHERE o2.dataobj# = bh.objd)
GROUP BY class#
4 HAVING count(class#) > 1;
CLASS# COUNT(CLASS#)
---------- -------------
12 59
13 36
18 15
20 20
22 25
30 12
32 6
36 28
38 3
42 16
44 125
CLASS# COUNT(CLASS#)
---------- -------------
52 4
12 rows selected.
Eliminei os valores de classe com apenas uma entrada. Foram 33 deles.
SELECT status, count(status) FROM v$bh bh
WHERE NOT EXISTS (SELECT 1 FROM obj$ o2 WHERE o2.dataobj# = bh.objd)
GROUP BY status;
STATUS COUNT(STATUS)
------- -------------
xcur 361
1 row selected.
Existe uma maneira de dizer ao VALIDATE RECOVERY FILEScomando para usar um local diferente com mais espaço em disco disponível?
Quando executo o comando no RMAN, ele falha com a seguinte pilha de erros:
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03009: failure of validate command on ORA_DISK_1 channel at 06/05/2012 12:02:42
ORA-19502: write error on file "/opt/app/oracle/product/11.2.0/dbhome_1/dbs/...
ORA-27072: File I/O error
Additional information: 4
Additional information: 1071488
Additional information: 286720
ORA-19502: write error on file "/opt/app/oracle/product/11.2.0/dbhome_1/dbs/...
Isso parece ser devido ao fato de que a validação está usando o banco de dados inicial para sua área de trabalho e não há espaço em disco suficiente lá. Na verdade, posso ver os 8 GB livres caírem para zero antes que o comando falhe e o espaço seja retornado.
Este local não é afetado pela configuração do local no formato ao alocar o canal para o dispositivo.
DB_RECOVERY_FILE_DEST está definido como '+FRA', mas atualmente a maioria dos backups está em /u01/back em vez de ASM. '+FRA' tem alguns backups de arquivos de controle.
Atualizar:
Não encontrei uma maneira de fazer isso, mas também não encontrei nada definitivo dizendo que não é possível. Há um tópico da comunidade Oracle discutindo isso, mas sem resolução. Curiosamente , RESTORE ARCHIVELOG ALL VALIDATEe RESTORE VALIDATE DATABASE CHECK LOGICALnão exibem esse comportamento, o que pode ser o motivo pelo qual mais pessoas não o encontraram.
Atualização 2:
Abri um SR com o suporte da Oracle para ver se eles podem esclarecer essa dúvida.
Atualização 3:
O suporte da Oracle conseguiu reproduzir esse problema internamente e está tratando-o como um bug.
Existe uma maneira de colocar comentários em um arquivo de parâmetro de exportação da bomba de dados?
O encerramento de um banco de dados antes de fazer uma atualização ou um patch pode ser feito de várias maneiras.
shutdown immediate;
ou
shutdown abort;
startup restrict;
shutdown immediate;
ou
shutdown abort;
startup restrict;
shutdown;
ou
alter system checkpoint;
shutdown abort;
startup restrict;
shutdown immediate;
Claro que existem outras opções também. Qual deve ser preferido e por quê?
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.
A partir desses dados (supondo que o número de linhas não seja conhecido antecipadamente):
with q1 as (select mod(ora_hash(level),5) c1 from dual connect by level <=4)
select * from q1;
/*
C1
--
2
1
4
1
*/
Eu quero o produto da coluna c1 de todas as linhas. Algo como os resultados de SUM(c1) apenas, quero cada valor multiplicado pelos outros, em vez de adicionados. Nesse caso, seria 2 * 1 * 4 * 1 = 8.
/*
X1
--
8
*/
Os dados podem conter números negativos e zero, que podem ser simulados usando:
with q1 as (select mod(ora_hash(level),5)-1 c1 from dual connect by level <=4)
select * from q1;
ou
with q1 as (select mod(ora_hash(level),5)-3 c1 from dual connect by level <=4)
select * from q1;
Sei que isso pode ser feito com função de agregação personalizada, mas estou interessado em abordagens nativas.
Vejo código de desenvolvedores usando conversão de data implícita. Eu gostaria de uma resposta definitiva sobre por que eles não deveriam fazer isso.
SELECT * from dba_objects WHERE Created >= '06-MAR-2012';
Se eu usar o DBMS_Profiler para criar o perfil de um script PL/SQL de longa duração (5 horas), por quanto tempo devo esperar que o script seja executado com a criação de perfil? Sei que isso dependerá do que o script está fazendo, mas, em geral, estou olhando para segundos, minutos ou talvez mais?
Temos uma consulta que estava obtendo baixo desempenho. A raiz do problema poderia ser reproduzida usando uma consulta simples acessando apenas um índice para recuperar uma coluna (a coluna indexada) de oito linhas.
A tabela não tinha estatísticas, mas o índice tinha. Reunir novas estatísticas sobre o índice não mudou o plano, mas reunir estatísticas sobre a mesa sim. Meu entendimento era que uma consulta que pudesse ser satisfeita usando apenas o índice não precisaria acessar a tabela, portanto meu modelo mental era que as estatísticas da tabela não importariam neste caso, mas a experiência parece indicar o contrário.
Tanto o plano de explicação quanto o plano de rastreamento automático mostram apenas o acesso ao índice, mas quando as estatísticas da tabela não estão presentes, há custos e cardinalidade significativamente maiores. O autotrace mostra maior CPU, DB Time e Consistent Gets. Ainda não tentei rastreá-lo, mas posso reproduzi-lo criando/soltando estatísticas na tabela conforme mostrado abaixo. Alguém pode explicar esse comportamento?
set serveroutput on
DECLARE
numr NUMBER;
numb NUMBER;
avgr NUMBER;
nrow NUMBER;
nblk NUMBER;
numd NUMBER;
avgl NUMBER;
avgd NUMBER;
cfac NUMBER;
ilvl NUMBER;
gues NUMBER;
BEGIN
--Gather Stats.
dbms_stats.Gather_table_Stats(USER,'RESULTS');
--Gather Index Stats.
dbms_stats.Gather_index_Stats(USER,'I1');
--Show Index Stats.
dbms_stats.get_index_stats(USER, 'I1', NULL, NULL, NULL, nrow, nblk
, numd, avgl, avgd, cfac, ilvl, NULL, gues);
dbms_output.put_line('Number of rows: ' || TO_CHAR(nrow));
dbms_output.put_line('Number of blocks: ' || TO_CHAR(nblk));
dbms_output.put_line('Distinct keys: ' || TO_CHAR(numd));
dbms_output.put_line('Avg leaf blocks/key: ' || TO_CHAR(avgl));
dbms_output.put_line('Avg data blocks/key: ' || TO_CHAR(avgd));
dbms_output.put_line('Clustering factor: ' || TO_CHAR(cfac));
dbms_output.put_line('Index level: ' || TO_CHAR(ilvl));
dbms_output.put_line('IOT guess quality: ' || TO_CHAR(gues));
delete from plan_table;
END;
/
EXPLAIN PLAN FOR SELECT rsample_id FROM results
WHERE rsample_id = '0555103360';
SELECT cost, substr(lpad(' ', level-1) || operation || ' (' || options
|| ')',1,50 ) "Operation", object_name "Object"
FROM plan_table START WITH ID = 0 CONNECT BY PRIOR id=parent_id;
DECLARE
nrow NUMBER;
nblk NUMBER;
numd NUMBER;
avgl NUMBER;
avgd NUMBER;
cfac NUMBER;
ilvl NUMBER;
gues NUMBER;
BEGIN
--Delete Stats.
dbms_stats.delete_table_stats(USER,'RESULTS');
--Gather Index Stats.
dbms_stats.Gather_index_Stats('LRIFFEL','I1');
--Show Index Stats.
dbms_stats.get_index_stats(USER, 'I1', NULL, NULL, NULL, nrow, nblk
, numd, avgl, avgd, cfac, ilvl, NULL, gues);
dbms_output.put_line('Number of rows: ' || TO_CHAR(nrow));
dbms_output.put_line('Number of blocks: ' || TO_CHAR(nblk));
dbms_output.put_line('Distinct keys: ' || TO_CHAR(numd));
dbms_output.put_line('Avg leaf blocks/key: ' || TO_CHAR(avgl));
dbms_output.put_line('Avg data blocks/key: ' || TO_CHAR(avgd));
dbms_output.put_line('Clustering factor: ' || TO_CHAR(cfac));
dbms_output.put_line('Index level: ' || TO_CHAR(ilvl));
dbms_output.put_line('IOT guess quality: ' || TO_CHAR(gues));
delete from plan_table;
END;
/
EXPLAIN PLAN FOR SELECT rsample_id FROM results
WHERE rsample_id = '0555103360';
SELECT cost, substr(lpad(' ', level-1) || operation || ' (' || options
|| ')',1,50 ) "Operation", object_name "Object"
FROM plan_table START WITH ID = 0 CONNECT BY PRIOR id=parent_id;
Isso teve a seguinte saída (modificada para caber):
anonymous block completed
Number of rows: 125226611
Number of blocks: 381090
Distinct keys: 5778886
Avg leaf blocks/key: 1
Avg data blocks/key: 3
Clustering factor: 19792294
Index level: 3
IOT guess quality:
plan FOR succeeded.
COST Operation Object
----- --------------------- ------
4 SELECT STATEMENT()
4 INDEX (RANGE SCAN) I1
anonymous block completed
Number of rows: 119034073
Number of blocks: 362402
Distinct keys: 5353024
Avg leaf blocks/key: 1
Avg data blocks/key: 3
Clustering factor: 18852918
Index level: 3
IOT guess quality:
plan FOR succeeded.
COST Operation Object
----- --------------------- ------
9 SELECT STATEMENT()
9 INDEX (RANGE SCAN) I1
Depois de criar isso, notei que as estatísticas do índice eram diferentes para cada execução, embora nada devesse mudar na tabela e as estatísticas do índice fossem reunidas novamente em cada execução. Minha teoria agora é que algo nas estatísticas do índice é retido ao reunir as estatísticas da tabela com a opção cascata, mesmo quando as estatísticas do índice são reunidas novamente.
A granularidade é definida como AUTO e Cascade é definida como AUTO_CASCADE.
As tarefas do Enterprise Manager em nosso sistema RAC começaram recentemente a falhar intermitentemente na inicialização com o seguinte erro:
Erro ao avaliar fontes de parâmetros/verificações de segurança/bloqueios ORA-06508: PL/SQL: não foi possível encontrar a unidade de programa sendo chamada
Tentamos pular o DBConsole, reenviar o trabalho da biblioteca e até mesmo recompilar o pacote que está sendo referenciado. Isso está acontecendo com vários trabalhos com cerca de uma execução em cada dez agendadas com sucesso. Alguma ideia sobre o que pode ser tentado ou verificado?
Atualização: abri um SR com Oracle.
O Gerenciador de Configuração da Oracle, que de acordo com a Oracle fornece uma "resolução de problemas 40% mais rápida" , viola a HIPAA ou requer configuração específica para estar em conformidade?
Esta questão diz respeito a bancos de dados que contêm Informações de Saúde Protegidas (PHI). O escopo das perguntas abrange apenas o OCM e não o escopo mais amplo do suporte Oracle acessando o banco de dados.
O seguinte da Oracle descreve o que o OCM coleta:
O Oracle Configuration Manager pode reunir automaticamente as informações de configuração das instalações de produtos Oracle e fazer upload dessas informações nos sistemas de suporte da Oracle. As informações de configuração coletadas pelo Oracle Configuration Manager incluem:
• Patches instalados
• Plataformas, datas, versões e tipo
de implantação • Componentes e aplicativos implantados
• Conteúdo dos arquivos de configuração
• Informações sobre configurações de redeObserve que as informações coletadas pelo Oracle Configuration Manager são limitadas às informações de configuração. O utilitário não coleta dados confidenciais, como dados reais do cliente (ou seja, quaisquer dados que não sejam informações de configuração, incluindo aplicativos reais ou transações de banco de dados), valores de hash de senha, eventos de logon, etc. A nota 728985.1 do My Oracle Support fornece uma lista de todos os dados coletados pelo Oracle Configuration Manager.
De acordo com hss.gov, as seguintes informações são protegidas pela HIPAA:
A Regra de Privacidade protege todas as "informações de saúde individualmente identificáveis" mantidas ou transmitidas por uma entidade coberta ou seu parceiro de negócios, em qualquer forma ou mídia, seja eletrônica, em papel ou oral. A Regra de Privacidade chama essas informações de "informações de saúde protegidas (PHI)".12
“Informações de saúde individualmente identificáveis” são informações, incluindo dados demográficos, relacionadas a:
• a saúde ou condição física ou mental passada, presente ou futura do indivíduo,
• a prestação de cuidados de saúde ao indivíduo, ou
• o pagamento passado, presente ou futuro pela prestação de cuidados de saúde ao indivíduo,e que identifica o indivíduo ou para o qual há uma base razoável para acreditar que pode ser usado para identificar o indivíduo.13 As informações de saúde identificáveis individualmente incluem muitos identificadores comuns (por exemplo, nome, endereço, data de nascimento, CPF).