Multiple materialized views against same mv logs

Hi,
I am currently moving an apex installation that uses materialized views for data source from one machine to another (both 11.1.0.6, diff nls_character sets WE8MSWIN1252 to AL32UTF8, so dpexp/dpimp is not working due to bug).
I am looking at exp/imp apex workspaces/apps and building the same mviews in the new instance clean and refreshing.
1.) I want to know if building and refreshing the new mviews copies ahead of cutover will have any impact on the curr prod instances mview logs (there are two) and or the curr apex install that is also refreshing from the same logs.
I want to make sure buliding and refreshing the new mview copies won't effect/corrupt anything currently being use in the current setup, the documentation I've found so far is very vague so if anyone has found any ML notes or other links that would be awesome too.
Thanks, Chris

To clarify what you are saying:
Database A - Master_Table with mview_log
Database B - Fast Refresh mview pointing @ database A and master_table
Database C - Fast Refresh mview pointing @ database A and master_table
I've done this @ 10.2.0.4 and it worked OK without causing any issues to the existing configuration so unless 11.1.0.6 introduced a new bug you should be OK.
HTH
Paul

Similar Messages

Materialized view log with multiple materialized views

DB: 9.2.0.8
Yes its old. I am not allowed to upgrade it.
I have a set of materialized views that are created off of 5 base tables. They do fast refreshes. So I have multiple materialized views for the same base table and same materialized view log.
1. how do materialized view logs manage multiple dependent materialized views?
2. How do I tell by looking at the materialized view log which rows have not been fast refresh for a specific materialized view?

As a starter for 10 try reading: Materialized View Refresh : Log Population and Purge (Doc ID 236233.1) on MOS.
Thanks
Paul

Multiple Goods Receipts Against Same Excise Invoice

All SAP Gurus,
We are having a scenario in which we need to do Multiple Goods Receipts Against Same Excise Invoice.
How it can be done?
Regards,

During first GR in the excise header tab select "Capture excise amount".
In the excise item tab enter in the EI quantity the total qty in invoice. In the quantity tab enter the qty which is to be received.
Post the gr.
During second gr in the excise header tab select "Only refer excise invoice".

Several Materialized Views reading same log

We have a production system that refreshes it's materialized view remotely from a materialized view log on a different instance. We have created a new upgraded instance that we want to run in parallel to verify everything will work. My question is, if we have the materialized views from both system being update from the one set of logs, will we get incomplete data in each system? Are the logs maintained in the source system, or are they cleaned out once one of the destination systems refreshes from them?
The existing production database is V9i, the new one is 10g. I don't know what the version the source database is.
Thanks

You shouldn't have a problem with incomplete data.
You should see that there are two rows in DBA_REGISTERED_MVIEWS in the source system, one for each target's materialized view (you may, of course, have other rows for other materialized views). Assuming that is what you see, and assuming both show a YES for the CAN_USE_LOG, the materialized view log will ensure that both sites have processed each change before that change is purged from the log.
Justin

I want to print multiple Material no against Purchase Order

hi i want to display MATNR against Purchase Order
suppose 10 Material no is there than i want to display 10 material no against that Purchase order.
thanks.
laxman sankhla.

hi
give PURCHASE ORDER as select options on selection screen .
select matnr from table EKPO based on PO no.
save them in internal table .
loop At internal table .
endloop.
display it any where on report SAP script or SF.
reward if helpful.

Questions on Materialized Views and MV Log tables

Hello all,
Have a few questions with regards to Materialized View.
1) Once the Materialized View reads the records from the MLOG table the MLOG's records get purged. correct? or is it not the case? In some cases I still see (old) records in the MLOG table even after the MV refresh.
2) How does the MLOG table distinguish between a read that comes from an MV and a read that comes from a user? If I manually execute
"select * from <MLOG table>" would the MLOG table's record get purged just the same way as it does after an MV refresh?
3) One of our MV refreshes hangs intermittently. Based on the wait events I noticed that it was doing a "db file sequential read" against the master table. Finally I had to terminate the refresh. I'm not sure why it was doing sequential read on the master table when it should be reading from the MLOG table. Any ideas?
4) I've seen "db file scattered read" (full table scan) in general against tables but I was surprised to see "db file sequential read" against the table. I thought sequential read normally happens against indexes. Has anyone noticed this behaviour?
Thanks for your time.

