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.
Related
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.
What's the best way to approach the above requirement?
I can work with PowerAutomate, but I'll still need to create SSIS package to run additional processing once the data has been loaded to SQL. Making PA approach to have 2 sets of solution.
Another reason for SSIS, I'd like to version control this and use Azure DevOps' CI/CD for builds and releases.
What's the best way, if I were to use SSIS purely to achieve this?
I need to create recurring job in which I have to map two SQL Server databases which are on two different servers. I need to check the data mismatch in both the tables in regular intervals because new data keeps on adding every second.
I am thing to use anyone of the ETL tool like kettle pentaho which will actually do the data mapping. Do we have any other better option to handle this scenario.
This seems a ETL job approach, as long as you're using SQL Server I would recommend you use SSIS, is the Microsoft ETL tool. Of course you can use Pentaho and I think it will work very good also.
Another approach would be use linked servers and a job, writing the script as a stored procedure, but in my opinion this is not a recommended way to address the problem (SSIS or any ETL tool is so much versatile).
I have a client who has been promised that he will get a regular copy of the database behind the application we are hosting for him.
The copy is in fact a backup (DB_EXPORT.BAK) that he downloads through SFTP.
(I know, I did not make that promise). I do not want to give him the whole with all the proprietary stored procedures, functions, users and other stuff. I want to give him a slimmed down version of that database with most tables, only selected sp's, some functions, no users and so on.
As I see there are two ways to do this:
a SSIS job that copies certain stuff (using Import/Export Wizard)
replication (snapshot or transactional)
The thing is: the original (DB1) AND the copy (DB_EXPORT) will be hosted on the same server. So using replication feels a bit awkward (publishing to yourself?) but it does give an easy interface for configuring which articles to replicate. Using a SSIS package feels more logical but is actually hard to change.
What can you say about this? Is there a better way for doing this? I am looking for a way that will allow people who just about understand SQL server wil be able to understand.
Thanks for thinking with me!
Not sure if this is the best answer, but I would go with snapshot replication per our discussion, and your avoidance of TSQL scripting.
Replication is relatively simple to setup, but can be a nightmare to troubleshoot (esp. transactional). Often times, its easier to completely delete the publication/subscription and rebuild.
On that note, you can fully script replication configurations -- if someone else has to maintain this, it may be as simple as you scripting out the replication removal (pub and sub removal), and scripting out the replication build-out. All they'd have to do is run the drop/build scripts and it's done.
You can also alter the scheduled job to run the backup immediately following the snapshot generation.
I'm trying to find out if this is possible, but so far I haven't found out any good solutions. What I would like to achieve is write a stored procedure that can clone a database but without the stored data. That means all tables, views, constraints, keys and indexes should be included but without any data. Can it be done?
Sure - your stored proc would have to read the system catalog views to find out what objects are in the database, determine their potential dependencies, and then create a single or a collection of SQL scripts which re-create the database, and execute those.
It's possible - not very nice and easy to do. Especially the dependencies between objects might cause more headaches than first meets the eye....
You could also:
use something like SQL Server Management Studio (if you're on SQL Server - you didn't specify) and create the scripts manually, and just re-execute them on a separate server
use a "diff" tool like Redgate SQL Compare to compare two servers and have the second one brought up to date
I've successfully used the Microsoft SQL Server Database Publishing Wizard for this purpose. It's pretty straightforward, no coding needed. Here's a sample call:
sqlpubwiz script -d DatabaseName -S ServerName -schemaonly C:\Projects2\Junk\ DatabaseName.sql
I believe the default is to create both data and schema, but you can use the schemaonly parameter.
Download it here
In SQL Server you can roll through the system tables (sys.tables, sys.columns, etc.) and construct things one at a time. It's going to be very manual and error prone at the beginning, but it should become systematic pretty quickly.
Another way to do it is to write something in .Net using SMO. Check out this link:
http://www.sqlteam.com/article/scripting-database-objects-using-smo-updated