Materialised Views and Redo

Hi,
I am using Oracle 10.2.0.3 enterprise edition
Since we put in two materialised views and 2 jobs to refresh the materialised views every 5 minutes the database has been creating a lot of redo. Around about 2GIG every hour.
We have tried to recreate the materialised views as nologging so that they don't produce redo but this doesn't seem to have made any difference. Is the materialised view nologging setting being superceded by the tablespace logging setting?

The NOLOGGING command would apply to creating the materialized view log.
- Inserting records into the materialized view log will generate redo.
- Doing a refresh will also generate redo.
Are you scertain that you really need to refresh every 5 minutes ?

Similar Messages

Materialized View and Redo Information

Hi!!
I have created a materialized view with fast refresh. I have created a materialized view log on master table with NOLOGING. My view is refresh every 3 seconds but My problem is that my archivelogs is now growing so much!!!
Please, How I avoid that redo information increasing so much?
Thank you,
Roxana.

I want to show on line some tables of my database,
because I have created materialized view every 3
seconds on test enviroment. I'm not sure I follow exactly what you're saying here.
- Are you sure that you need materialized views here? And not just a regular view? If you need to display the data online and you need a lag of no more than three seconds, is there some reason that you're not using a regular old view? Are you doing some significant aggregation of the data?
- Are you sure that you need the materialized views to refresh every 3 seconds? And not on some longer interval?
- If you're looking for near real-time data replication, you may be better served by using Streams rather than materialized views.
When I use stand by database, I have to replica my
full database???.- I'm assuming this is a completely separate question with no relation to the previous section.
- Yes, DataGuard (physical or logical) would create and maintain a copy of your existing database on a separate server in order to fail over in the event of a disaster or to be a reporting server.
Justin

What is the difference between materialised view and normal view?

please expalin the difference in detail with an example.
thanks.

Hi User,
Welcome to Forum !!!!
Materialized view is nothing but a database Object similar to Tables,Indexes,Procedures etc.
It contains the results of a query.
The materialized view is refreshed when the query is executed. And are refreshed on demand
Unlike Views, it contain data.
It does not contain real-time data.
Materialized view are called Snapshot(In Older Versions of Oracle).
Thanks,
Shankar

Same Code in ordinary view and Materialised View is performing differentl

I am currently working on a Data Warehouse Project hooked off the back of an accounting system. It takes data from an old system and data from a new system and uses both for Corporate Reporting.
For Historical and Legacy Reporting reasons it is necessary to keep the Transaction Codes in the system at three characters. so anything that occurs that is less than three characters is padded to the left with zero's.
The line of code that does this is ...
CAST(LPAD(TRIM(TransactionCode),3,0) AS VARCHAR2(3)) AS TransactionCode
There are then 2 Views.
The first is a Materialised View, this contains 21 days worth of data for short term reporting and manipulation. In here this code seems to work perfectly.
The second is an ordinairy real time View that spans all data available, within here the Transaction Codes are not padded, but remain at their random 1 or 2 digit lengths.
In both views the field is defined as a VARCHAR2(3)
This is not a data issue, as the 21 days will fall within the ordinairy view and there are no examples in the ordinary view of this working.
The only thing that I can think of is if the character that is used for padding in the LPAD statement needs to be in quotes, I will try this, but I dont get why this would work in a Materialised View and not a View.
Can anyone shed any light on why this might occur ???
Many Thanks in advance
Regards
Craig Golby
Dignitas Ltd
http://www.dignitas.ltd.uk

