Início / user-50938

Mark Stewart's questions

Martin Hope
Mark Stewart
Asked: 2023-03-16 03:19:03 +0800 CST
  • 6

Tenho suportado muitos bancos de dados Oracle (não em tempo integral; sou programador 90% do tempo) e acabei de ver no documento de instalação do Oracle 19 Linux que armazenar arquivos de dados Oracle em um sistema de arquivos local não é recomendado. Todos os bancos de dados que tenho suportado têm os dados em um sistema de arquivos local.

Estamos configurando um novo servidor com 5 drives internos; 2 unidades pequenas para o sistema operacional e 3 unidades grandes (quatro terabytes). Então, parece que eu poderia fazer o que estou familiarizado, configurar o RAID 5 nas 3 unidades grandes, apontando para /u01. Ou configure o ASM nessas unidades. Eu toquei com ASM talvez 10 anos atrás, então não estou muito familiarizado com isso.

Para este novo servidor, um grupo de DBA do centro de dados o configurará e o manterá. Então, basicamente, estou me perguntando se há alguma coisa que preciso estar ciente ao configurar isso com dados no ASM. E também, para nossos bancos de dados existentes, quão importante é migrar do sistema de arquivos local do Linux para o ASM.

oracle
Martin Hope
Mark Stewart
Asked: 2019-08-03 10:45:05 +0800 CST
  • 1

Eu tenho duas instâncias de banco de dados, desenvolvimento e produção, que são bastante idênticas. Na produção, o cache de resultados está funcionando bem, no desenvolvimento não. O valor do parâmetro de banco de dados result_cache_max_sizefoi definido como 0, então eu o redefini para remover o valor, devolvi o banco de dados e, quando o banco de dados foi feito o backup, o valor ainda estava definido, 0então tentei começar com um PFILEsem valor para o result_cache_max_sizemesmo problema. Então eu tentei configurá-lo para 20M(valor da produção) e saltei, mas os mesmos resultados. Eu então invoquei

SELECT dbms_result_cache.status() FROM dual;

que retorna BYPASS.

Os parâmetros result_cache_max_resulte result_cache_modesão definidos para 5e MANUALem ambos os bancos de dados.

Estou usando o Enterprise Edition em ambas as instâncias (portanto, a pergunta Por que o cache de resultados está sempre desabilitado no Oracle 11g não se aplica a mim):

Desenvolvimento:

SYS@extdev02> select banner from v$version;

BANNER
----------------------------------------------------------------------------
Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Production
...

Produção:

extuat01> select banner from v$version;

BANNER
----------------------------------------------------------------------------
Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Production
...

Editar: Tentei bypassproc por resposta @BalazsPapp, mas sem sorte. Acho que já tentei, mas sem o segundo parm, que teria como padrão false pela documentação. A tentativa de hoje, incluindo um flushproc apenas por diversão:

SYS@extdev02> select dbms_result_cache.status() FROM dual; 

DBMS_RESULT_CACHE.STATUS()
---------------------------
BYPASS

SYS@extdev02> exec dbms_result_cache.bypass(true, false);

PL/SQL procedure successfully completed.

SYS@extdev02> exec dbms_result_cache.flush

PL/SQL procedure successfully completed.

SYS@extdev02> select dbms_result_cache.status() FROM dual;

DBMS_RESULT_CACHE.STATUS()
--------------------------
BYPASS

SYS@extdev02> exec dbms_result_cache.bypass(false, false);

PL/SQL procedure successfully completed.

SYS@extdev02> select dbms_result_cache.status() FROM dual;

DBMS_RESULT_CACHE.STATUS()
--------------------------
BYPASS
oracle oracle-12c
Martin Hope
Mark Stewart
Asked: 2019-03-29 10:12:54 +0800 CST
  • 2

Estou fazendo um backup incremental de nível 0 (completo) aos domingos, com o seguinte script global:

