Maintaining Stock Availibility : physical table or materialized view ?

Hi All,
We have typical Order processing application where I should maintain
stock availibility => Order is rejected if Stock is not available. The number of orders is 1000 perday, 22 branch, using VPD. 10 users each branch.
We are really tempted to use JUST view /materialized view to maintain stock position. (where traditionally we use a phiysical table for this, updated after insert/update/delete of transactions)
So the view will be like this :
Create View Stock AS
Select Prod.Code, Prod.beginning_balance,
( SELECT Sum (Qty) from Purchase Where ProdCode = prod.code ...) AS Purchase,
( SELECT Sum (Qty) from Order Where ProdCode = prod.code ...) AS Order,
From Products Prod
So to get the stock availability for a particular product :
Select Beginning_balance + Purchase - Order from Stock Where Code = ...
Please give comments, will this work with good performance ?
Or has anybody done like this in their application ?
Thank you for your help,
xtanto

If we're talking about a materialized view, I assume you'd do incremental fast refreshes. If we're talking about 1000 transactions a day, I wouldn't be at all concerned. Growth of the transaction table ought to have no impact on the speed with which the materialized view could be refreshed.
I can't think of any blocking issues that would arise from using a materialized view that wouldn't occur if you were updating a separate physical table. The timing might be slightly different, but Oracle's multi-version read consistency ought to work the same either way, hence you ought not ever block.
Justin

Similar Messages

Table and Materialized View in different namespaces?

I've just faced something completly new for me. It appears that there are two objects with the same name and owner. Table and Materialized View have the same names and when I look into system dictionary I can se sth. like that:
OWNER OBJECT_NAME OBJECT_ID DATA_OBJECT_ID OBJECT_TYPE NAMESPACE
USER_A USER_TABLE 159381 159381 TABLE 1
USER_A USER_TABLE 159382 MATERIALIZED VIEW 19
(I couldn't find how to write above with const length font).
Two object in different namespace? I thought that Tables and Materialized Vievs have the same namespace.
Can you please tell me how can I create objects to achieve above result? I would also be grateful if you tell me where to find that topic in documentation.

Perfectly normal.
SQL> select object_name, object_type from user_objects where object_name = 'TEST_MV';
no rows selected
SQL>
SQL> create materialized view test_mv
2 as
3 select sysdate from dual;
Materialized view created.
SQL>
SQL> select object_name, object_type from user_objects where object_name = 'TEST_MV';
OBJECT_NAME                                        OBJECT_TYPE
TEST_MV                                            TABLE
TEST_MV                                            MATERIALIZED VIEW
SQL>
SQL> drop materialized view test_mv;
Materialized view dropped.
SQL>
SQL> select object_name, object_type from user_objects where object_name = 'TEST_MV';
no rows selected
SQL>

Truncate table and materialized view log

I user oracle 10 R2
I have a table and on that table a materialized view log.
I execute in a pl/sql procedure:
1) execute immediate('drop materialized view log on tab1');
then:
2) execute immediate('truncate table tab1');
3) Now I insert a lot of records in tab1
4) execute immediate('create materialized view log on tab1 WITH rowid INCLUDING NEW VALUES');
When I create the materialized view log I recieved this message:
ora32321: refresh fast on tab2 unsupported after detail table truncate
Why?

Refresh fast after truncate operation on container table is not supported, regardless the container table is or is not partitioned.
Perform a refresh complete.
ORA-32321 :
Cause:     A detail table has been truncated and no materialized view
     supports fast refersh after a detail table has been truncated
Action:     Use REFRESH COMPLETE. Note: you can determine why your
     materialized view does not support fast refresh after TRUNCATE
     using the DBMS_MVIEW.EXPLAIN_MV() API.

Oracle equals_path condition NOT working with table and materialized view

The user i am using is xdb with dba role.
1.When i try to use the statement
SELECT PATH FROM xdb.path_VIEW
WHERE
EQUALS_PATH(res, '/home/OE/PurchaseOrders/2002')=1
the result is
/home/OE/PurchaseOrders/2002
2. When i drop the path_view and recreated it like materialized view with statement
create MATERIALIZED view path_view as
select /*+ ORDERED */ t2.path path, t.res res,
xmltype.createxml(xdb.xdb_link_type(NULL, r2.xmldata.dispname, t.name,
h.name, h.flags, h.parent_oid, h.child_oid),
'http://xmlns.oracle.com/xdb/XDBStandard.xsd', 'LINK') link,
t.resid
from ( select xdb.all_path(9999) paths, value(p) res, p.sys_nc_oid$ resid,
p.xmldata.dispname name
from xdb.xdb$resource p
where xdb.under_path(value(p), '/', 9999)=1 ) t,
TABLE( cast (t.paths as xdb.path_array) ) t2,
xdb.xdb$h_link h, xdb.xdb$resource r2
where t2.parent_oid = h.parent_oid and t2.childname = h.name and
t2.parent_oid = r2.sys_nc_oid$
then the equals_path condition STOP working !!!
3. The same experiment, but i recreate it like table
create table path_view as .... using the rest of the statement ...
Can someone help me to understand why equals_path is NOT working on table and materialized view !