I am currently working on a Data Warehouse Project hooked off the back of an accounting system. It takes data from an old system and data from a new system and uses both for Corporate Reporting.
For Historical and Legacy Reporting reasons it is necessary to keep the Transaction Codes in the system at three characters. so anything that occurs that is less than three characters is padded to the left with zero's.
The line of code that does this is ...
CAST(LPAD(TRIM(TransactionCode),3,0) AS VARCHAR2(3)) AS TransactionCode
There are then 2 Views.
The first is a Materialised View, this contains 21 days worth of data for short term reporting and manipulation. In here this code seems to work perfectly.
The second is an ordinairy real time View that spans all data available, within here the Transaction Codes are not padded, but remain at their random 1 or 2 digit lengths.
In both views the field is defined as a VARCHAR2(3)
This is not a data issue, as the 21 days will fall within the ordinairy view and there are no examples in the ordinary view of this working.
The only thing that I can think of is if the character that is used for padding in the LPAD statement needs to be in quotes, I will try this, but I dont get why this would work in a Materialised View and not a View.
Can anyone shed any light on why this might occur ???
Many Thanks in advance
Regards
Craig Golby
Dignitas Ltd
http://www.dignitas.ltd.uk

Making more archieve file while refreshing materialised view

Hi experts,
i have created a materialised view and index on that, while refreshing it is making more archive files,
how to stop making archieve while refreshing the Materialised view.
i also opted nologging option on that,

Hi experts,
i have created a materialised view and index on that, while refreshing it is making more archive files,
how to stop making archieve while refreshing the Materialised view.
i also opted nologging option on that,

Materialised view

Hi
i have a problem with one of the materialized view created by a user.
This materialised view includes a select statement.The select statement usually takes 5 mins.When i create the materialised view and run it for the first time,it runs in 5 min as the select statement.But later on it takes 45 min or even higher to perform the task.sometimes i need to manually abort it.
The basic syntax created like this
CREATE MATERIALIZED VIEW oracle
TABLESPACE oracle
NOCACHE
LOGGING
NOCOMPRESS
NOPARALLEL
BUILD IMMEDIATE
REFRESH FORCE ON DEMAND
WITH PRIMARY KEY
AS
select statement );
The select statement pulls data from another oracle database with the database link.

There are some factors you should consider:
1. As long as table is not local, you should consider network traffic.
2. Transactional activity on the remote database may produce a lot of consistent reads, which adversely influence performance.
3. How the execution plan from your query works.
I suggest you to restate the way you are working with your materialized view, you may want to consider Materialized View Replication instead. This provides more control and fault tolerance mechanisms.
~ Madrid

Streams to do a table view and then monitor changes

Hi,
I want to do a real time table view in a GUI.
I know I can use Streams to watch table changes and pass these to the GUI, but how do I get the table to the GUI first and be sure to get all changes after that.
The problem is that if I get the table and then start listening, I could miss a update between the table load and the start of listening.
If there was any way to get the table to Stream itself I could get the table load and the subsequent updates via Streams, which would ensure I never miss an update.
Is there a simple way to do this.
I had thought about using streams from a Materialised View, and forcing a refresh on the view might then dump the whole view into Streams, although I do not know enough to be sure this will work.
Has anyone got any ideas ?
Thanks
john

Hi John,
I think Morgan is right. You are perhaps adressing wrong technology. It will not designed for providing what you want...
Please clarify, What do you mean by ur GIU?
Main purpose of Stream replication is to replicate the changes done in one database/schema/table to the other database/schema/object (Oracle or nonoracle).
Regards,
Dipali..

RDB, Oracle 9i and Materialised Views

Hi all,
I have a RDB 7.1.5.9.1 and an Oracle 9.0.1.4.0 database and the data from the RDB has to be available for queries in Oracle Discoverer. There is a 1Gb (fixed) line between the databases. I have created a database link and that is working fine.
The RDB is used 24h a day and it is very important that there are no performance problems. I do not think that a 1-on-1 recreation of the data model of the RDB in the Oracle database (with the use of the database link) is the answer. The advantage is of course that the data is always up to date, but when multiple queries are started in Oracle Discoverer I think we have a problem. And the users are used to the fact that the data is not refreshed during the day, so that isnât an issue.
So I was thinking of using Materialised Views. Because RDB doesnât understand Materialised View Logs I can only do a complete refresh of these Materialised Views in Oracle. I can spread the time in which these are refreshed, but I only got about 1 hour (from 7 AM to 8 AM) to refresh about 1200Mb (that is not a lot), but in the future there will be an increase in the amount that has te be refrshed.
Does anybody know what a complete refresh will do to the performance of the RDB?
And what happens if someone is querying on a Materialised View during a refresh?
Of course, any other ideas are more then welcome. I am also considering the use of triggers in the RDB to INSERT-UPDATE-DELETE the data in Oracle and the use of LogMinor, although this last option is a tricky one because the Redo-statements contain rowidâs except from the INSERT statements.
Thanks!