printing stored global script: weekly_backup
{
        allocate channel DISK1 device type disk format '&1/&2_Disk1_%U.bkp';
        allocate channel DISK2 device type disk format '&1/&2_Disk2_%U.bkp';
        allocate channel DISK3 device type disk format '&1/&2_Disk3_%U.bkp';
        backup section size 1g incremental level 0  as compressed backupset
                tag '&2'
                keep until time 'SYSDATE+&3'
                restore point '&2'
                database plus archivelog;
        delete noprompt obsolete;
}

E de segunda a sábado eu executo os seguintes comandos RMAN para um backup incremental de nível 1:

run {
        backup section size 1g incremental level 1  as compressed backupset archivelog all database;
        delete noprompt obsolete;
}

Minhas configurações significativas:

RMAN> show all;

RMAN configuration parameters for database with db_unique_name RCATN are:
CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default
CONFIGURE RMAN OUTPUT TO KEEP FOR 7 DAYS; # default
CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default

Agora, quando invoco meu script com um parâmetro de 15 por dias, meus conjuntos de backup de nível 0 têm os valores apropriados para Keep:

(Todo o resto desses comandos eu executei em 28 de março de 2019)

RMAN> list backupset tag=L0_2019_03_17;


List of Backup Sets
===================


BS Key  Size       Device Type Elapsed Time Completion Time
------- ---------- ----------- ------------ -------------------
4349986 7.90M      DISK        00:00:01     2019-03-17 02:05:12
        BP Key: 4349990   Status: AVAILABLE  Compressed: YES  Tag: L0_2019_03_17
        Piece Name: /mnt/shares/backup/RCATN/L0_2019_03_17_Disk2_sgtskh2n_1_1.bkp
        Keep: BACKUP_LOGS        Until: 2019-04-01 02:05:11
...

Mas quando eu listo todos os conjuntos de backup, isso mostra que tenho vários dias de backups incrementais de nível 1 que são mais antigos que meu backup de nível 0 (completo) mais antigo:

RMAN> list backupset summary;


