Skip to Main Content
  • Questions
  • Refresh materialized view with text indexes

Breadcrumb

Question and Answer

Connor McDonald

Thanks for the question, Saurabh.

Asked: April 21, 2023 - 5:29 am UTC

Last updated: May 01, 2023 - 3:19 pm UTC

Version: 19C

Viewed 1000+ times

You Asked

I have a base table on which a materialized view with "Refresh fast on commit" is built and on materialized view I have an oracle text search domain index with "sync on commit". As per the documentation
Synchronizes the index immediately after a commit transaction. The commit transaction does not return until the sync is complete. Before Oracle Database Release 18c, the synchronization was performed as a separate transaction. There was a time period, usually small, when the data was committed but index changes were not. Starting with Oracle Database Release 18c, the synchronization is performed as part of the same transaction.

1. This is causing the session blocking as index syncing is taking a bit of time. Is there a way we can change the index syncing to be an asynchronous process and independent of the base table transaction?
2. Does the materialize view refresh on commit also happens as part of the base table transaction? can it be done independently and asynchronously in a new transaction?
3. What is the role of memory parameter in oracle text search index?

and Chris said...

1. You can change the sync clause:

SYNC (MANUAL | EVERY "interval-string" | ON COMMIT)


https://docs.oracle.com/en/database/oracle/oracle-database/19/ccref/oracle-text-SQL-statements-and-operators.html#GUID-46981A92-A7F3-4431-AEDB-7E4F0C5FC862

2. If the MV is ON COMMIT, then the database updates the MV whenever you commit a transaction that changes any of its base tables.

You can change this to be manual or scheduled refresh

https://docs.oracle.com/en/database/oracle/oracle-database/19/dwhsg/refreshing-materialized-views.html

3. Which parameter are you referring to specifically?

Rating

  (2 ratings)

Is this answer out of date? If it is, please let us know via a Comment

Comments

A reader, April 28, 2023 - 5:12 am UTC

I was referring to this memory parameter:
CREATE INDEX doc_idx on docs(document) indextype is ctxsys.context
FILTER BY category, author
ORDER BY pub_date desc, docid
PARAMETERS ('memory 500M');
I have kind of figured out the problem in my case. My MV has three cols viz. Record_ID (base table record id), ROW_ID(base table record's row id) and Version(an incrementing integer value). The index is built on Version col.
Suppose my MV has a record (Record_id =123, Row_id= ABC123, Version=1) and this record is already synced in the index. If I am creating a new record in my base table, the mv is doing a delete insert for the record_id = 123 thus triggering the re-syncing of record_id 123. Just to add my base table is partitioned and has row movement enabled. I thought the row movement might be causing this reinsert for record_id 123 but the rowid after reinsert for the record is still ABC123 which means the row is not moved. I failed to understand why MV is doing a delete and insert for an existing refreshed record.


Chris Saxon
April 28, 2023 - 10:14 am UTC

Glad you figured it out.

As the docs say about MEMORY:

The memsize parameter specifies the amount of memory Oracle Text uses for indexing before flushing the index to disk. Specifying a large amount memory improves indexing performance because there are fewer I/O operations and improves query performance and maintenance, because there is less fragmentation.

Specifying smaller amounts of memory increases disk I/O and index fragmentation, but might be useful when run-time memory is scarce.

A reader, April 28, 2023 - 3:09 pm UTC

Could you please let me know why the MV is doing a delete insert for an existing record whenever a record is created in the base table.
Connor McDonald
May 01, 2023 - 3:19 pm UTC

Not sure what you mean.

I *suspect* you're referring to the refresh, which is handling everything that *might* be in the MV log. That *could* be deletes, it *could* be updates as well as inserts.

Hence the operations we do.

More to Explore

Design

New to good database design? Check out Chris Saxon's full fundamentals class.