1) Once all registered materialized views have read a particular row from a materialized view log, it is removed, yes. If there are multiple materialized views that depend on the same log, they would all need to refresh before it would be safe to remove the MV log entry. If one of the materialized views does a non-incremental refresh, there may be cases where the log doesn't get purged automatically.
2) No, your query wouldn't cause anything to be purged (though you wouldn't see anything interesting unless you happen to implement lots of code to parse the change vectors stored in the log). I don't know that the exact mechanism that Oracle uses has been published, though you could go through and trace a session to get an idea of the moving pieces. From a practical standpoint, you just need to know that when you create a fast-refreshable materialized view, it's going to register itself as being interested in particular MV logs.
3) It would depend on what is stored in the MV log. The refresh process may need to grab particular columns from the table if your log is just storing the fact that data for a particular key changed. You can specify when you create a materialized view log that you want to store particular columns or to include new values (with the INCLUDING NEW VALUES) clause. That may be beneficial (or necessary) to the fast refresh process but it would tend to increase the storage space for the materialized view log and to increase the cost of maintianing the materialized view log.
4) Sequential reads against a table are perfectly normal-- it just implies that someone is looking at a particular block in the table (i.e. looking up a row in the table by ROWID based on the ROWID in an index or in a materialized view log).
Justin

Materialized view logs in cloned database

Hi all!
We have materlialized views and materlialized view logs in two separate databases which are connected with a database link. The MV logs are in DB1_PROD, which is the database being cloned. The database link goes from DB2_PROD (where the MVs are located) to DB1_PROD:
DB2_PROD (materialized views) ----DB link---> DB1_PROD (materialized view logs)
When cloning DB1_PROD to DB3_DEV, the MV logs still have a reference to DB2_PROD. However, there is no connection between DB3_DEV and DB2_PROD.
In my opinion this is not harmful, but I would like to know if any of you can see any problems with this.
In summary;
DB1_PROD: Materialized view logs
DB3_DEV: Materialized view logs. Clone of DB1_PROD
DB2_PROD: Materialized views.
DB1_PROD and DB3_DEV:
select * from v$version;
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bi
PL/SQL Release 10.2.0.4.0 - Production
CORE 10.2.0.4.0 Production
TNS for Linux: Version 10.2.0.4.0 - Production
NLSRTL Version 10.2.0.4.0 - Production
DB2_PROD:
select * from v$version;
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
PL/SQL Release 11.2.0.3.0 - Production
CORE 11.2.0.3.0 Production
TNS for Linux: Version 11.2.0.3.0 - Production
NLSRTL Version 11.2.0.3.0 - ProductionPlease let me know if you need further information.

Oracle automatically purges rows in the materialized view log when they are no longer needed. Because Oracle must wait for all dependent materialized views to refresh before purging rows from a materialized view log, unwanted situations can occur that cause a materialized view log to grow indefinitely when multiple materialized views are based on the same master table or master materialized view.
For example, such situations can occur when more than one materialized view is based on a master table or master materialized view and one of the following conditions is true:
Materialized view is not configured for automatic refreshes and has not been manually refreshed for a long time. OR
Materialized view has an infrequent refresh interval, such as every year, etc
You can also refresh the materialized views associated with the log so that Oracle can purge rows from the materialized view log.
If a materialized view log needs to be purged manually for some reason a procedure called DBMS_MVEW.PURGE_LOG can be used.
Edited by: user130038 on Sep 30, 2011 6:49 AM

Materialized view logs issue

We are having issues with the size of materialized view logs in one od the database. The size of the log table is around 32G. Will appreciate if somebody will help in explaining why it is having such a huge size and is not getting purged.
At the same time the master table is having comparatively smaller size of 18G(did not check table fragmentation).
Also, please help me in understanding what is required to be done for fixing this issue.
SQL> select LOG_OWNER,MASTER,LOG_TABLE,LOG_TRIGGER,PRIMARY_KEY from dba_mview_logs where log_owner='MARTDATA' and MASTER='POLICY_CONFIGURATION';
LOG_OWNER MASTER LOG_TABLE LOG_TRIGGER PRI
MARTDATA POLICY_CONFIGURATION MLOG$_POLICY_CONFIGURATION NO
SQL> select owner, segment_name, sum(bytes)/1024/1024 "SIZE in MB" from dba_segments where segment_name='POLICY_CONFIGURATION' and owner ='MARTDATA' group by owner, segment_name;
OWNER SEGMENT_NAME SIZE in MB
MARTDATA POLICY_CONFIGURATION 18458
SQL> select owner, segment_name, sum(bytes)/1024/1024 "SIZE in MB" from dba_segments where segment_name='MLOG$_POLICY_CONFIGURATION' and owner ='MARTDATA' group by owner, segment_name;
OWNER SEGMENT_NAME SIZE in MB
MARTDATA MLOG$_POLICY_CONFIGURATION 32298
Thanks

