New answers tagged

0

That won't work. As soon as you recover the database after restore, that begins a new timeline for the database. If this is an on-going process, one possible solution is to get the team generating the backups to take a differential every day which will have fairly low impact on effort and system load. This is in addition to what they currently have. ...


1

There is an API called db2ReadLog() that you can use to read transaction logs and collect information about deleted records. IBM also sells a product called Recovery Expert that will help you do this and generate undo SQL statements.


1

Database or tablespace recovery is the only* way to go back in time and find deleted records if you haven't planned for this. To minimize the impact on the production environment you can always perform a restore on a different machine, export the records and import them in production. That does not require any downtime. HADR with delayed replay, possibly in ...


1

EDIT: I've finally managed to get the database restored. It took only 124 minutes, when we changed some settings on the server. I found the settings here: https://support.microsoft.com/da-dk/kb/2160002 and here https://technet.microsoft.com/en-us/library/cc778996.aspx


-2

Yes, Ian is correct here. I am sure your issue is resolve now. Also, archive logs can still exist in Active log path if we set LOGARCHMETH1 to LOGRETAIN correctly . Details at Information Center can give better overview .Hope it helps !


0

One can even search and replace each occurrence of Insert into with Insert Ignore into in the mysqldump file.


3

When I see messages of that nature, I usually blame the redo logs. This is where is LSN is written. The problem may stem from not preparing the incremental backup. What seems to be missing is the use of the --prepare option. What this essentially does is create the backup rolled forward to a specific point in time. This is particularly true if there were ...


1

You are trying to restore a 45GB database with 32GB memory on the server. What you can do is bump up the memory (RAM) on the server and play with Stripe your backup to multiple LUNs or disk. Use BUFFERCOUNT, BLOCKSIZE, MAXTRANSFERSIZE backup parameters along with INIT & COMPRESSION (you are using it as I see from your output) to tune your backup. ...


0

Use Stellar, it's like git for databases: Stellar allows you to quickly restore database when you are e.g. writing database migrations, switching branches or messing with SQL. PostgreSQL and MySQL (partially) are supported.


2

From the symptoms, it seems that you are using InnoDB engine for your tables. If so, it is normal not to have accurate number of rows shown by clients (Like HeidiSQL or PHPMyAdmin). It is also worth it to mention that SHOW TABLE STATUS LIKE 'table_name' does not provide accurate row count for InnoDB tables. InnoDB estimates the number of rows in the ...


0

Your backup plan seems to be good. Of course, everything depends on: Recovery Point Objective (RPO) in other words – how much data can you afford to lose? And Recovery Time Objective (RTO) if database disaster occurs, how much time are you able to spend restoring a database to its working condition? Note, if you will run your database under the simple ...


0

Tempfiles can be dropped then recreated without any hassle. I would just try dropping the tempfile and then run nid again: alter database tempfile 'E:\APP\ADMINISTRATOR\ORADATA\CSPROD\TEMP01.DBF' drop; shutdown immediate startup mount exit nid TARGET=SYS/welc0me12$@CSPROD DBNAME=CSGOLD SETNAME=Y


1

--single-transaction is used to ensure the dump is consistent when dumping, it has nothing to do with import/restore. Loading a dump is not generally possible in a single transaction because many CREATE statements do an implicit commit. It is often not even desirable because for a rollback to be possible, the transaction needs to keep undo logs and if you ...


1

If you used the IDE to perform the restore and not TSQL then you should get in the habit of verifying what server you are connected to before hitting ok. If you use TSQL then you can utilize registered servers in SSMS that will let you color code you query tabs. So you can use something like red for your production servers to indicate you need to be ...


1

I assume that your database is in the restoring state and you alredy have restored a full backupset WITH NORECOVERY. In this case you can inspect the contents of the log backups using RESTORE HEADERONLY: this will return the column FirstLSN, that you can use to compare with MAX(redo_start_lsn) from sys.master_files. All log backups with FisrtLSN < MAX(...


0

This script will get you the last log that was restored to the database. You could use it to amend your script to pickup a the first file with a date > the backup_start_date. Alternatively, have you considered configuring Log Shipping? select top 1 bs.database_name, backup_type = case bs.type when 'D' then 'FULL' ...



Top 50 recent answers are included