Why Sort operation on clustered columstore index insert?

Looking at the execution plan for a clustered columnstore index insert I noticed a Sort operation. My T-SQL has no sort and I understand that the clustered columnstore is not a sorted index. Why would there be a Sort operation in the execution plan?
This is running on:
Microsoft SQL Server 2014 - 12.0.2000.8 (X64)
Feb 20 2014 20:04:26
Copyright (c) Microsoft Corporation
Enterprise Edition: Core-based Licensing (64-bit) on Windows NT 6.3 <X64> (Build 9600: ) (Hypervisor)

Hello,
It's because how a columnstore index works: The index is created & compressed on column Level, not on row level. SQL Server orders the data to have the same data after each other to calculate the compressed index values.
Olaf Helper
[ Blog] [ Xing] [ MVP]

Similar Messages

Sort Operation in Collections

Hi All,
Can any one please explain where and why SORT operation will performed while executing below code?
PROCEDURE process_all_rows
IS
TYPE employees_aat IS TABLE OF employees%ROWTYPE INDEX BY PLS_INTEGER;
l_employees employees_aat;
BEGIN
SELECT * BULK COLLECT INTO l_employees FROM employees;
FOR index IN 1 .. l_employees.COUNT
LOOP
analyze_compensation
(l_employees(indx));
END LOOP;
END process_all_rows;
The code from below link:
http://www.oracle.com/technetwork/issue-archive/2008/08-mar/o28plsql-095155.html
Thanks in advance.

Red Penyon wrote:
An associative array (formerly called PL/SQL table or index-by table) is a set of key-value pairs. Each key is a unique index, used to locate the associated value with the syntax variable_name(index).
The data type of index can be either a string type or PLS_INTEGER. Indexes are stored in sort order, not creation order. For string types, sort order is determined by the initialization parameters NLS_SORT and NLS_COMP.So then associative arrays with name-value pairs where the name is numeric, are not sorted? Why would an associative array indexed by number not be sorted?

When table with clustered columnstore indexe is partitioned the performance degrades if data is located in multiple partitions

Hello,
Below I provide a complete code to re-produce the behavior I am observing. You could run it in tempdb or any other database, which is not important. The test query provided at the top of the script is pretty silly, but I have observed the same
performance degradation with about a dozen of various queries of different complexity, so this is just the simplest one I am using as an example here. Note that I also included approximate run times in the script comments (this is obviously based on what I
observed on my machine). Here are the steps with numbers corresponding to the numbers in the script:
1. Run script from #1 to #7. This will create the two test tables, populate them with records (40 mln. and 10 mln.) and build regular clustered indexes.
2. Run test query (at the top of the script). Here are the execution statistics:
Table 'Main'. Scan count 5, logical reads 151435, physical reads 0, read-ahead reads 4, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'Txns'. Scan count 5, logical reads 74155, physical reads 0, read-ahead reads 7, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'Workfile'. Scan count 0, logical reads 0, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'Worktable'. Scan count 0, logical reads 0, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
SQL Server Execution Times:
   CPU time = 5514 ms,
elapsed time = 1389 ms.
3. Run script from #8 to #9. This will replace regular clustered indexes with columnstore clustered indexes.
4. Run test query (at the top of the script). Here are the execution statistics:
Table 'Txns'. Scan count 4, logical reads 44563, physical reads 0, read-ahead reads 37186, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'Main'. Scan count 4, logical reads 54850, physical reads 2, read-ahead reads 96862, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'Worktable'. Scan count 0, logical reads 0, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'Workfile'. Scan count 0, logical reads 0, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
SQL Server Execution Times:
   CPU time = 828 ms,
elapsed time = 392 ms.
As you can see the query is clearly faster. Yay for columnstore indexes!.. But let's continue.
5. Run script from #10 to #12 (note that this might take some time to execute). This will move about 80% of the data in both tables to a different partition. You should be able to see the fact that the data has been moved when running Step #
11.
6. Run test query (at the top of the script). Here are the execution statistics:
Table 'Txns'. Scan count 4, logical reads 44563, physical reads 0, read-ahead reads 37186, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'Main'. Scan count 4, logical reads 54817, physical reads 2, read-ahead reads 96862, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'Worktable'. Scan count 0, logical reads 0, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'Workfile'. Scan count 0, logical reads 0, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
SQL Server Execution Times:
   CPU time = 8172 ms,