Oracle automatically purges rows in the materialized view log when they are no longer needed. Because Oracle must wait for all dependent materialized views to refresh before purging rows from a materialized view log, unwanted situations can occur that cause a materialized view log to grow indefinitely when multiple materialized views are based on the same master table or master materialized view.
For example, such situations can occur when more than one materialized view is based on a master table or master materialized view and one of the following conditions is true:
Materialized view is not configured for automatic refreshes and has not been manually refreshed for a long time. OR
Materialized view has an infrequent refresh interval, such as every year, etc
You can also refresh the materialized views associated with the log so that Oracle can purge rows from the materialized view log.
If a materialized view log needs to be purged manually for some reason a procedure called DBMS_MVEW.PURGE_LOG can be used.
Edited by: user130038 on Sep 30, 2011 6:49 AM

Materialized view excessive logging. SOS

The refresh of our materialized view is causing excessive logging. I altered the materialized view to NOLOGGING but it did not have any effect, not sure why?
We either need to change the refresh time from 3 minutes to every 15 minutes(which is a bummer, data would be more stale) or give up on the materialized view.
The quantity of archive logs has more than doubled since we adding this materialized view and the file system partition filed up last night, halting activity inside the database!
Any suggestions?

The refresh is not set for direct path inserts.Good. Now you have something you can change to help resolve the issue.
The MV does not have any indexes.So the logging issue you describe is purely caused by deletes from, and inserts into the MV during a complete refresh.
You can use the advice given by Alex above, and use atomic_refresh => false. Before you say it cannot be done because the users will not have access to the data during refresh, you might need to get creative. If you use query rewrite, for example, users would have access to data from the base tables while the MV is being refreshed. Their queries may be slower for a while, but they will still get data. If waiting 3 minutes or so is unacceptable for the queries that sneak in during a refresh, you can consider the following. Use query rewrite and have 2 materialized views, one of which can refresh while the other is available. After refreshing one, disable query rewrite on the older one.
We cannot perform a fast refresh due to the query required to build the view.I'll take your word on it, although I have come across this situation many times where MVs that were thought to be impossible to fast refresh actually can be made to do it. Again, you might need to get creative. Sometimes you can do this by having MVs built on other MVs.
Also, consider using MVs on prebuilt tables. You get additional control over how to refresh the MV this way. You can build your own custom refresh process that might help you do your own "fast refresh" by just applying the delta to your data (insert a few rows, update a few aggregates, perhaps). You can even do things like partition swapping so you can build your refreshed data in a separate table and then swap it with the MV partition (even if it is all in one partition).

Error While Creating Fast Refresh Materialized view.

