I have built materialized view on external table that have some billion rows. When i run command
show materialized views it is showing 0 in rows columns.
When i run the select query with limit on "MV" it returns some rows select * from MV_TABLE limit 3
But If i run simple command of select count(*) it is running unending. How can i know whether materilized views holds data or it is giving result from external table on fly. ?
The same problem has been stated here: https://community.snowflake.com/s/article/Why-is-the-row-count-reported-by-SHOW-MATERIALIZED-VIEWS-command-not-updated-when-I-insert-new-rows-to-the-source-table
Reason according to the above link is that the results of SHOW MATERIALIZED VIEWS are based on the data files of the materialized view and changes to the base table are not immediately merged there. This could be the reason for the discrepancy.
If you try to run SHOW MATERIALIZED VIEWS in a few minutes again, the question is, whether it is still returning 0 rows.
Related
I have created a view that returns data from more than one table using join. When I select from that view without using Order By clause, the time taken to execute that query is only about 1 second or less. But when I use order by with my select query, it takes about 27 seconds to return only the top(15) records from that view.
Here is my query that I run To get data from View
SELECT TOP(15) *
FROM V_transaction
ORDER BY time_stamp DESC
Note : total number of records that view has is about 300000
What can I change in my view's design to get better performance?
First thing that pops into mind is creating an index on time_stamp in the view. If you don't want to/can't create an indexed view you could create an index on the column in the underlying table that you are getting that value from. This should increase your queries performance.
If you are still having issues post the execution plan - this should show you exactly where/why your query is experiencing performance problems.
Why don't you create an extra column which stores the numbers of days + number of seconds for a each date record and then order by that column..
I've a Cognos report in which I've cascading prompts. The Hierarchy is defined in the image attached.
The First Parent (Division) fills the two cascading child in 3-5 seconds.
But when I select any Policy, (that will populate the two child beneath) it took around 2 minutes.
Facts:
The result set after two minutes is normal (~20 rows)
The Queries behind all the prompts are simple Select DISTINCT Col_Name
Ive created indexes on all the prompt columns.
Tried turning on the local cache and Execution Method to concurrent.
I'm on Cognos Report Studio 10.1
Any help would be much appreciated.
Thanks,
Nuh
There is an alternative to a one-off dimension table. Create a Query Subject in Framework for your AL-No prompt. In the query itself, build a query that gets distinct AL-No (you said that is fast, probably because there is an index on AL-No). Wrap that in a select that does a filter on ' #prompt('pPolicy')#' (assuming your Policy Prompt is keyed to ?pPolicy?)
This will force the Policy into the sql before it is sent to the database, but wrapping on the distinct AL-No will allow you to use the AL-No index.
select AL_NO from
(
select AL_NO, Policy_NO
from CLAIMS
group by AL_NO, Policy_NO
)
where Policy_NO = #prompt('pPolicyNo')#
Your issue is just too much table scanning. Typically, one would build a prompt page from dimension-based tables, not the fact table, though I admit that is not always possible with cascading prompts. The ideal solution is to create a one-off dimension table with these distinct values, then model that strictly for the prompts.
Watch out for indexing each field, as the indexes will not be used due to the selectivity of the values. A compound index of the fields may work instead. As with any time you are making changes to the DDL - open SQL profiler and see what SQL Cognos is generating, then run an explain plan before/after the changes.
Can someone explain to me what views or materialized views are in plain everyday English please? I've been reading about materialized views but I don't understand.
Sure.
A normal view is a query that defines a virtual table -- you don't actually have the data sitting in the table, you create it on the fly by executing.
A materialized view is a view where the query gets run and the data gets saved in an actual table.
The data in the materialized view gets refreshed when you tell it to.
A couple use cases:
We have multiple Oracle instances where we want to have the master data on one instance, and a reasonably current copy of the data on the other instances. We don't want to assume that the database links between them will always be up and operating. So we set up materialized views on the other instances, with queries like select a,b,c from mytable#master and tell them to refresh daily.
Materialized views are also useful in query rewrite. Let's say you have a fact table in a data warehouse with every book ever borrowed from a library, with dates and borrowers. And that staff regularly want to know how many times a book has been borrowed. Then build a materialized view as select book_id, book_name, count(*) as borrowings from book_trans group by book_id, book_name, set it for whatever update frequency you want -- usually the update frequency for the warehouse itself. Now if somebody runs a query like that for a particular book against the book_trans table, the query rewrite capability in Oracle will be smart enough to look at the materialized view rather than walking through the millions of rows in book_trans.
Usually, you're building materialized views for performance and stability reasons -- flaky networks, or doing long queries off hours.
A view is basically a "named" SQL statement. You can reference views in your queries much like a real table. When accessing the view, the query behind the view is executed.
For example:
create view my_counter_view(num_rows) as
select count(*)
from gazillion_row_table;
select num_rows from my_counter_view;
Views can be used for many purposes such as providing a simpler data model, implement security constraints, SQL query re-use, workaround for SQL short comings.
A materialized view is a view where the query has been executed and the results has been stored as a physical table. You can reference a materialized view in your code much like a real table. In fact, it is a real table that you can index, declare constraints etc.
When accessing a materialized view, you are accessing the pre-computed results. You are NOT executing the underlaying query. There are several strategies for how to keeping the materialized view up-to-date. You will find them all in the documentation.
Materialized views are rarely referenced directly in queries. The point is to let the optimizer use "Query Rewrite" mechanics to internally rewrite a query such as the COUNT(*) example above to a query on the precomputed table. This is extremely powerful as you don't need to change the original code.
There are many uses for materialied views, but they are mostly used for performance reasons. Other uses are: Replication, complicated constraint checking, workarounds for deficiencies in the optimizer.
Long version: -> Oracle documentation
A view is a query on one or more tables. A view can be used just like a table to select from or to join with other tables or views. A metrialized view is a view that has been fully evaluated and its rows have been stored in memory or on disk. Therefore each time you select from a materialized view, there is no need to perform the query that produces the view and the results are returned instantly.
For example, a view may be a query such as SELECT account, SUM(payment) FROM payments GROUP BY account with a large number of payments in the table but not many accounts. Each time this view is used the whole table must be read. With a materialized view, the result is returned instantly.
The non-trivial issue with materialized views is to update them when the underlying data is changed. In this example, each time a new row is added to the payments table, the row in the materialized view that represents the account needs to be updated. These updates may happen synchronously or periodically.
Yes. Materialized views are views with a base table underneath them. You define the view and Oracle creates the base table underneath it automatically.
By executing the view and placing the resulting data in the base table you gain performance.
They are useful for a variety of reasons. Some examples of why you would use a materialized view are:
1) A view that is complex may take a long time to execute when referenced
2) A view included in complex SQL may yield poor execution plans leading to performance issues
3) You might need to reference data across a slow DBLINK
A materialized view can be setup to refresh periodically.
You can specify a full or partial refresh.
Please see the Oracle documentation for complete information
Is there a way to fetch 4 million records from SQL Server 2005 in under 60 seconds?
My table consists of 15 columns. Each has datatype of varchar(100) and there is no primary key.
Assuming you want the entire contents of the table then try this first:
SELECT col1, col2, ... col15 FROM your_table
If that is too slow then there's not really anything more you can do apart from change your program design so that it is not necessary to fetch so many rows at once.
If this records will be displayed in a graphical user interface you could consider using paging instead of fetching all the rows at once.
Actually last time I did something like this, i put a filter dropdown and then the records would be filtered using the filter user selects. I also give the option "All" in the dropdown selecting which I show the user a message like "Retrieving all records will be bit slow. Want to continue?". And in any case, as Mark suggested, I used paging .
I have a select query to retrieve data from tables. It is working fine, but when there's a condition to select some 3 values, it is not giving a result. Error message;
Query processor ran out of Internal resources
I looked through INDEX seems to work fine, then I created view with that select statement, but couldn't create an index. Error message;
View is not schema bound
In order to create an indexed view the view needs to be schema bound to the entities that it is a view over.
To make a view schema bound, simply specify simply use WITH SCHEMABINDING in the view CREATE / UPDATE query, for example:
CREATE VIEW MyView
WITH SCHEMABINDING
AS
-- SELECT
See this link for more information on schema binding, or the MSDN page on the CREATE VIEW statement.
However from what you have said I don't think the indexed view will necessarily help you - the message "Query processor ran out of Internal resources" means that the query processor failed to produce an execution plan for your query, which I would guess only happens with extremely complex queries.
You should try to reduce the complexity of your query somehow.
I would guess that you are trying to create the index on the view instead of the underlying tables. if you truly need to index the view it must meet these criteria:
http://technet.microsoft.com/en-us/library/cc917715.aspx