You may see this message in your server’s SQL Log file:
“SQL Server has encountered 1 occurrence(s) of cachestore flush for the ‘SQL Plans’ cachestore (part of plan cache) due to some database maintenance or reconfigure operations.”

In the case of MAXDOP changing, if you look before the above event happened, you should see that MAXDOP was changed and hence caused the flush.

This makes sense. If you are changing the MAXDOP setting, all current query plans are worthless as they’re out of date with respect to this parameter. Some plans may now be able to benefit from parallelism, whereas before they could not. Or if constraining MAXDOP, some parallel plans may not be able to work anymore. (Or some combination thereof.) The easiest way to rectify this issue is to simply flush the plan cache and let all plans recompile at their next execution.

A common situation for changing MAXDOP could be for maintenance operations, where during normal operations MAXDOP is constrained to 1, yet while doing weekly work during a maintenance window the DBAs may elect to set MAXDOP to 0 (unrestricted).

So, when you’re scratching your head wondering where your plan cache went, it could be due to administrative tasks.

(Ref: http://www.sqlservercentral.com/Forums/Topic915058-2669-1.aspx. Thanks, Paul White, for doing all of the work for this post. )

-- In SQL Server 2005 only

-- fails
select round(0.5,0) 

-- 0.5 is cast as a numeric(1,1), which is used as the output type as well.
-- Since 0.5 rounds up to 1.0, this value is larger than a numeric(1,1) can store,
-- which is 0.9

-- works!
select round(0.5,0) as rnd
  into testround

-- view metadata of 'testround'
sp_help testround  

-- Observe that the 'rnd' column is defined as a numeric(1,1),
-- which technically means 0.9 is the max value

-- Now let's view the record:
select *
  from testround

-- WHAT?!  "Arithmetic Overflow"?  But, but, but the insert worked

-- Hmm, does this work? (Yes)
select cast(rnd as numeric(2,1)) as rnd
  from testround

-- Well, let's see what's going on here:

DBCC CHECKTABLE('testround') -- also catchable via DBCC CHECKDB, but not
                             -- with PHYSICAL_ONLY

/*
DBCC results for 'testround'.
Msg 2570, Level 16, State 3, Line 1
Page (1:1811349), slot 0 in object ID 2099048, index ID 0,
partition ID 72057594063028224, alloc unit ID 72057594096123904 (type
"In-row data"). Column "rnd" value is out of range for data type "numeric".
Update column to a legal value.
There are 1 rows in 2 pages for object "testround".
CHECKTABLE found 0 allocation errors and 1 consistency errors in table
'testround' (object ID 2099048).
DBCC execution completed. If DBCC printed error messages, contact your
system administrator.
*/

-- Okay, now let's see what's *REALLY* going on
DBCC TRACEON(3604)
GO

declare @db int
declare @filenumber int
declare @pagenumber int
set @db = db_id()
set @filenumber = 1       -- From DBCC output, adjust accordingly: Page (1:1811349)
set @pagenumber = 1811349 -- From DBCC output, adjust accordingly: Page (1:1811349)

DBCC PAGE(@db, @filenumber, @pagenumber, 3); -- 3 == full detail with ascii output 

-- Find the entry for slot 0 (according to the DBCC output above), note the out of range
-- value: "rnd = 1.0"

/*
Slot 0 Offset 0x60 Length 12

Record Type = PRIMARY_RECORD         Record Attributes =  NULL_BITMAP
Memory Dump @0x67EAC060

00000000:   10000900 010a0000 000100fe ††††††††††............             

Slot 0 Column 0 Offset 0x4 Length 5

rnd = 1.0
*/

-- Let's fix it

update testround
   set rnd = 0.9;
GO

-- Run CHECKTABLE again
DBCC CHECKTABLE('testround') -- success!  No issues.

-- Okay, example's over.  Turn off our TRACEON command and drop the table.

-- It is important to note that this does not work in 2008.  Whew.

DBCC TRACEOFF(3604)
GO

drop table testround;
GO

If you decide to use an ORDER BY in your source and want to tell the SSIS Data Flow that your data is sorted, follow the below steps:

First, ensure that your data is being sorted with the ORDER BY clause. Make note of which column(s) are in the sort and their positions.

Second, open the Advanced Editor for the OLE DB Source component by right-clicking on the OLE DB Source and selecting “Show Advanced Editor…”

Then, click on the “Input and Output Properties” tab.

Then highlight the “OLE DB Source Output Properties” branch and set the “IsSorted” property to True.

Next, expand the “OLE DB Source Output Properties” branch. From here, select the first column under “Output Columns” that corresponds to the first column in your ORDER BY clause. Set its “SortKeyPosition” property to the number 1.

Repeat the last step for each column in your ORDER BY clause, advancing the SortKeyPosition by one each time. (1,2,3,…)

That’s it. Now the SSIS Data Flow will understand and acknowledge that the incoming data is sorted and will not require a Sort Component between the source and a Merge Join component, for instance.


First_Name
John
Adam
Kris
NULL
Paula
NULL
George


’select count(*) from NAME’ will return the value of 7.
’select count(First_Name) from NAME’ will return the value of 5 because there are two NULL values that are being excluded by rule.

So far so good. The bug in this case shows up under conditions where you are COUNTing a column from what I’ll call a “grandchild table.” In other words, if I have a table, SYS.OBJECTS, and it is joined to SYS.COLUMNS, which is then joined to another table (ANOTHERTABLE) that may or may not have matching SYS.COLUMNS in it and you are counting a column (eliminating NULLs) within ANOTHERTABLE, you may get erroneous results.

A working example is below, thanks to Ionel’s repro query included in the Connect bug submission:

select o.object_id,
count(x.column_id) should_be_zero_always

group by o.object_id


You can run the above code in any database, and will likely see that 1s show up in the column titled, “should_be_zero_always.”

As you can see, the above query is going to be quite common where you do not want to filter results from the driving table and are forced to use an outer join.

The data behind the scenes looks like this:

o.object_id c.object_id x.column_id cnt_returns_1_y_n
1131151075 NULL NULL y
1147151132 1147151132 1 n
1147151132 1147151132 2 n
1147151132 1147151132 3 n
1147151132 1147151132 4 n
1147151132 1147151132 5 n
1147151132 1147151132 6 n
1163151189 NULL NULL y
1179151246 NULL NULL y


Where we have a NULL in c, x is also forced to be NULL (even though x is hardcoded to return an empty data set in the example above), COUNT(x.column_id) will return a 1 for this scenario, when it should be returning a zero.

This works correctly in SQL Server 2000, I might add.

The bug is currently being tracked internally at Microsoft, and in theory, no future CTPs (which would be for releases beyond 2008) won’t have the issue, but there is no E.T.A. on when we’ll see a fix in 2005 or 2008. Hopefully by the end of the year if we’re lucky and it doesn’t get de-prioritized.

I would encourage you to review the Connect bug submission and at least vote, but by all means, please leave your feedback on the issue while you are there.

https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=380304

First things first. Add a script component to the data flow. When prompted, select “Source” as the component type. (click on images for full sized version)

Next, for clarity’s sake, I’ll rename the default output. (An output simply contains a set of columns and will correlate to the green arrow on the data flow. The more outputs you have, the more green arrows you can use.) I’ll rename the default output, “Output 0″ to “MyOutput.”

Next, I’ll add an output column called, “MyColumn” and its type will be an integer. Be sure to change the type accordingly.

From here, we can edit the script by clicking on the script section on the left of the above window. From there click on the “Design Script…” button. Below is the setup:

Notice how when I type, I am automatically prompted for a list of available items to choose from. One of them is the column I added previously. Let’s pick the column and assign a value of 123 to it. Full script below:

For SSIS 2005:

Imports System
Imports System.Data
Imports System.Math
Imports Microsoft.SqlServer.Dts.Pipeline.Wrapper
Imports Microsoft.SqlServer.Dts.Runtime.Wrapper

Public Class ScriptMain
    Inherits UserComponent

    Public Overrides Sub CreateNewOutputRows()
        MyOutputBuffer.AddRow()
        MyOutputBuffer.MyColumn = 123
    End Sub

End Class

For SSIS 2008, it’s a bit different:
Visual Basic:

Imports System
Imports System.Data
Imports System.Math
Imports Microsoft.SqlServer.Dts.Pipeline.Wrapper
Imports Microsoft.SqlServer.Dts.Runtime.Wrapper

<Microsoft.SqlServer.Dts.Pipeline.SSISScriptComponentEntryPointAttribute> _
<CLSCompliant(False)> _
Public Class ScriptMain
    Inherits UserComponent

    Public Overrides Sub CreateNewOutputRows()
        Output0Buffer.AddRow()
        Output0Buffer.Column = 123
    End Sub

End Class

C#:

using System;
using System.Data;
using Microsoft.SqlServer.Dts.Pipeline.Wrapper;
using Microsoft.SqlServer.Dts.Runtime.Wrapper;

[Microsoft.SqlServer.Dts.Pipeline.SSISScriptComponentEntryPointAttribute]
public class ScriptMain : UserComponent
{

  public override void CreateNewOutputRows()
    {
        Output0Buffer.AddRow();
        Output0Buffer.Column = 123;
    }

}

You can close the script and then click OK on the script component dialog box. Now when you hook this source up to another component, you'll end up with one column with one row with a value of 123.