Table Scripts:
CREATE TABLE CONTRACT_MASTER
CONTRACT_SEQ                    NUMBER(10)    NOT NULL,
PDN                             CHAR(5)       NOT NULL,
APPID                           NUMBER(10)    NOT NULL,
CONTRACT_LOB_DESC               VARCHAR2(20) NOT NULL,
CUSTOMER_NAME                   VARCHAR2(57) NOT NULL,
CONTRACT_DT                     DATE          NOT NULL,
CONTRACT_RECD_DT                DATE          NOT NULL,
HELD_OFFERING_DT                DATE          NOT NULL,
DRAFT_AMT                       NUMBER(15,2) NOT NULL,
STATUS_DESC                                   VARCHAR2(20) NOT NULL,
GIF_UPLOAD_TM                                            TIMESTAMP     NOT NULL
CREATE table CONTRACT_COMMENTS
CONTRACT_COMMENTS_SEQ           NUMBER(10)     NOT NULL,
APPID                           NUMBER(10)     NOT NULL,
COMMENTS                        VARCHAR2(1000) NOT NULL,
GIF_UPLOAD_TM                                            TIMESTAMP      NOT NULL
Constraints on tables
ALTER TABLE CONTRACT_MASTER ADD
CONSTRAINT XPKCONTRACT_MASTER PRIMARY KEY (CONTRACT_SEQ) USING INDEX ;
ALTER TABLE CONTRACT_COMMENTS ADD
CONSTRAINT XPKCONTRACT_COMMENTS PRIMARY KEY (CONTRACT_COMMENTS_SEQ) USING INDEX ;
alter table CONTRACT_MASTER add CONSTRAINT XUIAPPCONTRACT_MASTER UNIQUE (APPID) USING INDEX;
CREATE INDEX XUIAPPCONTRACT_COMMENTS ON
CONTRACT_COMMENTS(APPID) ;
Materialized View Creation:
CREATE MATERIALIZED VIEW LOG ON CONTRACT_MASTER WITH PRIMARY KEY,ROWID;
CREATE MATERIALIZED VIEW LOG ON CONTRACT_COMMENTS WITH PRIMARY KEY, ROWID;
CREATE MATERIALIZED VIEW MV_CONTRACT_COMMENTS_HELDOFFERING
REFRESH FAST
ENABLE QUERY REWRITE AS
SELECT APPID,COMMENTS FROM CONTRACT_COMMENTS WHERE APPID IN (
SELECT APPID FROM CONTRACT_MASTER WHERE STATUS_DESC = 'Held Offering' )
Errors generated:
ERROR at line 4:
ORA-12015: cannot create a fast refresh materialized view from a complex query
_*Afer That I have changed the query but still it was not created like:*_
CREATE MATERIALIZED VIEW MV_CONT_COMMNTS_HELDOFFERNG
REFRESH FAST
ENABLE QUERY REWRITE AS
SELECT CONTRACT_COMMENTS_SEQ,c.APPID,COMMENTS
FROM CONTRACT_COMMENTS c,CONTRACT_MASTER m
WHERE m.APPID = c.APPID and m.STATUS_DESC = 'Held Offering'
*even though error displayed:
SQL> CREATE MATERIALIZED VIEW MV_CONT_COMMNTS_HELDOFFERNG*
   2 REFRESH FAST
   3 ENABLE QUERY REWRITE AS
   4 SELECT CONTRACT_COMMENTS_SEQ,c.APPID,COMMENTS
   5 FROM CONTRACT_COMMENTS c,CONTRACT_MASTER m
   6 WHERE m.APPID = c.APPID and m.STATUS_DESC = 'Held Offering';
FROM CONTRACT_COMMENTS c,CONTRACT_MASTER m
ERROR at line 5:
ORA-12052: cannot fast refresh materialized view GSSIO.MV_CONT_COMMNTS_HELDOFFERNG
*Again I have done "Analyzing Materialized Views for Fast Refresh" as follows:*
1: exec dbms_mview.explain_mview('MV_CONT_COMMNTS_HELDOFFERNG');
2: SELECT capability_name, possible, SUBSTR(msgtxt,1,60) AS msgtxt
           FROM mv_capabilities_table
           WHERE capability_name like '%FAST%';
Output is :
CAPABILITY_NAME                               P              MSGTXT
REFRESH_FAST                                   N
REFRESH_FAST_AFTER_INSERT            N the SELECT list does not have the rowids of all the detail t
REFRESH_FAST_AFTER_ONETAB_DML   N see the reason why REFRESH_FAST_AFTER_INSERT is disabled
REFRESH_FAST_AFTER_ANY_DML         N see the reason why REFRESH_FAST_AFTER_ONETAB_DML is disabled
REFRESH_FAST_PCT                            N PCT is not possible on any of the detail tables in the mater
Please suggest what to do to implement fast refresh materialized view for same.Edited by: dba on Sep 20, 2010 12:00 AM

If the two MVs have to be consistent with each other as of a specific time, put them into a Refresh Group and refresh them with DBMS_MVIEW.REFRESH
If an MV is dependent on another, use DBMS_MVIEW.REFRESH_DEPENDENT
See the "Oracle® Database PL/SQL Packages and Types Reference" documentation pages for DBMS_MVIEW.
Hemant K Chitale
http://hemantoracledba.blogspot.com --- this is NOT a documentation site.
Edited by: Hemant K Chitale on Sep 20, 2010 5:19 PM