List of Backups
===============
Key     TY LV S Device Type Completion Time #Pieces #Copies Compressed Tag
------- -- -- - ----------- --------------- ------- ------- ---------- ---
4324675 B  1  A DISK        2019-03-07      2       1       YES        TAG20190307T020510
4324676 B  0  A DISK        2019-03-07      1       1       YES        TAG20190307T020510
4324677 B  1  A DISK        2019-03-07      1       1       YES        TAG20190307T020510
4325630 B  A  A DISK        2019-03-07      1       1       NO         TAG20190307T120513
4326388 B  A  A DISK        2019-03-08      1       1       NO         TAG20190308T000512
4326760 B  A  A DISK        2019-03-08      1       1       YES        TAG20190308T020510
4326761 B  1  A DISK        2019-03-08      1       1       YES        TAG20190308T020510
4326762 B  1  A DISK        2019-03-08      2       1       YES        TAG20190308T020510
4327695 B  A  A DISK        2019-03-08      1       1       NO         TAG20190308T120513
4332857 B  A  A DISK        2019-03-09      1       1       NO         TAG20190309T000508
4333313 B  A  A DISK        2019-03-09      1       1       YES        TAG20190309T020508
4333314 B  1  A DISK        2019-03-09      1       1       YES        TAG20190309T020508
4333315 B  1  A DISK        2019-03-09      2       1       YES        TAG20190309T020508
4334294 B  A  A DISK        2019-03-09      1       1       NO         TAG20190309T120512
4335404 B  A  A DISK        2019-03-11      1       1       NO         TAG20190311T000508
4335904 B  A  A DISK        2019-03-11      1       1       YES        TAG20190311T020509
4335905 B  1  A DISK        2019-03-11      1       1       YES        TAG20190311T020509
4335906 B  1  A DISK        2019-03-11      2       1       YES        TAG20190311T020509
4336825 B  A  A DISK        2019-03-11      1       1       NO         TAG20190311T120508
4337610 B  A  A DISK        2019-03-12      1       1       NO         TAG20190312T000508
4338006 B  A  A DISK        2019-03-12      1       1       YES        TAG20190312T020509
4338007 B  1  A DISK        2019-03-12      1       1       YES        TAG20190312T020509
4338008 B  1  A DISK        2019-03-12      2       1       YES        TAG20190312T020509
4338956 B  A  A DISK        2019-03-12      1       1       NO         TAG20190312T120508
4339810 B  A  A DISK        2019-03-13      1       1       NO         TAG20190313T000508
4340248 B  A  A DISK        2019-03-13      1       1       YES        TAG20190313T020507
4340249 B  1  A DISK        2019-03-13      1       1       YES        TAG20190313T020507
4340250 B  1  A DISK        2019-03-13      2       1       YES        TAG20190313T020507
4341190 B  A  A DISK        2019-03-13      1       1       NO         TAG20190313T120508
4342684 B  A  A DISK        2019-03-14      1       1       NO         TAG20190314T000508
4343074 B  A  A DISK        2019-03-14      1       1       YES        TAG20190314T020508
4343075 B  1  A DISK        2019-03-14      1       1       YES        TAG20190314T020508
4343076 B  1  A DISK        2019-03-14      2       1       YES        TAG20190314T020508
4344192 B  A  A DISK        2019-03-14      1       1       NO         TAG20190314T120508
4345115 B  A  A DISK        2019-03-15      1       1       NO         TAG20190315T000509
4345510 B  A  A DISK        2019-03-15      1       1       YES        TAG20190315T020508
4345511 B  1  A DISK        2019-03-15      1       1       YES        TAG20190315T020508
4345512 B  1  A DISK        2019-03-15      2       1       YES        TAG20190315T020508
4346447 B  A  A DISK        2019-03-15      1       1       NO         TAG20190315T120508
4347266 B  A  A DISK        2019-03-16      1       1       NO         TAG20190316T000509
4347630 B  A  A DISK        2019-03-16      1       1       YES        TAG20190316T020508
4347631 B  1  A DISK        2019-03-16      1       1       YES        TAG20190316T020508
4347632 B  1  A DISK        2019-03-16      2       1       YES        TAG20190316T020508
4348621 B  A  A DISK        2019-03-16      1       1       NO         TAG20190316T120509
4349564 B  A  A DISK        2019-03-17      1       1       NO         TAG20190317T000509
4349986 B  A  A DISK        2019-03-17      1       1       YES        L0_2019_03_17
4349987 B  A  A DISK        2019-03-17      1       1       YES        L0_2019_03_17
4350036 B  0  A DISK        2019-03-17      1       1       YES        L0_2019_03_17
4350037 B  0  A DISK        2019-03-17      1       1       YES        L0_2019_03_17
4350038 B  0  A DISK        2019-03-17      1       1       YES        L0_2019_03_17
4350039 B  0  A DISK        2019-03-17      2       1       YES        L0_2019_03_17
4350061 B  A  A DISK        2019-03-17      1       1       YES        L0_2019_03_17
4350062 B  A  A DISK        2019-03-17      1       1       YES        L0_2019_03_17
4350079 B  F  A DISK        2019-03-17      1       1       YES        L0_2019_03_17
4350097 B  F  A DISK        2019-03-17      1       1       YES        L0_2019_03_17
4350114 B  A  A DISK        2019-03-17      1       1       YES        L0_2019_03_17
4351780 B  A  A DISK        2019-03-17      1       1       NO         TAG20190317T120509
4352876 B  A  A DISK        2019-03-18      1       1       NO         TAG20190318T000508
4353260 B  A  A DISK        2019-03-18      1       1       YES        TAG20190318T020508
4353261 B  1  A DISK        2019-03-18      1       1       YES        TAG20190318T020508
4353262 B  1  A DISK        2019-03-18      2       1       YES        TAG20190318T020508
4354185 B  A  A DISK        2019-03-18      1       1       NO         TAG20190318T120508
...

E se eu listar os detalhes de um backup incremental de nível 1 (eu escolhi o primeiro na lista de resumo acima), não vejo nenhum dado KEEP:

RMAN> list backupset 4324675;


List of Backup Sets
===================


