Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
Home
Discussion Groups
Database Servers
DB2InformixIngresMS SQLOraclePervasive.SQLPostgreSQLProgressSybase
Desktop Databases
FileMakerFoxProMS AccessParadox
General
General DB TopicsDatabase Theory
Related Topics
Java Development.NET DevelopmentVB DevelopmentMore Topics ...

Database Forum / DB2 Topics / January 2008

Tip: Looking for answers? Try searching our database.

problem with MQT

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
amitabh.mehra@gmail.com - 07 Jan 2008 11:51 GMT
Hi

I havent used MQT before. Read the online tips and tutorials but none
seems to give any hint for my problem.

I have a base table  (base_table) as:

                     st      varchar(25)     default 'my_null'
                     dt      timestamp     default
'1900-01-01-00.00.00.00000'
                     num  integer           default -999999

My requirement is that for any of these default value in base table,
null should be populated in the materialized view.
I tried the following to create a mqt:

CREATE TABLE OUT_table AS (SELECT
                                    CASE DT WHEN
'1900-01-01-00.00.00.000000'  THEN null ELSE DT END DT,
                    CASE NUM WHEN  -999999 THEN null ELSE NUM END  NUM,
                    CASE ST WHEN  'my_null'  THEN null ELSE ST END ST FROM
base_table)
DATA INITIALLY DEFERRED REFRESH DEFERRED

Then tried creating the staging table:

                 create table m_out_table for out_table propagate
immediate

This gave me error: SQL20058N  The fullselect specified for the
materialized query table "test.OUT_table" is not valid. Reason code =
"7

Can, the thing that I am trying to do (put null values for 'my_null'
etc), be done? If yes, how?

Thanks.
Lennart - 07 Jan 2008 14:43 GMT
On Jan 7, 12:51 pm, amitabh.me...@gmail.com wrote:
> Hi
>
[quoted text clipped - 33 lines]
>
> Thanks.

If you use a staging table you must obey the same rules as for an MQT
refresh immediate:

db2 "? SQL20058N"

SQL20058N The fullselect specified for the materialized query
         table "<table-name >" is not valid. Reason code =
         "<reason-code>".

Explanation:

The materialized query table definition has specific rules
regarding the contents of the fullselect. Some rules are based on
the materialized query table options (REFRESH DEFERRED or REFRESH
IMMEDIATE) while others are based on whether or not the table is
replicated. The fullselect in the CREATE TABLE statement that
returned this condition violates at least one of the rules as
described in the SQL Reference.

This error may occur during the creation of a staging table. In
such a case, the error applies to the query used in the
definition of the materialized query table with which the staging
table is associated.

The statement cannot be processed because it violates a
restriction as indicated by the following reason code:
[...]
7 When REFRESH IMMEDIATE is specified:

o   the materialized query table must not contain duplicate rows

o   when a GROUP BY clause is specified, all GROUP BY items must
   be included in the select list

o   when a GROUP BY clause is specified which contains GROUPING
   SETS, CUBE, or ROLLUP, then no grouping sets can be repeated,
   and if C is a nullable GROUP BY item that appears within
   GROUPING SETS, CUBE, or ROLLUP, then GROUPING(C) must appear
   in the select list

o   when no GROUP BY clause is present, then the underlying
   tables must each have at least one unique key defined, and
   all columns of these keys must appear in the select list of
   the materialized query table definition
[...]
7 Create the materialized query table as REFRESH DEFERRED, or

o   correct the CREATE TABLE statement to ensure all GROUP BY
   items are in the select list

o   correct the GROUP BY clause to ensure there are no duplicate
   grouping sets

o   remove the nullable column, C, or add GROUPING(C) in the
   select list

o   correct the CREATE TABLE statement to ensure at least one
   unique key from each table referenced in the query appears in
   the select list

Why do you need an MQT in the first place, can't you use a view
instead?

CREATE VIEW OUT_table AS
   SELECT CASE DT WHEN '1900-01-01-00.00.00.000000'  THEN null ELSE
DT END DT,
                 CASE NUM WHEN  -999999 THEN null ELSE NUM END  NUM,
                 CASE ST WHEN  'my_null'  THEN null ELSE ST END ST
   FROM base_table;

Another option is to add generated columns for the transformations,
but I would aim for the view