Materialized View big and empty after full refresh

Background:
Database 10.2.0.4 running on Windows 2003 Server R2 SP2.
Materialized view MV_A, selects from 3 base tables, 2 of which are partitioned, fast refresh on demand, approx 33 million rows. Initially populated with a complete refresh of 31 million rows about 2 months ago, and fast refreshed every 10 seconds since then.
Problem: Performed a partition split on one of the base tables and received this error on the next fast refresh:
ORA-32313: REFRESH FAST of "CUR"."MV_A" unsupported after PMOPs
Docs say a complete refresh is required.
So, created a new copy of the materialized view "MV_B", same storage params, same mview SELECT, same schema.
Did a complete refresh, the extents grew to the expected 10GB combined size. The DBMS_MVIEW.REFRESH reported 'PL/SQL procedure successfully completed' but the MVIEW is empty.
23:01:26 SQL> exec DBMS_MVIEW.REFRESH('MV_B','C','',FALSE,FALSE,0,0,0,TRUE) /* Complete */;
PL/SQL procedure successfully completed.
07:56:46 SQL> commit;
Commit complete.
08:17:51 SQL> select count(*) from mv_b;
COUNT(*)
0
08:19:39 SQL>
Since the MVIEW table MV_B added 10 GB worth of extents during the refresh, it appears that the rows were inserted but then for some reason were rolled back. Nothing unusual in the alert.log. If I execute the MVIEW select statement by itself in SQLPlus, yes, I do get rows back.
The tablespaces housing the MVIEW table as well as the temporary and undo tablespaces are set to autoextend/unlimited to make sure they are not an issue.
Next I dropped and recreated the materialized view MV_B, identical except an added condition to the WHERE clause so that the number of rows returned is only 7 million instead of 33 million and that works fine - a complete refresh populates it and subsequent fast refreshes work correctly.
I'm stumped. Any ideas? Could we be running out of some memory resource that when exhausted, is not trapped properly by Oracle as an error?
- Tom

Is the MV and the source tables on the same database? If this is a remote MV, then check the source site if there are any issues (TEMP, UNDO space issues).

Session Specific Materialized Views...

Its my understanding that when creating a materialized view, the default table the data is loaded into (from the query of the materialized view) is not session specific. Is there any way to make it session specific? Below is a view I just created... I want it to be session specific using the user currently logged into the system
CREATE MATERIALIZED VIEW DATA_PERMISSION_SETS
BUILD IMMEDIATE
REFRESH ON DEMAND AS
SELECT A.TRD_TRADER_LOGIN,
A.CY_COMPANY_KEY,
A.SID,
A.SERIAL_ID,
A.STRUCTURE_LEVEL,
A.STRUCTURE_KEY
FROM TRADER_DATA_PERMITS A
WHERE TRD_TRADER_LOGIN = USER;
If user "A" logs into the database, the data from the MV should be completely different than "B". I tried something close to this a few months ago using global temporary tables but it seems like oracle forms closes a session when using the built in "exit_form".. any help guys? Let me know your thoughts.
Thanks in advance.
Mo

Okay here is some details of what im trying to do. In my database is a security system, and within the security system is table which holds data permits for a row-level security system (oracle VPD using security context). So when a user logs in, he picks a security clearance, and based on the security clearance rows of data are populated into the filtering tables for the VPD context to decide which rows a user can see and not see... so heres an example...
Security clearance level 1 has access to
GVF Portfolio
RANDOM Portfolio
Subprime Portfolio
Security clearance level 2 has access to
1 Portfolio
RANDOM Portfolio
4 Portfolio
User 1 logs in using security clearance 1...
User 2 logs in using security clearance 2..
the filtering table will look like this for its permissions..
USER 1, GVF Portfolio
USER 1, RANDOM Portfolio
USER 1, Subprime Portfolio
USER 2, 1 Portfolio
USER 2, RANDOM Portfolio
USER 2, 4 Portfolio
now this example is assuming 2 users are in the system, with the minimal privledges inside the system. The current database can hold as many as 10k in users at a time all with entries in this table at login. If the VPD context has to sort through 150k + records for each row of a query, the run time is going to be EXTREMELY SLOW.
This is why I want to use a session specific materialized view or global table. It will minimize the records down to a few records, and the VPD context can use the materialized view as the filtering table instead of the full table.
The problem is the view data is not session specific. So if user 1 populates the materialized view and user 2 logs in to do the same, user 1's data from the materialized view will change from user 2's refresh...
Its a little hard to understand... let me know if you get me on this idea..
Mo