Thanks Jonah. I was under the impression that I already had it but seems like it has to be a direct priv - thru a role doesn't work.
I granted the reqd privs and then it worked fine. Thx for your help!

Dropping base table of materialized view

HI please let me know what happens if i drop the base table of a materialized view? does the MV remain valid with data?

Hi,
Well, it's easy to test yourself.
SQL> select count(*) from t1;
COUNT(*)
       100
SQL> desc t1
Name                                      Null?    Type
ID                                                 NUMBER(10)
SQL> create materialized view t1_mv as select * from t1;
Materialized view created.
SQL> select count(*) from t1_mv;
COUNT(*)
       100
SQL> drop table t1 purge;
Table dropped.
SQL> select count(*) from t1_mv;
COUNT(*)
       100
SQL> desc t1_mv
Name                                      Null?    Type
ID                                                 NUMBER(10)
SQL> select object_type, status from user_objects where object_name = 'T1_MV';
OBJECT_TYPE         STATUS
TABLE               VALID
MATERIALIZED VIEW   INVALID
SQL> select * from t1_mv where rownum < 5;
        ID
         1
         2
         3
         4
SQL>I think the answer is very clear.
Asif Momen
http://momendba.blogspot.com

Alter the main tables of materialized views

Hi
I want to add a new column to the main table of a materialized view.Can anyone let me know,what are the steps I need to take care on materialized views,In addition to recompiling dependent objects?

PER_SPECIAL_INFO_TYPES: This table holds the definitions of SITs that are available to each Business Group. Each special information type is a user defined structure for the personal analysis key flexfield. The name of the special information type is the same as the name of the corresponding key flexfield structure.
PER_SPECIAL_INFO_TYPES_V : This table has the Employee's SIT info. A supplementary view used to simplify forms coding
PER_SPECIAL_INFO_TYPES_V2 : A supplementary view used to simplify forms coding.

Synonym problem with external table in materialized view

I have a materialized view that includes selects on two external tables.
However, no matter how I try to access the external tables, the creation fails with a "Synonym Translation Is No Longer Valid" (ORA-00980) error.
This happens even when I replace the tablename with the full table name, including the link.
I can create a view just fine, but if I then try something like CREATE MATERIALIZED VIEW mvw_my_view AS SELECT * FROM vw_my_view (where vw_my_view is the view in question), it still throws the Synonym Translation exception.

00980, 00000, "synonym translation is no longer valid"
// *Cause: A synonym did not translate to a legal target object. This
//         could happen for one of the following reasons:
//         1. The target schema does not exist.
//         2. The target object does not exist.
//         3. The synonym specifies an incorrect database link.
//         4. The synonym is not versioned but specifies a versioned
//            target object.
// *Action: Change the synonym definition so that the synonym points at
//          a legal target object.It is really, Really, REALLY difficult to fix a problem that can not be seen.
use COPY & PASTE so we can see what you do & how Oracle responds.

Updating base table with Materialized View's data

Hi,
In order to update base table with MVs data, I am trying real time data transfer between two databases. One is Oracle 8i and other is Oracle 9i. I have created an updatable MV in 9i on a base table using database link. The base table is in 8i. Materialized View log is created in 8i on base table. MV has to be associated to some replication group, but I am not able to create replication group in 9i to which MV has to be associated. The required packages are not installed.
Replication packages are to be used to create replication group are :
/*Create Materialized View replication group*/
BEGIN
DBMS_REPCAT.CREATE_MVIEW_REPGROUP (
gname => 'TEST_MV_GRP',
master => 'TEST_DATA_LINK',
propagation_mode => 'ASYNCHRONOUS');
END;
But above block is giving error.
Can anyone suggest how to resolve this, or are there any other approaches (by not using replication packages) to update base table with MVs data ?
Thanks,
Shailesh

