Refresh Snapshot

Is there a command or a way to refresh many snapshot at the same time..
Message was edited by:
Simon

Oh, okay. If you wish, you can set up a refresh group for your MVs and schedule them to be refreshed automatically by Oracle. You would use the dbms_refresh package, ie
dbms_refresh.refresh('"schema"."mv_view_name"');To schedule this as a job, you would use the dbms_job package, ie
DECLARE
X NUMBER;
BEGIN
SYS.DBMS_JOB.SUBMIT
( job       => X
   ,what      => 'dbms_refresh.refresh(''"schema"."mv_view_name"'');'
   ,next_date => to_date('01/11/2007 08:53:02','dd/mm/yyyy hh24:mi:ss')
   ,interval => 'sysdate + 1 '
   ,no_parse => FALSE
--SYS.DBMS_OUTPUT.PUT_LINE('Job Number is: ' || to_char(x));
COMMIT;
END;
/

Similar Messages

APS Collections Refresh Snapshot Thread running for very long

Hi,
Program "APS Collections Refresh Snapshot Thread" for "BOM_INV_COMPS_SN" snapshot is running for very long time.
Can we cancel it?
It's running in FAST refresh mode.
Thanks.

Hi,
Count the records in the mlog tables of these MVs. If the record count is more than do a complete refresh.
Thanks,
Abhishek Sharma

Can not refresh snapshot changes after importing data of master site

Hello !
I have two database computer,one as master site,one as snapshot site.Because the error of the hard disk of master computer,I use the exporting data file to recover my database.after importing ,I found I can't refresh the refreshgroup on snapshot,who can tell me why?
thinks in advance!
(exp system/manager full=y inctype=complete file='/home/save/backdata/xhsdcomp.dat')
(imp system/manager inctype=system full=Y file='/home/save/backdata/xhsdcomp.dat'
imp system/manager inctype=restore full=Y file='/home/save/backdata/xhsdcomp.dat')
null

You haven't listed the errors that you're receiving when attempting to refresh your refresh group, but if your snapshots are attempting to fast refresh, I suspect it's because the creation timestamp of the snapshot log on the master site is newer than the creation timestamp of the snapshot. In this case you will need to do a complete refresh of the snapshot (or drop and recreate the snapshot) before you will be able to fash refresh it again.
If this is not the case, please post the errors you are receiving when you attempt to refresh the refresh group.
HTH,
-- Anita
Oracle Support Services
null

Which job refreshes Snapshot Queries?

Does anyone know which job in the Automation Server refreshes the cached used by Snapshot Queries?
The Admin Guide states "These cached search results are refreshed at the same interval as many other end-user caches, every 15 minutes.".
Does that correspond to a particular job (ie. Card Refresh or Search Update 1)? Or am I confused?
Thanks in advance,Justin

Hi,
I thing with the DBA studio it is taking the nextinterval time as sysdate+1/288; So find out that job which is running for that and change the interval value using the
dbms_job package to
trunc(sysdate)+1 then it will run exactly at 12 midnight;
I hope this will help you
regards,
khaleel

Fast refresh snapshots with primary key deferrable

Oracle version 8.1.7 standard
I've created this sample schema:
Tables:
create table a_customer
(c_id integer primary key deferrable,
zip integer
create table a_orders
(o_id integer primary key deferrable,
c_id integer,
constraint o_c foreign key (c_id)
references a_customer(c_id)
create index c_ind on a_orders(c_id);
create table a_order_line
(ol_id integer primary key deferrable,
o_id integer,
constraint ol_o foreign key(o_id)
references a_orders(o_id)
Snapshot logs:
create snapshot log on a_customer with primary key (zip);
create snapshot log on a_orders with primary key (c_id);
create snapshot log on a_order_line with primary key (o_id);
When I create the snapshot from another instance:
create snapshot orders_snap refresh fast as
select * from a_orders@dblink o where exists
(select c_id from a_customer@dblink c where
o.c_id = c.c_id and zip = 19555);
It return me the error ORA-12015.
If I recreate the primary keys without "deferrable" option, the snapshot is created succesfully.
Is it a bug of the Oracle version used?

Why will someone update the PK of a table. This itself violates the basic design of any application. A PK on a customer ID or a social security no of a person will never get updated in a life time of a user. In case a new number needs to be issued then the correct sequence is to delete the existing record and create new one rather then updating the existing record.
So you jsut need to check the logic with deleting the PK and then refreshing the Mviews. Please do not update the PK that will itself be a flaw in application design as far my experience is concerend with the PK.
Amar

Refreshing snapshots

Hello,
I am trying to make a basic replication schema. I want to use
read-only snapshots, and the snaphots to be auto-refreshed. I
have RTFM, and I have put in initXXX.ora the right lines
(job_queue_processes = 5
job_queue_interval = 60).
The refresh processes are created (SNPx). But there is a problem
with the snapshots to be automatically refreshed. In
rdbms/log/snp3_XXX_460.trc it says:
*** SESSION ID:(10.355) 1999.03.31.17.49.24.663
*** 1999.03.31.17.49.24.663
ORA-12012: error on auto execute of job 81
ORA-01001: invalid cursor
ORA-06512: at "SYS.DBMS_SNAPSHOT", line 386
ORA-06512: at "SYS.DBMS_IREFRESH", line 450
ORA-06512: at "SYS.DBMS_REFRESH", line 182
ORA-06512: at line 1
Anyone has an idea about where this comes from?
TIA,
Misa
null

<BLOCKQUOTE><font size="1" face="Verdana, Arial">quote:</font><HR>Originally posted by DSS:
How do you refresh a snapshot from a stored procedure which is running on database other than where the snapshot is compiled.?
The DBMS_SNAPSHOT procedure does not support synonyms.
Thanks<HR></BLOCKQUOTE>
null

10g Refresh Snapshot log question

Hi,
I need to run complete refresh on a materialized view log.
BEGIN
DBMS_SNAPSHOT.REFRESH(
LIST => 'XYZ_DETAIL'
,METHOD => 'C'
,PUSH_DEFERRED_RPC => TRUE
,REFRESH_AFTER_ERRORS => FALSE
,PURGE_OPTION => 1
,PARALLELISM => 0
,ATOMIC_REFRESH => TRUE
,NESTED => FALSE);
END;
I would like to Refresh it with PARALLELISM => 8 , and after the rebuild will finish
i want to set it back to serial (e.g: PARALLELISM => 0).
Is there an ALTER command that i can use ?
Please explain how to do that.
Thanks.

For the specific 10g case of
BEGIN
DBMS_SNAPSHOT.REFRESH(
LIST => 'XYZ_DETAIL'
,METHOD => 'C'
,PUSH_DEFERRED_RPC => TRUE
,REFRESH_AFTER_ERRORS => FALSE
,PURGE_OPTION => 1
,PARALLELISM => 0
,ATOMIC_REFRESH => TRUE
,NESTED => FALSE);
END;
and using PARALLELISM of 8 for a specific refresh
can you tell us what are the differences in Materialized Views , say between
10gR1 and 10gR2 if you can't tell us the differences between 8i and 10g ?
Message was edited by:
Hemant K Chitale

How to track Snapshot refresh error

Hi
I have a procedure which is doing the below transaction one after one:
1- Refresh snapshot Snap1
2- track snapshot refresh status If Ok do step 3 if not exit
2- Insert agregate data from snapshot Snap1 to table
3- Track insertion status if Ok proceed on next steps if not exit
3- commit
To refresh the snapshot here is the syntaxe i want to use.
DBMS_SNAPSHOT.refresh('Snap1','F');
If refresh ok then
insert into T1 select ..... from Snap1;
commit;
end if;
Thank you.

I try to show/hide a div depending on the occurence of errors. I resolved this problem by doing this in javascript.
function showEdu(){
$("#edu").animate({ height: 'show', opacity: 'show' }, 'slow');
$s('P6_EDU_SHOWN','Y');
function hideEdu(){
$("#edu").animate({ height: 'hide', opacity: 'hide' }, 'slow');
$s('P6_EDU_SHOWN','N');
function checkEduError(){
if($("span").hasClass("errTxt") == true)
{showEdu();}
else
if($v('P6_EDU_SHOWN') == 'Y')
{showEdu();}
else
{hideEdu();}
}

Snapshots refresh from package from another scheme

*Also posted to Database:General!
Hi all,
i have a trouble while refreshing snapshots.
First, i have a scheme where a package (for snapshots
update) and snapshots themselves reside:
package snp_update
procedure update_snapshots
is
begin
for s_name in ( SELECT owner, name
FROM user_snapshots )
loop
dbms_snapshot.refresh (s_name.owner || '.' ||
s_name.name, 'CA');
end loop;
end;
end;
Second, i have a scheme where reside only synonym to
snp_update package (synonym name is syn_snp_update) and
this scheme have granted 'execute' privilege on snp_update.
But when i try to use it as
begin
syn_snp_update.update_snapshot;
end;
i have error: ORA-01031: insufficient privileges.
But when i execute this pl/sql block from package
owner's scheme - everything ok.
Oracle: 8.0.5 on Sun Solaris 2.5
Plz, help me.
Maksym.

How has your schema been granted the rights on SYN_SNP_UPDATE? A common cause of this problem is that the rights have been granted to a role. Oracle does not allow you to build procedures, etc using objects that you have been granted through a role. If this is the case you'll have to grant EXECUTE on SYN_SNP_UPDATE to your schema explicitly.
Cheers, APCThrough
grant execute on snp_update <synonym's owner schema>;
BTW: Package's procedure is executing. Cursor (select ... from user_snapshots) retrieves first snapshot info in package's scheme and call to dbms_snapshot.refresh generates error.

ASCP Collections spawned Refresh Collection Snapshot taking longer

Hello Experts,
In a decentralized deployment, Refresh Snapshots spawned by ASCP Collections takes longer than the refresh snapshot launched as standalone request.
It looks like the program runs for long on the following queries
SELECT bic.component_item_id,
bic.component_quantit y
FROM MRP_SN_BOMS bom,
MRP_SN_INV_COMPS bic,
MTL_SYSTEM_ITEMS msi1,
MTL_SYSTEM_ITEMS msi2
WHERE bom.assembly_item_id =
:inventory_item_id
AND bom.organiz ation_id = :organization_id
AND msi1.inventory_item_id = bo
m.assembly_item_id
AND msi1.organization_id =
bom.organizat ion_id
AND bom.alternate_bom_designator IS NULL
AND b ic.bill_sequence_id =
bom.common_bill_sequence_id
AND bic.e ffectivity_date <
:g_scheduled_completion_date
AND NVL(bic .disable_date, :g_scheduled_completion_date + 1) >
:g_scheduled_completion_date
AND bic.WIP_ SUPPLY_TYPE = 6
AND msi2.inventory_item_id =
bic.component_ item_id
AND msi2.organization_id =
msi1.organization_id A ND NOT (msi1.AUTO_CREATED_CONFIG_FLAG='Y'
AND msi1.base_item_id IS NOT NULL
AND (msi2.BOM_ITEM_TYPE = 1
OR msi2.BOM_ ITEM_TYPE = 2))
SELECT ORGANIZATION_ID,
PLANNED_QUANTITY,
PRIMARY_ITEM_ID,
QUANTITY_COMPLETED,
SCHEDULED_COMPLETION_DATE,
SCHEDULED_START_DATE,
WIP_ENTITY_ID,
RN
FROM MRP_SN_FLOW_SCHDS
WHERE RN >= -1
AND PLANNED_QUANTITY > QUANTITY_COMPLETED
And the data volume seems very small, we have 30K items , less than
250 resources, no BOM.
If we run the Refresh collection snapshot as a standalone request on
Source/EBS instance, it completes in less than 5 mins. Only when it is
launched vial collections/db link, we are seeing this performance
issue.
We are on 12.1.3.4.
DBAs are not willing to modify the init.ora parameter mvrefresh_use_stats unless this is very specific.
Any help on this would be very helpful.
Regards
Sudeep

Is this issue resolved? If not can you throw some more information along the below questions.
Is the planning manager up and running? What about the firm planned flag? Is there any open quantity on job to be completed? Does this job show up on the view supply/demand screen on the txn instance?
Thanks,
Karthik

SRKIM: Snapshot Inv.Mlog$_mtl_system_items_b Records 수가 계속 증가함

PURPOSE
Tablespace 의 효과적인 관리를 위하여 아래의 작업을 진행 한다.
Problem Description
INV.MLOG$_MTL_SYSTEM_ITEMS_B table 이 계속적으로 증가하여 tablespace 를 차지할 뿐만 아니라 performance 에도 영향을 주고 있다.
Workaround
N/A
Solution Description
아래의 작업을 수행 후 해당 table 의 data volume 을 확인 하도록 한다.
Refresh Collection Snapshot 을 Complete Refresh 나 Automatic 으로 수행.
Complete Refresh 는 모든 snapshots 을 process 하고 refresh 하는 작업을 수행.
Automatic Refresh 는 snapshot log 를 truncate 한 후 complete
refresh of the snapshot(s) 작업을 수행 하는 역할이다.
Reference Documents
335747.1 Snapshot Inv.Mlog$_mtl_system_items_b Records Increasing

HI,
Please go through below MOS docs:-
When do Snapshot Logs get Purged [ID 35217.1]
SNAPSHOT LOGS GROWS DUE TO MISSING/INVALID SNAPSHOT [ID 1031924.6]
How To Improve the Performance of the Refresh Collection Snapshots When Running Very High Volumes [ID 550005.1]
MLOG$_ENI_OLTP_ITEM_STAR is Growing too Large, can it be Truncated? [ID 367693.1]
Materialized View Refresh : Log Population and Purge [ID 236233.1]
Refresh Collection Snapshots Performance - Managing MLOG$ Tables and Snapshots for Data Collections [ID 1063953.1]
Thanks,
JD

SNAPSHOT LOG의 데이타가 지워지지 않는 이유와 강제로 지우는 방법 (V7 ~ V8I)

제품 : ORACLE SERVER
작성날짜 : 2002-05-09
SNAPSHOT LOG의 데이타가 지워지지 않는 이유와 강제로 지우는 방법
(V7 ~ V8I)
====================================================
PURPOSE
사용하고 있는 snapshot의 refresh에는 이상이 없는데 master table의
sanpshot log가 지워지지 않고 계속 늘어만 가는 경우가 있을 수 있다.
이러한 경우 master site의 snapshot log가 증가하면서 space문제를
발생시킬 수도 있고, log의 내용을 refresh해가는 속도도 문제가 될 수
있으므로 여기에서는 그 원인과 조치 사항을 정리한다.
Explanation
1. snapshot log의 데이타가 지워지는 원리
snapshot log의 데이타가 지워지는 순간은 snapshot의 refresh time 때,
refresh 후, 해당 데이타에 대해서 MLOG$_<table_name>내의 SNAPTIME과
SYS.SLOG$의 해당 master table에 대한 snapshot들의 SNAPTIME을 비교해 보아
SYS.SLOG$.SNAPTIME이 MLOG$_<table_name>.SNAPTIME보다 미래이거나 같으면
그때 해당 데이타를 지우게 되는 것이다.
즉 다음 조건을 만족하는 때이다.
SYS.SLOG$.SNAPTIME >= MLOG$_<table_name>.SNAPTIME
그 이유는 snapshot log의 각 데이타는 master table에 연결된 여러 snapshot 중
첫 snapshot의 refresh시에만 refresh해당 시간이 SNAPTIME에 설정되고,
그 이후에 같은 데이타를 다른 snapshot 이 refresh해가도 값이 변경되지
않는다.
아무도 refresh하지 않은 경우는 default로 Oracle7의 경우 null이고,
Oracle8의 경우는 4000년 1월 1일로 설정된다.
SYS.SLOG$의 경우는 master table에 대해 연결된 모든 fast refresh로
refresh해가는 snapshot의 정보가 포함되어 있는데 각 snasphot이 refresh해
갈때마다 해당 snapshot에 대한 SNAPEIME이 변경된다.
그러므로 모든 snapshot이 snapshot log의 해당 레코드를 refresh해가는 경우
SYS.SLOG$의 SNAPTIME은 해당 MLOG$_<table_name>의 해당 레코드의 SNAPTIME
보다 미래이거나 같게 된다.
만약 SYS.SLOG$의 특정 snapshot의 SNAPTIME이 과거인채로 계속 refresh를
안해간다면 그래서 이 값이 snapshot log의 SNAPTIME보다 더 과거라면,
결국 해당 데이타를 refresh해가지 않은 snapshot이 존재하지 않는다는
것이므로 snapshot log의 데이타는 지워질 수 없는 것이다.
이러한 현상이 발생하는 경우는 master table에 연결되어 있는 하나의
snapshot site가 snapshot을 drop하지 않은 상태에서 장기간 데이타베이스
자체를 down시켜 둔 채 사용하지 않거나 아예 database를 remove시킨 경우이다.
그외에도 해당 master table에 snapshot을 test하다가 지우지 않고
그대로 둔 경우 등 이러한 문제는 실제 자주 발생하는 편이다.
2. snapshot log의 데이타를 강제로 지우는 방법
이렇게 사용하지 않는 snapshot으로 인해 비정상적으로 snapshot log의 크기가
커지는 경우, 가장 쉽게는 해당 snapshot을 찾아 drop해주면 문제는 바로
해결된다.
(1) snapshot 확인하는 방법
많은 경우 이러한 방치된 snapshot이 존재하는지 자체를 몰라 snapshot log가
계속 증가하게 되는데 이때는 다음과 같이 master site에서 snapshot 정보들을
확인할 수 있다.
- Oracle7의 경우:
Oracle7에서는 해당 master table에 걸려있는 모든 fast refresh의 snapshot의
정보를 확인할 수 있는 view는 SYS.SLOG$뿐이었다. 예를 들어 master table
이름이 DEPT인 경우 조회 방법은 다음과 같다.
SQL>connect sys/manager
SQL>select * from sys.slog$ where master = 'DEPT';
이 경우 snapshot을 나타내는 column은 SNAPSHOT으로 날짜로 표시된다.
이 snapshot을 실제 snapshot site에서 확인하려면 예상되는 snapshot
site에서 다음과 같이 조회하여 확인할 수 있다.
SQL>select * from sys.snap$ where master = 'DEPT';
- Oracle8의 경우
Oracle7에서는 위와 같이 snapshot의 정보를 master site에서 확인하는
것이 번거로운 문제점이 있어서 Oracle8부터는 snapshot을 나타내기 위한
snapshot id라는 개념이 추가되었고,
DBA_REGISTERED_SNAPSHOTS view가 생성되어 이 view를 통해 쉽게 snapshot를
찾는것이 가능해 졌다.
SQL>select snapid from sys.slog$ where master = 'DEPT';
SQL>select * from dba_registered_snapshots
where snapshot_id=위에서 확인한 번호;
이렇게 확인하면 해당 snapsot이 어느 site에 존재하는지에 대한 master
site의 database link이름 등도 확인 가능하다.
(2) 강제로 snapshot정보를 master site에서 제거하는 방법
위와 같이 확인하였는데도 snapshot을 snapshot site에서 직접 drop할 수
없는 환경이라면, master site에서 해당 snapshot에 대한 정보를 아예 지워
과거의 SNAPTIME을 가지는 snapshot이 SYS.SLOG$에 남지 않게 하면 된다.
SLOG$는 dictionary table이므로 바로 delete문장을 이용하여 해당 정보를
지워서는 안되며 다음과 같은 package를 이용한다.
- Orcle7의 경우:
SQL>exec DBMS_SNAPSHOT.PURGE_LOG('DEPT',2);
해당 master table에 걸려 있는 snapshot중 가장 과거의 SNAPTIME을 가지는
몇개의 snapshot정보를 지울 것인가를 지정하는 방식이다.
이 예의 경우는 DEPT table에 걸려있는 snapshot중 가장 이전에 refresh해간
두개의 snapshot의 정보를 master site의 SYS.SLOG$ 에서 제거한다.
- Oracle8의 경우:
Oracle7에서도 앞에서 설명한 DBMS_SNAPSHOT.PURGE_LOG는 여전히
사용가능하다.
그 외에 Oracle8에서 새로 추가된 snapshot id를 이용한 다음과 같은
package를 사용가능하다.
PROCEDURE PURGE_SNAPSHOT_FROM_LOG
Argument Name Type In/Out Default?
SNAPSHOT_ID BINARY_INTEGER IN
SNAPOWNER VARCHAR2 IN
SNAPNAME VARCHAR2 IN
SNAPSITE VARCHAR2 IN
예를 들어 다음과 같이 사용하면 된다.
SQL>exec DBMS_SNAPSHOT.PURGE_SNAPSHOT_FROM_LOG
(10, 'SCOTT', 'DEPT_SNAP', 'SNP8I.WORLD');

(SNAPSHOT) ORA-12004/ORA-12034 처리에 대해서 (7.X-8.X)

제품 : ORACLE SERVER
작성날짜 : 2000-11-03
fast refresh가 안 되는 ORA-12004 처리에 대해서 (7.x - 8.x)
=========================================================
snapshot 생성 시 같은 master table에 대해서 일부 snapshot site는 문제없이
사용을 하고 있는데 추가적으로 생성한 snapshot에 대해서만 fast refresh를
할 수 없다는 ora-12004 (Oracle8에서는 ORA-12034)가 발생되는 경우가 있다.
잘되는 snapshot과 같은 조건과, 환경의 경우 왜 새로 생성하는 곳만 문제가
되는지 설명이 되지 않는 경우가 있다면 다음 문서의 내용이 그 답이 될 수
있다.
기본적인 snapshot 환경과 생성에 문제가 없었는지는 <Bul:11186>을 통해 확인하
는 것이 도움이 된다.
1. 문제가 발생하는상황
~~~~~~~~~~~~~~~~~~~~~~
문제가 발생하는 snapshot의 master table에 대해서 이미 다른 snapshot이
만들어져 있고, 그 snapshot은 정상적으로 refresh가 되고 있는 상황,
그리고 master table의 data가 매우 많아서 새로 snpahsot을 만들거나,
refresh하는 것이 시간이 오래 걸리는 경우 주로 발생한다.
2. 문제의 원인
~~~~~~~~~~~~~~
master table의 snapshot log가 있는 table에 대해서, snapshot이 추가로
생성되고 나면 snapshot을 생성하기 시작한 시간과, 기존의 snapshot이 log를
refresh해간 시간을 비교하여 새로운 snapshot 생성시작 시간이 더 빠르면
ora-12004가 발생한다.
즉, snapshot을 생성하기 시작한 이후의 변경분이 이미 snapshot log에서
지워진 경우 새로 새성된 snapshot은 그 부분에 대한 변경을 반영할 수 없기
때문에 이후에 snapshot log 만을 의존해서 변경분만을 가져오는 fast
refresh를 수행하면 안된다는 것이다.
실제 이 mechanism이 이용하는 table은 sys user의 sys.mlog$, sys.slog$,
sys.snap$ table이다.
snapshot이 생성되기 시작한 시간은 sys.snap$의 snaptime에 기록이 되는데,
이 시간을 master table의 sys.mlog$의 oldest값과 비교하여 snaptime이 oldest
보다 이전 시간이면 ora-12004가 발생하는 것이다.
sys.mlog$의 oldest는 master table의 snapshot log 즉, mlog$_<table_name>에
저장된 data가 지워지는, 즉 purge되는 작업을 일으킨 마지막 refresh의
시간을 나타낸다. 하나의 master table에 여러개의 snapshot이 연결되어 있는
경우 모든 snapshot이 refresh를 해가야 해당 log data를 지우게 되므로,
일부만 refresh해간 경우에는 oldest값이 변경되지 않는다. mlog$_<table_name>
에 data가 없는 경우 refresh가 되면 정보는 변경된다.
oracle8의 경우 primary key base snapshot인 경우 oldest_pk를 확인한다.
fast refresh snapshot을 생성할때 이러한 oldest와 snaptime의 비교가 이루어
지게 되는데 snaptime이 oldest보다 늦으면 master site의 sys.slog$에 새로운
snapshot에 대한 entry가 추가되어 이후부터 정상적으로 refresh가 진행되고,
snaptime이 더 빠르면 sys.slog$에 기록이 되지 않아 이후에 refresh시에
slog$정보에서 entry를 찾지 못하여 ora-12004를 발생시키게 되는 것이다.
즉, snapshot생성시에는 오류 메시지를 만나지 않게 된다.
fast refresh로 지정된 snapshot이 생성되기 시작했는데도 mlog$_<table_name>의
data가 지워지는 이유는 이미 같은 master table에 걸려 있는 sys.slog$에
기록된 snapshot이 모두 refresh를 해가고 나면 그 log가 snapshot log에서
지워지기 때문인데, snapshot이 아직 생성되기 전에는 sys.slog$에 기록되지
않아 기존 snapshot만 refresh가 끝나면 지워지게 되기 때문이다.
그러나 snapshot생성 문장은 처음 master table의 data를 가져오기 시작한
시점을 유지하기 때문에 snapshot생성 중 변경된 부분에 대해서 변경된
것을 읽지 않고 rollback segment에서 변경 이전 image를 읽어 snapshot을
구성한다. snapshot 생성시간이 오래 걸리는 경우 생성 중 다른 transaction에
의해 변경된 data는 이후에 mlog$에서 fast refresh를 통해 가져가게 되나,
만약 이때 이미 존재하는 다른 snapshot이 refresh를 수행해 그 log data가
지워지게 되면 새로 생성된 snapshot은 snapshot log의 data만을 이용해
refresh해서는 master table과 같은 data를 유지할 수 없게 되는 것이다.
예를 들어 다음과 같은 작업을 가정하자.
master table: dept
기존 snapshot: A site의 dept_snap이라는 snapshot이 dept table에 대해 존재
새로 생성하는 snapshot이름: B site의 new_snap
----------|-----------------|--------------|--------------|-------------
시간 1:00 1:30 2:00 2:30
1:00 - B site에서 new_snap생성 시작
1:30 - master table dept변경
2:00 - A site에서 기존의 dept_snap이 refresh, 10초 refresh종료
2:30 - B site의 new_snap생성 종료
B site의 new_snap는 1시에 snapshot생성을 시작해 2시 30분에 종료되는데,
이때 1시 30분에 누군가 master table을 변경하여도 new_snap은 이시간의
변경 전 data를 읽어 snaphot을 구성한다.
new_snap의 sys.snap$에서 snaptime은 1시가 된다.
master table의 sys.mlog$는 dept_snap이 2시에 snapshot을 refresh해가고
mlog$_dept의 row를 지우기 때문에 oldest값으로 2시가 된다.
new_snap을 refresh시도할 때 master site의 sys.mlog$의 dept에 대한
oldest값이 2시인데, new_snap의 sys.snap$의 snaptime은 그 이전인
1시이기 때문에 master site의 sys.slog$에 entry를 추가하지 않고,
ora-12004를 유발시킨다.
3. 해결 방법
~~~~~~~~~~~~
결국 문제가 되는 것은 snapshot 생성 중에 같은 table에 대한 다른 snapshot이
refresh를 하는 것이 문제이다.
그러므로 생성하고자 하는 snapshot에 대한 master table의 다른 snapshot들을
refresh하지 못하도록 하거나, refresh하지 않는 시간에 새로운 snapshot을
생성하여야 한다.
refresh 못하도록 막는 방법으로는 일시적으로 snapshot job을 broken시킨 후
snapshot이 생성된 후 다시 broken을 false로 하면 된다.
10번 job을 broken시키는 것과 다시 해제하는 예이다.
os>sqlplus scott/tiger
SQL>select job, what from user_jobs;
SQL>exec dbms_job.broken(10,true);
SQL>exec dbms_job.broken(10,false);
refresh 시에 ora-12004가 발생하여도 다시 complete refresh를 수행하면
complete refresh 중 다른 snapshot이 refresh를 해가지 않는 경우,
master site의 sys.slog에 entry가 추가되면서 이후에는 fast refresh가
수행된다.
그러나 complete refresh를 수행하는 동안 기존의 다른 snapshot이 refresh를
해가게 되면, 아직 새로 생성한 snapshto의 정보가 master site의 sys.slog$에
기록되지 않았기 때문에 새로 생성한 snapshot은 고려하지 않고 바로
mlog$_<table_name>의 log data를 지우게 된다. 이렇게 되면 여전히
complete refresh가 끝나도 sys.slog$에 entry가 추가되지 않고, 이후의
fast refresh는 ora-12004를 발생시키게 된다.

The current one I am implementing is a development system. The database is less than 100GB. 800MB of PSAPUNDO is sufficient for our development usage.
Follow up on Problem 3:
I created another undo tablespace PSAPUNDO2(undodata.dbf) with size of 5GB. I switched undo tablespace to PSAPUNDO2 and placed PSAPUNDO(undo.data1) offline. With PSAPUNDO2 online and PSAPUNDO offline, I started brspace -f dbcreate and encountered the error below at Step 2 Export User tablespace:
BR0301E SQL error -376 at location BrStattabCreate-3
ORA-00376: file 17 cannot be read at this time
ORA-01110: data file 17: '/oracle/DVT/sapdata1/undo_1/undo.data1'
ORA-06512: at 'SYS.DBMS_STATS", line 5317
ORA-06512: at line 1
I aborted the process and verified that SAP is able to run with this settings. I started CheckDB in DB13 and it shows me these messages:
BR0301W SQL error -376 at location brc_dblog_open-5
ORA-00376: file 17 cannot be read at this time
ORA-01110: data file 17: '/oracle/DEV/sapdata1/undo_1/undo.data1'
BR0324W Insertion of database log header failed
I don't understand then. I have already switched the undo tablespace from PSAPUNDO to PSAPUNDO2. Why the message above still appears? Once I put PSAPUNDO online, CheckDB completes successfully without warning.
I did show parameter undo_tablespace and the result is PSAPUNDO2(5GB).
So exactly, what's going on? Can anyone advise?
===============================================
I have managed to clear the message in DB13 after dropping PSAPUNDO tablespace including contents and datafiles. This is mentioned is OSS note 600141 pg 8 as below:
Note: You cannot just set the old rollback-tablespace PSAPROLL to offline instead of deleting it properly. This results in ORA-00376 in connection with ORA-01110 error messages. PSAPROLL must remain ONLINE until it is deleted. (Oracle bug 3635653)
Message was edited by:
Annie Chan

(V8.1 REPLICATION) UPDATABLE SNAPSHOT환경 구축을 위한 초기 작업

제품 : ORACLE SERVER
작성날짜 : 2001-07-19
(V8.1 REPLICATION) UPDATABLE SNAPSHOT환경 구축을 위한 초기 작업
=============================================================
1. 개요
=======
Symmetric Replication의 한 종류인 updatable snapshot환경의 구축을 위해서는
replication manager를 사용하도록 한다. 이 문서는 replication manager사용을
통해 snapshot group및 object 등을 등록하고 관리하기 이전에 master및 snapshot
site에서 미리 설정되고 수행되어야 하는 작업들을 정리한다.
이중 일부 작업은 replication manager를 통해서도 구현이 되지만, 정확한
수행이 요구되어 지는 작업에 대해서는 이 문서에서와 같이 직접 SQL command를
통해 수행되어지는 것이 권고된다.
Oracle 8.1.x부터는 snapshot과 materialized view가 동의로 사용되어지나, 이
문서에는 snapshot으로 표시한다.
2. Init.ora parameters
======================
아래와 같은 initialisation parameter들이 추가되거나 수정되어져야 한다.
아래의 설정은 master site와 snapshot site모두 설정이 필요하며, master site가
하나뿐인 경우는 job_queue부분과 parallel_ parameter의 경우는 설장할 필요가
없다.
Parameter 이름 권장되는 초기 값
COMPATIBLE 8.1.5.0.0 이상
SHARED_POOL_SIZE 20M ~ 40M 정도가 추가로 요구
PROCESSES 현재 값에서 12정도 추가
GLOBAL_NAMES 반드시 TRUE
OPEN_LINKS 4, 추가되는 master site당 2 증가
DISTRIBUTED_TRANSACTIONS 최소 5 이상 (기본값은 trsactions/4)
가되는 master site당 2 증가
REPLICATION_DEPENDENCY_TRACKING TRUE
아래의 값은 상황에 맞게 조정하여 사용한다.
JOB_QUEUE_INTERVAL 10 초
JOB_QUEUE_PROCESSES 3, 추가되는 master site당 1씩 증가
PARALLEL_MAX_SERVERS 10
PARALLEL_MIN_SERVERS 2, max server의 갯수와 동일한것이 권장
parallel propagation을 사용하지 않고자
하면 설정하지 않는다.
SNAPSHOT_ 로 시작하는 parameter나 JOB_QUEUE_KEEP_CONNECTIONS parameter는
Oracle 8.1에서는 없어졌으므로 지정하지 않도록 한다.
3. Tablespace 요구 사항
=======================
다음은 replication을 사용하기 위해 추가적으로 필요한 tablespace용량이다.
Tablespace 권장사항
SYSTEM 최소 40 Mb free space
ROLLBACK SEGMENTS 최소 30 Mb free space
TEMPORARY 최소 20 Mb free space
4. Replication Catalogue 설치
==============================
database생성시에 replication catalog를 설치하지 않았다면, Database
Configuration Assistant 를 이용하여 Advance Replication Option부분을
database에 추가하도록 하거나, 아니면 다음과 같이 작업한다.
cd $ORACLE_HOME/rdbms/admin
sqlplus internal
SQL>spool rep.log
SQL>@catrep
SQL>spool off
이 script는 약 1시간 정도 수행되며, spool을 받아 수행에 문제가 있었는지
이후에 확인하도록 한다.
[주의] 이 script를 수행하게 되면, replication관련 table과 queue등이 system
owner로 생성되게 된다.
그러므로 이후에 replication작업이 일시 중단되어 queue가 커지게 되면,
system user의 default tablespace에 부담이 되므로 system owner의
default tablespace를 tools나 그외 replication관리를 위한 별도의
table로 일시 지정하도록 한다.
SQL>ALTER USER sysem DEFAULT TABLESPACE REPTBS;
catrep의 수행이 끝나면 spool로 생긴 rep.log도 확인하여 보고, 아래 문장을
통해 invalid상태인 object를 확인하고 재 compile을 시도한다.
SQL> SELECT OWNER, OBJECT_NAME FROM ALL_OBJECTS
WHERE STATUS = 'INVALID';
이때 만약 SYS나 SYSTEM package의 body가 invalid로 나타나면 다음과 같이 재
compile을 시도한다. package body만 invalid인데 aler package문장에서 compile
body대신 compile이라고만 하면 그 package에 대한 definition이 변경되어,
이 package와 dependency관계에 있는 다른 object도 invalid상태가 되도록 한다.
작업이 성공적으로 끝났으면, system user의 default tablespace의 원래대로,
tool나 system으로 수정한다.
SQL> alter user system default tablespace system;
5. Setup NET8
=============
Replication환경에 포함된 모든 server는 listener를 구동하도록 하며, snapshot
site에서는 master site를 가리키는 service alias를 tnsnames.ora file에 등록하
도록 한다.
또한, replication manager를 사용하는 client도 tnsnames.ora file에 master와
snapshot site와 연결가능하도록 service alias를 net8 easy configuration등을
통하여 등록하도록 한다.
6. Replication Manager Setup Wizard
===================================
위의 작업이 모두 끝났으면 앞으로의 작업은 replication manager를 통해서도
수행 가능하다.
그러나 이 문서에 포함된 내용은 replication환경 설정시 한번만 필요한 작업이며,
이 부분에 대한 사소한 실수도 이후 사용에 문제를 야기하기 때문에, 여기에 포함된
작업만큼은 sql command를 통해 직접 작업하기를 권고한다.
Replication manager가 포함되어 있는 OEM version은 1.4부터이며, Oracle8.1의
경우는 2.1이 최적화되어 있다. 그러나 그 이전 version도 사용가능하다.
7. Replication Users
=====================
일반적으로, multi-master환경보다는 updatable snapshot환경이 더 보안이 문제시
된다. multi-master의 경우는 일반적으로 중앙에서 같은 db admin에 의해 관리
되는것이 일반적이나 snapshot의 경우는 지역적으로 떨어져 별개로 관리되는 경우가
많아 그 snapshot에서 master site의 database에 손상을 주는 일을 막는것이
중요하여, user구성은 multi-master환경보다 복잡하다.
Snapshot Site Master Site
Replication administrator
Snapshot replication administrator ---> Proxy snapshot administrator
Propagator ---> Receiver
Refresher ---> Proxy refresher
Snapshot Owner(s) ---> Proxy refresher
- Replication administrator: master site에서, master group들의 구성과
관리를 책임진다.
- Snapshot administrators: snapshot site에서 snapshot replication group을
구성하고 관리하는 책임을 지며, master site의 Proxy administrator가
master group의 최소한의 access만 허용하게 된다.
- Propagators: deferred transaction을 master site에 전달하면, master site의
Receiver가 전달받은 data를 master table에 적용시킨다.
- Refreshers: snapshot site에서 master site의 변경된 data를 snapshot
site로 끌어오는 역할을 하며, master site의 Proxy refresher는 master
site의 table에 대한 최소한의 acess만을 허용한다.
이러한 user들의 생성하고 이용하는 방법은 여러가지로 가능하다. 아래에서는,
그중 가장 일반적으로 사용되는 방법을 기술한다.
8. Replication user 생성 및 권한 부여
=====================================
Oracle 8.1부터 updatable snapshot 환경 구축시 trusted와 untrusted두가지
방법이 가능하다. untrusted의 경우 snapshot site가 master site와 같은 관리자
아래에 포함되지 않아 보안을 더 강화해야 하는 model이다.
하나의 master site에 snapshot group이 여러개이고, 각 snapshot별로, 이
snapshot group을 공유하는것이 아니고, 별개로 사용하는 경우 서로 다른
snapshot이 사용하는 group에 대해 보안을 유지하려면 untrusted model을 사용해야
하나 실제 이러한 환경으로 구성되는 일은 거의 없고, 작업의 번거로움으로 이
문서에는 trusted model에 대해서는 설명한다.
8.1 Master Site user와 권한
(1) Replication Administrator (REPADMIN)
SQL>CONNECT system/<password>
SQL>CREATE USER repadmin IDENTIFIED BY <password>
DEFAULT TABLESPACE <tablespace name>
TEMPORARY TABLESPACE <tablespace name>;
SQL>GRANT connect, resource TO repadmin;
SQL>EXECUTE dbms_repcat_admin.grant_admin_any_schema('repadmin');
SQL>GRANT comment any table TO repadmin;
SQL>GRANT lock any table TO repadmin;
만약 replication group이 어느 특정 schema에만 한정된다면,
grant_admin_any_schema대신 grant_admin_schema를 사용하여도 된다.
(2) Proxy snapshot administrator / Receiver / Proxy refresher (SNAPPROXY)
master site의 proxy snapshot administrator, receiver, proxy refresher는
하나의 user로 관리하는 것이 일반적이다. 이러한 SNAPPROXY user를 생성하지
않고 REPADMIN user가 이러한 역할도 수행하도록 설정할 수 있으나, 그렇게
되면 snapshot site에 너무 많은 권한을 부여하게 되어 바람직하지 않다.
replication manager를 이용해 이러한 user를 생성하면 master site에 연결된
snapshot site마다 각각의 snapproxy_n과 같은 형태로 user를 생성하나,
같은 snapshot group에 대하여 이렇게 각각의 user를 생성하는 것은 의미가
없으므로 권장되지 않는다.
SQL>CONNECT system/<password>
SQL>CREATE USER snapproxy IDENTIFIED BY <password>
DEFAULT TABLESPACE <tablespace name>
TEMPORARY TABLESPACE <tablespace name>;
(3) Proxy snapshot administrator privileges
SQL>CONNECT system/<password>
SQL>BEGIN
dbms_repcat_admin.register_user_repgroup(
username => 'snapproxy',
privilege_type => 'proxy_snapadmin',
list_of_gnames => NULL);
SQL>END;
SQL>/
register_user_repgroup procedure를 통해 권한을 부여한다. 이때, "create
session" 과 dbmsobjgwrapper / dbms_repcat_untrusted package에 대한
"execute"권한이 부여된다.
Replication group에 table을 add하게 되면 그 table에 대한 "select" 권한이
부여된, master objects에 대한 DML권한은 이 user에게 부여되지 않는다.
(4) Receiver privileges
SQL>CONNECT system/<password>
SQL>BEGIN
dbms_repcat_admin.register_user_repgroup(
username => 'snapproxy',
privilege_type => 'receiver',
list_of_gnames => NULL);
SQL>END;
SQL>/
이 문장을 통해 "create session" 과 dbms_defer_internal packages,
dbms_defer package에 대한 "execute"권한이 부여된다. 그러나 이것도
마찬가지로 master object에 대한 DML권한을 부여하지 않는다.
또한 receiver는 replication object를 추가한 후 replication support시에
생성되는 <schema>.<object name>$RP (LOB table에 대해서는 $RL)에 대한
execute권한을 부여 받아 master site에 변경사항을 적용하게 된다.
(5) Proxy refresher privileges
SQL>CONNECT system/<password>
SQL>GRANT create session TO snapproxy;
SQL>GRANT select any table TO snapproxy;
(6) Schema Owner(s) (여기에서는 REPUSER로 명시)
SQL>CONNECT system/<password>
SQL>CREATE USER repuser IDENTIFIED BY <password>
DEFAULT TABLESPACE <tablespace name>
TEMPORARY TABLESPACE <tablespace name>;
SQL>GRANT connect, resource TO repuser;
8.2 Snapshot Site user와 권한
(1) Snapshot administrator / Propagator / Refresher (SNAPADMIN)
snapshot administrator, propagator, refresher에 대해서 하나의 user로
관리하는것이 일반적이다.
SQL>CONNECT system/<password>
SQL>CREATE USER snapadmin IDENTIFIED BY <password>;
DEFAULT TABLESPACE <tablespace name>
TEMPORARY TABLESPACE <tablespace name>;
(2) Snapshot administrator 권한
SQL>CONNECT system/<password>
SQL>EXECUTE dbms_repcat_admin.grant_admin_any_schema('snapadmin');
SQL>GRANT comment any table TO snapadmin;
SQL>GRANT lock any table TO snapadmin;
(3) Propagator 권한
SQL>EXECUTE DBMS_DEFER_SYS.REGISTER_PROPAGATOR('snapadmin');
(4) Refresher 권한
SQL>GRANT create any snapshot TO snapadmin;
SQL>GRANT alter any snapshot TO snapadmin;
refresher와 대응하는 master site의 proxy refrsher에 의해 master site의
table에 대한 "select any table" 권한을 가지게 된다.
(5) Schema Owner(s) (여기에서는 REPUSER로 명시)
replicate되고자 하는 table에 대한 master site의 schema와 동일한 이름의
shema가 snapshot site에서도 필요하다. 단 password는 같을 필요는 없다.
만약 다른 schema에 대해서 updatable snapshot을 생성하면, snapshot생성시는
오류없이 만들어지지만, create_snapshot_repobject 수행시에 아래와 같이
오류가 발생할 것이다.
ORA-23306: schema <schema name> does not exist
ORA-23308: object <schema name>.<object name> does not exist or is invalid
아래 문장과 같은 schema owner생성시 주의할 점은 이 권한을 role을 통해
부여하지 말고 직접 주어야 한다는것이다. 즉, 이미 connect, resource등을
통해 create table과 같은 권한은 부여된 상황임에도 불구하고, 이후에
procedure나 package등에서 이 권한이 필요한 경우 role을 통해 부여된 것은
인식이 되지 않고 ORA-1031이 발생하기 때문에 아래와 같이 직접 권한을
부여하여야 한다.
SQL>CONNECT system/<password>
SQL>CREATE USER repuser IDENTIFIED BY <password>
DEFAULT TABLESPACE <tablespace name>
TEMPORARY TABLESPACE <tablespace name>;
SQL>GRANT connect, resource TO repuser;
SQL>GRANT create table TO repuser;
SQL>GRANT create snapshot TO repuser;
이 user가 master site에 대해서 수행할 수 있는 권한에 대해서는 이 user에서
master site로 생성하는 database link를 어느 user로 connect하느냐에 달려
있으며 이것은 9.4에서 설명한다.
(6) End Users
snapshot schema에 있는 snapshot을 이용하는 user가 별도로 존재할 수
있으며, 이 경우 특별한 권한이 추가적으로 필요하지는 않고, snapshot
object에 대한 필요한 권한을 부여하면 된다.
9. Database Link
================
database link를 생성하기 전에 중요한 것은 replication 환경에 포함된 모든
database는 고유한 global name을 가지고 있어야 한다. default global name은
<db_name>과 동일하나 다음과 같이 문장을 통해 global name을 수정가능하다.
그러므로 db_name이 같더라도 이렇게 global name을 수정하여 replication
환경을 구성할 수 있다.
SQL>ALTER DATABASE RENAME GLOBAL_NAME TO <new global name>;
SQL>SELECT * FROM GLOBAL_NAME;
updatable snapshot환경에서 database link가 제대로 구성되지 않으면 이후
작업에 계속 문제가 생기므로 주의하여야 한다. 이 database link는 snapshot
site에서 master site로만 구성하면 되며, 반대로 master site에서 snapshot
site로 구성할 필요는 없다.
(1) Public Database Links
Net8 connection alias를 이용하여 다음과 같이 public database link를
만든다. 이후 생성되는 private link는 using절을 포함하지 않게 되며,
모두 public database link와 동일한 이름의 db link이름을 가져야 한다.
(global_names=true이기 때문)
SQL>CONNECT system/<password>
SQL>CREATE PUBLIC DATABASE LINK <remote databases global name.world>
USING 'Net8 alias';
여기에서 표현한 Net8 alias는 snapshot site의 tnsnames.ora file에 정의
되어 있어야만 한다.
(2) Snapshot Administrator / Snapshot propagator / refresher
snapshot administrator와 proxy snapshot administrator 다음과 같이 private
database link가 필요하다.
SQL>CONNECT snapadmin/<password>
SQL>CREATE DATABASE LINK <remote databases global name.world>
CONNECT TO snapproxy IDENTIFIED BY <password>;
(3) Schema Owner (여기에서는 REPUSER로 명시한다)
snapshot을 가지고 있는 모든 schema는 master site에 private database
link를 생성해야 한다. 이때, "Schema to Schema" 와 "Schema to Proxy
Refresher" 두가지를 고려할 수 있다.
만약 link를 schema to schema방식으로 생성하게 되면, snapshot owner는
쉽게 master site로 연결하여, master table에 DDL이나 DML을 수행가능하다.
이것은 일반적으로 바람직하지 않으므로 master의 proxy refresher로
private database link를 만들도록 권고된다. master에서 proxy refresher와
proxy administrator가 동일한것이 일반적으로 결국 proxy administrtor에게
연결하면 된다.
이렇게 되면 snapshot의 schema owner는 proxy refresher user에 의해,
master table에 대한 "select any table"권한은 가지게 되지만, DDL이나,
DML은 허용되지 않으므로 더 안정적이다.
SQL>CONNECT repuser/<password>
SQL>CREATE DATABASE LINK <remote databases global name.world>
CONNECT TO snapproxy IDENTIFIED BY <password>;
(5) End User
database link가 필요하지 않다.
9.6 Testing Database Links
database link생성 작업이 끝나면 다음과 같이 하여, 각 user별로 database
link 생성이 올바로 되었는지 확인하도록 한다.
SQL>CONNECT user/<password>
SQL>SELECT * FROM DUAL@<database link name>
10. schedule설정
================
1 ~ 9번까지 성공적으로 수행되었다면 이제 replication manager를 이용하여,
replication/snapshot group과 object를 추가할 수 있다.
replication manager를 이용시 master site는 repadmin user로 접속하고,
snapshot site는 snapadmin user로 접속하도록 한다.
snapshot site의 변경 작업을 master site로 주기적으로 push시키고, 이렇게
push된 data를 또 다른 주기로 purge시키는 scheduling이 필요하다.
이것은 replication manager를 이용하려면, 아래 menu를 이용하면 된다.
- Scheduling --> Scheduled Links
- Database Information --> Purge Job Tab
이 작업을 sql문으로 수행하려면 다음과 같은 문장을 snapshot site에서
수행한다.
SQL>CONNECT snapadmin/<password>
SQL>BEGIN
dbms_defer_sys.schedule_push(
destination => '<destination databases global name>.WORLD',
interval => '/*10:Mins*/ sysdate + 10/(60*24)',
next_date => sysdate,
stop_on_error => FALSE,
delay_seconds => 0,
parallelism => 1);
SQL>END;
SQL>/
SQL>BEGIN
dbms_defer_sys.schedule_purge(
next_date => sysdate,
interval => '/*1:Hr*/ sysdate + 1/24',
delay_seconds => 0,
rollback_segment => '');
SQL>END;
SQL>/

Purchase Order flow in ASCP

Hi eveyone.
Mi question is: after that these next steps complete:
Description of Data Flow:
New purchase orders or requisitions in approved status.
Snapshot does not contain that newly entered purchase order or requisition.
The MRP_AP_xxxxx_V views do not contain the new purchase order or requisition.
Internal rdbms trigger populates the newly entered purchase order or requisition RowID into Snapshot Log (MLOG$ objects).
Launch ASCP Data Collections.
Refresh Snapshot reads row id from MLOG$.
Refresh Snapshot gets record from base table using row id.
Refresh Snapshot populates/updates the snapshot with current table record information.
As the snapshot is updated, the MRP_SN_xxxxx_T triggers fire.
The tirggers update/insert into the MRP_AD_SUPPLY table.
The MRP_AP_xxxxx_V views now have the new purchase order or requisition.
Planning Data Pull reads the MRP_AP_xxxxx_V views.
Planning Data Pull validates and calculates the purchase order or requisition data.
Planning Data Pull pulls data from EBS source instance over the database links:
ERP-based programs look in mrp_ap_apps_instances_all on the source instance to get the link name to VCP.
VCP-based programs look in msc_apps_instances planning instances to get the link name to ERP.
Planning Data Pull inserts that pulled data into the MSC_ST_xxxxx staging tables.
ODS Load reads the MSC_ST_xxxxx staging tables.
ODS Load validates and calculates the purchase order or requisition data.
ODS Load purges existing ODS data and loads new/change records using either the Complete or Net Change methods.
ODS Load data is hard coded with PLAN_ID = -1 for Collected Raw Source Data.
ODS data is read by the MBP Memory Based Planner.
ODS data is read by Production Scheduler.
ODS data is read by Strategic Network Optimization.
What append next? The Order tables will be updated? or the information about these order is stored in a new table?.
Im asking because in need get a update information ot this order, to send a external systema trough a bpel process.
Thanks for the help and time.
resource.
Oracle Value Chain Planning Collections Implementation Guide

Hi,
In Cash journal, there are fields which are standard from the program SAPMFCJ0 and Control FTCJ_E_POSTINGS.
So you can see in FBCJ, while you post transaction line at the extreme right, you can see "configuration" there you can see the available fields. If you want to include, contact ABAP consultant or SAP team.
Regards,
Ramesh.

Refresh Snapshot

Similar Messages

Maybe you are looking for