Altering a table in a materialized view environment

Hello everybody!.
My question is as simple as this:
When I have a single master - multiple materialized views environment , and I want to alter the master table (usually adding a column) , how do I propagate the change to the materialized view sites ?
In Oracle's documentation manuals it is written the process ONLY for the master sites.If I manually just alter the materialized views to the mat.views sites , the new columns DON'T take data from the master table!
It would be very nice if someone could help me.
Thanks everybody on advance!.
Thanasis Avdis

Hi,
you must dorp and recreate materialized view.

Time taken to Refresh a Materialized View

Hi,
Can we somehow estimate the approximate time it takes to Fast Refresh a particular Materialized View?
In my case it is REFRESH FAST ON DEMAND and it contains close to 65 Million Records. On a daily basis 40K records are updated/inserted in the Materialized View. Also MV Logs are created on the Master Tables.
The query of the MV is a join between a Dimension and Fact Table of a Datawarehouse. Each Master Table contains close to 70 million records.
Could you please let me know?
Thanks, Ketan

Hi Jignesh,
Thanks for the reply.
Actually what I would like to know is can we somehow estimate/forecast the Refresh Time before actually refreshing the MV.
Currently, in my case I am testing in a Non-Production Environment where the two MV logs contain 65K and just 70 records respectively. The Records finally Inserted/Updated from the MV is just 50. The time to refresh is about 7 minutes.
However, in the Production Environment, I am expecting close to 25-30K Inserts/Updates from the MV. So, I would like to know if we could PREDICT the approximate time required to Refresh a far larger dataset?
For example, to refresh close to 100K records in the View Logs will it take a far greater time or just some additional time? Is the Refresh rate directly dependent on the Number of Records to be refreshed or it takes a standard time to Refresh irrespective of the No. of Records?
Would appreciate your inputs on this.
Thanks, Ketan

Error when Create Materialized View

Hi
When I tried to create MV show me error :
SQL> @CRIA_MV_ARC_BW.SQL
AND INDUSTRIAL.CD_FABRICA = SUBSTR(ARC.DS_ARC, 1, 3)
ERROR at line 88:
ORA-01031: insufficient privilegesI am using Oracle 9.02 and there are Grant for all Tablles , my query of creation is:
CREATE MATERIALIZED VIEW CLIBGF.MV_ARC_BW
NOCACHE
LOGGING
NOPARALLEL
BUILD IMMEDIATE
REFRESH FORCE
START WITH TO_DATE('26-nov-2009 02:00:00','dd-mon-yyyy hh24:mi:ss')
NEXT trunc(sysdate) + 1/12
ENABLE QUERY REWRITE
AS
SELECT     MAX(NVL((SELECT DECODE(A.T$CDNG$O,'F',DECODE(TRIM(B.T$CALC$O),'S','C',A.T$CDNG$O),A.T$CDNG$O)
                 FROM TRITON.TTDFAT995501 A, TRITON.TTDFAT996501 B
                WHERE A.T$OCOM$O + 0 = ARC.CD_UNIDADE_EXPEDIDORA
                  AND A.T$NDOC$O = NOTAS.CD_NOTA
                  AND (A.T$OCOM$O = B.T$OCOM$O AND A.T$NREF$O = B.T$NREF$O)
                                    AND ROWNUM =1),
               0)) NEGOCIO,
       ARC.CD_CLIENTE CD_CLIENTE,
       CLIENTE.T$NAMA DS_CLIENTE,
       ARC.CD_ARC,
       ARC.CD_STATUS,
       ARC.CD_STATUS || ' - ' || STATUS.DS_STATUS STATUS,
       TO_CHAR(ARC.DT_EMISSAO, 'DD/MM/YYYY') DT_EMISSAO,
       TO_CHAR(ACAO_INV.DT_REALIZADO, 'DD/MM/YYYY') DT_REALIZADO_INVESTIGACAO,
       ARC.CD_MARCA || ' - ' || MARCA.T$DSMA$O MARCA,
       ARC.CD_PRODUTO CD_PRODUTO,
       EMBALAGEM.T$CDAC$O || ' - ' || EMBALAGEM.T$DESC$O DS_EMBALAGEM,
       SUBSTR(ARC.DS_ARC, 1, 3) CD_COMPANHIA_PRODUTORA,
        ARC.CD_MOTIVO_RECLAMACAO CD_MOTIVO_RECLAMACAO,
        MOTIVO.DS_ITEM DS_MOTIVO_RECLAMACAO,
       DECODE(ARC.FL_PROCEDENCIA, 0, 'PROCEDENTE', 1, 'IMPROCEDENTE', ' ') PROCEDENCIA,
       SUM(NVL((SELECT SUM(NVL(T$IQUA$O, 0))
                 FROM TRITON.TTDFAT995501 A, TRITON.TTDFAT996501 B
                WHERE A.T$OCOM$O + 0 = ARC.CD_UNIDADE_EXPEDIDORA
                  AND A.T$NDOC$O = NOTAS.CD_NOTA
                  AND (A.T$OCOM$O = B.T$OCOM$O AND A.T$NREF$O = B.T$NREF$O)),
               0)) NR_QUANTIDADE_VENDIDA,
           ARC.NR_QUANTIDADE_AFETADA NR_QUANTIDADE_AFETADA,
       ARC.NR_QUANTIDADE_AFETADA_REAL NR_QUANTIDADE_AFETADA_REAL,
       DS_JUSTIFICATIVA DSJUST
