April 1, 2015 at 9:17 am
TIA for any help...
First some background...
I am supporting a 2000 instance that does ETL for reporting, custom VB forms, etc. This has been in place for 10+ years and remains mostly unchanged over time. As part of the process, SQL Tasks are used to update fields in tables.
Recently, (about 2 weeks ago) some of these updates seemed to stop working. There are no errors in the DTS package yet the updates to these fields appears to not have happened. The remedy now is to simply re-run those updates and populate those fields. This works as expected.
This is a 2000 Standard Edition install on a Windows 2008 Standard server. It is virtualized. VMware ESXi 5.5.0 blade with a DS3400 SAN. I'm not certain of the disk layout as that is done by others. The blade itself has 24 logical processors and has 39 virtualized processors so it is a little over the recommended ratio (1.5 V to L).
Has anyone seem similar behavior?
Thanks.
Bill
April 1, 2015 at 11:07 am
Quick questions, have you checked all log files? Are only updates failing while other activities (insert / delete) are working?
😎
Had a similar issue way back, turned out to be a logon time restriction, package would fail but no error was reported. :crazy:
April 1, 2015 at 12:01 pm
Yes. Log files are clean.
This issue appears to be only on the updates from a SQL task. Inserts via a Transform Data Task have been ok.
April 1, 2015 at 12:30 pm
Few more questions (bear with me), When was it moved to ESXi 5.5.0? Windows OS version? Recent upgrades/updates? Which drivers does VB use? Was this originally on SQL 7.0?
😎
April 1, 2015 at 2:43 pm
The blades were upgraded to 5.5 about 6 months ago. About a month ago, firmware was been updated on the blades to current levels.
It is on Windows 2008 Standard. This is a fresh install (OS and SQL) in December 2014 so no SQL 7.0. We likely have a month of Windows updates to apply but it's pretty current there too.
April 1, 2015 at 10:26 pm
Bill-89778 (4/1/2015)
The blades were upgraded to 5.5 about 6 months ago. About a month ago, firmware was been updated on the blades to current levels.It is on Windows 2008 Standard. This is a fresh install (OS and SQL) in December 2014 so no SQL 7.0. We likely have a month of Windows updates to apply but it's pretty current there too.
My instinct is that this is a problem with the package and it's error handling, not with the SQL Server. Start by enabling all possible logging options and preferably disabling relevant error handling in the package, start a trace on the server and then run the package. This should give you enough information to identify the source of the problem.
😎
Another possible cause would be a change in the incoming files but since running the package manually works fine, I think that one can be ruled out.
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply