The materizlezed view don't update

Question

hi all,
I create a materialized view like
create materialized view vw_jfp_jpgcb_mislog_1
refresh fast NEXT sysdate + 1/144
on demand
as
SELECT
* from big_table;
It should be update every 10 minutes.
But after I insert 100 thousand records, I find it don't update. What's reason of it ?

Answer 1

Have you traced a session doing the refresh to see
where the time is being taken? I'll wager it's in the
LOB processing, but having actual data to back that
up would be helpful.
<Cango> I check the row num in materialized
view every 10 second and compare time of the data
change I'm not sure how your answer relates to my question. I was talking about a session trace (run through tkprof) to validate that it's the query, not some function of the materialized view refresh process, that was running slowly, what the query is waiting on, etc.
Can you run that query separately over a sample of
however many rows are going to be refreshed and get a
timing? Obviously, if it takes 13 minutes to run that
query over 100,000 rows, you'd have to tune the
query.So, does it take 13 minutes to run the query over a sample of 100,000 rows?
What data type is the XML document stored in? I'm
guessing a BLOB from your syntax since you didn't
include the table definition. Why would you store XML
in a BLOB rather than a CLOB?
<Cango> yes, we stroe xml in BLOB ( we can't
modify the table structure). And we want to get the
specific node value from it. It's our performance
bottleneck.
Something may have to give here. Storing character data, an XML document, in a BLOB column and then trying to parse the XML document is going to be slow. Given your transaction volume, storing the data in a reasonable data type may be necessary to get the sort of performance you need. At a minimum, doing development against a data model that (presumably) everyone agrees is incorrect is going to introduce unnecessary overheads that are likely to be noticable.
If you're storing 100,000 XML documents, you should probably be using XML DB functionality rather than storing data directly in LOBs but if you're going to store the data in LOBs, at least use the right type.
Have you considered using an XML parser to parse the
XML document rather than trying to use SUBSTR and
INSTR?
<Cango> I want to use the XML parser but I
don't find doc about it. Can you provide the detail
of them ? Thanks a lot.You didn't indicate the Oracle version. Assuming you're on 10.2, there are a variety of packages. A quick search on http://tahiti.oracle.com for DBMS_XML turns up a number of packages. DBMS_XMLParser is one option, though it only takes CLOBs, so you'd have to convert everything from a BLOB to a CLOB in real time. DBMS_XMLQuery would be another option (though again you'll be incurring BLOB to CLOB conversion overhead).
That's going to be substantially more efficient.
Have you considered creating an Oracle Text index on
the data?
b]<Cango> I'm trying. Can you give me somesuggestions about it ? thanks.
Are you trying to create a materialized view that
simulates a Text index?
<Cango> Yes.
Reasonable suggestions are likely to begin with getting the data model right. Very little good comes from trying to handle large transaction volumes with incorrect data models.
Justin