I've done a migration from SQL 2008 to SQL 2014. Unfortunately, one of the SSIS package which takes only 6 hours to run on 2008 is now taking 8 hours on 2014.
Can somebody told me why this is happening and how can I solve this problem? Is it something to do with setting?
I appreciate any idea/help from you guys. Thanks in advance.
Could be some problems:
Check the operating system is the same data SQL 2008.
Check the memory SQL SERVER:
Right-click: Server properties -> Memory -> Maximum Server Memory
Sometimes the virtual team, lowers the CPU consumption for the benefit of another machine
(If this is a virtual machine).
What about logging?
In 2012, the concept of project deployments was born. In addition to that concept, a centralized SSIS database was created by default when as Integration Services server was installed. Are you deploying the packages to a server to be run? If so, then logging might slow you down. http://msdn.microsoft.com/en-us/library/hh231191.aspx especially if the default it set to verbose and/or you're doing your own custom logging ( for each event, two executions happen).
Your SSIS server may be drowning from the default logging in addition to the standard workload of the data movements in the package. Try turning logging down or off. Basic works well for us. While the package is executing, monitor any resources that are running too high. That could give you some hints about potential bottle necks and where else to look.
Related
Beginning on 12/29/2022, several of our SSISDB packages started taking twice as long to finish their etl. This delays the beginning of our daily reporting for our company.
There are no errors that give much of a clue, and there is nothing out of the ordinary in the logs. The company has been on a code deployment freeze for 3 weeks now, so I'm pretty sure it is not that.
The Server CPU fluctuates between 30 and 60%, so I don't think it's a server resource issue. This phenomenon is occurring to various ETLs. I have looked into the reasons while these jobs will "Hang" or go "Runaway", but there is no discernable explanation I can find.
Can you recommend steps for debugging? SQL Server Management Studio 2018.
Microsoft SQL Database Engine Tuning Advisor seems to crash constantly for me... on multiple different servers, for multiple different databases, and throughout multiple different versions of SQL server (and DTA)...
I know this is probably a ridiculous question and not of the quality one would expect on stackoverflow :( but has anyone else experienced this?
I was having the same problem, as recently as SQL Server 2014 with Service Pack 2. I had to use a two-step approach to get it working again:
Installed both the latest service pack, and also the latest cumulative update for the service pack. This fixed the issue with Database Engine Tuning Advisor, but it was still crashing for me (see step 2)
I read where "hypothetical indexes" are added to your database when Database Engine Tuning Advisor is running. If it crashes, and does not complete successfully, the hypothetical indexes are not dropped. It was recommended that the hypothetical indexes be dropped from your database.
The combination of installing the latest service packs and cumulative updates, along with dropping the hypothetical indexes, seems to have worked for me.
I've experienced this behavior many times, and the way to fix it was to update my instances to the latest Service packs.
also the first version of SQL 2012 Tuning Advisor was crashing for some reasons, but updating to the latest SP2 has fixed this issue.
side note: plan-cash (a new features in SQL 2012) maybe helpful until you fix this problem permanently.
I was experiencing the same issue when running analysis on a database that contained encrypted stored procedures. I removed the encryption before I captured my profiler trace workload then re-ran the analysis and issue was resolved.
I have created SSIS packages to move data from AS400 to SQL Server which are scheduled daily.some of the packages in sql agent are taking longer duration more than 9 hours to complete.IF I run same package in Business intelligence studio manually, it is completing in less than 4 hours.Due to this problem my schedule packages are not competing on time.please help me to sort out this issue. I am unable to understand why there is a difference in task completion duration between manual interaction and schedule jobs.
My environment is windows server 2003 with sql server 2005 with SP3.please help me to sort out this issue.
The best way to get around this problem is to watch the scheduled task by using some debug statements and messages. For example, have some insert statements in the stored procedures the SSIS package is invoking. This way u will get to know what control is taking more time than expected. First try to isolate the control that is making the difference.
Also, you can invoke the package from command prompt using:-
dtexec /f filename.dtsx
This will print out all the messages in the console at each step as well.
Use SSIS logging in the package to log to a database table. Set logging to record start and end of tasks. By running the package in BIDS and comparing it to the logging when it is run on the server you will see which tasks are taking too long. See http://msdn.microsoft.com/en-us/library/ms138020.aspx for more info on SSIS logging (in sql 2008)
Might it be that the SQL server is less powerful than your client or has more load when you execute the package?
Business intelligence Studio the package is executed on your local client with it's CPU and RAM (I think).
Check what version of DTSEXEC you are using. May be you are using 32-bit version at one place and 64-bit at the other one.
I have a server with a default instance and 2 named instances of SQL Server 2005 standard installed. This is a mission critical production server that cannot be restarted during normal business hours.
Will uninstalling the two named instances of SQL Server 2005 require a reboot or put the server in a state that may cause issues with the default instance of SQL Server 2005 until it's rebooted?
This would probably get a better answer at serverfault.com.
I'm not sure how much it would help perf, if SQL isn't getting hit it doesn't do much. You could probably get away with uninstalling, but then again when in surgery bad things happen. I've never killed SQL server uninstalling an instance, but I have killed the client tools. I would take one of the following approaches:
a) First, backup and drop all the databases to reclaim the disk space. Then stop disable the services for the named instances. The binaries will still be there, but they aren't too large and will be sitting idle.
b) Better long-term plan if you can source the hardware is to setup a new de novo box and drop a clean SQL instance over there, then port the live server over. Really not too painful. Then repurpose old box as is fit.
Is there a critical reason why you need to uninstall named instances. Can you just ignore them?
EDIT: the answer is yes you can uninstall via add/remove programs
Rebooting doesn't occur
An article which might apply to your situation:
http://support.microsoft.com/?kbid=915854
I'm running Sql Server Management Studio 2008 on a decent machine. Even if it is the only thing open with no other connections to the database, anything that has to do with the Database Diagram or simple schema changes in a designer take up to 10 minutes to complete and SQL Management Studio is unresponsive during that time. The same SQL code takes less than a second. This entirely defeats the purpose of the designers and diagramers.
------------------
System Information
------------------
Operating System: Windows Vista™ Ultimate (6.0, Build 6001) Service Pack 1 (6001.vistasp1_gdr.080917-1612)
Processor: Intel(R) Core(TM)2 Quad CPU Q6700 # 2.66GHz (4 CPUs), ~2.7GHz
Memory: 6142MB RAM
Please tell me this isn't a WOW64 problem; if it is, I love MS, but step up your 64-bit support in development tools.
Is there anything I can do to get the performance anywhere near acceptable?
Edit:
I've got version 10.0.1600.22 of SQL Server Management Studio installed. Is this not the latest release? I'm sure I installed it from an MSDN CD and I pretty much rely on Windows Update these days. Is there any place I can quickly see what the latest release version number is for tools like this?
Edit:
Every time I go to open a database diagram I get the message "This database does not have one or more of the support objects required to use database diagramming. Do you wish to create them?" I say yes every time. Is this part of the problem? Also, if I press the copy icon, I get the message "Current thread must be set to single thread apartment (STA) mode before OLE calls can be made." Database corruption?
I'm running in a similar environment and not having that problem.
As with any performance problem, you'll have to analyze it a bit - just saying "it takes 10 minutes" give no information on the reason it takes so long, so no information you can use to solve the problem.
Here are some tools to play around with. I'd have mentioned them originally, but "play around" is all I've learned to do with them. I'd recommend you try learning a little about them, which I have not done. http://technet.microsoft.com is a good source on performance issues.
Start with Task Manager, believe it or not. It's been enhanced in Vista and Server 2008, and now has a better Performance tab, and a Services tab. Be sure to click "Show processes from all users", or you'll miss nasty things done by services.
The bottom of the Performance tab has a "Resource Monitor" button. Click it, watch it, learn what it can do for you.
The Resource Monitor is actually part of a larger "Reliability and Performance Monitor" tool in Administrative Tools. Try it. It even includes the new version of perfmon, which will be more useful when you have a better idea what counters to look at.
I will also suggest the Process Explorer and Process Monitor tools from Sysinternals. See http://technet.microsoft.com/en-us/sysinternals/default.aspx.
Do your simple schema changes possibly mean that you're reordering the columns of a table?
In that case, what SQL Management Studio does behind the scenes is create a new table, move all the data from the old table to the newly created table, and then drop the old table.
Thus, if you reorder columns on a table with lots of data, lots of indices or both, you CAN incur a massive amount of "reorganization" work without really realizing it.
Marc
Can you try connecting your SQL Management Studio to a different instance of SQL Server or, better, an instance on a remote machine (and try to make similar changes)?
Are there any entries in the System or Application Event Logs (or SQL logs for that matter)? Have you tried uninstalling and reinstalling SQL Server on your machine? What version of SQL Server (database) are you running?
Lastly, can you open the Activity Monitor successfully? Right click on the server (machine name) - top of the three in the object explorer window - and click on 'Activity Monitor'.
Do you have problems with other software on your machine or only with SQL Server & Management Studio?
When you open SSMS it attempts to validate itself with Microsoft. You can speed this process by performing the second of the recommendations at the following link.
http://www.sql-server-performance.com/faq/sql_server_management_studio_load_time_p1.aspx
Also, are you using the registered servers feature? If so SSMS will attempt to validate all of these.
It seems as though it was a network configuration problem. Never trust a developer (myself) to setup a haphazard domain at his office.
I had my DNS server on my computer pointed to my ISP's (default because the wireless router we're using provided by the ISP doesn't allow me to override the DNS server to my own) instead of my DNS server here, so I have to remember to configure it manually on each computer, which I forgot for this particular computer.
I only discovered it when I tried to connect for the first time to a remote SQL Server instance form this PC. It was trying to resolve to an actual sub-domain of mycompany.com instead of my DNS server's authority of COMPUTERNAME.corp.mycompany.com
I can't say why this was an issue for the designers in SQL Server but not anything else, but my only hypothesis is that when I established a connection to my own computer locally using the computer name instead of "." or "localhost", SQL queries executed immediately, knowing it was local, but the designers still waited for a timeout from the external IP address before trying the local one.
Whatever the explanation is, changing my DNS server for my network card on the local machine to my DNS server's IP made it all work very quickly.
I had a similar issue with mine. Turned out to be some interference with the biometrics login service running on my laptop. Disabled the service and now it works.