on 2021 Apr 22 8:15 PM
SAP IQ Version 16.0, sp11.06 Running On LINUX in simplex mode.
IQ_Main 60% of 2.8 Tb.
Table in question about 360 Gb.
Using Load Table, loading 5.8-5.9 million rows per day to a table with 9 billion plus rows.
No Primary key, but 32 columns, NBit, 21 HG tiered indexes.
Majority of columns are integer, remainder char, nothing greater than 20 chars.
Fresh daily load requires 35-45 minutes, client wanted to know if I could speed this up, so now it gets interesting...
If we delete all the rows from the daily load, commit, then re-run the daily load, requires less than 1 minute??
This is a behaviour I've never noticed, probably because in 25 years of IQ never had the opportunity to test it. A load was a load and you lived with it pretty much unless you needed to juggle configs.
Then I re-tested, same data, this time cycled the server before test, same result, load runs < one minute.
Ran a second test, new data, load time back up to 35-45 minutes.
Question is: Is IQ caching pages for the table based on the deleted rows??
All dbspaces show as pre-allocated as they should...
Has anyone else noticed this behaviour?
Raymond
Hey Mark,
Thanks for the quick response!
Load test pattern example:
Step 1: Load Apr 20 data, new -> 35-45 minutes
Step 2: delete Apr 20 data,
Step 3: reload Apr 20, < 1 minute
Step 4: Load Apr 21 data, new -> 35-45 minutes
definitely pass 2 is the issue, pass 1 completes 5.8 million rows in 10 seconds or less.
No threading issues.
So it seems the HG pages are retained after step 2 and only pass 1 data pages are loaded in step 3
very smart if that is how it works!
I hear ya re: version and HG indexes, it was painful enough getting the client to drop LF and HNG's. Also engaged in updating ASE 15.7 CE to something on the support chain.
Back to IQ, there does not seem to be any magic bullet, it is what it is?
I'll emphasize updating their dev platform to IQ 16 at a minimum.
Raymond
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Are you sure that all HG indexes are tiered?
Here is some piece of code that works in HANA Cloud Data Lake IQ and in IQ 16.1. Run this and check the "tiered" column. Should all be Y.
create or replace procedure sp_iqshowtiered()
begin
declare tiered char(1);
select rtrim(table_name) as 'table_name',rtrim(table_owner) as 'table_owner',rtrim(index_name) as 'index_name',rtrim(column_name) as 'column_name',index_type,unique_index,' ' as tiered_index
into #tier_temp
from sp_iqindex()
where index_type = 'HG' and lower( index_name ) not like '%hotsql%'
and lower( table_name ) not like '%hotsql%'
and lower( table_name ) not like 't_pwd%';
commit;
--create indexes to avoid index advisor
--create unique HG index tier_HG on #tier_temp(table_name, table_owner, index_name);
create HG index index_name_HG on #tier_temp(index_name);
create HG index table_name_HG on #tier_temp(table_name);
create LF index table_owner_LF on #tier_temp(table_owner);
for FORLOOP as FORCRSR dynamic scroll cursor for
select table_name,table_owner,index_name from #tier_temp order by table_name asc,table_owner asc,index_name asc
do
execute immediate 'select (case when substring(value2,1,1)=''N'' then ''Y'' else ''N'' end) into tiered from sp_iqindexmetadata (''' || index_name || ''',''' || table_name || ''',''' || table_owner || ''') where value1 = ''Maintains Exact Distinct'';';
execute immediate 'update #tier_temp set tiered_index = tiered where table_name=''' || table_name || ''' and table_owner=''' || table_owner || ''' and index_name=''' || index_name || ''';'
end for;
--select * from #tier_temp where tiered in ('Y','y');
select table_owner, table_name, index_name, index_type, tiered_index from #tier_temp ;
end;
User | Count |
---|---|
66 | |
8 | |
8 | |
6 | |
6 | |
6 | |
6 | |
6 | |
5 | |
5 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.