Re: [oracle_br] Re: DBMS_SCH EDULER.create_job Não inicia
Opa
É isso =>
alter system set job_queue_processes=10 scope=both;
JOB_QUEUE_PROCESSES specifies the maximum number of processes that can be
created for the execution of jobs. It specifies the number of job queue
processes per instance (J000, ... J999). Replication uses job queues for data
refreshes. Advanced queuing uses job queues for message propagation. You can
create user job requests through the DBMS_JOB package.
Some job queue requests are created automatically. An example is refresh
support for materialized views. If you wish to have your materialized views
updated automatically, you must set JOB_QUEUE_PROCESSES to a value of one or
higher.
Abs,Em terça-feira, 15 de maio de 2018 13:34:45 BRT, gabrielhe...@gmail.com
[oracle_br] escreveu:
NAME TYPE
VALUE ---
--job_queue_processes integer
0 #yiv9459615870 #yiv9459615870 -- #yiv9459615870ygrp-mkp {border:1px solid
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv9459615870
#yiv9459615870ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv9459615870
#yiv9459615870ygrp-mkp #yiv9459615870hd
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px
0;}#yiv9459615870 #yiv9459615870ygrp-mkp #yiv9459615870ads
{margin-bottom:10px;}#yiv9459615870 #yiv9459615870ygrp-mkp .yiv9459615870ad
{padding:0 0;}#yiv9459615870 #yiv9459615870ygrp-mkp .yiv9459615870ad p
{margin:0;}#yiv9459615870 #yiv9459615870ygrp-mkp .yiv9459615870ad a
{color:#ff;text-decoration:none;}#yiv9459615870 #yiv9459615870ygrp-sponsor
#yiv9459615870ygrp-lc {font-family:Arial;}#yiv9459615870
#yiv9459615870ygrp-sponsor #yiv9459615870ygrp-lc #yiv9459615870hd {margin:10px
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv9459615870
#yiv9459615870ygrp-sponsor #yiv9459615870ygrp-lc .yiv9459615870ad
{margin-bottom:10px;padding:0 0;}#yiv9459615870 #yiv9459615870actions
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv9459615870
#yiv9459615870activity
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv9459615870
#yiv9459615870activity span {font-weight:700;}#yiv9459615870
#yiv9459615870activity span:first-child
{text-transform:uppercase;}#yiv9459615870 #yiv9459615870activity span a
{color:#5085b6;text-decoration:none;}#yiv9459615870 #yiv9459615870activity span
span {color:#ff7900;}#yiv9459615870 #yiv9459615870activity span
.yiv9459615870underline {text-decoration:underline;}#yiv9459615870
.yiv9459615870attach
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px
0;width:400px;}#yiv9459615870 .yiv9459615870attach div a
{text-decoration:none;}#yiv9459615870 .yiv9459615870attach img
{border:none;padding-right:5px;}#yiv9459615870 .yiv9459615870attach label
{display:block;margin-bottom:5px;}#yiv9459615870 .yiv9459615870attach label a
{text-decoration:none;}#yiv9459615870 blockquote {margin:0 0 0
4px;}#yiv9459615870 .yiv9459615870bold
{font-family:Arial;font-size:13px;font-weight:700;}#yiv9459615870
.yiv9459615870bold a {text-decoration:none;}#yiv9459615870 dd.yiv9459615870last
p a {font-family:Verdana;font-weight:700;}#yiv9459615870 dd.yiv9459615870last p
span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv9459615870
dd.yiv9459615870last p span.yiv9459615870yshortcuts
{margin-right:0;}#yiv9459615870 div.yiv9459615870attach-table div div a
{text-decoration:none;}#yiv9459615870 div.yiv9459615870attach-table
{width:400px;}#yiv9459615870 div.yiv9459615870file-title a, #yiv9459615870
div.yiv9459615870file-title a:active, #yiv9459615870
div.yiv9459615870file-title a:hover, #yiv9459615870 div.yiv9459615870file-title
a:visited {text-decoration:none;}#yiv9459615870 div.yiv9459615870photo-title a,
#yiv9459615870 div.yiv9459615870photo-title a:active, #yiv9459615870
div.yiv9459615870photo-title a:hover, #yiv9459615870
div.yiv9459615870photo-title a:visited {text-decoration:none;}#yiv9459615870
div#yiv9459615870ygrp-mlmsg #yiv9459615870ygrp-msg p a
span.yiv9459615870yshortcuts
{font-family:Verdana;font-size:10px;font-weight:normal;}#yiv9459615870
.yiv9459615870green {color:#628c2a;}#yiv9459615870 .yiv9459615870MsoNormal
{margin:0 0 0 0;}#yiv9459615870 o {font-size:0;}#yiv9459615870
#yiv9459615870photos div {float:left;width:72px;}#yiv9459615870
#yiv9459615870photos div div {border:1px solid
#66;min-height:62px;overflow:hidden;width:62px;}#yiv9459615870
#yiv9459615870photos div label
{color:#66;font-size:10px;overflow:hidden;text-align:center;white-space:nowrap;width:64px;}#yiv9459615870
#yiv9459615870reco-category {font-size:77%;}#yiv9459615870
#yiv9459615870reco-desc {font-size:77%;}#yiv9459615870 .yiv9459615870replbq
{margin:4px;}#yiv9459615870 #yiv9459615870ygrp-actbar div a:first-child
{margin-right:2px;padding-right:5px;}#yiv9459615870 #yiv9459615870ygrp-mlmsg
{font-size:13px;font-family:
Re: [oracle_br] Re: DBMS_SCH EDULER.create_job Não inicia
Opa
Chegou a executar? =>
show parameter job_queue_processes;
Abs,Em terça-feira, 15 de maio de 2018 11:54:33 BRT, gabrielhe...@gmail.com
[oracle_br] escreveu:
Rodei o SELECT * FROM dba_scheduler_global_attribute WHERE attribute_name =
'SCHEDULER_DISABLED';
E não trouxe linhas.
Nenhum job executa.
#yiv8596508054 #yiv8596508054 -- #yiv8596508054ygrp-mkp {border:1px solid
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv8596508054
#yiv8596508054ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv8596508054
#yiv8596508054ygrp-mkp #yiv8596508054hd
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px
0;}#yiv8596508054 #yiv8596508054ygrp-mkp #yiv8596508054ads
{margin-bottom:10px;}#yiv8596508054 #yiv8596508054ygrp-mkp .yiv8596508054ad
{padding:0 0;}#yiv8596508054 #yiv8596508054ygrp-mkp .yiv8596508054ad p
{margin:0;}#yiv8596508054 #yiv8596508054ygrp-mkp .yiv8596508054ad a
{color:#ff;text-decoration:none;}#yiv8596508054 #yiv8596508054ygrp-sponsor
#yiv8596508054ygrp-lc {font-family:Arial;}#yiv8596508054
#yiv8596508054ygrp-sponsor #yiv8596508054ygrp-lc #yiv8596508054hd {margin:10px
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv8596508054
#yiv8596508054ygrp-sponsor #yiv8596508054ygrp-lc .yiv8596508054ad
{margin-bottom:10px;padding:0 0;}#yiv8596508054 #yiv8596508054actions
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv8596508054
#yiv8596508054activity
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv8596508054
#yiv8596508054activity span {font-weight:700;}#yiv8596508054
#yiv8596508054activity span:first-child
{text-transform:uppercase;}#yiv8596508054 #yiv8596508054activity span a
{color:#5085b6;text-decoration:none;}#yiv8596508054 #yiv8596508054activity span
span {color:#ff7900;}#yiv8596508054 #yiv8596508054activity span
.yiv8596508054underline {text-decoration:underline;}#yiv8596508054
.yiv8596508054attach
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px
0;width:400px;}#yiv8596508054 .yiv8596508054attach div a
{text-decoration:none;}#yiv8596508054 .yiv8596508054attach img
{border:none;padding-right:5px;}#yiv8596508054 .yiv8596508054attach label
{display:block;margin-bottom:5px;}#yiv8596508054 .yiv8596508054attach label a
{text-decoration:none;}#yiv8596508054 blockquote {margin:0 0 0
4px;}#yiv8596508054 .yiv8596508054bold
{font-family:Arial;font-size:13px;font-weight:700;}#yiv8596508054
.yiv8596508054bold a {text-decoration:none;}#yiv8596508054 dd.yiv8596508054last
p a {font-family:Verdana;font-weight:700;}#yiv8596508054 dd.yiv8596508054last p
span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv8596508054
dd.yiv8596508054last p span.yiv8596508054yshortcuts
{margin-right:0;}#yiv8596508054 div.yiv8596508054attach-table div div a
{text-decoration:none;}#yiv8596508054 div.yiv8596508054attach-table
{width:400px;}#yiv8596508054 div.yiv8596508054file-title a, #yiv8596508054
div.yiv8596508054file-title a:active, #yiv8596508054
div.yiv8596508054file-title a:hover, #yiv8596508054 div.yiv8596508054file-title
a:visited {text-decoration:none;}#yiv8596508054 div.yiv8596508054photo-title a,
#yiv8596508054 div.yiv8596508054photo-title a:active, #yiv8596508054
div.yiv8596508054photo-title a:hover, #yiv8596508054
div.yiv8596508054photo-title a:visited {text-decoration:none;}#yiv8596508054
div#yiv8596508054ygrp-mlmsg #yiv8596508054ygrp-msg p a
span.yiv8596508054yshortcuts
{font-family:Verdana;font-size:10px;font-weight:normal;}#yiv8596508054
.yiv8596508054green {color:#628c2a;}#yiv8596508054 .yiv8596508054MsoNormal
{margin:0 0 0 0;}#yiv8596508054 o {font-size:0;}#yiv8596508054
#yiv8596508054photos div {float:left;width:72px;}#yiv8596508054
#yiv8596508054photos div div {border:1px solid
#66;min-height:62px;overflow:hidden;width:62px;}#yiv8596508054
#yiv8596508054photos div label
{color:#66;font-size:10px;overflow:hidden;text-align:center;white-space:nowrap;width:64px;}#yiv8596508054
#yiv8596508054reco-category {font-size:77%;}#yiv8596508054
#yiv8596508054reco-desc {font-size:77%;}#yiv8596508054 .yiv8596508054replbq
{margin:4px;}#yiv8596508054 #yiv8596508054ygrp-actbar div a:first-child
{margin-right:2px;padding-right:5px;}#yiv8596508054 #yiv8596508054ygrp-mlmsg
{font-size:13px;font-family:Arial, helvetica, clean, sans-serif;}#yiv8596508054
#yiv8596508054ygrp-mlmsg table {font-size:inherit;font:100%;}#yiv8596508054
#yiv8596508054ygrp-mlmsg select, #yiv8596508054 input, #yiv8596508054 textarea
{font:99% Arial, Helvetica, clean, sans-serif;}#yiv8596508054
#yiv8596508054ygrp-mlmsg pre, #yiv8596508054 code {font:115%
monospace;}#yiv8596508054 #yiv8596508054ygrp-mlmsg *
{line-height:1.22em;}#yiv8596508054 #yiv8596508054ygrp-mlmsg #yiv8596508054logo
{padding-bottom:10px;}#yiv8596508054 #yiv8596508054ygrp-msg p a
{font-family:Verdana;}#yiv8596508054 #yiv8596508054ygrp-msg
p#yiv8596508054attach-count span {color:#1E66AE;font-
Re: [oracle_br] Re: DBMS_SCHEDULER.create_job Não inicia
Opa, bom dia!
Poderia executar os comandos abaixo?
show parameter job_queue_processes;
/
SELECT * FROM dba_scheduler_global_attribute WHERE attribute_name =
'SCHEDULER_DISABLED';/
Obs: tem algum outro job que rode?
Abs!
Em terça-feira, 15 de maio de 2018 11:26:52 BRT, gabrielhe...@gmail.com
[oracle_br] escreveu:
Tentei e não funcionou.
A procedure simplesmente faz um update campo+1 e commit. (apenas teste)
E nada da job executar na hora agendada, também não passa para frente
BEGIN DBMS_SCHEDULER.CREATE_JOB ( job_name => 'JOB_TESTE',
job_type => 'PLSQL_BLOCK', job_action => 'begin PR_TESTEJOB; end;',
number_of_arguments => 0, start_date => systimestamp +
interval '60' second, repeat_interval => 'FREQ=MINUTELY;
INTERVAL=3', end_date => NULL, enabled => TRUE,
auto_drop => FALSE, comments => 'job teste gabriel');
end;
Quem puder ajudar agradeço,
#yiv9086372680 #yiv9086372680 -- #yiv9086372680ygrp-mkp {border:1px solid
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv9086372680
#yiv9086372680ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv9086372680
#yiv9086372680ygrp-mkp #yiv9086372680hd
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px
0;}#yiv9086372680 #yiv9086372680ygrp-mkp #yiv9086372680ads
{margin-bottom:10px;}#yiv9086372680 #yiv9086372680ygrp-mkp .yiv9086372680ad
{padding:0 0;}#yiv9086372680 #yiv9086372680ygrp-mkp .yiv9086372680ad p
{margin:0;}#yiv9086372680 #yiv9086372680ygrp-mkp .yiv9086372680ad a
{color:#ff;text-decoration:none;}#yiv9086372680 #yiv9086372680ygrp-sponsor
#yiv9086372680ygrp-lc {font-family:Arial;}#yiv9086372680
#yiv9086372680ygrp-sponsor #yiv9086372680ygrp-lc #yiv9086372680hd {margin:10px
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv9086372680
#yiv9086372680ygrp-sponsor #yiv9086372680ygrp-lc .yiv9086372680ad
{margin-bottom:10px;padding:0 0;}#yiv9086372680 #yiv9086372680actions
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv9086372680
#yiv9086372680activity
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv9086372680
#yiv9086372680activity span {font-weight:700;}#yiv9086372680
#yiv9086372680activity span:first-child
{text-transform:uppercase;}#yiv9086372680 #yiv9086372680activity span a
{color:#5085b6;text-decoration:none;}#yiv9086372680 #yiv9086372680activity span
span {color:#ff7900;}#yiv9086372680 #yiv9086372680activity span
.yiv9086372680underline {text-decoration:underline;}#yiv9086372680
.yiv9086372680attach
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px
0;width:400px;}#yiv9086372680 .yiv9086372680attach div a
{text-decoration:none;}#yiv9086372680 .yiv9086372680attach img
{border:none;padding-right:5px;}#yiv9086372680 .yiv9086372680attach label
{display:block;margin-bottom:5px;}#yiv9086372680 .yiv9086372680attach label a
{text-decoration:none;}#yiv9086372680 blockquote {margin:0 0 0
4px;}#yiv9086372680 .yiv9086372680bold
{font-family:Arial;font-size:13px;font-weight:700;}#yiv9086372680
.yiv9086372680bold a {text-decoration:none;}#yiv9086372680 dd.yiv9086372680last
p a {font-family:Verdana;font-weight:700;}#yiv9086372680 dd.yiv9086372680last p
span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv9086372680
dd.yiv9086372680last p span.yiv9086372680yshortcuts
{margin-right:0;}#yiv9086372680 div.yiv9086372680attach-table div div a
{text-decoration:none;}#yiv9086372680 div.yiv9086372680attach-table
{width:400px;}#yiv9086372680 div.yiv9086372680file-title a, #yiv9086372680
div.yiv9086372680file-title a:active, #yiv9086372680
div.yiv9086372680file-title a:hover, #yiv9086372680 div.yiv9086372680file-title
a:visited {text-decoration:none;}#yiv9086372680 div.yiv9086372680photo-title a,
#yiv9086372680 div.yiv9086372680photo-title a:active, #yiv9086372680
div.yiv9086372680photo-title a:hover, #yiv9086372680
div.yiv9086372680photo-title a:visited {text-decoration:none;}#yiv9086372680
div#yiv9086372680ygrp-mlmsg #yiv9086372680ygrp-msg p a
span.yiv9086372680yshortcuts
{font-family:Verdana;font-size:10px;font-weight:normal;}#yiv9086372680
.yiv9086372680green {color:#628c2a;}#yiv9086372680 .yiv9086372680MsoNormal
{margin:0 0 0 0;}#yiv9086372680 o {font-size:0;}#yiv9086372680
#yiv9086372680photos div {float:left;width:72px;}#yiv9086372680
#yiv9086372680photos div div {border:1px solid
#66;min-height:62px;overflow:hidden;width:62px;}#yiv9086372680
#yiv9086372680photos div label
{color:#66;font-size:10px;overflow:hidden;text-align:center;white-space:nowrap;width:64px;}#yiv9086372680
#yiv9086372680reco-category {font-size:77%;}#yiv9086372680
#yiv9086372680reco-desc {font-size:77%;}#yiv9086372680 .yiv9086372680replbq
{margin:4px;}#yiv9086372680 #yiv9086372680ygrp-actbar div a:first-child
{margin-right:2px;padding-right:5px;}#yiv9086372680 #yiv9086372680ygrp-mlmsg
{font-si
Re: [oracle_br] Sincronismo standby
Opa mano, tudo bem?
Uma duvida, é rac?
Abs,
Em sexta-feira, 11 de maio de 2018 14:54:09 BRT, Rafael Mendonca
raffaell.t...@yahoo.com [oracle_br] escreveu:
Senhores, boa tarde.
Cenario:
Oracle 11gR2 - Um primary db e um physical standby DB (OPEN WITH APPLY) -
Active DG
Estou com um problema em uma configuração de DataGuard. Utilizamos uma query
para monitorar o sincronismo entre o primary e o standby database. Temos em
torno de 20 dataguards, e o monitoramento está ok e funciona bem em todos
ambientes, *MAS EM UM AMBIENTE ESPECIFICO* a monitoração está alertando o tempo
inteiro enquanto não deveria alertar, segue:
NO PRIMARY DATABASE:
SELECT DATABASE_MODE , SUBSTR (RECOVERY_MODE, 1, 8) AS "RECOV_MODE" ,
PROTECTION_MODE AS "PROTECTION_MODE" , SUBSTR (DESTINATION, 1, 10) AS
"DEST" , ARCHIVED_SEQ# , APPLIED_SEQ# , SUBSTR
(SYNCHRONIZATION_STATUS, 1, 8) AS "SYNC_STATUS" , SYNCHRONIZED AS "SYNC"
, GAP_STATUS , STATUSFROM V$ARCHIVE_DEST_STATUSWHERE TYPE <>
'LOCAL'/
DATABASE_MODE |RECOV_MO|PROTECTION_MODE |DEST
|ARCHIVED_SEQ#|APPLIED_SEQ#|SYNC_STA|SYN|GAP_STATUS
|STATUS---|||--|-|||---||-OPEN_READ-ONLY
|MANAGED |MAXIMUM PERFORMANCE |sdemp_std | 139745| 139659|CHECK
CO|NO |NO GAP |VALID
Se voces perceberem o valor da coluna ARCHIVED_SEQ# (primary) = 139744e o valor
da coluna APPLIED_SEQ# (standby) = 139659
Será visto que existe uma diferença grande entre ambos. Porém, se eu realizar a
consulta abaixo, irá me mostrar o seguinte:
QUery executada no STANDBY DATABASE:
SELECT 'Last applied : ' Logs,
To_char(next_time, 'DD/MM/YY HH24:MI:SS') TimeFROM v$archived_logWHERE
sequence# = (SELECT Max(sequence#) FROM v$archived_log
WHERE applied = 'YES')UNIONSELECT 'Last received : '
Logs, To_char(next_time, 'DD/MM/YY HH24:MI:SS') TimeFROM
v$archived_logWHERE sequence# = (SELECT Max(sequence#)
FROM v$archived_log);
LOGS TIME -Last applied :
11/05/18 14:40:37Last received : 11/05/18 14:40:37
se eu fizer um outro select no standby:
SQL> select max(sequence#) from v$archived_log;
MAX(SEQUENCE#)-- 139745
Ou seja, a ultima sequence aplicada no standby bate com o do primary database.
Agora analisando o alert.log do physical standby:
Media Recovery Log /sdemp/arch/u01/archives/sdemp_1_139744_847202734.arcMedia
Recovery Waiting for thread 1 sequence 139745 (in transit)Fri May 11 14:40:37
2018RFS[27]: Selected log 8 for thread 1 sequence 139746 dbid 843466460 branch
847202734Fri May 11 14:40:37 2018Archived Log entry 142021 added for thread 1
sequence 139745 ID 0x38b9c4c7 dest 1:Fri May 11 14:40:38 2018Media Recovery Log
/sdemp/arch/u01/archives/sdemp_1_139745_847202734.arcMedia Recovery Waiting for
thread 1 sequence 139746 (in transit)
Ou seja, o recebimento e o apply está ocorrendo no standby, porém o
monitoramento no primary database não está OK.
Obs: Esse comportamento só ocorre nesse ambiente, em mais de 10 configurações
de DG, o APPLIED_SEQ# bate com o ARCHIVED_SEQ#.
Esse problema está nos dando dor de cabeça por o monitoramento está alertando e
enviando chamado o tempo inteiro. Se alguémm puder ajudar eu agradeço.
#yiv6967922749 #yiv6967922749 -- #yiv6967922749ygrp-mkp {border:1px solid
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv6967922749
#yiv6967922749ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv6967922749
#yiv6967922749ygrp-mkp #yiv6967922749hd
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px
0;}#yiv6967922749 #yiv6967922749ygrp-mkp #yiv6967922749ads
{margin-bottom:10px;}#yiv6967922749 #yiv6967922749ygrp-mkp .yiv6967922749ad
{padding:0 0;}#yiv6967922749 #yiv6967922749ygrp-mkp .yiv6967922749ad p
{margin:0;}#yiv6967922749 #yiv6967922749ygrp-mkp .yiv6967922749ad a
{color:#ff;text-decoration:none;}#yiv6967922749 #yiv6967922749ygrp-sponsor
#yiv6967922749ygrp-lc {font-family:Arial;}#yiv6967922749
#yiv6967922749ygrp-sponsor #yiv6967922749ygrp-lc #yiv6967922749hd {margin:10px
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv6967922749
#yiv6967922749ygrp-sponsor #yiv6967922749ygrp-lc .yiv6967922749ad
{margin-bottom:10px;padding:0 0;}#yiv6967922749 #yiv6967922749actions
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv6967922749
#yiv6967922749activity
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv6967922749
#yiv6967922749activity span {font-weight:700;}#yiv6967922749
#yiv6967922749activity span:first-child
{text-transform:uppercase;}#yiv6967922749 #yiv6967922749activity span a
{color:#5085b6;text-decoration:none;}#yiv6967922749 #yiv69679227
Re: [oracle_br] Re: Restore de banco em outra plataforma
Opa, tudo bem?
Tive um cenario parecido, so que era de AIX para LINUX
Usei o GoldenGate.
Instalei a mesma versão do DB no Linux, criei os tbs, users e fiz impdp via
networklink com o SCN de prod.(Pode fazer impdp/expdp se quiser)
Depois startei o Replicate do GG com o SCN de prod e deixei sincando.
Obs: o Extract tem que esta startado antes do import.
Espero ter ajudado!
Abs,Em terça-feira, 10 de abril de 2018 11:24:12 BRT,
jlchia...@yahoo.com.br [oracle_br] escreveu:
Blz ? Então, antes de te responder eu ** tenho ** que dizer : se vc quer ter
uma Homologação REAL, que não seja só 'pra inglês ver' e Realmente Sirva para
antecipar possíveis problemas que vc pode ter em PROD, COM CERTEZA tanto PROD
quanto HOMO *** deveriam *** ser o mesmo exato Sistema Operacional, o mesmo
exato hardware (ou na pior das hipóteses hardwares o mais equivalentes
possível), com a mesma exata configuração Sem isso, nada impede de
(digamos) vc ter um bug específico pro Linux que OBVIAMENTE tua máquina HP-UX
não vai cair, E/OU de vc ter alguma config específica de Linux que não possa
ser replicada no HP-UX, e coisas assim... Sorry, mas imho essa sua homo
diferente de prod tá caindo no caso de 'para inglês ver'
Isso dito, a sua resposta : só no 12c é que a Oracle introduziu a feature de
backup RMAN conversível entre endian formats diferentes , veja a nota metalink
"12c How Perform Cross-Platform Database Transport to different Endian Platform
with RMAN Backup Sets" (Doc ID 2013271.1) para refs...
No 11g e anteriores, o RMAN só pode converter arquivos se o ENDIAN format ***
é o MESMO *** : assim sendo, como o HP-UX é BIG ENDIAN e o Linux é Little
Endian, o comando CONVERT DATABASE não vai ser capaz de realizar a conversão :
veja o manual Oracle correspondente em
https://docs.oracle.com/cd/E25178_01/backup./e10642/rcmxplat.htm#CHDHHCGI,
http://www.dba-oracle.com/t_rman_91_cross_platform_migration.htm e a nota
metalink "Frequently Asked Questions about Restoring Or Duplicating Between
Different Versions And Platforms" (Doc ID 369644.1)que eles documentam isso...
Assim sendo, a sua resposta inicial é clara , Não tem Como vc restaurar um
backup Linux no HP-UX... PREFERENCIALMENTE, vc deveria é ter realmente um banco
HOMO idêntico à PROD, mas ENQUANTO isso não é corrigido, tuas opções pra
transportar dados do Linux para o HP-UX são :
1. Transporte de Tablespaces Cross-Platform : no 10g foi introduzida a
possibilidade de fazer transporte de tabblespace entre plataformas com endian
formats diferentes, veja
https://levipereira.wordpress.com/2011/01/23/how-convert-full-database-10g-linux-x86-64bit-to-aix-64bit-different-endian-format/
onde o Autor dá um exemplo EVIDENTEMENTE, há requisitos e limitações para
a tablespace a ser transportada, o artigo cita alguns mas consulte a
documentação (online em
https://docs.oracle.com/cd/E18283_01/server.112/e17120/tspaces013.htm) para
detalhes...
ou
2. export/import : seja pelo export e import tradicionais, seja pelo datapump,
o dump file gerado É cross-platform e independente do hardware, principalmente
em qusitos como bitsize... Cabe a você avaliar se com o uso das técnicas de
Aceleração de export (ie, configs no máximo, exports sendo feitos num horário
de menor concorrência, múltiplos exports e imports em paralelo, NÃO EXPORTAR
índices e constraints mas sim apenas o DDL deles que depois vai ser aplicado em
parallel mode, múltiplas sessões, NOLOGGING e/ou NOVALIDATE, etc) a performance
é Aceitável pro teu hardware e pra sua janela de manutenção...
ou
3. database link entre os dois bancos : SE houver uma rede Rápida e Confiável
entre os dois bancos, E SE for possível algum tipo de Paralelismo
(preferencialmente o Parallel SQL nativo se os bancos forem Enterprise Edition,
senão o paralelismo de pobre/diy via DBMS_PARALLEL) , a opção de se montar
scripts seus que façam INSERT /*+ APPEND */ into tabelaemhomo (SELECT * FROM
tabelaprod@databaselink); via de regra oferece boa performance
ou
4. gerar arquivos-texto com os dados em PROD Linux que vão ser importados em
HOMO HP-UX via sql*loader : a VANTAGEM desta opção sobre o dumpfile gerado via
export é que o arquivo-texto com os dados PODE ser carregado em direct-mode e
em paralelo, o que nem sempre ocorrer com dumpfiles - vide
https://docs.oracle.com/cd/B28359_01/server.111/b28319/ldr_modes.htm#g1023818
para detalhes...
[]s
Chiappa
#yiv8694179680 #yiv8694179680 -- #yiv8694179680ygrp-mkp {border:1px solid
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv8694179680
#yiv8694179680ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv8694179680
#yiv8694179680ygrp-mkp #yiv8694179680hd
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px
0;}#yiv8694179680 #yiv8694179680ygrp-mkp #yiv8694179680ads
{margin-bottom:10px;}#yiv8694179680 #yiv8694179680ygrp-mkp .yiv8694179680ad
{padding:0 0;}#yiv8694179680 #yiv8694179680ygrp-mkp .yiv8694
Re: [oracle_br] Re: Multiples discos em diferentes RAID levels
Evandro, boa tarde!
Ve se esse link te ajuda =>
https://oracle-base.com/articles/misc/oracle-and-raid
Abs
Em Terça-feira, 20 de Fevereiro de 2018 14:14, "jlchia...@yahoo.com.br
[oracle_br]" escreveu:
Blz ? Então, OBRIGATORIEDADE não existe (nem em lugar ** nenhum ** da
Documentação e nem em nota técnica NENHUMA do metalink vc vai achar uma
OBRIGATORIEDADE pra isso), mas é FORTEMENTE RECOMENDADO que os discos físicos
(e os disk volumes, óbvio) dentro de um diskgroup sejam IDÊNTICOS entre si,
tanto na questão de tamanho quanto na questão de tecnologia : a nota metalink
How to Prepare Storage for ASM (Doc ID 452924.1) diz isso com ** TODAS AS
LETRAS ** :
"
C) Recommendations for Storage Preparation. The following are guidelines for
preparing storage for
use with ASM:
1) Configure two disk groups, one for the datafile and the other for the Flash
Recovery Area. For availability purposes, one is used as a backup for the other.
2) Ensure that LUNs, which are disk drives of partitions, that ASM disk groups
use have similar storage performance and availability characteristics. In
storage configurations with mixed speed drives, such as 10K and 15K RPM, I/O
distribution is constrained by the slowest speed drive.
3) Be aware that ASM data distribution policy is capacity-based. LUNs provided
to ASM have the same capacity for each disk group to avoid an imbalance..
"
OK ? Viole essa Recomendação Oficial por sua conta e risco... Eu, se estivesse
no seu lugar, PRIMEIRO mandaria tirar a turma tirar o escorpião do bolso e
DISPENSAR esses RAID-5 se a máquina em questão é Produção E performance decente
é paradigma (vide http://www.baarf.dk/BAARF/BAARF2.html e os outros n+1!
materiais disponíveis) ...
APENAS SE REALMENTE não tiver outra solução, tapando o nariz eu SEM DÚVIDA
criaria um OUTRO diskgroup pra conter os tais discos RAID-5...
[]s
Chiappa #yiv8205266535 #yiv8205266535 -- #yiv8205266535ygrp-mkp {border:1px
solid #d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv8205266535
#yiv8205266535ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv8205266535
#yiv8205266535ygrp-mkp #yiv8205266535hd
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px
0;}#yiv8205266535 #yiv8205266535ygrp-mkp #yiv8205266535ads
{margin-bottom:10px;}#yiv8205266535 #yiv8205266535ygrp-mkp .yiv8205266535ad
{padding:0 0;}#yiv8205266535 #yiv8205266535ygrp-mkp .yiv8205266535ad p
{margin:0;}#yiv8205266535 #yiv8205266535ygrp-mkp .yiv8205266535ad a
{color:#ff;text-decoration:none;}#yiv8205266535 #yiv8205266535ygrp-sponsor
#yiv8205266535ygrp-lc {font-family:Arial;}#yiv8205266535
#yiv8205266535ygrp-sponsor #yiv8205266535ygrp-lc #yiv8205266535hd {margin:10px
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv8205266535
#yiv8205266535ygrp-sponsor #yiv8205266535ygrp-lc .yiv8205266535ad
{margin-bottom:10px;padding:0 0;}#yiv8205266535 #yiv8205266535actions
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv8205266535
#yiv8205266535activity
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv8205266535
#yiv8205266535activity span {font-weight:700;}#yiv8205266535
#yiv8205266535activity span:first-child
{text-transform:uppercase;}#yiv8205266535 #yiv8205266535activity span a
{color:#5085b6;text-decoration:none;}#yiv8205266535 #yiv8205266535activity span
span {color:#ff7900;}#yiv8205266535 #yiv8205266535activity span
.yiv8205266535underline {text-decoration:underline;}#yiv8205266535
.yiv8205266535attach
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px
0;width:400px;}#yiv8205266535 .yiv8205266535attach div a
{text-decoration:none;}#yiv8205266535 .yiv8205266535attach img
{border:none;padding-right:5px;}#yiv8205266535 .yiv8205266535attach label
{display:block;margin-bottom:5px;}#yiv8205266535 .yiv8205266535attach label a
{text-decoration:none;}#yiv8205266535 blockquote {margin:0 0 0
4px;}#yiv8205266535 .yiv8205266535bold
{font-family:Arial;font-size:13px;font-weight:700;}#yiv8205266535
.yiv8205266535bold a {text-decoration:none;}#yiv8205266535 dd.yiv8205266535last
p a {font-family:Verdana;font-weight:700;}#yiv8205266535 dd.yiv8205266535last p
span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv8205266535
dd.yiv8205266535last p span.yiv8205266535yshortcuts
{margin-right:0;}#yiv8205266535 div.yiv8205266535attach-table div div a
{text-decoration:none;}#yiv8205266535 div.yiv8205266535attach-table
{width:400px;}#yiv8205266535 div.yiv8205266535file-title a, #yiv8205266535
div.yiv8205266535file-title a:active, #yiv8205266535
div.yiv8205266535file-title a:hover, #yiv8205266535 div.yiv8205266535file-title
a:visited {text-decoration:none;}#yiv8205266535 div.yiv8205266535photo-title a,
#yiv8205266535 div.yiv8205266535photo-title a:active, #yiv8205266535
div.yiv8205266535photo-title a:hover, #yiv8205266535
div.yiv8205266535photo-title a:visited {text-decoration:none;}#yiv8205266535
di
Re: [oracle_br] Re: Trazer primeiros registros, só que mais enrolado
Opa, segue um exemplo => SELECT cd_days FROM (SELECT cd_days, ROW_NUMBER() OVER (ORDER BY cd_days) R from teste d where cd_marca = 2 AND d.contract_type = 'GERAL' and d.logistic_contract is not NULL) WHERE R BETWEEN 10 and 20; Abs, Em Quarta-feira, 3 de Janeiro de 2018 13:04, "jlchia...@yahoo.com.br [oracle_br]" escreveu: Pra não ficar só no bláblablá, vamos a um exemplo - suponha que eu quero agrupar por departamento, e para cada departamento eu quero ordenar por Salário e mostrar os 3 primeiros salários, e tenho os seguintes dados : scott@DESENV:SQL>select deptno, empno, sal from emp order by deptno, sal; DEPTNO EMPNO SAL - - - 10 7934 1300 10 7782 2450 10 7839 5000 20 7369 800 20 7876 1100 20 7566 2975 20 7788 3000 20 7902 3000 30 7900 950 30 7654 1250 30 7521 1250 30 7844 1500 30 7499 1600 30 7698 2850 14 linhas selecionadas. PERCEBA que para o departamento 30 o segundo e o terceiro salário empataram, ambos recebem 1250... Aí vem a pergunta, o que faço nesse caso ? Se vc quer simplesmente mostrar os 3 salarios ordenados SEM se importar com desempates seria simplesmente atribuir um número sequencial pra cada registro dentro do grupo E filtrar depois onde esse número seja < 4 (ou <= 3, como preferir) Tipo : scott@DESENV:SQL>SELECT deptno, 2 empno, 3 sal, 4 row_number() OVER (PARTITION BY deptno ORDER BY sal) AS NUM_REG 5* FROM emp; DEPTNO EMPNO SAL NUM_REG - - - - 10 7934 1300 1 10 7782 2450 2 10 7839 5000 3 20 7369 800 1 20 7876 1100 2 20 7566 2975 3 20 7788 3000 4 20 7902 3000 5 30 7900 950 1 30 7654 1250 2 30 7521 1250 3 30 7844 1500 4 30 7499 1600 5 30 7698 2850 6 14 linhas selecionadas. scott@DESENV:SQL> ==> Tá vendo ? Os registros foram AGRUPADOS por DEPTNO e o NUM_REG é resetado a cada vez que muda de DEPTO, essa lógica é Automágica nas funções analíticas Vamos filtrar por esse número, para receber só os 3 primeiros registros do grupo ? Isso vai ficar : scott@DESENV:SQL>select * from ( 2 SELECT deptno, 3 empno, 4 sal, 5 row_number() OVER (PARTITION BY deptno ORDER BY sal) AS NUM_REG 6 FROM emp ) 7* WHERE NUM_REG < 4; DEPTNO EMPNO SAL NUM_REG - - - - 10 7934 1300 1 10 7782 2450 2 10 7839 5000 3 20 7369 800 1 20 7876 1100 2 20 7566 2975 3 30 7900 950 1 30 7521 1250 2 30 7654 1250 3 9 linhas selecionadas. scott@DESENV:SQL> Simples, só encapsulei o agrupamento num sub-query para poder aplicar um WHERE nele... Não é ? SE é isso que vc quer (simplesmente listar os 3 primeiros dentro de cada grupo, SEM se preocupar com empates) tá feita a fofoca... Já se neste meu exemplo eu quisesse que quando houvesse empate (por exemplo, no depto 30 a terceira linha fosse o salário 1500, desconsiderando o empate em 1250) aí eu usaria algo tipo DENSE_RANK : scott@DESENV:SQL>SELECT deptno, 2 empno, 3 sal, 4 dense_rank() OVER (PARTITION BY deptno ORDER BY sal) AS NUM_REG 5* FROM emp scott@DESENV:SQL>/ DEPTNO EMPNO SAL NUM_REG - - - - 10 7934 1300 1 10 7782 2450 2 10 7839 5000 3 20 7369 800 1 20 7876 1100 2 20 7566 2975 3 20 7788 3000 4 20 7902 3000 4 30 7900 950 1 30 7654 1250 2 30 7521 1250 2 30 7844 1500 3 30 7499 1600 4 30 7698 2850 5 14 linhas selecionadas. scott@DESENV:SQL> ==>> PERCEBA que no departamento 30 a segunda posição foi um empate, ambos 'dividiram o pódio' na medalha de prataSacou ?? É ISSO que eu solicitei que vc verificasse com teu Analista pra saber se é o que ele quer - via de regra, 99,99% das vezes quando neguim fala em N primeiros ou N últimos registros
Re: [oracle_br] Objetos invalidos apos um shutdown é possivel ?
Opa, boa tarde!
Faz um teste com o flashback na dba_objects e ve se ja estava invalido.
Obs. dependendo do tamanho da undo e da retention, pode ser que vc consiga ve
alguma coisa.
select * from dba_objects as of timestamp SYSDATE -1/24
Abs,
Em Terça-feira, 26 de Dezembro de 2017 10:41, "angelo
angelolis...@gmail.com [oracle_br]" escreveu:
Bom dia,
Poderia acontecer de, supor que um servidor Oracle tenha a base parada com
shutdown immediate, para uma atualização do sistema operacional e um reboot, ao
retornar em produção, um schema apresentar diversos objetos marcados como
inválidos ?
Eu acho que isso não aconteceria, a base foi encerrada bonitinha mas quero ver
se estou certo.
Tá rolando um inquérito aqui na empresa, porque isso aconteceu aqui, nesse
feriado do Natal, o servidor foi atualizado e hoje cedo o sistema que acessa
essa base, um erp, nao abria justamente por dar mensagens de erros de objetos
inválidos e ninguém sabia dizer quem foi ou como foi que alterou... isso porque
nao comecei a procurar nada ainda no banco... quero ver se alguém se acusa
E pressionando as pessoas, porque to achando que teve dedo do fornecedor (que
tem acesso também porque eventualmente faz algumas alterações no schema dele)
no meio porque por volta das 8:00 o erro ainda ocorria e ja tinha usuario
reclamando e depois das 8:30, "misteriosamente", os objetos ficaram validos e
começou a funcionar e não avisaram nada a gente...
situacao escrota de lidar né ?
[]s angelo
#yiv4582466619 #yiv4582466619 -- #yiv4582466619ygrp-mkp {border:1px solid
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv4582466619
#yiv4582466619ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv4582466619
#yiv4582466619ygrp-mkp #yiv4582466619hd
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px
0;}#yiv4582466619 #yiv4582466619ygrp-mkp #yiv4582466619ads
{margin-bottom:10px;}#yiv4582466619 #yiv4582466619ygrp-mkp .yiv4582466619ad
{padding:0 0;}#yiv4582466619 #yiv4582466619ygrp-mkp .yiv4582466619ad p
{margin:0;}#yiv4582466619 #yiv4582466619ygrp-mkp .yiv4582466619ad a
{color:#ff;text-decoration:none;}#yiv4582466619 #yiv4582466619ygrp-sponsor
#yiv4582466619ygrp-lc {font-family:Arial;}#yiv4582466619
#yiv4582466619ygrp-sponsor #yiv4582466619ygrp-lc #yiv4582466619hd {margin:10px
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv4582466619
#yiv4582466619ygrp-sponsor #yiv4582466619ygrp-lc .yiv4582466619ad
{margin-bottom:10px;padding:0 0;}#yiv4582466619 #yiv4582466619actions
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv4582466619
#yiv4582466619activity
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv4582466619
#yiv4582466619activity span {font-weight:700;}#yiv4582466619
#yiv4582466619activity span:first-child
{text-transform:uppercase;}#yiv4582466619 #yiv4582466619activity span a
{color:#5085b6;text-decoration:none;}#yiv4582466619 #yiv4582466619activity span
span {color:#ff7900;}#yiv4582466619 #yiv4582466619activity span
.yiv4582466619underline {text-decoration:underline;}#yiv4582466619
.yiv4582466619attach
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px
0;width:400px;}#yiv4582466619 .yiv4582466619attach div a
{text-decoration:none;}#yiv4582466619 .yiv4582466619attach img
{border:none;padding-right:5px;}#yiv4582466619 .yiv4582466619attach label
{display:block;margin-bottom:5px;}#yiv4582466619 .yiv4582466619attach label a
{text-decoration:none;}#yiv4582466619 blockquote {margin:0 0 0
4px;}#yiv4582466619 .yiv4582466619bold
{font-family:Arial;font-size:13px;font-weight:700;}#yiv4582466619
.yiv4582466619bold a {text-decoration:none;}#yiv4582466619 dd.yiv4582466619last
p a {font-family:Verdana;font-weight:700;}#yiv4582466619 dd.yiv4582466619last p
span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv4582466619
dd.yiv4582466619last p span.yiv4582466619yshortcuts
{margin-right:0;}#yiv4582466619 div.yiv4582466619attach-table div div a
{text-decoration:none;}#yiv4582466619 div.yiv4582466619attach-table
{width:400px;}#yiv4582466619 div.yiv4582466619file-title a, #yiv4582466619
div.yiv4582466619file-title a:active, #yiv4582466619
div.yiv4582466619file-title a:hover, #yiv4582466619 div.yiv4582466619file-title
a:visited {text-decoration:none;}#yiv4582466619 div.yiv4582466619photo-title a,
#yiv4582466619 div.yiv4582466619photo-title a:active, #yiv4582466619
div.yiv4582466619photo-title a:hover, #yiv4582466619
div.yiv4582466619photo-title a:visited {text-decoration:none;}#yiv4582466619
div#yiv4582466619ygrp-mlmsg #yiv4582466619ygrp-msg p a
span.yiv4582466619yshortcuts
{font-family:Verdana;font-size:10px;font-weight:normal;}#yiv4582466619
.yiv4582466619green {color:#628c2a;}#yiv4582466619 .yiv4582466619MsoNormal
{margin:0 0 0 0;}#yiv4582466619 o {font-size:0;}#yiv4582466619
#yiv4582466619photos div {float:left;width:72px;}#yiv4582466619
#yiv4582466619photos div div {border:1p
Re: [oracle_br] Re: Consulta muito lenta!!
olá, boa tarde!
você poderia testar o hint /*+ use_nl()*/ e ve se o resuldato melhora?
se o resultado for satisfatorio, você pode aplicar esse plano para a sua query,
com a criação de uma profile.
Att,
Em Sexta-feira, 15 de Dezembro de 2017 14:28, "jlchia...@yahoo.com.br
[oracle_br]" escreveu:
Blz ? Vamos por partes aí : primeiro, antes de tudo, tecnicamente falando
*** Não é verdade *** que vc não consegue mudar o texto de um SQL (para injetar
um hint, para mudar cláusulas no WHERE, mudar tabelas no FROM, enfim,
re-escrever o SQL) sem ter acesso ao fonte da Aplicação : minha Apresentação no
dba brasil 1.0 (veja em
http://www.dbabr.com.br/blog/wp-content/uploads/2016/03/SQL-Factoring.pdf) foi
EXATAMENTE SOBRE ISSO, no caso usando a DBMS_ADVANCED_REWRITE, mas também falei
de passagem sobre outras menos invasivas como views, sinônimos, etc... ok ?
CONHEÇA as capacidades mas ANALISE A VIABILIDADE antes de usar...
Mas só porque vc PODE fazer não quer dizer que vc DEVA okdoc ? Em especial
quando falamos de SAP, que é uma aplicação TREMENDAMENTE FECHADA, onde nem
sequer usar a tool de backup nativa do banco eles te deixam Sendo assim,
NECESSARIAMENTE tudo o que vou falar tem que ser feito com CONCORDÂNCIA DO
SUPORTE DA SAP, sim sim ?? Então se não abriu Chamado lá, ABRA!!!
Bom, para vc começar uma análise visando tuning (E EM ESPECIAL para um SQL que
usa & abusa de binds como parece ser esse aí!!) o Passo Inicial é vc obter um
PLANO DE EXECUÇÃO EXTENDIDO, que mostre as colunas A-ROWs e E-ROWs, pra vc
poder Validar se as estatísticas usadas estão razoáveis : veja
https://blogs.oracle.com/optimizer/how-do-i-know-if-the-cardinality-estimates-in-a-plan-are-accurate
Outra Possibilidade é que vc tenha BIND VARIABLE PEEKING acontecendo aí e o
Otimizador está usando estatísticas para um determinado valor peeked numa
execução anterior que não é de frequência comum, OU mesmo que o banco esteja
criando Múltiplos cursores child por causa dos binds : veja
http://optimizermagic.blogspot.com.br/2007/12/why-are-there-more-cursors-in-11g-for.html
e
http://kerryosborne.oracle-guy.com/2009/03/bind-variable-peeking-drives-me-nuts/
como refs... INCLUSIVE, a entrada
https://blogs.sap.com/2013/06/13/oracle-db-optimizer-part-vi-effects-of-disabled-bind-variable-peeking-adaptive-cursor-sharing-and-cardinality-feedback-on-the-cbo-in-sap-environments/
num blog da SAP mesmo já Alerta para essa Possibilidade, e PERCEBA que essa
entrada mesmo do blog USA TAMBÉM as colunas A-ROWs e E-ROWs do Plano de
Execução Extendido para Diagnóstico, sim sim ?? veja lá...
Uma outra possibilidade que vc pode Perseguir é a possibilidade que o Plano de
Execução em si esteja o melhor possível para as condições exigidas MAS
fisicamente na hora de executar o plano o banco tá demorando muito - seja
porque Outros SQLs tão consumindo muita banda de rede, I/O e/o CPU não deixando
poder de hardware pro banco executar esse seu, seja porque tá com montes de
whitespace nos segmentos em questão, ou seja qual for WAITs/locks/latches tão
envolvidos... Faça um TRACE 10046 level máximo de uma sessão executando esse
SQL em questão...
E finalmente : vc Não Só deve repassar para o Suporte da SAP o tracle, o Plano
Extendido e as suas conclusões da análise MAS também TEM que validar com eles
esses PROFILES DE SQL, SQL patches e etc que alguém (eles mesmos ?? você ??)
criou, pois vi nos planos as linhas :
- SQL profile coe_ag6zapv5kypgx_1159570678 used for this statement
- SQL patch "suggest_support_sap" used for this statement
[]s
Chiappa
OBS : para fins de Análise, já que vc Identificou o SQL, nada Impede que vc,
no seu banco de TESTE mas que tenha um volume Razoável de dados, experimentar
HINTs, criar outros índices, alterar o SQL para que faça acesso à chave
COMPLETA do índice (e não à chave parcial, que deduzo estar acontecendo por
causa dos "INDEX RANGE SCAN" e "INDEX SKIP SCAN" que vi)... QUalquer informação
que vc obtenha nesses testes Repasse pro Suporte SAP... #yiv5259282637
#yiv5259282637 -- #yiv5259282637ygrp-mkp {border:1px solid
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv5259282637
#yiv5259282637ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv5259282637
#yiv5259282637ygrp-mkp #yiv5259282637hd
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px
0;}#yiv5259282637 #yiv5259282637ygrp-mkp #yiv5259282637ads
{margin-bottom:10px;}#yiv5259282637 #yiv5259282637ygrp-mkp .yiv5259282637ad
{padding:0 0;}#yiv5259282637 #yiv5259282637ygrp-mkp .yiv5259282637ad p
{margin:0;}#yiv5259282637 #yiv5259282637ygrp-mkp .yiv5259282637ad a
{color:#ff;text-decoration:none;}#yiv5259282637 #yiv5259282637ygrp-sponsor
#yiv5259282637ygrp-lc {font-family:Arial;}#yiv5259282637
#yiv5259282637ygrp-sponsor #yiv5259282637ygrp-lc #yiv5259282637hd {margin:10px
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv5259282637
#yiv5259282637ygrp-s
Re: RES: RES: [oracle_br] AJUDA - UPDATE MONSTRO TABELA DE 11,5 MILHOES DE LINHAS
Opa, boa tarde!
Segue um bloco de exemplo.
CREATE TABLE teste_update (ID NUMBER, texto CHAR(1))/SELECT * FROM
teste_update/SQL> desc teste_update;Name Type Nullable Default Comments
- --- --- ID NUMBER Y
TEXTO CHAR(1) Y
SQL>
DECLARE
CURSOR C IS SELECT ROWID rrowid FROM teste_update; -- se tiver
um filtro de data vc pode rodar em parallel
TYPE T_C IS TABLE OF C%ROWTYPE;
C_Array T_C;
BEGIN
dbms_application_info.set_action('Abrindo cursor'); OPEN C; -- LOOP
dbms_application_info.set_action('Qtd C '||C%ROWCOUNT); FETCH C BULK
COLLECT INTO C_array LIMIT 1;
FORALL i IN 1..C_array.count UPDATE teste_update SET texto =
'.' WHERE rowid = C_Array(i).rrowid;
COMMIT;
EXIT WHEN C%NOTFOUND;
END LOOP;
COMMIT;
CLOSE C;
EXCEPTION WHEN OTHERS THEN ROLLBACK; RAISE;
END;/-- vc pode criar uma procedure com parametro de entrada no bloco acima e
depois usar esse bloco abaixo para atualizar em parallel
DECLARE
L_date DATE := DATE '2013-03-14'; L_date_f DATE := DATE '2013-03-15';
BEGIN -- FOR i IN REVERSE 0..(L_date_f-L_date)-1 LOOP --
dbms_application_info.set_module('BKLOG', TO_CHAR(L_date + i, '-mm-dd'));
-- BEGIN -- NULL; -- END; -- END LOOP; --END;
Espero que ajude.
Abs,
Em Terça-feira, 17 de Outubro de 2017 14:48, "Ricardo Sá
ricardo@terra.com.br [oracle_br]" escreveu:
Chiappa, De fato foi o que aconteceu, inicialmente o bloco PL/SQL rodou
tranquilo, a cada 100.000 linhas, porém aos poucos foi ficando lento, aí eu
cancelei.E fiz exatamente o procedimento que você informou neste, ou seja,
dropei todos os índices, desabilitei as triggers, em um base StandBy em um DG
que mantenho.Estabeleci uma área de UNDO de 256GB de disco e RETENÇÃO de 6
Horas.O processo rodou em 2 horas, em um servidor com recursos inferior ao de
produção ( 2 Nodes rodando em storage VNX bem configurado pelo pessoal da
DELL-EMC).Depois a recriação dos índices demorou 1 hora rodando com parallel
10, totalizando todo o processo aprox.. 3 horas.Irei rodar este processo em uma
janela bem folgada no amb produção , e acredito que irá cair para quase a
metade do tempo. De qq forma, muito obrigado pela abordagem. Att.:Ricardo
De: oracle_br@yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br]
Enviada em: terça-feira, 17 de outubro de 2017 13:55
Para: oracle_br@yahoogrupos.com.br
Assunto: Re: RES: [oracle_br] AJUDA - UPDATE MONSTRO TABELA DE 11,5 MILHOES DE
LINHAS Ricardo, eu ** discordo ** dessa Abordagem : se o objetivo é máxima
Performance o correto e Recomendado é vc ter uma área de ROLLBACK o mais larga
Possível e fazer num comando só INCLUSIVE, eu imagino que vc Saiba que :
a. cada COMMIT *** implica *** em espera por I/O, já que força um sync write
b. vc está jogando PELA JANELA a integridade dos dados, pois se vc tinha que
processar x linhas, processou menos que isso e deu um COMMIT, se as próximas
linhas falharem vc acabou com uma tabela MEio processada e Meio não processada,
comofaz ??
c. vc está jogando PELA JANELA o conceito de Transação, que demanda que ***
TODOS *** os comandos/operações Tem que ser reversíveis : ora , no mesmo
exemplo de cima se vc comitou algumas vezes no LOOP e depois disso houve falha
(ou o usuário quer Desfazer a transação) o ROLLBACK SIMPLESMENTE NÃO VAI
FUNCIONAR, o que tá comitado comitou, comofaz??
==> NADA do que eu disse é novidade, há 15 anos o Tom Kyte já falava isso, vide
https://asktom.oracle.com/pls/asktom/f?p=100:11:0P11_QUESTION_ID:4951966319022
. PENSE NESSAS CONSEQUÊNCIAS antes de sair usando essa 'técnica', sim sim
???
imho os procedimentos Performáticos e Seguros de se fazer seriam :
1. Paralelismo : já que é EE vc ** necessariamente ** TEM aí na mão a chance
de rodar o DML em parallel-mode e/ou de ler os registros que quer alterar em
Parallel... O degree de parallelismo vai depender muito do teu hardware, vc tem
que levantar qual tua capacidade em termos de CPU e I/O...
ou
2. se a Maioria das linhas vão ser Updateadas, vc faz um INSERT */ APPEND */
num outra tabela , alterando o valor que quer alterar : isso vai diminuir
MONSTRUOSAMENTE o tanto de redo log gerado (não vai zerar mas vai Diminuir
Enormemente!!) e é mais rápido que UPDATE, veja
https://asktom.oracle.com/pls/apex/asktom.search?tag=how-to-update-millions-or-records-in-a-table-200211#6417104879869
para um Exemplo
===> E NECESSARIAMENTE um DML largo é SIM uma Manutenção da tabela, então TEM
que ser feita num período de menor carga no sistema, e PREFERENCIALMENTE, com
os índices E constraints desabilitados, os quais vc Reconstruiria em parallel
depois e com NOVALIDATE nas constraint se possível...
[]s
Chiappa
OBS : se por qualquer Motivo não puder fazer Parallel SQL ao menos valide a
opção de B
Re: [oracle_br] Re: Erro ao instalar GRID
Opa, boa tarde!
No outro node você conseguiu rodar o root.sh?
Se sim, como esta seu parametrro asm_diskstring?
Abs,
Em Terça-feira, 17 de Janeiro de 2017 14:48, "Rafael Mendonca
raffaell.t...@yahoo.com [oracle_br]" escreveu:
OK Chiappa, irei verificar essa sua recomendação. caso não consiga
resolver, irei seguir o tutorial do Tim Hall indicado por você.
Obrigado.
Em Terça-feira, 17 de Janeiro de 2017 13:46, "jlchia...@yahoo.com.br
[oracle_br]" escreveu:
Bem, como nunca usei esse Tutorial (sempre preferi os do ORACLE-BASE,
normalmente o cara é bem cuidadoso nos detalhes) então não sei te
indicar/avaliar onde pode estar a falha O mais que posso Recomendar, se vc
*** RECHECOU *** direitinho, passo-a-passo e não esqueceu NADICA DE NADA, seria
mesmo checar por prováveis conflitos de IP... Inclusive, pelo que entendi nesse
Tutorial aí ele cria uma terceira interf de rede em BRIDGE pra dar acesso à
internet, experimenta remover/desabilitar isso pra ver se não é esse carinha
dando conflito eventualmente
[]s
Chiappa
#yiv0611982609 #yiv0611982609 -- #yiv0611982609ygrp-mkp {border:1px solid
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv0611982609
#yiv0611982609ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv0611982609
#yiv0611982609ygrp-mkp #yiv0611982609hd
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px
0;}#yiv0611982609 #yiv0611982609ygrp-mkp #yiv0611982609ads
{margin-bottom:10px;}#yiv0611982609 #yiv0611982609ygrp-mkp .yiv0611982609ad
{padding:0 0;}#yiv0611982609 #yiv0611982609ygrp-mkp .yiv0611982609ad p
{margin:0;}#yiv0611982609 #yiv0611982609ygrp-mkp .yiv0611982609ad a
{color:#ff;text-decoration:none;}#yiv0611982609 #yiv0611982609ygrp-sponsor
#yiv0611982609ygrp-lc {font-family:Arial;}#yiv0611982609
#yiv0611982609ygrp-sponsor #yiv0611982609ygrp-lc #yiv0611982609hd {margin:10px
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv0611982609
#yiv0611982609ygrp-sponsor #yiv0611982609ygrp-lc .yiv0611982609ad
{margin-bottom:10px;padding:0 0;}#yiv0611982609 #yiv0611982609actions
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv0611982609
#yiv0611982609activity
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv0611982609
#yiv0611982609activity span {font-weight:700;}#yiv0611982609
#yiv0611982609activity span:first-child
{text-transform:uppercase;}#yiv0611982609 #yiv0611982609activity span a
{color:#5085b6;text-decoration:none;}#yiv0611982609 #yiv0611982609activity span
span {color:#ff7900;}#yiv0611982609 #yiv0611982609activity span
.yiv0611982609underline {text-decoration:underline;}#yiv0611982609
.yiv0611982609attach
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px
0;width:400px;}#yiv0611982609 .yiv0611982609attach div a
{text-decoration:none;}#yiv0611982609 .yiv0611982609attach img
{border:none;padding-right:5px;}#yiv0611982609 .yiv0611982609attach label
{display:block;margin-bottom:5px;}#yiv0611982609 .yiv0611982609attach label a
{text-decoration:none;}#yiv0611982609 blockquote {margin:0 0 0
4px;}#yiv0611982609 .yiv0611982609bold
{font-family:Arial;font-size:13px;font-weight:700;}#yiv0611982609
.yiv0611982609bold a {text-decoration:none;}#yiv0611982609 dd.yiv0611982609last
p a {font-family:Verdana;font-weight:700;}#yiv0611982609 dd.yiv0611982609last p
span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv0611982609
dd.yiv0611982609last p span.yiv0611982609yshortcuts
{margin-right:0;}#yiv0611982609 div.yiv0611982609attach-table div div a
{text-decoration:none;}#yiv0611982609 div.yiv0611982609attach-table
{width:400px;}#yiv0611982609 div.yiv0611982609file-title a, #yiv0611982609
div.yiv0611982609file-title a:active, #yiv0611982609
div.yiv0611982609file-title a:hover, #yiv0611982609 div.yiv0611982609file-title
a:visited {text-decoration:none;}#yiv0611982609 div.yiv0611982609photo-title a,
#yiv0611982609 div.yiv0611982609photo-title a:active, #yiv0611982609
div.yiv0611982609photo-title a:hover, #yiv0611982609
div.yiv0611982609photo-title a:visited {text-decoration:none;}#yiv0611982609
div#yiv0611982609ygrp-mlmsg #yiv0611982609ygrp-msg p a
span.yiv0611982609yshortcuts
{font-family:Verdana;font-size:10px;font-weight:normal;}#yiv0611982609
.yiv0611982609green {color:#628c2a;}#yiv0611982609 .yiv0611982609MsoNormal
{margin:0 0 0 0;}#yiv0611982609 o {font-size:0;}#yiv0611982609
#yiv0611982609photos div {float:left;width:72px;}#yiv0611982609
#yiv0611982609photos div div {border:1px solid
#66;height:62px;overflow:hidden;width:62px;}#yiv0611982609
#yiv0611982609photos div label
{color:#66;font-size:10px;overflow:hidden;text-align:center;white-space:nowrap;width:64px;}#yiv0611982609
#yiv0611982609reco-category {font-size:77%;}#yiv0611982609
#yiv0611982609reco-desc {font-size:77%;}#yiv0611982609 .yiv0611982609replbq
{margin:4px;}#yiv0611982609 #yiv0611982609ygrp-actbar div a:first-child
Re: [oracle_br] monitoramento de índex - Oracle
Opa, boa noite!
Você precisa está logado com o dono do indice.
Ou abre a view pegue o select e retire a condição => io.owner# =
userenv('SCHEMAID')
select io.name, t.name, decode(bitand(i.flags, 65536), 0, 'NO', 'YES'),
decode(bitand(ou.flags, 1), 0, 'NO', 'YES'), ou.start_monitoring,
ou.end_monitoringfrom sys.obj$ io, sys.obj$ t, sys.ind$ i, sys.object_usage
ouwhere i.obj# = ou.obj# and io.obj# = ou.obj# and t.obj# = i.bo#;
Essa á a minha =>
select ui.name index_owner, io.name index_name, ut.name table_owner,
t.name table_name, decode(bitand(i.flags, 65536), 0, 'NO', 'YES')
MONITORING, decode(bitand(ou.flags, 1), 0, 'NO', 'YES') USED,
ou.start_monitoring START_MONITORING, ou.end_monitoring
END_MONITORINGfrom sys.obj$ io, sys.obj$ t, sys.ind$ i, sys.object_usage ou,
sys.user$ ui, sys.user$ utwhere i.obj# = ou.obj# and io.obj# = ou.obj# and
t.obj# = i.bo# and ui.USER# = io.owner# and ut.user# = t.owner# AND t.name
= '' --tabela-- and decode(bitand(i.flags, 65536), 0, 'NO', 'YES') = 'YES'
order by 6,1;
Abs,
Em Quarta-feira, 10 de Agosto de 2016 19:09, "alisson...@yahoo.com.br
[oracle_br]" escreveu:
olá boa noite a todos!
Estou ativando o monitoramentos de alguns indexes do oracle, com suspeita de
desuso.
o comando usado foi ALTER INDEX aluno.ix_candidato MONITORING USAGE;
Esse comando foi aplicado a mais ou menos a 1h:30 mm e quando consulto a view
V$OBJECT_USAGE ela simplesmente não me traz nenhuma linha. Ela não deveria
trazer o índex informando se teve ou não uso ?
Oracle 11r2 windows server 2012
At,Alisson Luz #yiv9458225710 #yiv9458225710 -- #yiv9458225710ygrp-mkp
{border:1px solid #d8d8d8;font-family:Arial;margin:10px 0;padding:0
10px;}#yiv9458225710 #yiv9458225710ygrp-mkp hr {border:1px solid
#d8d8d8;}#yiv9458225710 #yiv9458225710ygrp-mkp #yiv9458225710hd
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px
0;}#yiv9458225710 #yiv9458225710ygrp-mkp #yiv9458225710ads
{margin-bottom:10px;}#yiv9458225710 #yiv9458225710ygrp-mkp .yiv9458225710ad
{padding:0 0;}#yiv9458225710 #yiv9458225710ygrp-mkp .yiv9458225710ad p
{margin:0;}#yiv9458225710 #yiv9458225710ygrp-mkp .yiv9458225710ad a
{color:#ff;text-decoration:none;}#yiv9458225710 #yiv9458225710ygrp-sponsor
#yiv9458225710ygrp-lc {font-family:Arial;}#yiv9458225710
#yiv9458225710ygrp-sponsor #yiv9458225710ygrp-lc #yiv9458225710hd {margin:10px
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv9458225710
#yiv9458225710ygrp-sponsor #yiv9458225710ygrp-lc .yiv9458225710ad
{margin-bottom:10px;padding:0 0;}#yiv9458225710 #yiv9458225710actions
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv9458225710
#yiv9458225710activity
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv9458225710
#yiv9458225710activity span {font-weight:700;}#yiv9458225710
#yiv9458225710activity span:first-child
{text-transform:uppercase;}#yiv9458225710 #yiv9458225710activity span a
{color:#5085b6;text-decoration:none;}#yiv9458225710 #yiv9458225710activity span
span {color:#ff7900;}#yiv9458225710 #yiv9458225710activity span
.yiv9458225710underline {text-decoration:underline;}#yiv9458225710
.yiv9458225710attach
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px
0;width:400px;}#yiv9458225710 .yiv9458225710attach div a
{text-decoration:none;}#yiv9458225710 .yiv9458225710attach img
{border:none;padding-right:5px;}#yiv9458225710 .yiv9458225710attach label
{display:block;margin-bottom:5px;}#yiv9458225710 .yiv9458225710attach label a
{text-decoration:none;}#yiv9458225710 blockquote {margin:0 0 0
4px;}#yiv9458225710 .yiv9458225710bold
{font-family:Arial;font-size:13px;font-weight:700;}#yiv9458225710
.yiv9458225710bold a {text-decoration:none;}#yiv9458225710 dd.yiv9458225710last
p a {font-family:Verdana;font-weight:700;}#yiv9458225710 dd.yiv9458225710last p
span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv9458225710
dd.yiv9458225710last p span.yiv9458225710yshortcuts
{margin-right:0;}#yiv9458225710 div.yiv9458225710attach-table div div a
{text-decoration:none;}#yiv9458225710 div.yiv9458225710attach-table
{width:400px;}#yiv9458225710 div.yiv9458225710file-title a, #yiv9458225710
div.yiv9458225710file-title a:active, #yiv9458225710
div.yiv9458225710file-title a:hover, #yiv9458225710 div.yiv9458225710file-title
a:visited {text-decoration:none;}#yiv9458225710 div.yiv9458225710photo-title a,
#yiv9458225710 div.yiv9458225710photo-title a:active, #yiv9458225710
div.yiv9458225710photo-title a:hover, #yiv9458225710
div.yiv9458225710photo-title a:visited {text-decoration:none;}#yiv9458225710
div#yiv9458225710ygrp-mlmsg #yiv9458225710ygrp-msg p a
span.yiv9458225710yshortcuts
{font-family:Verdana;font-size:10px;font-weight:normal;}#yiv9458225710
.yiv9458225710green {color:#628c2a;}#yiv9458225710 .yiv9458225710MsoNormal
{margin:0 0 0 0;}#yiv9458225710 o {font-
