Tag Info

New answers tagged

1

First thing if transaction log is not damaged you should go for tail log backup. That would cause minimal data loss. Then restore would be Weekly full backup with no recovery 10:05PM Differential backup with no recovery All log backups after this differential backup with no recovery and finally tail log backup with stopat command with recovery Please ...


4

You need to restore last FULL backup, the Differential, the 10:15 transaction backup and the 10:30 one with the STOPAT = '2015-05-22 22:24:00' clause.


0

Someone sent me a compressed gtar. Wasn't even too familiar with gtar, but it is another compression format. $ file core_production-1432173533.sql.gtar core_production-1432173533.sql.gtar: gzip compressed data, from Unix, last modified: Wed May 20 21:59:31 2015 However, I was able to decompress it the same as usual: tar -zxvf ...


1

I tend to use OFFLINE strictly because on active instances trying to set a database to SINGLE_USER and be the single user that connects is not always consistent. If you set it offline that is it, it is offline. I will also add that a better practice to do the restore is to have the application stopped or block access from the server. This will save from ...


1

The last LSN of the FULL BACKUP should match the Last LSN of the log backup. This will be your first log backup and then after that the consecutive log backups will be having A.LAST_LSN = B.FIRST_LSN --> where B = log backup taken immediately after A. From BOL : Now look at the error you are getting : The log in this backup set begins at LSN ...


1

You are trying to apply a Log file that finish with LSN 421814812000000025600001 into a DB restored with LSN 421787067000000013800001 , so, the LSN of the Full Backup (restored) is older than the log file that is trying to apply. So, the log file would not possible to apply , being a change in sequence. So possible cause here being that you are not ...


4

I would set it offline. I say this because SINGLE_USER mode is generally used to allow an administrator to perform some kind on maintenance on a database without users attempting to access and possibly interfering with the maintenance. It doesn't really matter either way for a restore as your users will experience the same thing which is they wont be able ...


3

I would just go with your script with a little modification. Add a waitfor delay. Also, make sure that Instant file initialization is enabled to cut down the restore time. --first command use master go -- second command alter database MyDB set SINGLE_USER with rollback IMMEDIATE waitfor delay '00:00:05' -- 5 sec delay .. no other spid takes our space ...


3

Running this all at once does not guarantee that no one will open a connection between you putting it in single-user mode and you starting the restore. Instead, you can put the database in offline mode rather of single-user mode to avoid this problem. E.g. ALTER DATABASE MyDB SET OFFLINE WITH ROLLBACK IMMEDIATE;


3

You can run the following code to see how much longer a backup or a restore will take. It also tells you how long a DBCC checkdb will take and a few other commands as well. SELECT session_id, command, s.text, start_time, percent_complete, CAST(((DATEDIFF(s,start_time,GetDate()))/3600) as varchar) + ' hour(s), ' + ...


0

Not sure what you expect from partial backups, but they are only useful for read-only filegroups: partial backups are designed for use under the simple recovery model to improve flexibility for backing up very large databases that contain one or more read-only filegroups. Differential backups are a different story, but they are not used as you use ...


8

This information is not tracked in MSDB, so there's no way to find it there (unless the restore operation is in its own step in a job, in which case you could get it from msdb.dbo.sysjobhistory). If you can't rely on job history, and it was recent enough, you can approximate it from the default trace, with the assumption that the system does something to ...


2

You can use somewhat of below script to view details of last restore for a particular database. DECLARE @dbname sysname, @days int SET @dbname = 'DB name here' --substitute for whatever database name you want SET @days = -3 --previous number of days, script will default to 30 SELECT rsh.destination_database_name AS [Database], rsh.user_name AS [Restored ...


3

First things first, before you restore anything - back up your log with no_truncate. If your database is offline, then take a copy of your LDF file first, then bring your database online, ignoring any errors, and then do your log backup. This log backup is then the last one in your recovery process, which involves a full database backup which doesn't have ...


2

You start by making a tail of the log backup of the damaged database, backup log database to disk = 'disk' with no_truncate. You then restore the database from your last full backup backup, with no recovery and then restore your all your log backups ending with the one you made with no_truncate see this kb article: ...


0

If you can setup a linked server to the source database server you can simply do a restore from the last backup device containing a full database backup by finding the last backup file like this: Declare @Database sysname = 'a' Declare @BackupFile NVARCHAR(1024) select @BackupFile = bf.physical_device_name from (select MAX(ISNULL(bs.backup_finish_date, 0)) ...


0

First I agree you should not migrate from 2000 to 2012 directly. I think that process has been covered well. I wanted to suggest you find out for sure if anyone is using the databases and what they are using them for. It may be that they are not being used. It happens and if that is the case then you have no worries. It might be that adding 2 or 3 tables and ...


0

You say you "have come across three old databases sitting on SQL Server 2000" which leads me to believe you only need the data. I would guess that if they were being run for a purpose, you would know. If this is the case, ignore all questions of users, security, etc. Import/Export wizard all the tables Script the stored procedures and views Check for ...


0

You can not migrate directly from SQL Server 2000 to SQL Server 2012, and if you try to do it you will get the following error number 3169, that is related to compatibility issues. The migration to SQL Server 2012 can be done from one of the following versions (minimum versions) SQL Server 2005 SP4 or SQL Server 2008 SP2 or SQL Server 2008 R2 SP1. So ...


6

Stating there is no workaround seems a little premature. You say your database only contains a few tables and views. Why not export the tables and views schema as SQL create statements and run them on your target database? You could then also export the actual data into something like CSV format and import them into the target database, or perhaps even ...


17

No, there is no workaround to upgrading a database directly from 2000 to 2012. Since you don't have a ton of data, you can do all kinds of things to move the data (but not the database as a whole), including: Import/Export wizard SSIS BCP Manual queries using a linked server from 2012 or an application However these will not necessarily bring over other ...


2

No, you cannot migrate it directly from 2000 to 2012. What you can do is install a temporary instance of 2005 OR 2008 oR 2008R2, restore the 2000 database here. Once done you can now upgrade from installed instance by taking the backup of database from that instance and restoring onto sql server 2012. You will have to make the migration in two steps: ...



Top 50 recent answers are included