BS Key  Type LV Size       Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
4324675 Incr 1  380.61M    DISK        00:01:15     2019-03-07
  List of Datafiles in backup set 4324675
  File LV Type Ckp SCN    Ckp Time   Abs Fuz SCN Sparse Name
  ---- -- ---- ---------- ---------- ----------- ------ ----
  3    0  Incr 40466491   2019-03-07              NO    /u01/app/oracle/oradata/rmcat/sysaux01.dbf

  Backup Set Copy #1 of backup set 4324675
  Device Type Elapsed Time Completion Time Compressed Tag
  ----------- ------------ --------------- ---------- ---
  DISK        00:01:15     2019-03-07      YES        TAG20190307T020510

    List of Backup Pieces for backup set 4324675 Copy #1
    BP Key  Pc# Status      Piece Name
    ------- --- ----------- ----------
    4324680 1   AVAILABLE   /u01/app/oracle/recovery_area/RCATN/backupset/2019_03_07/o1_mf_nnnd1_TAG20190307T020510_g80vlp4r_.bkp
    4324681 2   AVAILABLE   /u01/app/oracle/recovery_area/RCATN/backupset/2019_03_07/o1_mf_nnnd1_TAG20190307T020510_g80vn3cq_.bkp

RMAN>

Então, por que o RMAN mantém backups de nível 1 mais antigos que meu backup de nível 0 mais antigo?

oracle oracle-12c
Martin Hope
Mark Stewart
Asked: 2018-06-21 10:45:43 +0800 CST
  • 0

Sou um pouco novo no RMAN e fiz uma aula do Oracle sobre ele, mas não consigo validar meus backups ao usar os níveis 0 e 1; para economizar espaço, estou pensando em fazer um backup incremental de nível 0 (completo) no domingo, backups diferenciais de nível 1 na segunda e terça-feira e cumulativos no nível 1 na quarta-feira. Em seguida, backups diferenciais de nível 1 na quinta e sexta-feira e no nível 1 cumulativo no sábado.

O pensamento era que, após um backup cumulativo de nível 1 bem-sucedido na quarta-feira, eu poderia excluir os backups de nível 1 diferenciais de segunda e terça-feira. Então, na quarta-feira, para verificar antes de fazer algo drástico para testar, fiz uma

RMAN> restore database validate;

E lá se foi, validando arquivos; mas apenas olhou para os arquivos do backup de domingo de nível 0.

Eu esperava que também validasse pelo menos o backup incremental de nível 1 de quarta-feira.

Então duas perguntas:

  1. Minha estratégia de excluir backups de nível 1 diferencial após um backup incremental de nível 1 bem-sucedido é válida?
  2. Como posso testar para garantir que isso está correto?
oracle-12c rman
Martin Hope
Mark Stewart
Asked: 2018-05-31 13:13:48 +0800 CST
  • 2

Tenho o Oracle 12c instalado em dois servidores. No servidor UATtenho uma instância RMCATque hospeda um catálogo de recuperação RMAN. No servidor EXTeu tenho duas instâncias extdev02e extuat01. Eu posso usar o seguinte comando no servidor UATpara conectar ao meu RMCATcatálogo e destino de extdev02, mas quando tento me conectar a extuat01ele dá umORA-01017

UAT> rman target= sys/tiger@extdev02  catalog= rmuser/tigerman@rmcat

Recovery Manager: Release 12.1.0.2.0 - Production on Wed May 30 22:59:26 2018

Copyright (c) 1982, 2014, Oracle and/or its affiliates.  All rights reserved.

connected to target database: EXTDEV02 (DBID=4287636681)
connected to recovery catalog database

RMAN> exit


Recovery Manager complete.

UAT> rman target= sys/tiger@extuat01  catalog= rmuser/tigerman@rmcat

Recovery Manager: Release 12.1.0.2.0 - Production on Wed May 30 22:59:42 2018

Copyright (c) 1982, 2014, Oracle and/or its affiliates.  All rights reserved.

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-00554: initialization of internal recovery manager package failed
RMAN-04005: error from target database:
ORA-01017: invalid username/password; logon denied