FROM ARCTB_ARC                 ARC,
       ARCTB_NOTAS               NOTAS,
       ARCTB_TABELA_MOTIVO       MOTIVO,
       ARCTB_ACAO_IMEDIATA       ACAO_INV,
       ARCTB_ACAO_IMEDIATA       ACAO_IME,
       ARCTB_STATUS              STATUS,
       TRITON.TTCCOM010501       CLIENTE,
       TRITON.TTCCOM936501       CIDADE,
       TRITON.TTIITM001810       D,
       TRITON.TTIITM983501       PRODUTO,
       TRITON.TTFGLD010806       CC,
       TRITON.TTCCOM983501       MARCA,
       TRITON.TTCCOM000501       CIA,
       TRITON.TTIITM982501       NAT,
       SEI.SIBTB_MULTIMARCA      MULTIMARCA,
       SEI.SIBTB_DIRETORIA_DEPTO DIRETORIA,
       TRITON.TTCCOM994501       USUARIO,
       ARCTB_GERENCIA_INDUSTRIAL INDUSTRIAL,
       TRITON.TTIITM984501       EMBALAGEM
WHERE ARC.CD_ARC = NOTAS.CD_ARC(+)
   AND ARC.CD_ARC = ACAO_INV.CD_ARC(+)
   AND ACAO_INV.CD_TIPO_ACAO(+) = 0
   AND ACAO_INV.CD_ACAO_IMEDIATA(+) = 999
   AND ARC.CD_ARC = ACAO_IME.CD_ARC(+)
   AND ACAO_IME.CD_TIPO_ACAO(+) = 1
   AND ACAO_IME.CD_ACAO_IMEDIATA(+) = 999
   AND ARC.CD_CLIENTE = CLIENTE.T$CUNO(+)
   AND CLIENTE.T$ESTA$L = CIDADE.T$ESTA$L(+)
   AND CLIENTE.T$CDMU$L = CIDADE.T$MUNI$L(+)
   AND TRIM(REPLACE(ARC.CD_PRODUTO, '-', '')) =
       TRIM(REPLACE(D.T$ITEM(+), '-', ''))
   AND TRIM(REPLACE(ARC.CD_PRODUTO, '-', '')) =
       TRIM(REPLACE(PRODUTO.T$ITEM$O(+), '-', ''))
   AND PRODUTO.T$PROC$O = NAT.T$PROC$O(+)
   AND EMBALAGEM.T$CDAC$O(+) = PRODUTO.T$CDAC$O
   AND ARC.CD_MOTIVO_RECLAMACAO = MOTIVO.CD_ITEM(+)
   AND ARC.CD_MARCA = MARCA.T$CDMA$O(+)
   AND SUBSTR(ARC.DS_ARC, 1, 3) = CIA.T$NCMP(+)
   AND ARC.CD_STATUS = STATUS.CD_STATUS(+)
   AND TRIM(ARC.CD_CENTRO_CUSTO) = TRIM(CC.T$DIMX(+))
   AND CC.T$DTYP(+) = 2
   AND CC.T$SUBL(+) = 0
   AND ARC.CD_DEPTO_MULTIMARCA = MULTIMARCA.CD_MULTIMARCA(+)
   AND ARC.CD_DEPTO = DIRETORIA.CD_DEPTO(+)
   AND ARC.CD_USUARIO = TRIM(USUARIO.T$CDUS$O(+))
   AND ARC.CD_STATUS IS NOT NULL
   AND ARC.CD_MOTIVO_RECLAMACAO = MOTIVO.CD_ITEM(+)
   AND INDUSTRIAL.CD_FABRICA = SUBSTR(ARC.DS_ARC, 1, 3)
   GROUP BY TO_CHAR(ARC.DT_EMISSAO, 'YYYY'),
          TO_CHAR(ARC.DT_EMISSAO, 'MM'),
          ARC.CD_ARC,
          ARC.DS_ARC,
          ARC.DS_SUPERVISOR,
          ARC.CD_STATUS,
          STATUS.DS_STATUS,
          TO_CHAR(ARC.DT_EMISSAO, 'DD/MM/YYYY'),
          TO_CHAR(ACAO_INV.DT_ORIGINAL, 'DD/MM/YYYY'),
          TO_CHAR(ACAO_INV.DT_REALIZADO, 'DD/MM/YYYY'),
          TO_CHAR(ACAO_IME.DT_ORIGINAL, 'DD/MM/YYYY'),
          TO_CHAR(ACAO_IME.DT_REALIZADO, 'DD/MM/YYYY'),
          TO_CHAR(ARC.DT_PROCEDENCIA, 'DD/MM/YYYY'),
          TO_CHAR(ARC.DT_RECEBIMENTO, 'DD/MM/YYYY'),
          TO_CHAR(NVL(ARC.DT_APROVACAO_INDUSTRIAL,
                      ARC.DT_APROVACAO_COMERCIAL),
                  'DD/MM/YYYY'),
          ARC.CD_CLIENTE,
          CLIENTE.T$NAMA,
          CIDADE.T$DSCA$L,
          ARC.CD_MARCA,
          MARCA.T$DSMA$O,
          ARC.CD_PRODUTO,
          D.T$SEAK,
          EMBALAGEM.T$CDAC$O || ' - ' || EMBALAGEM.T$DESC$O,
          NAT.T$DESC$O,
          ARC.NR_LOTE,
          ARC.DT_FABRICACAO,
          SUBSTR(ARC.DS_ARC, 1, 3),
          CIA.T$CITY,
          ARC.CD_MOTIVO_RECLAMACAO,
          MOTIVO.DS_ITEM,
          DECODE(ARC.FL_PROCEDENCIA,
                 0,
                 'PROCEDENTE',
                 1,
                 'IMPROCEDENTE',
          ARC.DS_DISPOSICAO,
          ARC.CD_CENTRO_CUSTO,
          CC.T$DESC,
          ARC.NR_QUANTIDADE_AFETADA,
          DS_JUSTIFICATIVA,
          DS_DISPOSICAO,
          CD_RESPONSAVEL_CAUSA,
          ARC.NR_QUANTIDADE_AFETADA_REAL,
          ARC.DT_ATENDIMENTO,
          MOTIVO.CLASSIFICACAO,
          ARC.DS_COORDENADOR,
          ARC.FL_ATENDIMENTO,
          TO_CHAR(ARC.DT_ATENDIMENTO, 'DD/MM/YYYY'),
          ARC.DS_COORDENADOR_INVESTIGACAO,
          INDUSTRIAL.REGIAO
ORDER BY ARC.CD_ARC DESC;
Edited by: muttleychess on Nov 25, 2009 10:25 AM

Please see my privilege
GRANTEE PRIVILEGE ADM
CLIBGF CREATE TABLE NO
CLIBGF CREATE ANY VIEW NO
CLIBGF CREATE SNAPSHOT NO
CLIBGF SELECT ANY TABLE NO
CLIBGF CREATE ANY TRIGGER NO
CLIBGF CREATE ANY SNAPSHOT NO

Multiple materialized views against same mv logs

Similar Messages

Maybe you are looking for