Jason Krs's questions

Acho que tenho um problema de banco de dados... Não necessariamente com Oracle Forms (10g)...Deixa eu explicar...

Estou tentando implementar esta configuração de segurança do Oracle Forms Menu Quando eu faço isso, ele diz que recebo ORA - 01775 "Looping Chain of Synonyms".... Como não tenho IDEIA de qual sinônimo está criando o problema, eu queria saber como voces podem me ajudar a corrigir esse problema.... Talvez haja um script DBA em algum lugar para resolver isso....

ATUALIZAR

O log de rastreamento do Oracle Database diz que o SQL culpado é:

select ROLE GRPNAME ,FLAG GRPFLG from FRM50_ENABLED_ROLES order by ROLE desc e FRM50_ENABLED_ROLESé criado a partir da etapa 1 aqui

Essa instrução é executada corretamente onde eu a executo no SQL*PLUS

Estou estudando um pouco de DBA e me deparei com falha/recuperação de instância.

Digamos que o usuário A faça DML e o usuário B também faça DML.

Neste ponto, acredito que seja seguro assumir que o cache de buffer de banco de dados contém blocos de tabela alterados e segmentos de desfazer, e também que o buffer de log contém informações de redo para o novo valor de blocos de tabela e o novo valor de segmentos de desfazer.

• Caso 1: Nenhum usuário emite uma COMMITe nenhuma gravação no disco por DBWn e falha de instância. Resultado: DB não corrompido. É como se o DML deles nunca tivesse ocorrido.

• Caso 2: Somente o usuário A emite um arquivo COMMIT. As alterações não confirmadas do usuário B são gravadas no disco e a instância falha. O LGWR terá escrito dados suficientes no redo log , especialmente os segmentos de undo do usuário B , para que a fase de rollback da recuperação torne o banco de dados consistente novamente

• Caso 3: Nenhum usuário emite a, COMMIT mas seus blocos de tabela alterados são antigos o suficiente para fazer o DBWn gravá-los em disco. Então BOOM! A instância falha. Como será SMONrealizado o rollback para limpar blocos sujos de arquivos de dados aqui? Especialmente porque não há valores de segmento de desfazer para eles no log de refazer aqui.

Depois de muitas tentativas e erros, consegui enviar um e-mail com UTL_SMPT. No código abaixo, em uma versão anterior, usei um arquivo raw e T_BLOB para p_attach_filee enviei um PDF ilegível de 32 K como anexo. Nada mal. Mas o PDF sendo maior que 32 K e também quero poder lê-lo, usei a versão original do código. Mas não funciona. Ele diz que UTL_ENCODE está falhando no loop FOR.

O código de erro é

Abaixo está o código completo do que eu fiz até agora

**Meu código para ler BLOB**

CREATE DIRECTORY PDF_DIR as 'c:\doc\';

create table tmpblob(x varchar2(200), y blob);

DECLARE
v_file_loc BFILE;
v_diagram_loc BLOB;
v_diagram_size INTEGER;
BEGIN
  v_file_loc := BFILENAME('PDF_DIR','doc.pdf');
  v_diagram_size := DBMS_LOB.GETLENGTH(v_file_loc);
  DBMS_OUTPUT.PUT_LINE('Pdf size: ' || v_diagram_size);
  DBMS_OUTPUT.PUT_LINE('Inserting Pdf Diagram Row');
  INSERT INTO tmpblob (x,y)
  VALUES (' ', EMPTY_BLOB )
  RETURNING y INTO v_diagram_loc;
  DBMS_OUTPUT.PUT_LINE('Loading Content of PDF ');
  DBMS_LOB.LOADFROMFILE(v_diagram_loc, v_file_loc, v_diagram_size);
  COMMIT;
  EXCEPTION
  WHEN OTHERS
  THEN
  DBMS_OUTPUT.PUT_LINE('OTHERS Exception ' || sqlerrm);
END; 

DECLARE
 -- l_name images.name%TYPE := 'site_logo.gif';
  l_blob tmpblob.y%TYPE;
BEGIN
  SELECT y
  INTO   l_blob
  FROM   tmpblob;

  send_mail(p_to          => '[email protected]',
            p_from        => '[email protected]',
            p_subject     => 'Test Message',
            p_text_msg    => 'This is a test message.',
            p_attach_name => 'doc.pdf',
            p_attach_mime => 'application/pdf',
            p_attach_blob => l_blob,
            p_smtp_host   => '192.168.50.1');
END;

SEND_MAIL Procedure : Source => oracle-base

