So I have added a table to inmemory and have scanned the table after that. But it is still not appearing in V$IM_SEGMENTS. In EXPLAIN PLAN it is showing INMEMORY ACCESS FULL. So not sure if it is using the column store.
Did these:
ALTER TABLE INMEMORY;
SELECT * FROM ;
SELECT * FROM V$IM_SEGMENTS;
no rows
To start with inmemory_size should be around 100M.
Following command should show appropriate size value for parameter inmemory_size:
show parameter inmemory_size
Loading of table segments into inmemory area kicks when there is a full scan on the table or inmemory priority clause is other than none, so we need to be sure the select query you had done went through table access full path.
So, one more way to initiate full table scan is to do select count(*) from table.
Or you can use populate procedure from dbms_inmemory package to load the table manually into inmemory area.
Example usage (for user inmem_user, table t1):
exec dbms_inmemory.populate('INMEM_USER','T1');
One more thing to consider here with respect to querying v$im_segments is; bytes_not_populated and populate_status columns also to be queried for correctness.
When v$im_segments returns rows, bytes_not_populated should be 0 and populate_status should be COMPLETED.
More information about inmemory population can be foune here
Related
I would like to query data from a table, and if a row is locked, show it as a different color. Is this possible using postgresql's locking for update?
e.g.
select
*,
(select from pg_x -- link row somehow )
from table
thank you
There is no good way to do that. The row locks are stored in the row (system column xmax), but this attribute serves other purposes too, and the flags that determine if it is indeed a row lock or perhaps a rolled back update are not exposed via SQL.
There are only unpleasant alternatives:
Use the pageinspect contrib module to examine those flags. That would be a second scan of the table, and such a query doesn't respect MVCC visibility.
Run a second query:
SELECT * FROM atable
FOR UPDATE SKIP LOCKED;
That would lock all rows in the table and be very bad for concurrency.
Besides, that information would be pretty useless for the user. In a well-written application, row locks are only held for split seconds, so the information would be outdated by the time it reaches the user.
I have a table like below :
create table xx (university varchar2(2), sub_uni varchar2(2), id varchar2(30), name varchar2(80))
Which has pk index on university,sub_uni,id
I wanted to perform a quick search on the name column which looked something like below:
select * from xx where upper(name) like upper('%JOHN%')
However as my table contains around 22 million records and the above query does a full table scan it takes around 20-25 seconds.
To optimize the query I now tried to use Oracle Text..
CREATE INDEX xx_name ON xx(name) INDEXTYPE IS CTXSYS.CONTEXT
After the creation of this index the query to filter records takes less than a second
select * from xx where contains(name,'JOHN') > 0
However as I am unable to locate a lot of documentation on oracle text I am worried/concerned about the other impacts of such index.
for eg. On average 5000 rows are added to this table while 10million are updated on daily basis.
Is there any impact of using Oracle Text in such scenario / is there any other way of speeding up this query.
Also I am unable to specify tablespace in the creation of domain index and when I drop it, it doesnt even show up in recyclebin!!!
Thanks in advance.
After enabling In-Memory in Database, I was trying to send a table to I-Memory by using ALTER TABLE EMP INMEMORY;
The Table was altered and then I had executed a simple query to check whether the table is actually altered. My query was as below;
SELECT ENAME, COUNT(*)
FROM EMP
WHERE ENAME='JAMES'
GROUP BY ENAME;
Query executed successfully, but when I execute a statement on V$IM-SEGMENTS, no rows had been selected.
If I'm not mistaken, When a table had moved to ORACLE IN-MEMORY, all segments should have been recorded with V$IM-SEGMENTS. If it is so why does my query does not showing in the v$im-segments?
Can someone help me out on this please?
This is because of the default priority clause "priority none".
The documentation says:
On-demand population
By default, the INMEMORY PRIORITY parameter is set to NONE. In this
case, the database only populates the object when it is accessed
through a full table scan. If the object is never accessed, or if it
is accessed only through an index scan or fetch by rowid, then
population never occurs.
So, in your case you need to do full scan (select query covering all the rows in the table) to induce the population of table into inmemory segments. Following lists the altered steps:
Rem -- Enable table for inmemory
alter table emp inmemory;
Rem -- Perform full scan
select count(*) from emp;
Rem -- Sleep for few seconds
Rem -- This is to ensure segments are fully
Rem -- loaded into inmemory area before
Rem -- query v$im_segments
exec dbms_lock.sleep(30);
Rem -- Now query v$im_segments
select substr(segment_name,1,20), populate_status, bytes_not_populated from v$im_segments;
For my Project Purpose I want to create a table from the data fetched from a view. I am using the basic statement:
CREATE TABLE TABLE_NAME AS (SELECT * FROM VIEW_NAME) ;
The problem is that Around 3 cores of data will be fetched from that view and as the view has joins on many tables and many conditions are applied the performance of the view is bit slow. When I am trying the basic syntax (as mentioned above) after sometime the session is getting timed out and hence it fails. Any alternative way to do this?
an alternative way will be using Postgres Copy option.but you will have to create table schema prior to copy.
so actual query will be
CREATE TABLE yourtable AS (SELECT * FROM view With no Data);Copy select * from view to yourtable;
you can follow the provided link to know advanced options to increase performance of copy command.hope this helps.
Could anyone offer a solution to speed up one of our processes? We have a view used for reporting that is a union all of 10 tables. The view has 180 million rows. We would like to generate a list of the distinct values of individual columns. The current SQL generated by the reporting tool does a select distinct on the view which takes 10 minutes. Preferably the solution would be automatically updated. We have been trying to create a MQT in DB2 udb V8 as a union all, refresh immediate with little success. Any suggestions would be greatly appreciated.
Charles.
There are a lot of restrictions in DB2 8.2 for refresh immediate MQTs, and they can have a significant performance impact on applications that write to the base tables. That said, you may be able to use an MQT. However, instead of using SELECT DISTINCT, try making the query look something like:
select yourcolumn, count(*) as ignore
from union_all_view
group by yourcolumn
The column (yourcolumn) from must be defined as NOT NULL for this to work (in DB2 8.2). The optimizer may not select this MQT if you still issue SELECT DISTINCT against the union all view, so you may need to query the MQT (or a view defined on top of it) directly. Ignore the column "ignore" in the MQT -- that is there only for DB2; if you really don't want to see it, you can create a vew on top of the MQT.
However, this is really a database design issue. Why do you need to scan 180 million rows of data to find the unique values in a particular column? Why don't these values already reside in their own table, with foreign keys defined against it from each of the 10 base tables?