First of all you will need to use DROP_EXISTING = ON while re-creating a Columnstore Index over the Clustered rowstore one.
Do not drop Columnstore Index, it makes no sense. Create a Rowstore index with DROP_EXISTING = ON ordering data on the most frequently used column, and then re-create a Columnstore Index with DROP_EXISTING = ON.

I am facing problem with a simple select query which involves three tables with clustered columnstore index on them. For every 15 mins, there is a ETL load running and one of the three tables gets truncated each time before new rows get inserted. This leaves the rowgroup to be open and query becomes too slow.

It will run fine if I run rebuild index and update stats on tables.
The problem is we are unable to run rebuild index and update stats for every 15 mins. I wanted to know your thoughts on this and if there is anyway this problem can be avoided.

I couldn’t submit my comment on that blog post because of some issues, Can you please help me on below questions ?

As you mentioned in part-38 “I understand that at the moment when we are reading Columnstore data from the disk, it is being read directly into Columnstore Object Pool without decompression, and then all the respective pages from the Segments are decompressed into Buffer Pool for returning the result.” – 1) Does it mean Buffer Pool Extension can store decompressed Columnstore data in SQL Server 2016 Standard edition ?

answering your questions:
1) yes. But avoid Buffer Pool Extension for Columnstore Indexes right now, since it is focused on the OLTP scenarios. All operations are done on the page (8KB) level.
2) There is no way to control that.
3) It will depend on the actual data. The cap is the maximum value, it does not mean that your workload will strive to achieve that.
4) yes, to my understanding.

Hey Niko,
1st Congratulations on all work and knowledge share. Truthfully appreciated.
On a scenario like this:
Sql server 2016 on prem , git(visual studio) with all sql structure (…create tables…) how would i change a normal rowstore create table to a columnstore and have it correctly deploied everytime?
Thank you

Sorry for the delay – you caught me on the vacations.
Using Test or DEV environment, create Clustered Columnstore Index on the table (you might consider using CISL for that) and start experimenting and observing.

I have no such information …
I see it as a bigger decision, which is probably not to be taken any time soon.
DatetimeOffset(4) occupies 9 bytes and this would imply feature support for > 8 bytes, which I believe is not on the highest priority list right now …

Hi Niko!
I’m testing your maintenance solution… But i got one issue… In¿¿On our environment we have partitioned and non partitioned clustered columnstores.. The thing is if I use @usePartitionLevel=1 the script showed an error saying that I cannot use partition clause in a non partitioned index. Since i’m executing this in a UAT environment (because we have real data on that env).. The problem is that if i use @usePartitionLevel=0 I’ll be running the maintenance on the whole partitioned table… So, is this expected? What will be your recommendation here? By the way excellent script!!
Regards!

Your DB size is probably already includes compression, and so I would be careful thinking that the In-Memory will take care of it all. In-Memory is not a solution for the pure memory access, it was designed to tackle locking and latching problems for concurrent access.
Take a very detailed look at the In-Memory limitations before going that way.

Regarding the CCI location, no – I do not think that there are any compelling arguments of choosing In-Memory CCI over CCI just on the base of the memory access. Such limitations as no inter-db access of the In-Memory is a major pain, In-Memory CCI requires you to have a nonclustered PK anyway and there is no compression, plus you won’t be able to use the Archival compression, etc …
Nope.
Choose In-Memory CCI when you are already working with the In-Memory and need to run aggregations in near real-time on it.

Hi Niko,
at the yesterdays PASS in Coblenz you’ve mentioned that you could provide us with a list regarding to “in wich cases which index should be used”.
We would appreciate it, if you’d send us this “checklist”

We don’t have a DW but an OLTP database with some tables over 300M records. In order to use the benefits of SQL2016 batch mode Window Aggregate operator, I tried to add a fake columnstore to the bigger tables
e.g. CREATE NONCLUSTERED COLUMNSTORE INDEX idx_cs_dummy ON dbo.TRADE_BATCH(iBatchNo) WHERE iBatchNo = -1 AND iBatchNo = -2
Suddenly the application became extremely slow, and we had issues with tempdb. Noticed that any user/process attempting to add records to a temp table, it blocks other processes/users.
Once I dropped all the columnstore indexes, everything started running fast, no tempdb blocking.

I read also that you use another tip, using a left join on a dummy table that has a column store
LEFT JOIN dbo.dummyTable ON 1 = 2 — but this requires code changes to every query