Yes, I created link between two databases and was able to update tables on 8i from 9i database using that link.
The error I am getting while creating replication group is :
ORA-06550
PLS-00201 : identifier 'SYS.DBMS_REPCAT_UTL2@'TEST_DATA_LINK' must be declared
ORA-06550
PLS-00201 : identifier 'SYS.DBMS_REPCAT_UNTRUSTED@'TEST_DATA_LINK' must be declared
ORA-06512 : at "SYS.DBMS_REPCAT_UTL", line 2394
ORA-06512 : at "SYS.DBMS_REPCAT_SNA_UTL", line 1699
ORA-06512 : at "SYS.DBMS_REPCAT_SNA", line 64
ORA-06512 : at "SYS.DBMS_REPCAT", line 1262
Is there any other approach which can be used to update base table with MVs data instead of using replication packages ?
Thanks,
Shailesh

User_catalog - object listed as both 'TABLE' and 'MATERIALIZED VIEW'

SELECT * FROM USER_CATALOG ORDER BY OBJECT_NAME
returns ...
OBJECT_NAME              OBJECT_TYPE
BLOBBY                   SYNONYM
BONUS                    TABLE
DEPT                     TABLE
EMP                      TABLE
EMPLOYEES                SYNONYM
EMPWITHDEPT              MATERIALIZED VIEW
EMPWITHDEPT              TABLE
                         ^^^^^^^^^^^^Any ideas to show only the 'MATERIALIZED VIEW' row for the above query?
Thanks in advance,
Mike Norman

So, I would need some sort of logic to
check if the OBJECT_NAME from user_objects
is present in user_snapshots print 'MATERIALIZED VIEW'
otherwise take the OBJECT_TYPE from user_objects -
some sort of DECODE?

Convertion of Base tables to Material views while executing dbms_refreshes

Hi all,
I have a typical type of problem. We have a daily task of database activities like monitoring the space, refreshing Material views etc and currently using While doing refreshing the materialized views (using dbms.refresh) All master tables are become MV's in the database.This is a serious issue has to be solved asap.
Also I find the materialized views got some data's in it. Now I want to get my master tables back to original.
I have an idea to drop all the respective base tables, materialized view and recreate the same once again.
But Is there any other alternate method there to get back my materialized views converted to base tables???
Can someone help me how to do the same????
Thanks in advance.
Regards
Dinesh

While doing refreshing the materialized views (using dbms.refresh)
All master tables are become MV's in the database?????
So strange that I'd say that's not possible. How did you check that ? and which command did you execute exactly ?

Need Advise on Global Temporary tables or Materialized views or Views

Need advise on a plsql procedure working on.
I had 6 tables having 200,000 rows in total intially,but will get added a maximum 20,000 rows daily by a batch process.
I am writing a plsql code that takes an input ,for example customer_id, and is required to get all the data for that customer_id and
had to do some complex calculation that includes stepwise validations before giving the output.Now while doing the logic it has the get the data for that customer_id from all the tables.
There may be 100 records for that particular customer_id.
I need advise on the below options.
1.Use of global temporary tables get those 100 records and do the calculation part on that Global Temporary table.
2.Use of Views or Materialized views.
3.Using the Record Structures(like table types for those records) and then do the logic on them
As Performance is the key point here i would like pull all the data at once into memory and then do the calculations instead of hitting the database many times, this is my main idea(correct me if am wrong).Also please advise if there are any other options
I am using ORACLE 10G.
Thanks
Rede

The approach that many advocate for here (including myself) is to do as much in SQL as possible. So, copying to GTTs or using record structures is probably not the solution you should be after.
If you can provide the following details we may be able to steer you down the right path
1. Oracle version (SELECT * FROM V$VERSION)
2. Sample data in the form of CREATE / INSERT statements.
3. Expected output
4. Explanation of expected output (A.K.A. "business logic")
5. Use \ tags for #2 and #3. See FAQ (Link on top right side) for details.
Ideally try and re-create the problem, simplifying it as much as possible, without losing context. Use #1-#5 above as a base for posting your simplified problem here. Then we may be able to give you a solution specific to your problem.

Performance difference between tables and materialized views

hi ,
I created a materialized view on a query that involves partition table in it.
When i used the same query and created a table out of it <create table xyz as select * from (the query)> ,the table got created quickly.
So does that mean performance wise creating table is faster than creating/refreshing the materialized view ?or is that due to the refresh method i use ?Currently i use a complete refresh

I created a materialized view on a query that involves partition table in it.
When i used the same query and created a table out of it <create table xyz as select * from (the query)> ,the table got created quickly.
So does that mean performance wise creating table is faster than creating/refreshing the materialized view ?or is that due to the refresh method i use ?Currently i use a complete refresh Well, for starters, if you created the materialized view first and then the standard table, the data for the second one has already been fetched recently and so will reduce your I/O due to caching, and will therefore be quicker. There are also other factors such as the materialized view creating other internal bits that are required to allow for refreshes to be done quickly, such as the primary key etc which you haven't created on your second creation.
What you have shown is that two completely different statements running at different times, appear to operate with different speed. It is not a comparison of whether the materialized view is slower or quicker than the create table statement.

