We performed a rmelem on a softlink (vob element) on doing this it got deleted from integration stream too.
Is there a way using which we can recover/undo the changes especially on the integration stream.
You can restore an individual element from backup using the process at:
IBM: Restoring an element from backup
Related
We have a TFS2017 environment. The size is growing every week for a long time now.
In this environment , i have multiple collection ; the size of Transaction Log File , is very big (overtop the 155 Gb)
My question is : It's safe to do a shirnk of the log file for the defined TFS collection ? (without loss data or getting error in administration console) ?
Thanks
Yes. You can.
The log file is there so you can restore to a point in time between full backups. If you have backups enabled on your server and regularly take a full backup, then you can truncate the logs after each full backup.
If you want to just "delete the logs" then temporarily turn off TFS by running this on every application tier server you have: TFSServiceControl quiesce, then truncate the logs, then turn TFS back on using TFSServiceControl unquiesce.
You may also want to verify your backup strategy. If all is well, you shouldn't see a ever growing log file.
See:
https://learn.microsoft.com/en-us/azure/devops/server/command-line/tfsservicecontrol-cmd?view=azure-devops-2019
I have found myself in a very strange situation: what used to work before does not work anymore.
I'm trying to restore an Adventureworks backup on a SQL Server running on an Ubuntu machine with this T-SQL code:
RESTORE DATABASE AdventureWorks2017
FROM DISK = '/home/sergey/AW/AdventureWorks2017.bak'
WITH MOVE 'AdventureWorks2017' TO '/home/sergey/AW/AdventureWorks2017.mdf',
MOVE 'AdventureWorks2017_log' TO '/home/sergey/AW/AdventureWorks2017_log.ldf'
GO
But I'm getting an error:
[S0001][3142] File "AdventureWorks2017" cannot be restored over the existing "/home/sergey/AW/AdventureWorks2017.mdf". Reissue the RESTORE statement using WITH REPLACE to overwrite pre-existing files, or WITH MOVE to identify an alternate location.
This blog post seem to talk about a similar issue, but the recipes mentioned does not work.
Any help is highly appreciated!
The error message states, that the target file already exists.
Try
RESTORE DATABASE AdventureWorks2017
FROM DISK = '/home/sergey/AW/AdventureWorks2017.bak'
WITH MOVE 'AdventureWorks2017' TO '/home/sergey/AW/AdventureWorks2017.mdf',
MOVE 'AdventureWorks2017_log' TO '/home/sergey/AW/AdventureWorks2017_log.ldf',
REPLACE
GO
The full documentation for the RESTORE Transact-SQL command can be found here.
I want to create a copy of my sql server 2008 r2 database (named ERP) inside the same machine. so I did the following steps:-
I right click on the original database ERP and I select Tasks>>Backup.
then I create a new empty database named "ERP_Copy".
I right click on the ERP_Copy database, then select restore>>database.
inside the restore options I define the To to be ERP_Copy and the From to be ERP.
then I click to start the process, but I got the following error :-
so can anyone advice on these 2 questions:-
what is causing this error ?
could my original database ERP got corrupted or modified due to the error ?? or my ERP should not be modified by my above operation and the error I got ?
Thanks
the error is as stated in the message: you are restoring on a target database that is not the one used as the backup source.
To solve and complete the restore, start the restore, go to the Options page and tick the Overwrite the existing database (WITH REPLACE) checkbox.
DOUBLE CHECK source and destination database because the above checkbox would completely smash your production db if you make the wrong choices...
The original database has not been altered by the first (failed) operation.
I am trying to programmatically create and connect to an application specific LocalDB database. I would like to do this by specifying the file name of a .MDF file only, ideally without specifying an instance name or a name for the database that gets registered anywhere.
The database is to be accessed from some unit tests so it will only be used for a brief time before being deleted. My current approach creates the .MDF file correctly but also registers the name with the default instance which I would like to avoid given the temporary and 'non-singleton' nature of the database instances.
Is it possible to do what I am trying to do, or have I misunderstood how LocalDB works?
LocalDB automatic instance with specific data file
Server=(localdb)\v11.0;Integrated Security=true;
AttachDbFileName=C:\MyFolder\MyData.mdf;
Update
This can be used with the Deployment area in your .testsettings file. You just need to check 'Enable deployment' and add both the .mdf and .ldf files to 'Additional files and directories to deploy'.
You can then simply use the connection string above, and the test runner will take care of moving your data files to an appropriate temp folder for you.
Chrisb's answer got me on the right lines to solve this, but I noticed that the database remained attached to the default instance in LocalDB even after the connection had been closed. I read that this might eventually be purged after a few minutes but in my case this was too long as the file was located in a temporary directory used by MSTest and had to be closed in time for the cleanup at the end of the test run.
The solution was to use a connection string similar to https://stackoverflow.com/a/26712648 and a detach process similar to https://stackoverflow.com/a/6646319 immediately after I had finished using the connection.
Creating the MDF file in the first place could be accomplished by connecting to the automatic LocalDB instance, executing CREATE DATABASE and then using the same detach method. By using the file name for the database name, which is allowed in LocalDB due to the much longer names permitted, I ensured beyond reasonable doubt that the database name will not clash with anything else on the computer even during the short period it stays attached.
Access file not opening. Error Message: The Microsoft Access database engine stopped the process because you and another user are attempting to change the same data at same time.
It is not repairing / compacting through database Jet Engine.
Are you positive you are the only user in the database? If it's on a network drive, try copying it to your local hard drive, doing the compact/repair there, and then copy it back to the network. If it's on your local drive, try rebooting your computer, deleting the .LDB locking file in the same directory as your database (if it exists) and compact/repair again.
I know the original question was posted half a year ago so this is too late to help the poster.
If there is no .ldb file, the database is copied locally (so no possibility of it being locked), you can't repair and JetComp (download from Microsoft) also won't repair then your database is corrupt and the only way forward is to restore from a backup. Sorry.