At this time I have one server with a few databases. I have to move Transact-SQL jobs to SSIS packages (company's policy, so I have to do it).
The advantage of the T-SQL is that I can identify really fast if we have modifications (msdb.dbo.sysjobsteps). If I moved the scripts to SSIS Execute SQL tasks, it will be really hard.
I read a lot of post about this topic, but I didn't find the answer.
If I put the scripts into stored procedures and use it in Data Flow tasks, will I lose performance? If yes, do you have any idea how do I search quickly in SSIS packages without opening those?
f I put the scripts into stored procedures and use it in Data Flow tasks, will I lose performance?
Shouldn't. And dynamic SQL in stored procedures will be identical to a TSQL job step.
If yes, do you have any idea how do I search quickly in SSIS packages without opening those?
SSIS packages are XML files. And SSIS projects can be easily managed in a source control system with Visual Studio. This really is a better way.
Related
I know this topic is a bit general but I do have a specific use case. Does the logging utility in SSIS have any specific advantages, or additional information, over the internal logging of the SSISDB?
My environment contains packages, which are executed via the stored procs in the SSISDB. We have a separate table that tracks the executionid of each package as they are processed and reports the statuses back to the user through a web application.
I am trying to have some foresight. So far I have been monitoring the event_messages, operations and executions table in SSISDB and it has been completely sufficient in debugging and troubleshooting so far. SSISDB seems to keep track of the exact same information that SSIS logging does.
Are there any discrepancies or differences, other than the obvious data structure differences, between the SSISDB tables and SSIS package logging? Specifically, does SSIS logging have any additional information that the SSISDB does not record? I would rather not have to come back and update all of my SSIS packages (and sprocs, and application...) later if I can avoid it.
I'm hoping someone else has come across this scenario and has some insight. Thanks!
Started on a project a year or so ago and set up both types of logging, with the same fear you have. I can safely say it was a complete waste of time and I only ever use the SSISDB execution reports.
I highly recommend you check out custom SSISDB logging options if you haven't already.
https://www.timmitchell.net/post/2016/12/22/ssis-custom-logging-levels/
I need to copy all databases from server1 to Server2, i saw with SSIS is possible transfer objects with "Transfer SQL Database Task", but it works just for one database.
It's possible coppy all databasses from server1 to server2 using SSIS ?
Best Regards:
Why don't you simply backup your database(s) on the old server?
And after that simply restore your database(s) in the new server.
However if you want to use SSIS, simply start the TransferDatabaseTask for each database.
To do this with SSIS I would recommend using BIML. If you create a table with all of your mappings in it you can use BIML to iterate over that and create the SSIS packages for you. Or you could create a callable BIML script and repeat over it yourself. BIML is perfect for generating these kinds of repeatable patterns in SSIS.
This article has an intro on how to automate SSIS design patterns. While this is more difficult to use it works really well once you have it done.
Cathrine Wilhelmsen's blog has some examples on reusing biml as well. This method is much easier to get started with.
I am just starting to use the Enterprise version of SQL Server 2014. I am completely new to Integration Services and need to use it to call stored procedures asynchronously.
Is using SSIS different from using SQL Server Agent? I am aware of SQL jobs and agents to execute stored procedures asynchronously. Is there any other way to do it using SSIS?
What I really mean to ask is Is there any other way to use SSIS for asynchrnous execution besides this?
Also, Can I get guidance on how to start with it as I am completely raw with SSIS.
Yes. Just create your tasks (such as Execute SQL Task which can invoke stored procedures) in parallel. Make sure the arrows don't lead into each other. SSIS will invoke the tasks simultaneously.
Is there a way to backup/track changes to SQL stored procedures in SVN or any other method for tracking changes to SQL? I am using SQL 2008 and am not a DBA but am in charge of a small companies database.
TIA,
Brian Enderle
You might try Red Gate's SQL Source Control and SQL Compare to track changes.
We write procs and save them in Subversion as scripts. You check in each version of the script and then you can easily see previos versions or do a diff between them. If youwant to reduce unnecessary diffs from formatting, get a SQL formatting tool and have everyone format the same way before check in.
All SQL code should be handled this way not just procs. We store table strutures, views etc in Subversion. Of course with tables you havea create script and then alter table table scripts for each change in order, so that you don't wipe our tables with existing data by doing a drop and recreate. We also script out inserts to lookup tables to make them easier to port to other servers as well.
You can store it in svn, but it will have difficulty tracking exact changes if members of your team use different tools to write sql: postgresql seems to be particularly bad at formatting sql. You could consider using a free formatter: Eddie Awad lists some here:
http://awads.net/wp/2005/12/12/format-your-sql-the-easy-way/
Committing your code to source control depends on how you arrange your projects: your scripts could exist in a "misc" folder in an eclipse/visual studio project, or directly committed to svn via TortoiseSVN.
I have two suggestions for you (which I have both used myself):
you can use ScriptDB in order to extract the database schema to your file system and then commit it to svn. I actually set up a scheduled task which invokes ScriptDB every night and then commits the folder to svn (which only commits actually modified files) automatically.
If you are using VS2010 you can open a database project and synchronize it periodically with your database via the schema compare option from the data menu. After that you can commit your changes via tortoiseSVN or Ankh directly from VS.
I have a 'reference' SQL Server 2005 database that is used as our global standard. We're all set up for keeping general table schema and data properly synchronized, but don't yet have a good solution for other objects like views, stored procedures, and user-defined functions.
I'm aware of products like Redgate's SQL Compare, but we don't really want to rely on (any further) 3rd-party tools right now.
Is there a way to ensure that a given stored procedure or view on the reference database, for example, is up to date on the target databases? Can this be scripted?
Edit for clarification: when I say 'scripted', I mean running a script that pushes out any changes to the target servers. Not running the same CREATE/ALTER script multiple times on multiple servers.
Any advice/experience on how to approach this would be much appreciated.
1) Keep all your views, triggers, functions, stored procedures, table schemas etc in Source Control and use that as the master.
2) Failing that, use your reference DB as the master and script out views and stored procedures etc: Right click DB, Tasks->Generate Scripts and choose your objects.
3) You could even use transactional replication between Reference and Target DBs.
I strongly believe the best way is to have everything scripted and placed in Source Control.
You can use the system tables to do this.
For example,
select * from sys.syscomments
The "text" column will give you all of the code for the store procedures (plus other data).
It is well worth looking at all the system tables and procedures. In fact, I suspect this is what RedGate's software and other tools do under the hood.
I have just myself begun experimenting with this, so I can't really be specific about all the gotcha's and what other system tables you need to query, but this should get you started.
Also see:
Query to list SQL Server stored procedures along with lines of code for each procedure
which is slightly different question than yours, but related.
I use (and love) the RedGate tools, but when Microsoft announced Visual Studio 2010, they decided to allow MSDN subscribers who get Visual Studio 2008 Team System to also get Visual Studio 2008 Database Edition (which has a schema compare tool).
So if you or your organization has an MSDN subscription, you might want to consider downloading and installing the Database Edition over your Team System to get all the features now.
More details at http://msdn.microsoft.com/en-us/vsts2008/products/cc990295.aspx
Take a look at ScriptDB on Codeplex (http://www.codeplex.com/ScriptDB)
It is a console C# app that creates scripts of the SQL Database objects using SMO. You can use that to compare scripts generated on two servers. Since its open source, adjust it if you need it.
Timur