/Lennart
amitabh.mehra@gmail.com - 08 Jan 2008 04:44 GMT
> On Jan 7, 12:51 pm, amitabh.me...@gmail.com wrote:
>
[quoted text clipped - 110 lines]
>
> /Lennart

Thanks Lennart for the reply. But the problem with the view is that I
would not be able to refresh them incrementally if my base table gets
updated (as with mqts). or can i?
amitabh.mehra@gmail.com - 08 Jan 2008 04:45 GMT
On Jan 8, 9:44 am, amitabh.me...@gmail.com wrote:

> > On Jan 7, 12:51 pm, amitabh.me...@gmail.com wrote:
>
[quoted text clipped - 114 lines]
> would not be able to refresh them incrementally if my base table gets
> updated (as with mqts). or can i?

Also since I am not using REFRESH IMMEDIATE, I cant understand how
this error is coming.
Lennart - 08 Jan 2008 05:24 GMT
On Jan 8, 5:45 am, amitabh.me...@gmail.com wrote:
> On Jan 8, 9:44 am, amitabh.me...@gmail.com wrote:
>
[quoted text clipped - 119 lines]
> Also since I am not using REFRESH IMMEDIATE, I cant understand how
> this error is coming.

That's because of the staging table. If you add a staging table to a
"refresh deferred" MQT, youi must obey the same rules as for an
"refresh immediate" MQT

/Lennart
Lennart - 08 Jan 2008 05:21 GMT
On Jan 8, 5:44 am, amitabh.me...@gmail.com wrote:

> > On Jan 7, 12:51 pm, amitabh.me...@gmail.com wrote:
>
[quoted text clipped - 114 lines]
> would not be able to refresh them incrementally if my base table gets
> updated (as with mqts). or can i?

I'm not sure I understand your question, but a view is sort of a query
stored in the database so you will definitely get updated results from
the view as you update the underlaying tables. In an MQT on the other
hand, the result is physically stored on disk.

HTH
/Lennart
Lennart - 08 Jan 2008 05:26 GMT
> On Jan 8, 5:44 am, amitabh.me...@gmail.com wrote:
>
[quoted text clipped - 121 lines]
> the view as you update the underlaying tables. In an MQT on the other
> hand, the result is physically stored on disk.

That is, with a view you don't need to do any refresh. It is refreshed
by definition

/Lennart
amitabh.mehra@gmail.com - 08 Jan 2008 05:50 GMT
> > On Jan 8, 5:44 am, amitabh.me...@gmail.com wrote:
>
[quoted text clipped - 126 lines]
>
> /Lennart

The problem with the view is that it will get updated as soon my base
table is updated. I dont want that. I want to refresh my"snapshot" as
n when required. So i found out that mqt was solving my purpose. I cud
update them as n when required.
Any other idea?
Lennart - 08 Jan 2008 07:03 GMT
On Jan 8, 6:50 am, amitabh.me...@gmail.com wrote:

> > > On Jan 8, 5:44 am, amitabh.me...@gmail.com wrote:
>
[quoted text clipped - 132 lines]
> update them as n when required.
> Any other idea?

Why do you need the staging table?

/Lennart
amitabh.mehra@gmail.com - 08 Jan 2008 07:41 GMT
> On Jan 8, 6:50 am, amitabh.me...@gmail.com wrote:
>
[quoted text clipped - 138 lines]
>
> /Lennart

So that I can incrementally refresh a REFRESH DEFERRED MQT. The idea
is to use the staging table to incrementally refresh the MQT, rather
than regenerate the MQT from scratch and so enhance the performance.
Lennart - 08 Jan 2008 08:11 GMT
On Jan 8, 8:41 am, amitabh.me...@gmail.com wrote:

> > On Jan 8, 6:50 am, amitabh.me...@gmail.com wrote:
>
[quoted text clipped - 142 lines]
> is to use the staging table to incrementally refresh the MQT, rather
> than regenerate the MQT from scratch and so enhance the performance.

I see. How long does it take to refresh the MQT without a staging
table, and what is acceptable? As mentioned before you can't use a
staging table with your query definition, since it doesnt obey the
rules for immediate refresh.

From what you have described I don't see any other way than to build
something on your own to manually maintain OUT_table.

/Lennart
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2009 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.