Just to make it clear, my objective is to reproduce an environment similar to a TFS 2013 that someone backup from.
The backup (full) was made manually from SQL cause TFS is reproducing an error in the attempt of it and I'm trying to fix this error in a test environment.
Which way should I use SQL to backup it?
How should i restore and map TFS in the new server to understand it?
Note: The backup was created by an user that does not exist on the test machine;
Note²: I have the .bak's files (Tfs_configuration, Tfs_DefaultCollection and Tfs_Warehouse).
I can paste the error log of TFS if needed.
The whole process is well documented, it's easiest when you have a Full TFS backup from the Administration Console, that way you're sure to have all the databases in their right state.
The process to follow is quite extensive, make sure you follow each of the steps. If the environment you're restoring from didn't have the backup feature built-in (it was added in one of the update packs), then you can get it by installing the Team Foundation Server Power Tools on the Application Tier server.
To update the accounts use:
https://msdn.microsoft.com/en-us/library/ms404869(v=vs.120).aspx#UpdateNetworkService
It looks like you may have all the databases required, though it's possible there are more. To restore TFS to a new environment, you need all the databases that belong to the installation.
Related
Hello we have some SSIS packages with XML file configurations. Basically we configure the database connection, password, etc. to run the packages in different environment (Production vs. Testing). We use a 3rd party software to run our SSIS packages on target SQL servers. The packages run fine on our Testing environment, however fail miserably on Production server. The difference is SQL server on testing is vs. 2016, while on Production only 2012.
There are various error messages on why they fail on production, some of them about "Failed to load at least one of the configuration entries for the package..". And then there are some that cannot login to the database connection provided in the XML files, even though the info is 100% correct.
Does anyone know if XML config file is not supported in SQL 2012?
You really shouldn't be going from a test environment that's a different version than your production environment, it will only lead to more headache in the future.
If you can't upgrade production then I'd suggest getting another test system on the same version as production.
That being said...
The functionality is there in 2012, but the format probably isn't the same.
You need to set the TargetServerVersion to SQL Server 2012 in Visual Studio under Project > Properties and build the project again.
Project Properties
I have seen other posts about this topic where some of the suggestions lead people to check the ProtectionLevel to DontSaveSensitive. I have made sure that is set to DontSaveSenistive, as well as I have checked permissions and made sure where the files/dtsx files are getting called from have ample permissions set for the service account which owns the SQL Agent.
The odd thing is this process was working fine until i went into one of the previous dtsx files and had to update a datatype precision to go from a limit of 1 character to 30 characters. That was literally the only change made to the process, but now I am getting this error. I have gotten this error before, which is when I was set on the path to checking protection level and permissions/ownership. For some reason it went away and began working when i made those changes. None of that stuff (permissions/ownership) is incorrect this time around yet I am getting that same error.
Another weird thing about the process is that it is only the last step which is failing (the FTP step.) When I try to go in and execute the psftp.exe and put in the command which is being passed normally through SSIS execute process task step, the psftp.exe is telling me that the port number is incorrect..yet when I test connection on the connection manager inside VS with the exact same port, it says connection successful.
This error is vague and confusing!
I would love some guidance on some more things to try.
thank you !
SSIS tooling and version
SQL Server 2008 and 2008 R2 can only be edited using Visual Studio 2008 which has the Business Intelligence Design Studio templates installed. Those can only be acquired by having the physical SQL Server iso handy. Developer edition will work, but you need some form of licensed media to get BIDS working.
Visual Studio 2013 is going to attempt to upgrade 2008/R2 to the internals for a SQL Server 2012 installation. There is no going backwards/downgrading once this is done.
Any tooling (dtexec, dtutil, etc) you use must be from the same version otherwise, the first thing the binaries do is update the package to match that version. For execution (dtexec), each time you run a package, there is a delay as the original is upgraded in memory to match and then execution begins (assuming all goes well). It sounds like it's not based on
The package failed to load due to error 0xC0010014...
For deployment (dtutil), you only pay the price of upgrading once and then it's upgraded forever. Which probably isn't what you wanted. Be aware that tools like Visual Studio and SSMS "know" which version of tooling they are associated with so deploying from SSMS 2016 can result in the binaries for SQL Server 2016 SSIS upgrading your 2008 package to 2016 format and then attempting to deploy the now upgraded bits to your 2008 box. It's all very frustrating and not intuitive.
From your comment "In the 2008 version, the play button is greyed out..." That indicates you have opened a File in Visual Studio that is an SSIS package. Visual Studio will open it and paint all the icons on there but it can't actually run a package unless you have an Integration Services project open (and have the BI templates installed).
Assuming you have source control, you can rollback the change that broke everything and try to edit the package properly.
Execute process task
You have an Execute Process Task that is invoking psftp.exe and it's generating a 1 versus a 0. Is that bad? Based on previous workings with SFTP clients, they're rather picky so running it as me on production would fail since I didn't have whatever bits associated to my domain account but the service account had all the right things in their profile and it would run just fine - same machine, same package, just different user.
I currently have a ETL system running on SQL Server 2014, it used to be using individual package deployment method. We recently changed it to use the new SSISDB project deployment method.
The issue is these same packages with no other changes take roughly twice as long as the old deployment method. I understand a lot of overhead may have been from the logging that is set to 'Basic' by default for project deployments. I changed that to none with some improvement, but still far slower than our old deployment model, or even running the packages locally in visual studio.
Based on my research this is because 'None' still logs quite a bit of information to SSISDB which is causing a huge overhead. Previously we only logged errors by email with the Package Deployment Model, but with the Project Deployment Model that is not the case, and as I understand I cannot log less information in Sql Server 2014 when using this deployment model, as custom logging was only introduced in 2016.
Has anyone else had this issue and come up with any solution? Preferably a solution that isn't "switch back to Package Deployment Model" or to upgrade to 2016 which will not be in the near future. Currently I have tried and index on internal.executables from the SSISDB database. referencing this article http://www.argento-it.co.uk/ssis/ssisdb-slow/
This did not improve the situation at all, with the run time remaining the same
I have been using a database project in visual studio 2010 to create a database. Visual Studio makes this process really easy to deploy the database and deploy updates. The issue I have is how I can get visual studio to create a script that will build the database that I can use on a QA or production system.
I thought that building the project would create a SQL file that did this but this does not seem to be true. Can someone please advise on how I can do this or what simple step I am clearly missing.
As strange as it may sound, Visual Studio does not create a SQL file to deploy your database when you perform a Build.
Instead, this occurs at Deploy time. The reason behind this lies in the way that Visual Studio makes changes to the database that you're deploying to: in order to change your database, it must first compare the project model (as defined in the files contained within the .dbproj) with that of the existing database schema to determine what changes you have made since the database was last deployed.
You then have the choice of manually executing the SQL script produced using the SQLCMD command-line utility (or through SSMS in SQLCMD mode), or alternately you can configure your Visual Studio Database Project to execute the script if you specify the following Deploy Action in project settings:
Generate a deploy script (.sql) and deploy to the database
Note that you will need to provide a connection string in project settings so VS knows where to deploy to.
When you get to the stage where you want to deploy to a QA or PROD environment, you have a couple of options:
Deploy directly within Visual Studio. In addition to the standard Debug and Release configurations that you get when you first create your Database Project, you can also create your own configurations which you could use to deploy to your QA and PROD environments (i.e. potentially with a different connection string/target database name).
Deploy from a Build Server. Install Visual Studio on a separate machine and call MsBuild against your .dbproj/.sln file with the Build and Deploy targets specified along with the appropriate connection properties.
Doug Rathbone has written a great blog post on subject if you want to learn more:
http://www.diaryofaninja.com/blog/2011/06/23/compare-amp-update-database-schemas-right-within-your-ide--part-2-automation-with-teamcity
Best practices or tools for installing a SQL Server database
I have a SQL Server database designed with the SQL Server GUI database editor/Visual Studio.
What is the best way to "install" that database on other systems. Said another way how should I ship this thing?
I know I can save the scripts and set the primary/foreign keys with T-SQL but I suspect their is something better. I guess you could have people restore from backup but that does not seem very professional.
What other choices are there and what are the pluses and minuses?
For it to look professional make a small setup program.
You currently have sql scripts that you use to create your db.
Make yourself a small xml file that contains the path to your scripts.
Create a small c# library that will connect to the db server, and run those scripts.
You can test this outside of the setup, in visual studio, then add it to the setup like this.
To do this from your setup all you have to do is put the xml file in a component so it is deployed,
And create a custom action in your setup, that will call your C# lib, read the xml and run the scripts on the sql server to create your db.
Also, from a setup program it's easy to set a registry key to identify the version of the your db that you just installed.
The minuses and pluses: It's a bit of work to start with, but with this you'll have all the ground work done to handle upgrades automatically later on, to do so, just add an upgradeScript section to your xml, an attribute called version for each upgrade script, and simply compare it against the version of the db you have save in the registry. The advantage is this way it can easily scale with your project.
My previous answer is mostly to keep full control on the deployment and upgrades.
I have searched for more built-in and streamlined solution that goes along with the DB designer mode you have used.
I found that in the version Studio 2005 Team Edition for Database Professionals of visual studio there might be deployment features.
Build and Deployment
You've seen that you can generate a
T-SQL update script manually via the
Schema Comparison tool. However, as
part of the build process, DB Pro
edition can generate a complete script
for deploying your database project.
This deployment script can do either a
complete build or an incremental
update. The build process can even
consolidate all of your pre- and
post-deployment scripts into one
complete deployment script. You can
deploy the script via the Build |
Deploy Selection command right from
within Visual Studio 2005. Under
project properties, you will find a
number of options to control and
adjust the build process. The Build
tab contains the core settings, such
as Target connection, Target database
name, and Block incremental deployment
if data loss might occur. You'll note
there is also a Build Events tab that
you can use to type pre- or post-build
event commands. DB Pro edition uses
MSBuild for its build process and
supports integration with Team Build
if you're using Team Foundation
Server.