Recebo resultados OK tnspingdo UATservidor para ambas as instâncias no EXT, e posso me conectar a um usuário não dba do UATservidor para ambas as instâncias. Eu recriei o arquivo de senha do Oracle usando orapwna EXTinstância do servidor EXTUAT01e isso não ajudou.

Os nomes das instâncias são extdev02e extuat01no servidor EXT. Aqui estão meus arquivos de senha nesse servidor:

/u01/app/oracle/product/12.1.0.2/db_1/dbs> ls -o orapw*
-rw-r-----. 1 oracle 18432 Jun  1 00:07 orapwextuat01
/u01/app/oracle/product/12.1.0.2/db_0/dbs> ls -o orapw*
-rw-r-----. 1 oracle  7680 Feb  6 20:22 orapwextdev02

Observe que eles estão em dois diretórios ORACLE_HOME diferentes. O valor para remote_login_passwordfileé EXCLUSIVEpara ambas as instâncias

Problema Resolvido

O servidor UAT que hospeda a instância do catálogo RMAN RMCATfoi reinicializado há alguns dias para adicionar memória e agora posso me conectar! Se eu tivesse uma máquina de retorno, voltaria e veria se tentar reiniciar o ouvinte no host UAT teria ajudado; em qualquer caso, funciona. Obrigado pelas sugestões; Estou colocando as respostas apenas para a posteridade.

Comentários respondidos

  • Não é um ambiente de instância Grid nem RAC nem Dataguard.
  • selecionando de v$pwfile_users:

extdev02:

AtlasExt:SYS@extdev02> select * from v$pwfile_users;

USERNAME  SYSDBA  SYSOPER SYSASM  SYSBACKUP  SYSDG   SYSKM   CON_ID
--------- ------- ------- ------- ---------- ------- ------  ------
SYS       TRUE    TRUE    FALSE   FALSE      FALSE   FALSE   0

extuat01 (nota: eu executei orapw especificando sysbackup sem sucesso)

AtlasExt:SYS@extuat01> select * from v$pwfile_users;

USERNAME  SYSDBA  SYSOPER SYSASM  SYSBACKUP  SYSDG  SYSKM    CON_ID
--------- ------- ------- ------- ---------- ------ -------- ------
SYS       TRUE    TRUE    FALSE   FALSE      FALSE  FALSE    0
SYSBACKUP FALSE   FALSE   FALSE   TRUE       FALSE  FALSE    0
  • Não consegui conectar do UAT à instância EXT extuat01via SQL*Plus; mas após a reinicialização eu estava:

extdev02 do UAT:

AtlasUAT:SYS@extdev02> select host_name, instance_name from v$instance;

HOST_NAME                 INSTANCE_NAME
------------------------- ----------------
plsekatlasexta01          extdev02

extuat01 do UAT:

18:25:07 AtlasUAT:SYS@extuat01> select host_name, instance_name from v$instance;

HOST_NAME                 INSTANCE_NAME
------------------------- ----------------
plsekatlasexta01          extuat01
  • Os processos extuat01 e extdev01 verificados estavam sendo executados na mesma casa:

PID pmon encontrado:

plsekatlasexta01> ps -fu oracle  | grep pmon | grep -v grep
oracle    1976     1  0 Jun01 ?        00:00:43 ora_pmon_extuat01
oracle   32373     1  0 May16 ?        00:02:45 ora_pmon_extdev02
plsekatlasexta01> cat /proc/1976/environ | tr '\000' '\n' | grep -E 'ORACLE_(HOME|SID)'
ORACLE_HOME=/u01/app/oracle/product/12.1.0.2/db_1
ORACLE_SID=extuat01
plsekatlasexta01> cat /proc/32373/environ | tr '\000' '\n' | grep -E 'ORACLE_(HOME|SID)'
ORACLE_HOME=/u01/app/oracle/product/12.1.0.2/db_0
ORACLE_SID=extdev02
oracle oracle-12c
Martin Hope
Mark Stewart
Asked: 2016-05-28 10:17:35 +0800 CST
  • 3