in oracle9i database you can create materialized views with logs option but it works only under certain conditions. there is another option in oracle9i database of materialized views in which you can use time refresh.you specify time period after which your database refrsh automatically.
Yes freshing of materialized view cause performance cost on the server but it is only for time based refresh.as well as concern to the queries their is no problem with them when m-vies is in refresh state.oracle's own infrastructure can handel it.

OLAP on 11g and Materialised Views with Multiple Value-Based Hierarchies

Hello OLAPians
I am trying to setup Orable BIEE to report on an OLAP cube with pre-aggregated data. As OBIEE is not able to hook into the OLAP directly i have to create an SQL cubeview.
Currently i am on a 10g OLAP environment and am using the oracle sample SQL cubeview generator to create an SQLview of my cube.
The cube itself has multiple dimensions and these dimensions have multiple VALUE-based (ragged) hierarchies and dimension members can be shared across hierarchies also.
Initially i had a problem running the view generator plugin because there is a bug within it that does not finish if there are multiple value-based hierarchies present. I was able to get around this by manually editing the limitmap for the cubeview and manually creating the SQL view.
The question that i want to ask is how robust is the 11g materialised views with multiple value-based hierarchies and the sharing of dimension members across different hierarchies?
Has anyone successfully been able to create a cubeview and import it into OBIEE without the hassle of manually editing the limitmap?
A problem arises with the value-based setup whereby if the client creates a newer depth in the ragged hierarchy, i need to manually create the limitmap and the cube-view over again, and then re-map the BI Administration mappings.

The simple answer to your question,
how robust is the 11g materialised views with multiple value-based hierarchies...?is that materialized views are not supported on top of value-based hierarchies in 11g. The reason is that it is not possible to write a reasonable SQL statement that aggregates a fact over a value-based hierarchy. Such a SQL statement is necessary if we want to create a rewritable MV on top of the cube.
But I suspect this is not what you are really asking. If you are trying to set up OBIEE on top of the cube in 10g using the view generator, then you will probably want to use the "ET VIEWS" that are generated automatically in 11g. These are generated whether or not you enable materialized views on top of your cube. I am not aware of any issues with the generated value-based hierarchy view support in 11g. Members may be shared between value hierarchies and you will not need to generate or modify limit maps.

Is Snapshot and Materialised view are the same?

Can you please help me on this...
I am using oracle 10G enterprise edition...
Thanks in advance..

Re: Is Snapshot and Materialised view are the sameYes

How to restore views and procedures after drop user command?

How to restore views and procedures after drop user command?
We have 817 EE on NT and one developer created a lot of procedures, functions and vews. DB was not backuped and archived and export has not been done - our fault and we understand it. Sorry for this.
Ok, now the story: another developer dropped this db user and we lost everything: procedures, functions and vews. The new user with trhe same name was created and new schema was imported in this user, but all old objects are lost. We don't have export and backup and archive log files.
Question: may we can restore this lost stuff from some other sources. We are looking for lost codes, not data. May be we can use redo logs or shared pool or any other things. Any idea will be appreciated.
Thanks.
Victor
[email protected]

The switch has occurred after user was dropped, the data has been overwritten and there is be no way to use redo log files.
I would like to explore another opportunity. Is possible to use Shared Pool or any Data Dictionary internal information to restore texts of the lost SQL and PL/SQL scripts executed in this DB before user was dropped? Not too many scripts are executed in this DB and the lost ones may still be in stack. I remember that Shared Pool (cash) should keep last executed scripts in order to improve performance. They probably are kept in some special format. Can we restore these scripts? Of course they also might be pushed out by Import that had been done after user was dropped.
Thanks for your help,
Victor

Materialised view not getting refreshed.