CREATE OR REPLACE PROCEDURE send_mail (p_to          IN VARCHAR2,
                                       p_from        IN VARCHAR2,
                                       p_subject     IN VARCHAR2,
                                       p_text_msg    IN VARCHAR2 DEFAULT NULL,
                                       p_attach_name IN VARCHAR2 DEFAULT NULL,
                                       p_attach_mime IN VARCHAR2 DEFAULT NULL,
                                       p_attach_blob IN BLOB DEFAULT NULL,
                                       p_smtp_host   IN VARCHAR2,
                                       p_smtp_port   IN NUMBER DEFAULT 25)
AS
  l_mail_conn   UTL_SMTP.connection;
  l_boundary    VARCHAR2(50) := '----=*#abc1234321cba#*=';
  l_step        PLS_INTEGER  := 12000; -- make sure you set a multiple of 3 not higher than 24573
BEGIN
  l_mail_conn := UTL_SMTP.open_connection(p_smtp_host, p_smtp_port);
  UTL_SMTP.helo(l_mail_conn, p_smtp_host);
  UTL_SMTP.mail(l_mail_conn, p_from);
  UTL_SMTP.rcpt(l_mail_conn, p_to);

  UTL_SMTP.open_data(l_mail_conn);

  UTL_SMTP.write_data(l_mail_conn, 'Date: ' || TO_CHAR(SYSDATE, 'DD-MON-YYYY HH24:MI:SS') || UTL_TCP.crlf);
  UTL_SMTP.write_data(l_mail_conn, 'To: ' || p_to || UTL_TCP.crlf);
  UTL_SMTP.write_data(l_mail_conn, 'From: ' || p_from || UTL_TCP.crlf);
  UTL_SMTP.write_data(l_mail_conn, 'Subject: ' || p_subject || UTL_TCP.crlf);
  UTL_SMTP.write_data(l_mail_conn, 'Reply-To: ' || p_from || UTL_TCP.crlf);
  UTL_SMTP.write_data(l_mail_conn, 'MIME-Version: 1.0' || UTL_TCP.crlf);
  UTL_SMTP.write_data(l_mail_conn, 'Content-Type: multipart/mixed; boundary="' || l_boundary || '"' || UTL_TCP.crlf || UTL_TCP.crlf);

  IF p_text_msg IS NOT NULL THEN
    UTL_SMTP.write_data(l_mail_conn, '--' || l_boundary || UTL_TCP.crlf);
    UTL_SMTP.write_data(l_mail_conn, 'Content-Type: text/plain; charset="iso-8859-1"' || UTL_TCP.crlf || UTL_TCP.crlf);

    UTL_SMTP.write_data(l_mail_conn, p_text_msg);
    UTL_SMTP.write_data(l_mail_conn, UTL_TCP.crlf || UTL_TCP.crlf);
  END IF;

  IF p_attach_name IS NOT NULL THEN
    UTL_SMTP.write_data(l_mail_conn, '--' || l_boundary || UTL_TCP.crlf);
    UTL_SMTP.write_data(l_mail_conn, 'Content-Type: ' || p_attach_mime || '; name="' || p_attach_name || '"' || UTL_TCP.crlf);
    UTL_SMTP.write_data(l_mail_conn, 'Content-Transfer-Encoding: base64' || UTL_TCP.crlf);
    UTL_SMTP.write_data(l_mail_conn, 'Content-Disposition: attachment; filename="' || p_attach_name || '"' || UTL_TCP.crlf || UTL_TCP.crlf);

    FOR i IN 0 .. TRUNC((DBMS_LOB.getlength(p_attach_blob) - 1 )/l_step) LOOP
      UTL_SMTP.write_data(l_mail_conn, UTL_RAW.cast_to_varchar2(UTL_ENCODE.base64_encode(DBMS_LOB.substr(p_attach_blob, l_step, i * l_step + 1))));
    END LOOP;

    UTL_SMTP.write_data(l_mail_conn, UTL_TCP.crlf || UTL_TCP.crlf);
  END IF;

  UTL_SMTP.write_data(l_mail_conn, '--' || l_boundary || '--' || UTL_TCP.crlf);
  UTL_SMTP.close_data(l_mail_conn);

  UTL_SMTP.quit(l_mail_conn);
END;
/

Parece que as principais funcionalidades de um programa aplicativo em que estou trabalhando não são nada além de entidades associativas . Portanto, as relações um-para-muitos produzem "metadados" que apenas alimentarão (de uma forma ou de outra) as entidades associativas para as funcionalidades de nossa aplicação.

Agora temos um diagrama entidade-relacionamento (ERD) que tem muitos um-para-muitos (mais de 10 tabelas) e apenas uma entidade associativa. O que isso diz sobre esse modelo ou o aplicativo?

É melhorável, ou seja, a aplicação pode contornar mais funcionalidades se o ERD for melhorado para adicionar mais entidades associativas?

Ter poucas entidades associativas significa que a aplicação não será rica em funcionalidades?

Considerações adicionais