elapsed time = 3119 ms.
And now look, the I/O stats look the same as before, but the performance is the slowest of all our tries!
I am not going to paste here execution plans or the detailed properties for each of the operators. They show up as expected -- column store index scan, parallel/partitioned = true, both estimated and actual number of rows is less than during the second
run (when all of the data resided on the same partition).
So the question is: why is it slower?
Thank you for any help!
Here is the code to re-produce this:
--==> Test Query - begin --<===
DBCC DROPCLEANBUFFERS
DBCC FREEPROCCACHE
SET STATISTICS IO ON
SET STATISTICS TIME ON
SELECT COUNT(1)
FROM Txns AS z WITH(NOLOCK)
LEFT JOIN Main AS mmm WITH(NOLOCK) ON mmm.ColBatchID = 70 AND z.TxnID = mmm.TxnID AND mmm.RecordStatus = 1
WHERE z.RecordStatus = 1
--==> Test Query - end --<===
--===========================================================
--1. Clean-up
IF OBJECT_ID('Txns') IS NOT NULL DROP TABLE Txns
IF OBJECT_ID('Main') IS NOT NULL DROP TABLE Main
IF EXISTS (SELECT 1 FROM sys.partition_schemes WHERE name = 'PS_Scheme') DROP PARTITION SCHEME PS_Scheme
IF EXISTS (SELECT 1 FROM sys.partition_functions WHERE name = 'PF_Func') DROP PARTITION FUNCTION PF_Func
--2. Create partition funciton
CREATE PARTITION FUNCTION PF_Func(tinyint) AS RANGE LEFT FOR VALUES (1, 2, 3)
--3. Partition scheme
CREATE PARTITION SCHEME PS_Scheme AS PARTITION PF_Func ALL TO ([PRIMARY])
--4. Create Main table
CREATE TABLE dbo.Main(
SetID int NOT NULL,
SubSetID int NOT NULL,
TxnID int NOT NULL,
ColBatchID int NOT NULL,
ColMadeId int NOT NULL,
RecordStatus tinyint NOT NULL DEFAULT ((1))
) ON PS_Scheme(RecordStatus)
--5. Create Txns table
CREATE TABLE dbo.Txns(
TxnID int IDENTITY(1,1) NOT NULL,
GroupID int NULL,
SiteID int NULL,
Period datetime NULL,
Amount money NULL,
CreateDate datetime NULL,
Descr varchar(50) NULL,
RecordStatus tinyint NOT NULL DEFAULT ((1))
) ON PS_Scheme(RecordStatus)
--6. Populate data (credit to Jeff Moden: http://www.sqlservercentral.com/articles/Data+Generation/87901/)
-- 40 mln. rows - approx. 4 min
--6.1 Populate Main table
DECLARE @NumberOfRows INT = 40000000
INSERT INTO Main (
SetID,
SubSetID,
TxnID,
ColBatchID,
ColMadeID,
RecordStatus)
SELECT TOP (@NumberOfRows)
SetID = ABS(CHECKSUM(NEWID())) % 500 + 1, -- ABS(CHECKSUM(NEWID())) % @Range + @StartValue,
SubSetID = ABS(CHECKSUM(NEWID())) % 3 + 1,
TxnID = ABS(CHECKSUM(NEWID())) % 1000000 + 1,
ColBatchId = ABS(CHECKSUM(NEWID())) % 100 + 1,
ColMadeID = ABS(CHECKSUM(NEWID())) % 500000 + 1,
RecordStatus = 1
FROM sys.all_columns ac1
CROSS JOIN sys.all_columns ac2
--6.2 Populate Txns table
-- 10 mln. rows - approx. 1 min
SET @NumberOfRows = 10000000
INSERT INTO Txns (
GroupID,
SiteID,
Period,
Amount,
CreateDate,
Descr,
RecordStatus)
SELECT TOP (@NumberOfRows)
GroupID = ABS(CHECKSUM(NEWID())) % 5 + 1, -- ABS(CHECKSUM(NEWID())) % @Range + @StartValue,
SiteID = ABS(CHECKSUM(NEWID())) % 56 + 1,
Period = DATEADD(dd,ABS(CHECKSUM(NEWID())) % 365, '05-04-2012'), -- DATEADD(dd,ABS(CHECKSUM(NEWID())) % @Days, @StartDate)
Amount = CAST(RAND(CHECKSUM(NEWID())) * 250000 + 1 AS MONEY),
CreateDate = DATEADD(dd,ABS(CHECKSUM(NEWID())) % 365, '05-04-2012'),
Descr = REPLICATE(CHAR(65 + ABS(CHECKSUM(NEWID())) % 26), ABS(CHECKSUM(NEWID())) % 20),
RecordStatus = 1
FROM sys.all_columns ac1
CROSS JOIN sys.all_columns ac2
--7. Add PK's
-- 1 min
ALTER TABLE Txns ADD CONSTRAINT PK_Txns PRIMARY KEY CLUSTERED (RecordStatus ASC, TxnID ASC) ON PS_Scheme(RecordStatus)
CREATE CLUSTERED INDEX CDX_Main ON Main(RecordStatus ASC, SetID ASC, SubSetId ASC, TxnID ASC) ON PS_Scheme(RecordStatus)
--==> Run test Query --<===
--===========================================================
-- Replace regular indexes with clustered columnstore indexes
--===========================================================
--8. Drop existing indexes
ALTER TABLE Txns DROP CONSTRAINT PK_Txns
DROP INDEX Main.CDX_Main
--9. Create clustered columnstore indexes (on partition scheme!)
-- 1 min
CREATE CLUSTERED COLUMNSTORE INDEX PK_Txns ON Txns ON PS_Scheme(RecordStatus)
CREATE CLUSTERED COLUMNSTORE INDEX CDX_Main ON Main ON PS_Scheme(RecordStatus)
--==> Run test Query --<===
--===========================================================
-- Move about 80% the data into a different partition
--===========================================================
--10. Update "RecordStatus", so that data is moved to a different partition
-- 14 min (32002557 row(s) affected)
UPDATE Main
SET RecordStatus = 2
WHERE TxnID < 800000 -- range of values is from 1 to 1 mln.
-- 4.5 min (7999999 row(s) affected)
UPDATE Txns
SET RecordStatus = 2
WHERE TxnID < 8000000 -- range of values is from 1 to 10 mln.
--11. Check data distribution
SELECT
OBJECT_NAME(SI.object_id) AS PartitionedTable
, DS.name AS PartitionScheme
, SI.name AS IdxName
, SI.index_id
, SP.partition_number
, SP.rows
FROM sys.indexes AS SI WITH (NOLOCK)
JOIN sys.data_spaces AS DS WITH (NOLOCK)
ON DS.data_space_id = SI.data_space_id
JOIN sys.partitions AS SP WITH (NOLOCK)
ON SP.object_id = SI.object_id
AND SP.index_id = SI.index_id
WHERE DS.type = 'PS'
AND OBJECT_NAME(SI.object_id) IN ('Main', 'Txns')
ORDER BY 1, 2, 3, 4, 5;
PartitionedTable PartitionScheme IdxName index_id partition_number rows
Main PS_Scheme CDX_Main 1 1 7997443
Main PS_Scheme CDX_Main 1 2 32002557
Main PS_Scheme CDX_Main 1 3 0
Main PS_Scheme CDX_Main 1 4 0
Txns PS_Scheme PK_Txns 1 1 2000001
Txns PS_Scheme PK_Txns 1 2 7999999
Txns PS_Scheme PK_Txns 1 3 0
Txns PS_Scheme PK_Txns 1 4 0
--12. Update statistics
EXEC sys.sp_updatestats
--==> Run test Query --<===

Hello Michael,
I just simulated the situation and got the same results as in your description. However, I did one more test - I rebuilt the two columnstore indexes after the update (and test run). I got the following details:
Table 'Txns'. Scan count 8, logical reads 12922, physical reads 1, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'Main'. Scan count 8, logical reads 57042, physical reads 1, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'Worktable'. Scan count 0, logical reads 0, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'Workfile'. Scan count 0, logical reads 0, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'Worktable'. Scan count 0, logical reads 0, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
SQL Server Execution Times:
CPU time = 251 ms, elapsed time = 128 ms.
As an explanation of the behavior - because of the UPDATE statement in CCI is executed as a DELETE and INSERT operation, you had all original row groups of the index with almost all data deleted and almost the same amount of new row groups with new data
(coming from the update). I suppose scanning the deleted bitmap caused the additional slowness at your end or something related with that "fragmentation".
Ivan Donev MCITP SQL Server 2008 DBA, DB Developer, BI Developer

Confusion in FILTER and SORT operations in the execution plan

Hi
I have been working on tuning of a sql query:
SELECT SUM(DECODE(CR_FLG, 'C', NVL(TOT_AMT, 0), 0)),
       SUM(DECODE(CR_FLG, 'C', 1, 0)),
       SUM(DECODE(CR_FLG, 'R', NVL(TOT_AMT, 0), 0)),
       SUM(DECODE(CR_FLG, 'R', 1, 0)),
       SUM(DECODE(CR_FLG, 'C', NVL(TOT_AMT, 0), -1 * NVL(TOT_AMT, 0))),
       SUM(1)
     FROM TS_TEST
    WHERE SMY_DT BETWEEN TO_DATE(:1, 'DD-MM-YYYY') AND
       TO_DATE(:1, 'DD-MM-YYYY');Table TS_TEST is range partitioned on smy_dt and there is an index on smy_dt column. Explain plan of the query is:
SQL> explain plan for SELECT SUM(DECODE(CR_FLG, 'C', NVL(TOT_AMT, 0), 0)),
2         SUM(DECODE(CR_FLG, 'C', 1, 0)),
3         SUM(DECODE(CR_FLG, 'R', NVL(TOT_AMT, 0), 0)),
4         SUM(DECODE(CR_FLG, 'R', 1, 0)),
5         SUM(DECODE(CR_FLG, 'C', NVL(TOT_AMT, 0), -1 * NVL(TOT_AMT, 0))),
6         SUM(1)
7    FROM TS_TEST
8   WHERE SMY_DT BETWEEN TO_DATE(:1, 'DD-MM-YYYY') AND
9         TO_DATE(:1, 'DD-MM-YYYY');
Explained.
SQL> @E
PLAN_TABLE_OUTPUT
Plan hash value: 766961720
| Id | Operation                            | Name                | Rows | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
|   0 | SELECT STATEMENT                     |                     |     1 |    14 | 15614   (1)| 00:03:08 |       |       |
|   1 | SORT AGGREGATE                      |                     |     1 |    14 |            |             |       |       |
|* 2 |   FILTER                             |                     |       |       |            |          |       |       |
|   3 |    TABLE ACCESS BY GLOBAL INDEX ROWID| T_TEST             | 79772 | 1090K| 15614   (1)| 00:03:08 | ROWID | ROWID |
|* 4 |     INDEX RANGE SCAN                 | I_SMY_DT         |   143K|       |   442   (1)| 00:00:06 |       |       |
Predicate Information (identified by operation id):
   2 - filter(TO_DATE(:1,'DD-MM-YYYY')<=TO_DATE(:1,'DD-MM-YYYY'))
   4 - access("SMY_DT">=TO_DATE(:1,'DD-MM-YYYY') AND "SMY_DT"<=TO_DATE(:1,'DD-MM-YYYY'))
17 rows selected.
SQL>I am not able to understand the FILTER & SORT operations. As there is an index on SMY_DT column, so index range scan is fine. But why a FILTER (Step no 2) and SORT (Step no 1) operation after that ?
Oracle version is 10.2.0.3 on AIX 5.3 64 bit.
Any other information required please let me know.
Regards,
Amardeep Sidhu

Sort aggregate tells you that there was performed an aggregate operation which returns one row, in opposite to sort order by or hash group by which indicates you have grouping, and there more than one row can be returned.
SQL> SELECT SUM(comm) FROM emp;
SUM(COMM)
      2200
Plan wykonywania
Plan hash value: 2083865914
| Id | Operation          | Name | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT   |      |     1 |     2 |     3   (0)| 00:00:01 |
|   1 | SORT AGGREGATE    |      |     1 |     2 |            |          |
|   2 |   TABLE ACCESS FULL| EMP |    14 |    28 |     3   (0)| 00:00:01 |
SQL> SELECT AVG(comm) FROM emp;
AVG(COMM)
       550
Plan wykonywania
Plan hash value: 2083865914
| Id | Operation          | Name | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT   |      |     1 |     2 |     3   (0)| 00:00:01 |
|   1 | SORT AGGREGATE    |      |     1 |     2 |            |          |
|   2 |   TABLE ACCESS FULL| EMP |    14 |    28 |     3   (0)| 00:00:01 |
SQL> SELECT MIN(comm) FROM emp;
MIN(COMM)
         0
Plan wykonywania
Plan hash value: 2083865914
| Id | Operation          | Name | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT   |      |     1 |     2 |     3   (0)| 00:00:01 |
|   1 | SORT AGGREGATE    |      |     1 |     2 |            |          |
|   2 |   TABLE ACCESS FULL| EMP |    14 |    28 |     3   (0)| 00:00:01 |
SQL> SELECT deptno, SUM(comm) FROM emp GROUP BY deptno;
    DEPTNO SUM(COMM)
        30       2200
        20
        10
Plan wykonywania
Plan hash value: 4067220884
| Id | Operation          | Name | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT   |      |     3 |    15 |     4 (25)| 00:00:01 |
|   1 | HASH GROUP BY     |      |     3 |    15 |     4 (25)| 00:00:01 |
|   2 |   TABLE ACCESS FULL| EMP |    14 |    70 |     3   (0)| 00:00:01 |
SQL>Edited by: Łukasz Mastalerz on Jan 14, 2009 11:41 AM

Double WINDOW SORT Operation

Please review following SQL and it's execution plan. Why am I seeing 2 WINDOW SORT operations even though in sql . analytic function "row_number" has been used only once?
Also, In step 3 of the plan, why "bytes" goes from 35 GB(4th step) to 88GB when row count remains the same. In fact , since I'm selecting just 1st row , both row count as well as "bytes" should have gone down. Shouldn't it?
SELECT orddtl.ord_dtl_key, orddtl.ld_nbr, orddtl.actv_flg,
         orddtl.ord_nbr
     FROM (SELECT /*+ parallel(od, 8) parallel(sc,8) */ od.ord_dtl_key, od.ld_nbr, od.actv_flg,
                  od.ord_nbr,
                  ROW_NUMBER () OVER (PARTITION BY od.ord_dtl_key, od.START_TS ORDER BY sc.START_TS DESC)
                                                                      rownbr
             FROM edw.order_detail od LEFT OUTER JOIN edw.srvc_code sc
                  ON (    sc.srvc_cd_key = od.srvc_cd_key
                      AND od.part_nbr = sc.part_nbr
                      AND od.item_cre_dt >= sc.START_TS
                      AND od.item_cre_dt < sc.END_TS
            WHERE od.part_nbr = 11 ) orddtl
    WHERE orddtl.rownbr = 1;Execution Plan
| Id | Operation                      | Name              | Rows | Bytes |TempSpc| Cost (%CPU)| Time     | Pstart| Pstop |    TQ |IN-OUT| PQ Distrib |
|   0 | SELECT STATEMENT               |                   |    88M|   121G|       | 2353K (65)| 00:33:07 |       |       |        |      |            |
|   1 | PX COORDINATOR                |                   |       |       |       |            |          |       |       |        |      |            |
|   2 |   PX SEND QC (RANDOM)          | :TQ10002          |    88M|   121G|       | 2353K (65)| 00:33:07 |       |       | Q1,02 | P->S | QC (RAND) |
|* 3 |    VIEW                        |                   |    88M|   121G|       | 2353K (65)| 00:33:07 |       |       | Q1,02 | PCWP |            |
|* 4 |     WINDOW SORT PUSHED RANK    |                   |    88M|    35G|    75G| 2353K (65)| 00:33:07 |       |       | Q1,02 | PCWP |            |
|   5 |      PX RECEIVE                |                   |    88M|    35G|       | 2353K (65)| 00:33:07 |       |       | Q1,02 | PCWP |            |
|   6 |       PX SEND HASH             | :TQ10001          |    88M|    35G|       | 2353K (65)| 00:33:07 |       |       | Q1,01 | P->P | HASH       |
|* 7 |        WINDOW CHILD PUSHED RANK|                   |    88M|    35G|       | 2353K (65)| 00:33:07 |       |       | Q1,01 | PCWP |            |
|* 8 |         HASH JOIN RIGHT OUTER |                   |    88M|    35G|       | 1610K (92)| 00:22:39 |       |       | Q1,01 | PCWP |            |
|   9 |          PX RECEIVE            |                   | 1133K|    32M|       | 1197 (20)| 00:00:02 |       |       | Q1,01 | PCWP |            |
| 10 |           PX SEND BROADCAST    | :TQ10000          | 1133K|    32M|       | 1197 (20)| 00:00:02 |       |       | Q1,00 | P->P | BROADCAST |
| 11 |            PX BLOCK ITERATOR   |                   | 1133K|    32M|       | 1197 (20)| 00:00:02 |   KEY |   KEY | Q1,00 | PCWC |            |
| 12 |             TABLE ACCESS FULL | SRVC_CODE        | 1133K|    32M|       | 1197 (20)| 00:00:02 |     1 |     1 | Q1,00 | PCWP |            |
| 13 |          PX BLOCK ITERATOR     |                   |    88M|    32G|       |   188K (27)| 00:02:39 |   KEY |   KEY | Q1,01 | PCWC |            |
| 14 |           TABLE ACCESS FULL    |    ORDER_DETAIL   |    88M|    32G|       |   188K (27)| 00:02:39 |     1 |     1 | Q1,01 | PCWP |            |
Predicate Information (identified by operation id):
   3 - filter("orddtl"."rownbr"=1)
   4 - filter(ROW_NUMBER() OVER ( PARTITION BY "od"."ORD_DTL_KEY","od"."START_TS" ORDER BY INTERNAL_FUNCTION("SC"."START_TS"(+))
              DESC )<=1)
   7 - filter(ROW_NUMBER() OVER ( PARTITION BY "od"."ORD_DTL_KEY","od"."START_TS" ORDER BY INTERNAL_FUNCTION("SC"."START_TS"(+))
              DESC )<=1)
   8 - access("od"."part_nbr"="SC"."part_nbr"(+) AND "SC"."SRVC_CD_KEY"(+)="od"."SRVC_CD_KEY")
       filter("od"."ITEM_CRE_DT"<"SC"."END_TS"(+) AND "od"."ITEM_CRE_DT">="SC"."START_TS"(+))

Thanks Jonathan for your reply.
This type of pattern happens quite frequently in parallel execution with aggregation. A layer of slave processes can do partial aggregation before passing a reduced result set to the query co-ordinator to finish the job.
I wouldn't be 100% sure without building a model to check, but I think the logic of your quer allows the eight slaves to identify each "rownumber() = 1" for the data set they have collected, and the allows the query coordinator to do the window sort on the eight incoming rows (for each key) and determine which one of the eight is ultimate the highest date.So is it a normal pattern? Will step#7 & #4 do the same amount work as stated in PREDICATE information part of execution plan.?
You’re correct! There are 8 slave processes appears to be performing WINDOW PUSHED RANK ( Step#7 in Execution Plan ) as you see in following output. Per execution plan and your comment, each one appears to be finding partial set of rows row_num <= 1. It’s apparently doing lots of work and very slow even with 8 processes. So not sure , how slow would be QC doing the same work just by itself.
And as you see below , it’s [Step#7 ] very slow and half of the slaves performing multi pass sort operation. Even though , it was estimated 35GB for that operation, why it’s estimating work area size of only 6-14MB only? Also, It’s allocating so low amount of PGA than expected. P_A_T was set to approx 11 GB. Currently this was the only query/operation on the Instance.
Why it’s not allocating more PGA for that operation? [My apologies for diverting from my original question ].
I have included PGA stats as well here which was taken 5-10 minutes later than other PQ session information. It’s still shows that there is no shortage of PGA.
Moreover, I have observed this behavior (under allocation of PGA) especially for WINDOWS SORT operations for other SQLs too. Is it normal behavior ? I’m on 10.2.0.4.
select
decode(px.qcinst_id,NULL,username,
' - '||lower(substr(pp.SERVER_NAME,
length(pp.SERVER_NAME)-4,4) ) )"Username",
decode(px.qcinst_id,NULL, 'QC', '(Slave)') "QC/Slave" ,
to_char( px.server_set) "SlaveSet",
to_char(s.sid) "SID",
to_char(px.inst_id) "Slave INST",
decode(sw.state,'WAITING', 'WAIT', 'NOT WAIT' ) as STATE,
case sw.state WHEN 'WAITING' THEN substr(sw.event,1,30) ELSE NULL end as wait_event ,
to_char(s.ROW_WAIT_OBJ#) wait_OBID,
decode(px.qcinst_id, NULL ,to_char(s.sid) ,px.qcsid) "QC SID",
to_char(px.qcinst_id) "QC INST",
px.req_degree "Req. DOP",
px.degree "Actual DOP"
from gv$px_session px,
gv$session s ,
gv$px_process pp,
gv$session_wait sw
where px.sid=s.sid (+)
and px.serial#=s.serial#(+)
and px.inst_id = s.inst_id(+)
and px.sid = pp.sid (+)
and px.serial#=pp.serial#(+)
and sw.sid = s.sid
and sw.inst_id = s.inst_id
order by
decode(px.QCINST_ID, NULL, px.INST_ID, px.QCINST_ID),
px.QCSID,
decode(px.SERVER_GROUP, NULL, 0, px.SERVER_GROUP),
px.SERVER_SET,
px.INST_ID
UNAME        QC/Slave SlaveSet SID       Slave INS STATE    WAIT_EVENT                      WAIT_OBID QC SID QC INS Req. DOP Actual DOP
APPS_ORD     QC                1936      2         WAIT     PX Deq: Execute Reply          71031      1936
- p006      (Slave) 1        1731      2         WAIT     PX Deq: Execution Msg          71021      1936   2             8          8
- p007      (Slave) 1        2159      2         WAIT     PX Deq: Execution Msg          71021      1936   2             8          8
- p002      (Slave) 1        2090      2         WAIT     PX Deq: Execution Msg          71021      1936   2             8          8
- p005      (Slave) 1        1965      2         WAIT     PX Deq: Execution Msg          71021      1936   2             8          8
- p001      (Slave) 1        1934      2         WAIT     PX Deq: Execution Msg          71021      1936   2             8          8
- p004      (Slave) 1        1843      2         WAIT     PX Deq: Execution Msg          71021      1936   2             8          8
- p000      (Slave) 1        1778      2         WAIT     PX Deq: Execution Msg          71021      1936   2             8          8
- p003      (Slave) 1        1751      2         WAIT     PX Deq: Execution Msg          71021      1936   2             8          8
- p009      (Slave) 2        2138      2         NOT WAIT                                71031      1936   2             8          8
- p012      (Slave) 2        1902      2         NOT WAIT                                71031      1936   2             8          8
- p008      (Slave) 2        1921      2         NOT WAIT                                71031      1936   2             8          8
- p013      (Slave) 2        2142      2         NOT WAIT                                71031      1936   2             8          8
- p015      (Slave) 2        2091      2         NOT WAIT                                71031      1936   2             8          8
- p014      (Slave) 2        2122      2         NOT WAIT                                71031      1936   2             8          8
- p010      (Slave) 2        2146      2         NOT WAIT                                71031      1936   2             8          8
- p011      (Slave) 2        1754      2         NOT WAIT                                71031      1936   2             8          8
SELECT operation_type AS type                      ,
        workarea_address WADDR,
        operation_id as OP_ID,
        policy                                      ,
        vwa.sql_id,
        vwa.inst_id i#,
        vwa.sid                                     ,
        vwa.qcsid   QCsID,
        vwa.QCINST_ID QC_I#,
        s.username uname,
        ROUND(active_time    /1000000,2)   AS a_sec ,
        ROUND(work_area_size /1024/1024,2) AS wsize ,
        ROUND(expected_size /1024/1024,2) AS exp   ,
        ROUND(actual_mem_used/1024/1024,2) AS act   ,
        ROUND(max_mem_used   /1024/1024,2) AS MAX   ,
        number_passes                      AS p#,
        ROUND(tempseg_size/1024/1024,2)    AS temp
FROM   gv$sql_workarea_active vwa ,
        gv$session s
where vwa.sid = s.sid
and    vwa.inst_id = s.inst_id
order by vwa.sql_id, operation_id, vwa.inst_id, username, vwa.qcsid
TYPE            WADDR            OP_ID POLI SQL_ID         I#    SID QCSID QC_I# UNAME                A_SEC      WSIZE        EXP        ACT        MAX   P#       TEMP
WINDOW (SORT)   07000003D2B03F90     7 AUTO 8z5s5wdy94ty3   2   2146   1936     2 APPS_ORD            1181.22      13.59      13.59       7.46      90.98    1        320
WINDOW (SORT)   07000003D2B03F90     7 AUTO 8z5s5wdy94ty3       2142   1936     2 APPS_ORD            1181.07       7.03       7.03       4.02      90.98    0        288
WINDOW (SORT)   07000003D2B03F90     7 AUTO 8z5s5wdy94ty3       2091   1936     2 APPS_ORD            1181.06       7.03       7.03        4.5      90.98    0        288
WINDOW (SORT)   07000003D2B03F90     7 AUTO 8z5s5wdy94ty3       1921   1936     2 APPS_ORD            1181.09      13.59      13.59       2.24      90.98    1        320
WINDOW (SORT)   07000003D2B03F90     7 AUTO 8z5s5wdy94ty3       2138   1936     2 APPS_ORD            1181.16       7.03       7.03       1.34      90.98    0        288
WINDOW (SORT)   07000003D2B03F90     7 AUTO 8z5s5wdy94ty3       1754   1936     2 APPS_ORD            1181.09      14.06      14.06       5.77      90.98    1        320
WINDOW (SORT)   07000003D2B03F90     7 AUTO 8z5s5wdy94ty3       2122   1936     2 APPS_ORD            1181.15       6.56       6.56        .24      90.98    0        288
WINDOW (SORT)   07000003D2B03F90     7 AUTO 8z5s5wdy94ty3       1902   1936     2 APPS_ORD            1181.12      14.06      14.06       9.12      90.98    1        320
HASH-JOIN       07000003D2B03F28     8 AUTO 8z5s5wdy94ty3       2142   1936     2 APPS_ORD            1183.24      98.64      98.64     100.44     100.44    0
HASH-JOIN       07000003D2B03F28     8 AUTO 8z5s5wdy94ty3       2138   1936     2 APPS_ORD            1183.24      98.64      98.64     100.44     100.44    0
HASH-JOIN       07000003D2B03F28     8 AUTO 8z5s5wdy94ty3       2122   1936     2 APPS_ORD            1183.24      98.64      98.64     100.44     100.44    0
HASH-JOIN       07000003D2B03F28     8 AUTO 8z5s5wdy94ty3       2091   1936     2 APPS_ORD            1183.24      98.64      98.64     100.44     100.44    0
HASH-JOIN       07000003D2B03F28     8 AUTO 8z5s5wdy94ty3       1921   1936     2 APPS_ORD            1183.24      98.64      98.64     100.44     100.44    0
HASH-JOIN       07000003D2B03F28     8 AUTO 8z5s5wdy94ty3       1902   1936     2 APPS_ORD            1183.24      98.64      98.64     100.44     100.44    0
HASH-JOIN       07000003D2B03F28     8 AUTO 8z5s5wdy94ty3       2146   1936     2 APPS_ORD            1183.24      98.64      98.64     100.44     100.44    0
HASH-JOIN       07000003D2B03F28     8 AUTO 8z5s5wdy94ty3       1754   1936     2 APPS_ORD            1183.24      98.64      98.64     100.44     100.44    0
                                                          sum                                                872.07            838.21
PGA Stats – taken 5-10 minutes later than above.
select name, decode(unit,'bytes',round(value/1048576,2)||' MB', value) value from v$pgastat
NAME                                               VALUE
aggregate PGA target parameter                     11264 MB
aggregate PGA auto target                          9554.7 MB
global memory bound                                1024 MB
total PGA inuse                                    902.21 MB
total PGA allocated                                3449.64 MB
maximum PGA allocated                              29155.44 MB
total freeable PGA memory                          2140.56 MB
process count                                      107
max processes count                                379
PGA memory freed back to OS                        77240169.56 MB
total PGA used for auto workareas                  254.14 MB
maximum PGA used for auto workareas                22797.02 MB
total PGA used for manual workareas                0 MB
maximum PGA used for manual workareas              16.41 MB
over allocation count                              0
bytes processed                                    323796668.77 MB
extra bytes read/written                           183362312.02 MB
cache hit percentage                               63.84
recompute count (total)                            2054320
SELECT
PGA_TARGET_FOR_ESTIMATE/1048576 ESTMTD_PGA_MB,
   PGA_TARGET_FACTOR PGA_TGT_FCTR,
   ADVICE_STATUS ADV_STS,
   BYTES_PROCESSED/1048576 ESTMTD_MB_PRCD,
   ESTD_EXTRA_BYTES_RW/1048576 ESTMTD_XTRA_MB,
   ESTD_PGA_CACHE_HIT_PERCENTAGE ESTMTD_CHIT_PCT,
   ESTD_OVERALLOC_COUNT O_ALOC_CNT
FROM V$PGA_TARGET_ADVICE
ESTMTD_PGA_MB PGA_TGT_FCTR ADV ESTMTD_MB_PRCD ESTMTD_XTRA_MB ESTMTD_CHIT_PCT O_ALOC_CNT
        1,408         .125 ON     362,905,053    774,927,577              32      19973
        2,816          .25 ON     362,905,053    571,453,995              39        709
        5,632           .5 ON     362,905,053    249,201,001              59          5
        8,448          .75 ON     362,905,053    216,717,381              63          0
       11,264            1 ON     362,905,053    158,762,256              70          0
       13,517          1.2 ON     362,905,053    153,025,642              70          0
       15,770          1.4 ON     362,905,053    153,022,337              70          0
       18,022          1.6 ON     362,905,053    153,022,337              70          0
       20,275          1.8 ON     362,905,053    153,022,337              70          0
       22,528            2 ON     362,905,053    153,022,337              70          0
       33,792            3 ON     362,905,053    153,022,337              70          0
       45,056            4 ON     362,905,053    153,022,337              70          0
       67,584            6 ON     362,905,053    153,022,337              70          0
       90,112            8 ON     362,905,053    153,022,337              70          0

NOT operator: What kind of index to create to prevent unindexed searches ?

I see the following unindexed searches in my ODSEE (dsconf : 11.1.1.3.0 B2010.0630.2145) directory access log:
[30/Sep/2011:11:42:04 +0200] conn=133 op=1 msgId=2 - SRCH base="ou=people,ou=.... " scope=1 filter="(!(employeeType=P))" attrs="mail sn givenName"
[30/Sep/2011:11:42:28 +0200] conn=133 op=1 msgId=2 - RESULT err=0 tag=101 nentries=94312 etime=24 notes=U
I've created an equality index on the employeeType attribute with a threshold of 130 000. I know that I have 4 possible values for the
employeetype attribute, where at most 90000 entries have the same value. So, I don't understand why it's considered as an unindexed search.
What index(es) and index parameter(s) should I create to have that kind of search match an index ?

A while back Ludovic (I think) posted that there is no index for NOT. If you think about it, the usual index operation for equality, for example, has a key and value. The employeeType equality index key for "P" would have as its value a list of entryIDs that have the appropriate employeetype. So where would we get the list of entryIDs that don't have the value? Every key would need a corresponding negation key, containing the symmetric difference of ALLIDs with the original key. Computing it on the fly involves ALLIDs, which puts it right in to the unindexed category. Maintaining such a collection of indexes looks like a significant increase in processing time, I/O to the DB, and data size in the indexes. I'm guessing a bit of analysis on that may well show the cost is prohibitive. And in many cases any significant additional processing of this kind ought to be avoided. Maybe someone in ENG will chime in here with more details.
But if you already know all the other values you are looking for, can't you do a compound OR filter and get them all that way? It may still be unindexed if the candidate list grows over time to be more than your ALLIDs threshold. To be frank this query does not look like something that ought to be indexed. It grabs a pretty large number of your users. Your ALLIDS threshold already looks too high to me. If this is a reporting query of some kind, I'd recommend either parsing an LDIF backup (if you don't need realtime data) or using a utility/reporting server that you can bog down with long-running queries. If you are already using a utility server for this, you can examine whether the query really needs to be indexed at all. It may not make sense to try to index it.
As to why an operator would be available but not indexable, remember that the second major step of search processing examines each member of the candidate list and verifies a match on the filter. We routinely include filter components that we do not expect to assist in the creation of the candidate list, but we still want to be applied to the candidates during the filtering phase. For instance, consider the conventional filter (&(objectclass=person)(cn=XYZ)). In many Directories the objectclass filter component will evaluate to ALLIDs, and we want it to, because the cn component will have a much shorter list. We don't want the server to have to perform set intersection of a huge list of entryIDS (all the person objects) with the cn list. This is an example of how a too large ALLIDs threshold can hinder performance. We want the server to do the much easier intersection of ALLIDs with the short cn component list, because we know intersection of any subset of ALLIDs with ALLIDs is the subset. But we do want the server to check the candidates to make sure they really are person entries before returning them.

Buffer(sort) operator

Hi,
i'm trying to understand what "buffer sort" operation is in the following explain plan:
0 SELECT STATEMENT
-1 MERGE JOIN CARTESIAN
--2 TABLE ACCESS FULL PLAYS
--3 BUFFER SORT
---4 TABLE ACCESS FULL MOVIE
In Oracle 9i DataBase Performance Guide and Reference, "buffer sort" is not mentioned although all other explain plan's operations are.
What does it mean? Does it take place in main memory or is it an external sort?
Thank you.

A BUFFER SORT typically means that Oracle reads data blocks into private memory,because the block will be accessed multiple times in the context of the SQL statement execution. in other words, Oracle sacrifies some extra memory to
reduce the overhead of accessing blocks multiple times in shared memory.
Hope this will clear your doubts.
Thanks.

Why do I keep getting a message "insert blank disk" when trying to burn playlist to cd?

Why do I keep getting a message "insert blank disk" when trying to burn playlist to cd? I can import burned cds to iTunes just fine, but cannot burn playlist to disk.

because you have to be using a blank cd-rw or cd-r.

Why does it say No bootable device Insert bootable device?

Why does it say No bootable device Insert bootable device?

Can i suggest you spend more time explaining the situation, what you are doing, what has been done recently, etc? One sketchy line is not much help.
That said, i will guess that yu are trying to turn on your mac, and it gve you that message, immediately.
It means that soemthing has caused it to not recognize your hard disk and the OSX software on it. It could be:
1. a dmaaged disk
2. corrupted software
3. a firmware bug
4. a hardware failure
Most likely the software has been corrupted at least slightly.
The best first step is to boot from your original CD and run disk diagnostics/ repairs on the hard drive.
I hope that fixes it.
Then go buy an external bootabl hard drive and begin making complete, bootable backups on weekly basis.
Grant

Why SQL Operation is misfire in FLASHBACK_TRANSACTION_QUERY (Ora 10g XE)?

I am selecting the list of sql queries issued using FLASHBACK_TRANSACTION_QUERY . (Oracle 10g XE)
The below is query...
select operation,START_SCN,undo_sql from FLASHBACK_TRANSACTION_QUERY where logon_user='SHARMA' AND table_owner='SHARMA' AND TABLE_NAME='EMPLOYEE';
Output is..
operation START_SCN undo_sql
DELETE 1000896 insert into "SHARMA"."EMPLOYEE"("ID","NAME") values ('103','Shiva');
UPDATE 966271 update "SHARMA"."EMPLOYEE" set "NAME" = 'Fernandas' where ROWID = 'AAADeIAABAAAKlaAAD';
INSERT 966222 delete from "SHARMA"."EMPLOYEE" where ROWID = 'AAADeIAABAAAKlaAAD';
From the above o/p
Sql query is "Delete from.." for that Operation is INSERT and vice versa.
Update is correct format only.
How to rectify this?
Thanks

Thanks for yor reply..
I am trying to get when the INSERT,UPDATE and DELETE query is issued..
For this i had created a table with 'ROWDEPENDENCIES'.
Then i issue a query
SELECT SCN_TO_TIMESTAMP(ORA_ROWSCN),ID,NAME FROM emptest;
It shows except DELETED quey information..
I need to get DELETED query details also..
Using FLASHBACK we can retrive the deleted query info know?
For that only i tried in FLASHBACK_TRANSACTION_QUERY table.
It wont give full information..
I had tried AS OF clause
SELECT * FROM emptest AS OF TIMESTAMP
TO_TIMESTAMP('25-JAN-08 07.53.17 PM', 'DD-MON-YY HH:MI:SS AM')
The above query also doesn't display DELETED query details..
How to get when the record is got deleted?
Thanks

Swap, temporary tablespace and sort operations

Hello.
I have an Oracle 8.1.7 on Linux RH7.1. I see a very interesting situation: when users begin to execute large selects with many sorts operation swapping grows, but temporary tablespace does'nt grow. As I know, when Oracle has no memory to use as "sort_area_size" it uses temporary tablespace. But looks like that when Oracle ask for memory Linux begin to swap (in order to give memory for Oracle). I mean that Oracle don't use temporary tablespace but use swap instead of it. Is it true? Is it problem? Is it Oracle, Linux or my own configuration bug? Is it better to use swap or to use temporary tablespace? What is faster?
Thanx for all advises and ideas. ANd sorry for pure English

login to your database as DBA (SYS AS SYSDBA) and issue the following query:
SQL> select name, value from v$parameter where name = 'sga_max_size' ;
see the value defined for this parameter. If this is larger than what you have configured as your SGA size,
Oracle will assume that it can expand the SGA to "sga_max_size" value, and will try to expand the SGA when
required. This will result in Oracle asking more memory from the linux kernel and then linux starts to use
the swap space.
Try changing the value of this parameter and see if it helps.

Is max function will carry sort operation..?

Hi friends,
Is the max function will perform sort operation in temporary
segments..? Please list the set of operations that will take
place for the following Query (Apart from Syntax & Fetching the
data).
Ex:
delete from tab1 p1
where p1.rowid < (select max(p2.rowid)
from tab1 p2 where
p1.c1 = p2.c2);
Regards,
G. Rajakumar.

you can get that information using explain plan command.
DELETE STATEMENT
DELETE TAB1
FILTER
TABLE ACCESS FULL TAB1
SORT AGGREGATE TAB1
TABLE ACCESS FULL TAB1

Why don't be used composite index in partition table.

A table has done range list partition.
Then, I create a composite index named INDEX_N2(COLUMN_005, COLUMN_002). --COLUMN_005 AND COLUMN_002 ARE VARCHAR2
When I run the SQL
select 1
from table1 T1
where T1.COLUMN_005 = 'x'
and T1.COLUMN_002 = 'y'
And view the explain plan, INDEX_N2 has been used.
But when I join the COLUMN_005 to other column, the index will not be used.
The SQL is like below.
select 1
from table1 T1, table T2
where T1.COLUMN_005 = T2.COLUMN_002 --T2.COLUMN_002 IS VARCHAR2
and T1.COLUMN_002 = 'y'
The explain plan is like below
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |
| 0 | SELECT STATEMENT | | 426 | 44730 | 65367 (1)| 00:13:05 | | |
|* 1 | HASH JOIN | | 426 | 44730 | 65367 (1)| 00:13:05 | | |
| 2 | PARTITION RANGE ALL| | 8 | 792 | 5 (0)| 00:00:01 | 1 | 32 |
| 3 | PARTITION LIST ALL| | 8 | 792 | 5 (0)| 00:00:01 | 1 | 8 |
|* 4 | TABLE ACCESS FULL| TABLE1 | 8 | 792 | 5 (0)| 00:00:01 | 1 | 256 |
| 5 | PARTITION RANGE ALL| | 1112K| 6519K| 65355 (1)| 00:13:05 | 1 | 34 |
| 6 | PARTITION LIST ALL| | 1112K| 6519K| 65355 (1)| 00:13:05 | 1 | LAST |
| 7 | TABLE ACCESS FULL| TABLE2 | 1112K| 6519K| 65355 (1)| 00:13:05 | 1 | 442 |
Query Block Name / Object Alias (identified by operation id):
1 - SEL$1
4 - SEL$1 / T1@SEL$1
7 - SEL$1 / T2@SEL$1
Predicate Information (identified by operation id):
1 - access("T1"."COLUMN_005"="T2"."COLUMN_002")
4 - filter("T1"."COLUMN_002"='y')
Column Projection Information (identified by operation id):
1 - (#keys=1)
2 - "T1"."COLUMN_005"[VARCHAR2,150]
3 - "T1"."COLUMN_005"[VARCHAR2,150]
4 - "T1"."COLUMN_005"[VARCHAR2,150]
5 - "T2"."COLUMN_002"[VARCHAR2,20]
6 - "T2"."COLUMN_002"[VARCHAR2,20]
7 - "T2"."COLUMN_002"[VARCHAR2,20]
Note
- dynamic sampling used for this statement
My Questin is:
Two columns are include the columns of index.
Why it can't be used?
Thanks

I create a new index on column2, (INDEX_N3)
and change SQL to
select 1 from table T1 where
T1.COLUMN_002 = '848K 36892'
This time INDEX_N3 will be used.
but change SQL to
select 1 from table T1 where
T1.COLUMN_002 = '848K 36892'
and T1.COLUMN_004 = '1000'
The explain plan will show full scan.
Why？
Thanks.

Group By, Sort operation on pl/sql collection

Hi,
Is it possible to do a group by or a order by operation on a pl/sql table of records?
Thanks,
Ashish

If you are building your cllection from a database then why dont you SORT in the SQL that you use toget data from the database. If that dose not help then this link will help you.
sort data of pl/sql table
Thanks

Why is Oracle not using the index??

Hi,
I have a table called 'arc_errors' which has an index on 'member_number' as follows:- Create/Recreate indexes
create index DWO.DW_ARC_CERRORS_MNO on DWO.DW_ARC_CERRORS (MEMBER_NUMBER);
But surpisingly, when I execute the following query, it does not use the index.
SELECT member_number,
COUNT(*) error_count
FROM arc_errors a
WHERE member_number = 68534152 AND
( tx_type = 'SDIC' AND
error_number IN (4, 7, 12, 13, 15, 17, 18, 705) )
OR
( tx_type = 'AUTH' AND
error_number IN (100, 104, 107, 111, 116) )
OR
( tx_type = 'BHO' AND
error_number IN (708,710) )
OR
( tx_type = 'XLGN' AND
( error_number BETWEEN 102 AND 105 OR
error_number BETWEEN 107 AND 120 OR
error_number BETWEEN 300 AND 304 ) )
OR
( tx_type = 'None' AND
( error_number IN (20, 112) OR
error_number BETWEEN 402 AND 421 ) )
OR
( tx_type = 'HYBR' AND
error_number IN (303, 304) )
GROUP BY member_number;
This is what 'explain plan' tell me
SELECT STATEMENT, GOAL = RULE               237907     502923     15087690
SORT GROUP BY               237907     502923     15087690
PARTITION RANGE ALL
TABLE ACCESS FULL     DWO     DW_ARC_CERRORS     237209     502923     15087690
Can someone tell me why a 'table acess full' is required here?
Thanks in advance,
Rajesh

Sorry, I just found the solution myself. I need to put an extra pair of braces around the set of conditions seperated by OR.

Why Sort operation on clustered columstore index insert?

Similar Messages

Maybe you are looking for