No Oracle 12c, banco de dados relativamente novo com APEX instalado. eu faço um

 expdp \"/ as sysdba\"  directory=dp_dir full=y dumpfile=full.dmp logfile=full.log

E estou obtendo apenas algumas tabelas de SYS e SYSTEM exportadas:

. . exported "SYS"."KU$_USER_MAPPING_VIEW"               5.882 KB      24 rows
. . exported "SYS"."AUD$"                                    0 KB       0 rows
. . exported "SYS"."DAM_CLEANUP_EVENTS$"                     0 KB       0 rows
. . exported "SYS"."DAM_CLEANUP_JOBS$"                       0 KB       0 rows
. . exported "SYS"."DAM_CONFIG_PARAM$"                   6.523 KB      14 rows
. . exported "SYS"."TSDP_ASSOCIATION$"                       0 KB       0 rows
. . exported "SYS"."TSDP_CONDITION$"                         0 KB       0 rows
. . exported "SYS"."TSDP_FEATURE_POLICY$"                    0 KB       0 rows
. . exported "SYS"."TSDP_PARAMETER$"                     5.945 KB       1 rows
. . exported "SYS"."TSDP_POLICY$"                        5.914 KB       1 rows
. . exported "SYS"."TSDP_PROTECTION$"                        0 KB       0 rows
. . exported "SYS"."TSDP_SENSITIVE_DATA$"                    0 KB       0 rows
. . exported "SYS"."TSDP_SENSITIVE_TYPE$"                    0 KB       0 rows
. . exported "SYS"."TSDP_SOURCE$"                            0 KB       0 rows
. . exported "SYS"."TSDP_SUBPOL$"                        6.320 KB       1 rows
. . exported "SYSTEM"."REDO_DB"                          25.58 KB       1 rows
. . exported "SYSTEM"."REDO_LOG"                             0 KB       0 rows
. . exported "SYS"."FGA_LOG$FOR_EXPORT"                      0 KB       0 rows
. . exported "SYSTEM"."SCHEDULER_JOB_ARGS"               8.671 KB       4 rows
. . exported "SYSTEM"."SCHEDULER_PROGRAM_ARGS"           10.21 KB      22 rows
. . exported "SYS"."AUDTAB$TBS$FOR_EXPORT"               5.953 KB       2 rows
. . exported "SYS"."DBA_SENSITIVE_DATA"                      0 KB       0 rows
. . exported "SYS"."DBA_TSDP_POLICY_PROTECTION"              0 KB       0 rows
. . exported "SYS"."NACL$_ACE_EXP"                       10.14 KB       3 rows
. . exported "SYS"."NACL$_HOST_EXP"                      6.976 KB       2 rows
. . exported "SYS"."NACL$_WALLET_EXP"                        0 KB       0 rows
Master table "SYS"."SYS_EXPORT_FULL_01" successfully loaded/unloaded

No entanto, sei que tenho tabelas e outros objetos em outros esquemas:

AtlasProd:SYS@extern01> select owner, 
  2  decode(segment_type, 'TABLE', 'TABLE', '-other-') as segment_type,
  3  count(*)
  4  from dba_segments
  5  group by owner, decode(segment_type, 'TABLE', 'TABLE', '-other-')
  6  order by 1, 2;

OWNER                          SEGMENT_TYPE         COUNT(*)
------------------------------ ------------------ ----------
APEX_050000                    -other-                   646
APEX_050000                    TABLE                     155
AUDSYS                         -other-                     6
DBSNMP                         -other-                     4
DBSNMP                         TABLE                       2
GSMADMIN_INTERNAL              -other-                    15
GSMADMIN_INTERNAL              TABLE                       6
OUTLN                          -other-                     6
OUTLN                          TABLE                       3
SYS                            -other-                  1987
SYS                            TABLE                    1059
SYSTEM                         -other-                   321
SYSTEM                         TABLE                     124
XDB                            -other-                   655
XDB                            TABLE                      49

15 rows selected.

Vejo uma solução alternativa em Exportar bombear todos os esquemas, exceto os esquemas relacionados ao sistema , mas sei que já usei full=yantes com sucesso.

oracle oracle-12c