Materialized views on prebuilt tables - query rewrite

Hi Everyone,
I am currently counting on implementing the query rewrite functionality via materialized views to leverage existing aggregated tables.
Goal*: to use aggregate-awareness for our queries
How*: by creating views on existing aggregates loaded via ETL (+CREATE MATERIALIZED VIEW xxx on ON PREBUILT TABLE ENABLE QUERY REWRITE+)
Advantage*: leverage oracle functionalities + render logical model simpler (no aggregates)
Disadvantage*: existing ETL's need to be written as SQL in view creation statement --> aggregation rule exists twice (once on db, once in ETL)
Issue*: Certain ETL's are quite complex via lookups, functions, ... --> might create overy complex SQLs in view creation statements
My question: is there a way around the issue described? (I'm assuming the SQL in the view creation is necessary for oracle to know when an aggregate can be used)
Best practices & shared experiences are welcome as well of course
Kind regards,
Peter

streefpo wrote:
I'm still in the process of testing, but the drops should not be necessary.
Remember: The materialized view is nothing but a definition - the table itself continues to exist as before.
So as long as the definition doesn't change (added column, changed calculation, ...), the materialized view doesn't need to be re-created. (as the data is not maintained by Oracle)Thanks for reminding me but if you find a documented approach I will be waiting because this was the basis of my argument from the beginning.
SQL> select * from v$version ;
BANNER
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
PL/SQL Release 11.2.0.1.0 - Production
CORE     11.2.0.1.0     Production
TNS for Linux: Version 11.2.0.1.0 - Production
NLSRTL Version 11.2.0.1.0 - Production
SQL> desc employees
Name                                                                                            Null?    Type
EMPLOYEE_ID                                                                                     NOT NULL NUMBER(6)
FIRST_NAME                                                                                               VARCHAR2(20)
LAST_NAME                                                                                       NOT NULL VARCHAR2(25)
EMAIL                                                                                           NOT NULL VARCHAR2(25)
PHONE_NUMBER                                                                                             VARCHAR2(20)
HIRE_DATE                                                                                       NOT NULL DATE
JOB_ID                                                                                          NOT NULL VARCHAR2(10)
SALARY                                                                                                   NUMBER(8,2)
COMMISSION_PCT                                                                                           NUMBER(2,2)
MANAGER_ID                                                                                               NUMBER(6)
DEPARTMENT_ID                                                                                            NUMBER(4)
SQL> select count(*) from employees ;
COUNT(*)
       107
SQL> create table mv_table nologging as select department_id, sum(salary) as totalsal from employees group by department_id ;
Table created.
SQL> desc mv_table
Name                                                                                            Null?    Type
DEPARTMENT_ID                                                                                            NUMBER(4)
TOTALSAL                                                                                                 NUMBER
SQL> select count(*) from mv_table ;
COUNT(*)
        12
SQL> create materialized view mv_table on prebuilt table with reduced precision enable query rewrite as select department_id, sum(salary) as totalsal from employees group by department_id ;
Materialized view created.
SQL> select count(*) from mv_table ;
COUNT(*)
        12
SQL> select object_name, object_type from user_objects where object_name = 'MV_TABLE' ;
OBJECT_NAME                                                                                                                      OBJECT_TYPE
MV_TABLE                                                                                                                         TABLE
MV_TABLE                                                                                                                         MATERIALIZED VIEW
SQL> insert into mv_table values (999, 100) ;
insert into mv_table values (999, 100)
ERROR at line 1:
ORA-01732: data manipulation operation not legal on this view
SQL> update mv_table set totalsal = totalsal * 1.1 where department_id = 10 ;
update mv_table set totalsal = totalsal * 1.1 where department_id = 10
ERROR at line 1:
ORA-01732: data manipulation operation not legal on this view
SQL> delete from mv_table where totalsal <= 10000 ;
delete from mv_table where totalsal <= 10000
ERROR at line 1:
ORA-01732: data manipulation operation not legal on this view While investigating for this thread I actually made my own question redundant as the answer became gradually clear:
When using complex ETL's, I just need to make sure the complexity is located in the ETL loading the detailed table, not the aggregate
I'll try to clarify through an example:
- A detailed Table DET_SALES exists with Sales per Day, Store & Product
- An aggregated table AGG_SALES_MM exists with Sales, SalesStore per Month, Store & Product
- An ETL exists to load AGG_SALES_MM where Sales = SUM(Sales) & SalesStore = (SUM(Sales) Across Store)
--> i.e. the SalesStore measure will be derived out of a lookup
- A (Prebuilt) Materialized View will exist with the same column definitions as the ETL
--> to allow query-rewrite to know when to access the table
My concern was how to include the SalesStore in the materialized view definition (--> complex SQL!)
--> I should actually include SalesStore in the DET_SALES table, thus:
- including the 'Across Store' function in the detailed ETL
- rendering my Aggregation ETL into a simple GROUP BY
- rendering my materialized view definition into a simple GROUP BY as wellNot sure how close your example is to your actual problem. Also don't know if you are doing an incremental/complete data load and the data volume.
But the "SalesStore = (SUM(Sales) Across Store)" can be derived from the aggregated MV using analytical function. One can just create a normal view on top of MV for querying. It is hard to believe that aggregating in detail table during ETL load is the best approach but what do I know?

Table Operator Vs Materialized View Operator

Hi All,
Could you please give the differences between Table Operator and Materialized view Operator in Oracle Warehouse Builder 11g.
Regards,
Subbu

Below an extract of my notes of the Materialized view. The complete notes are here :
http://gerardnico.com/wiki/dw/aggregate_table
=====Notes=====
Materialized views are the equivalent of a summary table. (Materialized views can be also use as replica).
In a olap approach, each of the elements of a dimension could be summarized using a hierarchy.
The end user queries the tables and views in the database. The query rewrite mechanism in a database automatically rewrites the SQL query to use this summary tables.
This mechanism reduces response time for returning results from the query. Materialized views within the data warehouse are transparent to the end user or to the database application.
This is relatively straightforward and is answered in a single word - performance. By calculating the answers to the really hard questions up front (and once only), we will greatly reduce the load on the machine, We will experience:
* Less physical reads - There is less data to scan through.
* Less writes - We will not be sorting/aggregating as frequently.
* Decreased CPU consumption - We will not be calculating aggregates and functions on the data, as we will have already done that.
* Markedly faster response times - Our queries will return incredibly quickly when a summary is used, as opposed to the details. This will be a function of the amount of work we can avoid by using the materialized view, but many orders of magnitude is not out of the question.
Materialized views will increase your need for one resource - more permanently allocated disk. We need extra storage space to accommodate the materialized views, of course, but for the price of a little extra disk space, we can reap a lot of benefit.
Also notice that we may have created a materialized view, but when we ANALYZE, we are analyzing a table. A materialized view creates a real table, and this table may be indexed, analyzed, and so on.
Success
Nico

Materialized Views appear twice - under MV and under tables

Hi,
I've encountered a wierd issue.
It seems that every materialized view is also appearing under the tables tab.
For example sh.cal_month_sales_mv. Another example, run this as sh:
CREATE MATERIALIZED VIEW SH.OFIR_MV
REFRESH FORCE ON DEMAND
ENABLE QUERY REWRITE
AS SELECT sum(s.amount_sold) AS dollars
FROM sales s;
You'll see a table OFIR_MV under the table tab. If you try to drop it(right-click-> table-> drop), you get ora-12083 must use DROP MATERIALIZED VIEW to drop "SH"."OFIR_MV"
Also, SQL tab of the "table" has the folowing remark
-- DBMS_METADATA was unable to use TABLE_EXPORT to generate sql. Now trying to use TABLE
I guess this is the source of the issue:
select object_name,object_type from user_objects where object_name = 'OFIR_MV';
OBJECT_NAME OBJECT_TYPE
OFIR_MV TABLE
OFIR_MV MATERIALIZED VIEW
2 rows selected
So, creating a MV also adds a table to user_objects/tables. (Huh? that suprised me)
Could SQL Dev filter these fake tables or at least have a different icon/color for them?
Thanks.
Ofir
BTW - Win XP, 10.2.0.3EE, SQL Dev 1.1.1.25.14

e.g Re: Materialized Views, indexes and Raptor Eeerrr... no.
That user wanted to be able to access indexes, etc., which he thought could be easily accomplished by adding the MV to the tables node.
To what the response was: the options on the MV will be improved (which it has), NOT bringing it in the tables node. As Ofir also pointed out, there's a reason for it not belonging there: the operations performed on the objects of the table node expect tables, not MVs.
So, between fixing the tables node for accepting MVs and it's operations, and just removing the MVs from the node, I'd go for the second, faster, more correct solution.
K.

Maintaining Stock Availibility : physical table or materialized view ?

Similar Messages

Maybe you are looking for