O que eu estou querendo saber é: se as declarações de escopo do projeto levam a um ERD com apenas uma relação muitos-para-muitos e uma dúzia de um-para-muitos, isso significaria que o projeto não resolve muitos problemas (funcionalidades) exceto apenas digitalizar muitos dados?

Eu acho que com menos muitos para muitos, eles apenas espelharão no início (a menos que criemos consultas de junção para outros propósitos...).

Ou simplesmente: um número alto de associações muitos-para-muitos significa que o software será mais rico em funcionalidades do que com menos muitos-para-muitos (não inclua consultas de junção nos pensamentos para este)?

Eu li que o modo de servidor compartilhado permite que os processos do despachante usem duas novas estruturas SGA: filas (solicitação e resposta) e UGA (que é apenas "descarregado" do PGA no SGA)

Com isso, um único despachante pode lidar com várias conexões de cliente.

Meu problema é que vi uma expressão que não entendo: "circuito virtual". O que ele faz e onde exatamente está posicionado?

O seguinte é um trecho de um livro ORACLE

Durante a recuperação do cache, o Oracle reproduz as transações dos arquivos redo log online desde o último ponto de verificação. Durante essa operação de avanço, as alterações confirmadas e não confirmadas são aplicadas aos arquivos de dados. No final da operação rollforward, os arquivos de dados terão alterações confirmadas, alterações não confirmadas que foram gravadas nos arquivos de dados para liberar espaço no cache do buffer e alterações não confirmadas aplicadas pela operação rollforward . O banco de dados pode ser aberto assim que a recuperação do cache for concluída.

A frase em negrito acima é a que eu não entendo. Como um arquivo de redo log pode gerar dados não confirmados, já que todas as suas informações são registradas após o COMMIT?

Além disso, diz

Na fase de recuperação da transação da recuperação da instância, o Oracle aplica blocos de desfazer para reverter alterações não confirmadas em blocos de dados que foram gravados antes da falha da instância ou feitos pela operação de avanço durante a recuperação do cache .

Eu entendo que se os blocos sujos foram gravados no disco sem um COMMIT anterior (se possível), durante a recuperação da transação, os blocos de desfazer podem ser usados ​​para revertê-los. MAS como os blocos de desfazer podem ser usados ​​para reverter alterações não confirmadas (o que são essas alterações de qualquer maneira ...) introduzidas pela repetição de logs de refazer durante a recuperação do cache?

Hmmm, não entendo, pois o redo log online, que deve conter apenas informações confirmadas, cria informações não confirmadas durante a recuperação da instância.

Abaixo está uma descrição do ORACLETIMESTAMP WITH LOCAL TIME ZONE

... os dados armazenados no banco de dados são normalizados para o fuso horário do banco de dados e o deslocamento do fuso horário não é armazenado como parte dos dados da coluna. Quando os usuários recuperam os dados, o Oracle os retorna no fuso horário da sessão local dos usuários .

O que os dados armazenados no banco de dados são normalizados para o fuso horário do banco de dados ? Normalizado... como?

Se for normalizado, por que não é retornado de acordo com o fuso horário do servidor em vez do fuso horário da sessão local dos usuários ... Como é "sessão" e não "servidor"?

Eu estava lendo o manual de conceitos do Oracle 12c. Então percebi que algo não é "tecnicamente" explicado. Segue trecho do parágrafo 13.2.2.2:

Quando um banco de dados é fechado como parte de um SHUTDOWN com qualquer opção diferente de ABORT, o Oracle Database grava dados no SGA nos arquivos de dados e nos arquivos de redo log online. Em seguida, o banco de dados fecha os arquivos de dados on-line e os arquivos de redo log on-line ...... Depois que o banco de dados é fechado, o Oracle Database desmonta o banco de dados para desassociá-lo da instância .

Não entendo tecnicamente o que acontece com essas duas frases em negrito acima. Alguma ideia?

Não conheço todo o processo, mas acredito que quando um arquivo é fechado, o sistema operacional ou o programa o retira da RAM. Não consigo alinhar isso com as frases em negrito acima.

Basta fazer isso: startup open;

Então show parameter background_dump

O resultado do comando show na minha máquina é: /ora01/app/oracle/product/12.1.0/db_1/rdbms/log

Portanto, quando vou a esse local, não há registro de alerta lá.

Então eu fui e $ORACLE_BASE/diag/rdbms/<db_name>/<oracle_sid>/trace encontrei o log de alerta lá.

Então, minha pergunta é por que BACKGROUND_DUMP_DEST não contém o caminho correto para o log de alerta?

Digitei show con_name;sqlDeveloper mas o resultado é o seguinte erro: SP2-0158: unknown SHOW option "con_name"... Outros comandos como Show user; funcionam perfeitamente. Eu tentei no sqlplus e não há problema lá.

Alguma ideia do que está acontecendo aqui?

ps: Estou usando o Oracle 12c no Linux