Not sure where the problem lies. Maybe you ran into similar situation.

this would require looking at the execution plans.
There are many elements that can potentially go wrong – skewing of the parallelism (often), sorting (because of the memory grants – frequently on Hybrid Systems), etc

Hi Niko,
I attended your session on Worst Practices & Less Known Limitations for Columnstore Indexes at SQLSaturday Vienna in January 2018.
There you mentioned that in order to get rid of the deleted_rows in the segments it is necessary to rebuild the index and reorganize is not enough.
Now I found some Microsoft statements (https://docs.microsoft.com/en-us/sql/relational-databases/indexes/columnstore-indexes-defragmentation?view=sql-server-2017) that starting from SQL Server 2016 also reorganize removes deleted rows.
Am I missing something, or could I now also use reorganize my indexes on a daily basis in order to lower fragmentation?

We have some legacy SSIS packages that use this component so we can analyze Google analytics data and integrate with other data, but have moved them to a new computer and dont have the files to re-setup

just download the archive at https://archive.codeplex.com/?p=analyticssource
and to my understanding it should be there – somewhere in the sources.
Otherwise try reaching out to Tillmann – he should have the executable installer definitely.

Niko, I noticed you’re giving back in the new year 1 hour sessions. That’s a very generous thing for you to do! I was curious if you’d be able to help us with some tips and tricks using ColumnStore indexes. We’ve been migrating off of Sybase IQ for some time now and each database has its challenges, mostly because they shouldn’t have been put on IQ to begin with! We’ve got 140TB IQ database in 1 data space in IQ and looking to migrate it to SQL Server 2017. We thought we’d follow the normal 1 database per year, partitioned by day and make it columnar to compress the best we could. We’ve also got analytics databases that are 40+TB large and looking for help!

Hello Niko,
I work at Mercy Corps, our 5,000+ staff over 40 countries work to alleviate suffering, poverty and oppression by helping people build secure, productive and just communities. https://www.mercycorps.org/about-us

As a resource-constrained non-profit that raises funds for beneficiaries and must be prudent yet innovative with how we spend those dollars, we have to thoughtful about what we choose to invest in.

On our fundraising team, we have a very traditional, Ralph Kimball-based Data Warehouse. We primarily use SSIS, SSRS & SSAS to service and deliver these data assets.

What is the primary use case of ColumnStore over traditional row store?

How could Columnstore help us?

For example, we have fundraising data that we are hesitant to allow to scale because we don’t fully comprehend how to handle those data stores efficiently.

If we have a row store table in the ~110 million row range and we would like to blow it up to a billion rows, could this be a good candidate use case for ColumnStore? Is this even the right question for this technology?

Would we look to ColumnStore to help handle this large table, speed up ETL into and out of it (and updating of it) as well as general queries against it?

We would gather at least 3 people from across our tech team for your 1-hour call. We feel this would greatly help us frame this technology in our current environment and how we could place in the context of future opportunities that we want to go after.
Thank you very much for your consideration and for giving back to the community!

thank you for the contact – I am truly honoured to be of help.
Even though officially the decision will fall in early January 2019, in your case you can definitely start picking the month you prefer to have my hour.

Hi Niko, I want to first thank you for taking up column store as your topic for a deep dive. I’ve read all your blogs on the subject. I am building a mixed use data warehouse that relies heavily on column store for performance.
Your blog has been key to giving me confidence in the technology. As long as there are people experimenting and blogging about it – one has a chance of understanding what’s going on when you start hitting the edge cases.
I come from the world of Oracle databases, including Oracle Exadata, hybrid columnar storage, parallel query performance, compression and etc. I’ve presented many times on topics on memory management, performance and others.

Recently I ran into a problem where a query that typically completes in 45 ms, was taking 8,000+ ms to complete, with the primary culprit being ROWGROUP_VERSION due to a full can on a clustered column store index. I do use snapshot isolation. I couldn’t figure out what’s going on and why we have this wait one day, and not another day. I understand it has to do with transactions – but I don’t understand why nor the exact conditions it would manifest itself.

parallel access (read & write, while using TRICKLE inserts) to the same underlying Row Groups will cause you ROWGROUP_VERSION waits.
Let’s say you are loading one day 1 Million Rows … You might escape seeing the waits …
Next day you will load 100.000 Rows into a SINGLE Row Group (Parallel Insertion splits between the available MAXDOP, and do not forget the actual partitioning, which will cause more splits) – you will see the ROWGROUP_VERSION waits as a result.
Check you Row Group trimming reasons, it would be a great place to start investigating.

Regarding the link to the presentation – that is the submission for the next year 2019 SQLBits edition, so it might be chosen or not.
I will be delivering this session this friday for the Group By online conference, and there will be a recording of it in the next days available on the Youtube, if you can’t attend it live.

Regarding the 1 hour call – I will let you know by the beginning of the year 2019, once I will review all the submissions.

Hi, Niko.
First of all, thank you very much for your blog. It is an invaluable resource for information on columnstore indexes. Please, keep up the great work.

I have a question related to creating a columnstore index on a temp table (regardless local or global).

Question is – are you aware of any specifics of creating a columnstore index on a temp table with regards to waiting for a memory grant?
Specifically, have you ever seen that this operation does not honor the “request_memory_grant_timeout_sec” option of the relevant Resource Governor workload group?

In my case, even though I have increased this option up to 3600 seconds (from the default “0”, which afaik is equivalent to 25 times of a query cost), I am still getting memory timeout exception whenever my “create columnstore index” operation happens to wait for memory grant (RESOURCE_SEMAPHORE wait type) for over 25 seconds.
I am running SQL Server 2016 SP1 no CUs.

I could not find the answer either on internet, or on your blog, although yours is so vast that I might have simply missed it.

can you share more details, such as:
– how many rows do you have in your tables ?
– what are the other RG settings are set to ? (Trying to understand the memory grant throttling here)
– what is the SQL Server version & edition you are running ?

– how many rows do you have in your tables ?
the number of rows in a temp table varies with each run, but whenever the create index operation fails due to memory timeout, the table has a few million rows;
however, despite the table itself has that many rows, the index I am creating is actually a dummy one – I am using a filter condition “WHERE [the_date] = ‘19000101’ AND [the_date] = ‘19000102’”;
essentially, I am creating the columnstore index here just to leverage the Batch execution mode;
on the latest occasion of the memory timeout, the create index operation had the query cost of 146.6 and the requested memory grant of 736MB

– what are the other RG settings are set to ? (Trying to understand the memory grant throttling here)
I only changed the following settings:
ALTER WORKLOAD GROUP [default] WITH( request_memory_grant_timeout_sec = 3600);
ALTER WORKLOAD GROUP [default] WITH( request_max_memory_grant_percent = 8);
all other settings are left as default;
I have 20 CPUs on the box, organized as 4 numa nodes with 5 CPUs each;
I set the “max degree of parallelism” server level setting at 10;

– what is the SQL Server version & edition you are running ?
I am running Enterprise Edition (64-bit) of SQL Server 2016 SP1 with no CUs (13.00.4210 build)

with regards to a repro – unfortunately, I don’t have one right at this point..

the only thing that comes to my mind (besides possible bug) is that your server under extremely heavy workload and there is no memory available at all …
I assume that statistics are in place …
I would try to play with Resource Governor to see if you can guarantee some more resources for your process.
Otherwise you would need to work on the reproduction of the situation or/and contact support.

Niko
Actually you are exactly right – whenever a memory timeout happens, the server indeed is under extremely heavy workload and there is no memory available at all. And there are other concurrent processes (not related to columnstore indexes) that are waiting for their memory grants along with the “create columnstore index” process.
The only problem is that these other processes continue to wait for their memory grants for well over 25 seconds, honoring the “request_memory_grant_timeout_sec” RG setting (which is 3600 seconds, as I set it up).

Yes, I will try to play with the RG settings to maybe further decrease the memory available for a single query.

Niko, a slight correction – just this morning, this memory timeout happened again.
In this case, the global temp table had just 543 records, the create “filtered-dummy” columnstore index operation had the query cost of just 0.2, belonged to the “default” RG workload group (which has 3600 memory grant timeout setting) and the requested memory grant was 376MB.
At the point of the memory timeout, the query has been waiting for memory grant (RESOURCE_SEMAPHORE) for almost exactly 25 seconds.

Hello,
I’m on your workshop on SQL Day 2018 in Poland, Wroclaw. The workshop is about ColumstoreIndex (clustered, nonclastered etc).
I have link to your one drive, but unfortunatelly link expired. It is possible to get your presentation (only pdf/ppt, without data and scripts?).

I am sorry to hear that it took you so long to get to the materials – but nobody should expect that a link for the workshop materials will stay over 10 months.
Can you please contact the SQLDay event organizers and ask them to share the materials?

I attended your course at SQL Bits “Optimising ETL on Microsoft Data Platform (SQL & Azure)”. Are you able to forward the slides for the day please? The day was fantastic and I want to make sure I missed nothing.

I also attended your precon Optimising ETL at SQL Bits 2019, and have been struggling to get hold of the materials from SQL Bits organisers.
Please could you email me the materials? I’d be most grateful.

most probably your data ended landing in the Tail Row Group (aka In-Memory Delta-Store).
Try to force the compression of it with the sys.sp_memory_optimized_cs_migration procedure while monitoring the status of all the Row Groups with the help of the CISL or the sys.columnn_store_row_groups.

We have a true puzzler. Non deterministic failure on an update to a Clustered Columnstore Index.

(Firstly I apologise for not constructing a repro… when we try to synthesise the error we cannot ever get the failure.)

We have a very (Very) wide CCI. With a set of source data, an update statement covering 100+ columns. It fails on a particular set of source data, with an “exceeds 8060 bytes” error. I paraphrase – I don’t have the exact error text to hand.

So then, playing elimination, we only update half the original 100 columns. It succeeds.

Then we run the original update again, with all the columns. It succeeds.

So, non deterministic.

Fails with all the columns.
Succeeds with few columns.
Succeeds with all the columns.

Ever heard of 8060 byte failures in a CCI update?

(I know a lot more detail may be needed here, and I will try to get a repro…. just chucking this out there for starters)

this sounds like a problem of the Sql Server 2014.
Delta-Stores in SQL 2014 were page-compressed and that would cause the errors of the 8064 bytes.
In Sql Server 2016 Delta-Stores were changed to NO compression specifically to allow wide tables to function correctly.

Hello Niko, when deploying DDL changes for a columnstore table with a DACPAC onto an existing database using sqlpackage.exe or Visual Studio (it is really just VS calling sqlpackage.exe for you), the deployment process seems odd.

Watching the deployment output you can see it go through these steps:
1. Drop the columnstore index. This results is the database size increasing a lot as the table is convert to a rowstore.
2. Alter the table
3. Apply the columnstore index again. The database size then shrinks as the table is converted back to a columnstore.

This yoyoing of the database size coupled with the long deployment times as the database goes through all that IO is annoying. Do you know why it wants to go through this process?

I just finished deploying a change to one fact table with ~30 million rows and it took an hour with 8 vCores. Microsoft claims that should have 4000 IOPS screaming away during the deployment. Any thoughts, not that we can change much about this process?

I do not have much to say about the DacPac deployments …
The found solution is the easy one, not the correct one.
DacPacs ARE oriented/thought/implemented for smaller DBs, not for the real production heavyweights.
*cough* Besides that sometimes the implemented solution is to drop and recreate table … *cough*
Manual optimisations are the key …
“Devops” optimisations are beautiful and wonderful, if you have a tool that will do the needed job. I have seen it work in small and non-critical installations.
Yeah “Devops” is not Devops.

Our stage table holds 130 + columns with 1 billion 430 million rows with partition with service date. we created non clustered column store index, it took 36 hours for its completion. after creating the index the select count_big(col_name) from table shows 40 billion as row count, we tested this by sp_space used, sys.indexex table, right click and properties the table all shows the 1 billion 430 million rows. Before index creation also we count the table after 45 minutes execution it says the 1 billion 430 million. estimated number of rows in non clustered column store also shows 1 billion 430 million rows, but count shows very strange result. Niko do you have any thought on this?

Actual rows in the table matches with plan's estimated number of rows, but after executing the below query the count will be 40145305259. I also ran the query with group by clause below are the split-ups with index and without index

without index it took 1 hour 13 minutes, with index it took 5 minutes. The table is a stage table with 135 + columns partitioned with date. we tested with sp_space used it gives the without index row count details, table properties it also gave the without index number, queries from sys.indxes also gave the same number. Kindly share your thoughts. I created a clustered index on top of non clustered columnstore for a memberid column after 1 hours we faced disk space issue with error

Could not allocate space for object 'dbo.SORT temporary run storage: 140746840342528' in database 'XXX' because the 'XXXX_Sx_TBL_xx_5' filegroup is full. Create disk space by deleting unneeded files, dropping objects in the filegroup, adding additional files to the filegroup, or setting autogrowth on for existing files in the filegroup. [SQLSTATE 42000] (Error 1105) The statement has been terminated. [SQLSTATE 01000] (Error 3621). The step failed.