[SRC_OLEDB ] Error: SSIS Error Code DTS_E_OLEDBERROR. An OLE DB error has occurred. Error code: 0×80004005.

An OLE DB record is available. Source: “Microsoft SQL Server Native Client 10.0″ Hresult: 0×80004005 Description: “Internal Query Processor Error: The query processor encountered an unexpected error during execution.”.

Vague much?

The package had been run several times (read at least 10) with no changes to its code. The database had not grown in size. What was going on? Running the query inside sql server management studio initially returned a result set without the error, but the error returned when the query was executed from inside SSIS. We scratched our heads and kept troubleshooting. Eventually, the query returned the error inside SSMS as well as from SSIS.

We tried cycling the service on the box. No dice. Same bat error same bat location in the package. We googled the error message and found more vagueness– no real explanations or solutions. It seems that this error message is in fact as generic and milque toast as it sounds. One thread on the forums seemed to unearth a ghastly bug that required the help of a Microsoft Trouble ticket to resolve. This sentiment was echoed by two more threads. I was feeling queasy at the thought of having to go through even finding the contact who would permit me to make the call to Microsoft, when another thread in the forums hinted in a different direction, which resonated with me. This forum poster claimed no “aha” moment as to what the error meant, but did state that he had solved the problem by rebuilding the indexes on troublesome tables.

Usually you suspect fragmentation when a query which has been performing well stops performing well. One usually sees degradation, not errors. I knew that we had indeed been updating these tables. A Lot. (NOT a good idea in this specific case, but these were desperate times). What’s more, I knew that the updates had not been highly anticipated (again, times were hard–this was supposed to be a fresh load of a new warehouse) or planned for as far as indexing strategies. Our Fill Factors on the indexes were all the default—100.

So I checked the fragmentation on the indexes of the two largest and most likely suspect indexes: 99.7%. Wow. Anything over 30% with a page number for the table of at least 1000 pages is a problem. Here we were at almost 100% fragmented (and the tables were very large, way over 1000 pages). That’s both impressive and frightening. I rebuilt those indexes, (which took some time) and we were able to execute the SSIS package without the error.

Basically our server was having a Roberto Duran ‘no mas’ moment. The indexes, having been beaten to a bloody 99.7% fragmented pulp simply couldn’t go on. Instead of yelling no mas at the ref, the engine reported a vague error, threw in the towel and sat down in the corner. Luckily the corner man (me) was able to fix it up with some Dristan , q-tips and various coagulants (I rebuilt the indexes).

The End of the Story.

Further reading/learning: I have two ways of checking fragmentation on indexes, DBCC ShowContig and using the sys.dm_db_index_physical_stats DMV (which stands for Dynamic Management View, and was introduced with SQL Server 2005). Here is some info on how to use both methods.

And by the way, I am speaking at SQL Rally in Orlando in May! If you are going, please find me and introduce yourself.

–Julie