Hi All
I have created a Materialised view which looks at the master tables in another database... using a DB link. I use to have the refresh force option in the materialised view.. I recieve no error messages when I create DB link, create Mview and I can refresh the Mview manually.. but the auto refresh is not happening... for some reason.. Database version is 10.2.0.1 Standard Edition on Solaris 10 OS.
Below are the scripts I have used to create DB link and MView... Please do let me know if I am missing any detail.. in particular.. what could be the issue/miss here thats avoiding the auto refresh of MView.
Thank you in advance.
Sarat.
DB LINK :
create public database link FBS_DB_LINK.REGRESS.RDBMS.DEV.US.ORACLE.COM connect to FBSUSER20 identified by <pwd> using 'FBSTEST'
Materialized View :
CREATE MATERIALIZED VIEW TWPERFUSER.CASE_DETAILS
                PCTFREE 10 PCTUSED 0 INITRANS 2 MAXTRANS 255
                STORAGE(
                                INITIAL 64 K
                                MINEXTENTS 1
                                MAXEXTENTS UNLIMITED
                                PCTINCREASE 0
                                BUFFER_POOL DEFAULT
TABLESPACE USERS
LOGGING
NOCACHE
NOPARALLEL
USING INDEX     PCTFREE 10 INITRANS 1 MAXTRANS 255
                STORAGE(
                                BUFFER_POOL DEFAULT
REFRESH FORCE
                WITH ROWID
USING DEFAULT LOCAL ROLLBACK SEGMENT
DISABLE QUERY REWRITE AS
select frc.reg_case_id,fp.provider_id,fptm.name,fp.provider_name,flam.authority_name,fp.creation_date,fp.multicentre_flag,
                                                fp.commercial_for_profit_flag,fp.three_month_programmes_flag,frcsm.long_form,frcsm.short_form
                                from
                                                fbs_provider@FBS_DB_LINK fp,
                                                fbs_provider_type_mst@FBS_DB_LINK fptm,
                                                fbs_reg_case@FBS_DB_LINK frc,
                                                fbs_reg_case_status_mst@FBS_DB_LINK frcsm,
                                                fbs_address@FBS_DB_LINK fa,
                                                fbs_local_authority_mst@FBS_DB_LINK flam
                                where
                                                      frc.provider_id = fp.provider_id
                                       and    fp.provider_type_id = fptm.provider_type_id
                                       and    fp.address_id = fa.address_id
                                       and    fa.local_authority_id = flam.local_authority_id

Hi,
REFRESH FORCE
As per my knowledge
REFRESH COMPLETE NEXT <date>
else check for the job status
select job, what, last_date, last_sec, this_date, this_sec, next_date, next_sec, failures, broken from user_jobs ;
Thanks
Pavan Kumar N

Should I use materialised view?

I am using the following sql in my code. This takes a long time to execute and I need to tune this. Please review and suggest if I should be using a materialized view instead.
Main Select statement for interest calculation
SELECT          intratechgcur.SECURITY, intratechgcur.srl_no, intratechgcur.schg_type,
     CASE WHEN intratechgcur.effective_date < ADt_Start_Date THEN ADt_Start_Date
                         ELSE intratechgcur.effective_date END AS start_date,
     CASE WHEN intratechgcur.effective_date < ADt_End_Date
                         AND NVL(intratechgnext.effective_date, ADt_End_Date) > ADt_End_Date THEN ADt_End_Date
                         ELSE NVL(intratechgnext.effective_date, ADt_End_Date) END AS end_date,
                    intratechgcur.rate, intratechgcur.face_value, intratechgcur.listing_int, intratechgcur.comm_prod_int,
                    intratechgcur.sec_create_int, intratechgcur.int_type, intratechgcur.interest_key, intratechgcur.margin,
                    intratechgcur.FLOOR, intratechgcur.cap, intratechgcur.reset_freq, intratechgcur.cmpd_y_n, intratechgcur.cmpd_freq,
                    intratechgcur.comp_type, intratechgcur.int_day, intratechgcur.int_day_1, intratechgcur.int_day_2, intratechgcur.int_dtls_yn
FROM               v_intratechg intratechgcur, v_intratechg intratechgnext
WHERE               intratechgcur.SECURITY          = AS_Security
AND          intratechgcur.effective_date < ADt_End_Date
AND               intratechgnext.SECURITY          (+)= intratechgcur.SECURITY
AND               intratechgnext.srl_no          (+)= intratechgcur.srl_no + 1
ORDER BY      intratechgcur.SECURITY, intratechgcur.effective_date, intratechgcur.srl_no ;
The code for the view V_intratechg is;
CREATE OR REPLACE VIEW V_INTRATECHG AS
SELECT     security,
     schg_type,
     effective_date,
     SUM(1) over (PARTITION BY security ORDER BY security, effective_date ASC, schg_type ASC) AS srl_no,
     face_value,
     rate,
     listing_int,
     comm_prod_int,
     sec_create_int,
     int_type,
     interest_key,
     margin,
     FLOOR,
     cap,
     NVL(reset_freq, 'DAILY') AS reset_freq,
     NVL(cmpd_y_n, 'N') AS cmpd_y_n,
     NVL(cmpd_freq, 'DAILY') AS cmpd_freq,
     NVL(comp_type, 'N') AS comp_type,
     int_day, int_day_1, int_day_2, int_dtls_yn
FROM
     (SELECT     security.security, 'IM' AS schg_type,
          GREATEST(security.prv_int_dt, NVL(security.allot_date, security.prv_int_dt),
          NVL(security.first_int_date,security.prv_int_dt)) AS effective_date,
          DECODE(intday.int_day_1, 'ACD', NVL((SELECT interest_amt FROM securityschddtls A WHERE security.security = A.security
          AND A.adhoc_schd_date > GREATEST(security.prv_int_dt, NVL(security.allot_date, security.prv_int_dt),
          NVL(security.first_int_date,security.prv_int_dt))
          AND a.rectype ='L' AND A.ADHOC_SCHD_DATE = (SELECT MIN(ADHOC_SCHD_DATE) FROM securityschddtls
WHERE      securityschddtls.adhoc_schd_date > GREATEST(security.prv_int_dt, NVL(security.allot_date, security.prv_int_dt), NVL(security.first_int_date,security.prv_int_dt))
     AND securityschddtls.security = A.security AND securityschddtls.rectype='L')),
          NVL(secchg.rate, security.interest)), NVL(secchg.rate, security.interest)) AS rate,
          NVL(secchg.face_value, security.face_value) AS face_value,
          NVL(secchg.listing_int, security.listing_int) AS listing_int,
          NVL(secchg.comm_prod_int, security.comm_prod_int) AS comm_prod_int,
          NVL(secchg.sec_create_int,security.sec_create_int) AS sec_create_int,
          NVL(secchg.int_type, security.int_type) AS int_type,
          NVL(secchg.interest_key, security.interest_key) AS interest_key,
          NVL(secchg.margin, security.margin) AS margin,
          NVL(secchg.FLOOR, security.FLOOR) AS FLOOR,
          NVL(secchg.cap, security.cap) AS cap,
          NVL(secchg.reset_freq, security.reset_freq) AS reset_freq,
          NVL(secchg.cmpd_y_n, security.cmpd_y_n) AS cmpd_y_n,
          NVL(secchg.cmpd_freq, security.cmpd_freq) AS cmpd_freq,
          NVL(secchg.comp_type, security.comp_type) AS comp_type,
          NVL(secchg.int_day, security.int_day) AS int_day, intday.int_day_1,
          intday.int_day_2, 'Y' AS int_dtls_yn
          FROM          security, assetype, intday, securityschddtls secdtls,
                    (SELECT     secchg.security AS security, secchg.call_date AS effective_date,
                    NVL(secchg.rate,0) AS rate, secchg.face_value,
                    SUM(1) over (PARTITION BY secchg.security ORDER BY secchg.security,
                    secchg.call_date ASC) AS srl_no,
                    NVL(secchg.listing_int,0) AS listing_int, NVL(secchg.comm_prod_int,0) AS comm_prod_int,
                    NVL(secchg.sec_create_int,0) AS sec_create_int,
                    secchg.int_type, secchg.interest_key,
                    nvl(secchg.margin,0) as margin, nvl(secchg.FLOOR,0) as floor,
                    nvl(secchg.cap,0) as cap, secchg.reset_freq,
                    secchg.cmpd_y_n, secchg.cmpd_freq, secchg.comp_type, secchg.int_day FROM          secchg) secchg
          WHERE          security.asset_type     = assetype.asset_type
               AND          security.int_day          = intday.int_day
               AND          assetype.int_y_n           = 'Y'
               AND          security.rectype          = 'L'
               AND          assetype.rectype          = 'L'
               AND          intday.rectype               = 'L'
               AND          secchg.security (+)= security.security
                    AND          secchg.srl_no (+)= 1
                    AND          secdtls.security (+)= security.security
                    AND          secdtls.srl_no (+)= 1
                    AND          secdtls.rectype (+)= 'L'
          UNION ALL
          SELECT     schedules.security,
               DECODE(schedules.schd_past_yn, 'Y', 'RP', 'RS') AS schg_type,
               DECODE(intday.int_day_1, 'ACD',security_cashflow.start_date,security_cashflow.inflow_date) AS effective_date,
               --commented by vijai
               -- DECODE(intday.int_day_1, 'ACD', intschdamt.amount, NVL(intratechg.rate,security.interest)) AS rate,
               DECODE(intday.int_day_1, 'ACD', intschdamt.amount,decode(security_cashflow.start_Date,intratechg.value_Date, intratechg.rate, security.interest)) as rate,
               decode(nvl(schedules.tot_face_value - schedules.cum_face_value,security.face_value),0,security.face_value,schedules.tot_face_value - schedules.cum_face_value,security.face_value) AS face_value,
               NVL(intratechg.listing_int,security.listing_int) as listing_int,
               NVL(intratechg.comm_prod_int,security.comm_prod_int) as comm_prod_int,
               NVL(intratechg.sec_create_int,security.sec_create_int),
               NVL(intratechg.int_type,security.int_type) as int_type,
               nvl(intratechg.interest_key,security.interest_key) as interest_key,
               nvl(intratechg.margin,security.margin) as margin,
               nvl(intratechg.FLOOR,security.floor) as floor,
               nvl(intratechg.cap,security.cap) as cap,
               nvl(intratechg.reset_freq,security.reset_freq) as reset_freq,
               nvl(intratechg.cmpd_y_n,security.cmpd_y_n) as cmpd_y_n,
               nvl(intratechg.cmpd_freq,security.cmpd_freq) as cmpd_freq,
               nvl(intratechg.comp_type,security.comp_type),
               nvl(intratechg.int_day,security.int_day),
               intday.int_day_1, intday.int_day_2,
               DECODE(intratechg.security, NULL, 'N', 'Y') AS int_dtls_yn
          FROM     v_schedules schedules, security, intday, intratechg, v_schedules intschdamt, security_cashflow
          WHERE     schedules.security          = security.security
          AND          schedules.red_yn      = 'Y'
          AND          security.int_day               = intday.int_day
          AND          security.rectype               = 'L'
          AND          intday.rectype                    = 'L'
          AND          intratechg.security (+)= schedules.security
          AND          intratechg.value_date(+)= schedules.schd_date
          AND          intratechg.rectype     (+)= 'L'
          AND          intschdamt.security (+)= schedules.security
          AND          intschdamt.schd_date (+)= schedules.schd_date
          AND          intschdamt.red_yn (+)= 'N'
          AND           security_cashflow.inflow_type      = 'INT'
          AND           security_cashflow.inflow_date     = schedules.schd_date
          AND           security.security               = security_cashflow.security
          AND           schedules.security          = security_cashflow.security
          UNION ALL
          SELECT     intratechg.security, 'IR' AS schg_type,
               intratechg.value_date AS effective_date,
               NVL(intratechg.rate,security.interest),
               security.face_value,
               NVL(intratechg.listing_int,security.listing_int),
               NVL(intratechg.comm_prod_int,security.comm_prod_int),
               NVL(intratechg.sec_create_int,security.sec_create_int),
               nvl(intratechg.int_type,security.int_type),
               nvl(intratechg.interest_key,security.interest_key),
               nvl(intratechg.margin,security.margin),
               nvl(intratechg.FLOOR,security.floor),
               nvl(intratechg.cap,security.cap),
               nvl(intratechg.reset_freq,security.reset_freq),
               nvl(intratechg.cmpd_y_n,security.cmpd_y_n),
               nvl(intratechg.cmpd_freq,security.cmpd_freq),
               nvl(intratechg.comp_type,security.comp_type),
               nvl(intratechg.int_day,security.int_day),
               intday.int_day_1, intday.int_day_2, 'Y' AS int_dtls_yn
          FROM     intratechg, security, intday
          WHERE     intratechg.security          = security.security
          AND     security.int_day               = intday.int_day
          AND     intratechg.rectype          = 'L'
          AND     security.rectype               = 'L'
          AND     intday.rectype                    = 'L'
          AND     NOT EXISTS     (SELECT     1 FROM          v_schedules schedules
                         WHERE          schedules.security     = intratechg.security
                         AND          schedules.schd_date     = intratechg.value_date
                         AND          schedules.red_yn          = 'Y'))
          ORDER BY security, srl_no
The code for the view V_schedules is;
CREATE OR REPLACE VIEW V_SCHEDULES AS
SELECT schdall.security,
          schdall.schd_date,
          schdall.schd_type,
          schdall.percent,
          schdall.units_o,
          schdall.units_n,
          schdall.amount,
          schdall.sequences,
schdall.act_sch_dt,
     schdall.security_n,
          schdall.prior_act,
     schdall.red_amount,
          schdall.ben_refer,
     schdall.round_method,
schdall.round_dec,
schdall.average_y_n,
     schdall.schd_past_yn,
     CASE WHEN schd_type IN(sysschd.red, sysschd.disred) THEN 'Y' ELSE 'N' END AS red_yn,
     SUM( CASE WHEN schd_type IN(sysschd.red, sysschd.disred) THEN schdall.red_amount ELSE 0 END)
                              over(PARTITION BY schdall.security) AS tot_face_value,
SUM( CASE WHEN schd_type IN(sysschd.red, sysschd.disred) THEN schdall.red_amount ELSE 0 END)
                              over(PARTITION BY schdall.security
                                   ORDER BY schdall.security, schdall.schd_date ASC) AS cum_face_value,
     SUM( CASE WHEN schd_type IN(sysschd.red, sysschd.disred) THEN schdall.red_amount ELSE 0 END)
                                   over(PARTITION BY schdall.security
                                   ORDER BY schdall.security, schdall.schd_date DESC) AS to_be_redeemed ,
          SUM(CASE WHEN schd_type =sysschd.INT THEN 0 ELSE 1 END)
                                   over(PARTITION BY schdall.security,schdall.schd_date,schd_type)
                         AS no_of_schd
FROM
               (SELECT      schedules.security_o AS security,
                              schedules.schd_date,
                              schedules.schd_type,
                              schedules.percent,
                              schedules.units_o,
                              schedules.units_n,
                              schedules.amount,
                              schedules.sequences,
                              schedules.act_sch_dt,
                              schedules.security_n,
                              schedules.prior_act,
                              schedules.red_amount,
                              schedules.ben_refer,
                              schedules.round_method,
                              schedules.round_dec,
                              schedules.average_y_n,
                              DECODE(schedules.schd_type,'RED','Y','Y') AS schd_past_yn
          FROM           schdpast schedules
          WHERE           prior_act = 'A'
          AND                rectype = 'L'
          UNION ALL
          SELECT           schedules.security_o AS security,
                              schedules.schd_date,
                              schedules.schd_type,
                              schedules.percent,
                         schedules.units_o,
               schedules.units_n,
                         schedules.amount,
                    schedules.sequences,
                    schedules.act_sch_dt,
               schedules.security_n,
               schedules.prior_act,
                    schedules.red_amount,
                    schedules.ben_refer,
               schedules.round_method,
               schedules.round_dec,
               schedules.average_y_n,
                    'N' AS schd_past_yn
          FROM           schedules
          WHERE           prior_act = 'A'
          AND                rectype = 'L'
          AND                Process_date IS NULL ) schdall,
          (SELECT           MAX(redschdtype) AS red,
                         MAX(disredtype) AS disred,
                              MAX(intschdtype) AS      INT
                              FROM sysparamschd
          WHERE rectype = 'L') sysschd
ORDER BY security, schd_date, schd_type

Too much SQL... makes me eyes hurt.
I think you're running down the wrong alley here. The very first and fundamental principle of performance tuning is identifying the performance problem. Saying that there is a problem is not identifying the actual problem.
You cannot run down the alley with a knife looking for a performance problem to kill if you do not know how it looks like. Good that you are running though - the old Klingon saying of "a running warrior can slit more throats" hold very true. :-)
Why is the existing SQL slow? You first need to identify that. Sure, a materialised view can make the end-query much faster as it has no longer to do all the work - that has now been done in batch by a DBMS_REFRESH job updating and maintaining that materialised view. But that work is still done... so have you actually fixed the cause of the performance problem, or merely hid it by addressing the symptoms?
How does one find and identify the underlaying performance problem with too-much-SQL-that-makes-Billy's-eyes-hurt? Software Engineering 101. Take any complex problem. Break it down into lots of smaller little problems. Solve each on in turn.
Take the SQL, break it down into simpler pieces and check each for performance issues. Look at the execution plan and cost. Determime if you (via the physical db design) are providing optimal I/O paths to the CBO in order for it to get to the required data with as little I/O as possible.
Once you deal with the facts, you can make an informed decision or whether or not a materialised view will actually fix the cause of the performance problem.

What is the use of materialised view in ORACLE

Hi All,
What is the use of Materialised view in ORACLE.Can anyone please help me out by giving a real time example in banking application (How MV is used in banking applications).
Thanks & Regards,
SB2013

SB2013 wrote:
What is the use of Materialised view in ORACLE.Can anyone please help me out by giving a real time example in banking application (How MV is used in banking applications).http://docs.oracle.com/cd/E11882_01/server.112/e25789/schemaob.htm#CNCPT411
Just add for example in a banking application at the end of each paragraph
E.g.
>
In data warehouses, you can use materialized views to compute and store data generated from aggregate functions such as sums and averages, for example in a banking application

Materialised view runs for ever ...

Hi
I'd appreciate if someone could shine some light on an issue I'm having with a materialised view.
I inherited this when I came into my current project, so before you ask me why tables are not partitioned or why a MV is being used for such a scenario, the answer is I don't know!!
Anyway ... I'm using "Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - Prod" running on SUSE ...
There are a number of normalised tables two of which contain in the region of 400million rows each and tend to grow at the rate of 27000 rows per day.
There's a materialised view (for the purposes of providing fast interactive reporting) that is setup as a normal join between 4 tables; the above two and the other two are just basic dictionary type lookups each containing around 100 or so rows.
SELECT .... FROM LargeTable1, LargeTable2, Lookup3, Lookup4 WHERE Lookup3.ID=LargeTable1.LID and LargeTable2.ID=LargeTable1.ID and LargeTable2.LID=Lookup4.ID ;
Running a FULL refresh on the MV failes with a 'ora-01555 snapshot too old' error after about 5 days!! Then takes around the same amount of time to rollback. Can't do a FAST refresh, I think because logs and/or mv indecies are out of sync.
Table space is 63% full and undo space is set to auto-extend.
I've tried /*+RULE */ but that doesn't seem to make a huge difference.
Why does it take so long? Why does it fail? What can I do to speed it up?
Thanks in advance for your assistance.
Edited by: 883758 on Sep 7, 2011 2:16 PM

You should approach this as a SQL tuning exercise, without the ability to change the query itself.
Are table statistics up to date? Look at the execution plan – does it look reasonable for you? Are there any indexes that can help? (I am thinking covering indexes on the large tables …)
Iordan Iotzov
http://iiotzov.wordpress.com/

Materialised Views and Redo

Similar Messages

Maybe you are looking for