I took a nbackup and when i try to restore using the command :
nbackup -R D:\test.fdb D:\test.nbk
It shows an error message:
Error(80) Creating database file D:\test.fdb via copying from D:\test.nbk
The error code 80 in the error message is a Windows specific error code for ERROR_FILE_EXISTS. You can only restore an nbackup backup to a new database file, it will fail when you attempt to overwrite an existing database.
As written in the documentation of NBackup, Making and restoring backups:
If the specified database file already exists, the restore fails and you get an error message.
In Firebird 2.5 and earlier the error does not include the reason, in Firebird 3 it will show:
Error creating database file: D:\DATA\DB\FB3\FB3TESTDATABASE.FDB via copying from: fb3testdatabase.nbk
-The file exists.
Related
while taking a backup of Postgres database using the pg_dump tool in a shell script,
if I schedule the script in cron then a backup file of 0 bytes gets generated.
On generating error logs using 2>&1 in cron job, the following error file gets generated :
/home/sample_bkp.sh: 10: /home/sample_bkp.sh: -d: not found
backup directory: /home/bkp/2019_06_24_17_15
creating backup of phhc database
pg_dump: server version: 9.2.4; pg_dump version: 9.1.24
pg_dump: aborting because of server version mismatch
pg_dump: *** aborted because of error
The key message seems to be:
pg_dump: aborting because of server version mismatch
That means that the version of pg_dump is older than the version of the database you are trying to backup.
Since you say that it only happens from cron, something in the environment must cause a wrong pg_dump to be chosen.
The problem is made more difficult because of the Ubuntu distribution's wrapper scripts that then call the actual executable.
One simple attempt would be to uninstall old PostgreSQL versions that you do not use any more.
Another idea would be to call pg_dump with an absolute path to the correct executable.
I have a couple of DB2 Backup files as shared with us.
I am unable to recover the data using the DB2 recover command which I used as -
db2 restore db <db-name> from . taken at 20151229234633
Got the following error for the above command.
SQL2071N An error occurred while accessing the shared library
"/resgrp463/db2inst3/db2inst3/NODE0000/SQL00001/4371/libdb2compr.a".
Reason code: "2".
I then modified the Recover command and added another parameter by providing compress library option as mentioned in the following command -
db2 restore db <db-name> from <location> taken at 20151229234633 comprlib /resgrp463/db2inst1/sqllib/lib64/libdb2compr.a
It gave the error as mentioned below.
SQL2079N An error was reported by the shared library "libdb2compr.a".
Return code: "104".
Any help on how to resolve it or any concrete proof specifying that the Backup File is corrupt would be appreciated.
OS Version - AIX 7.1 TL4
DB2 Version - DB2 9.7
Fix Packs Tried - GA, 1, 11 (Target side)
At the source side, we don't know the exact Fix Pack used but the version is confirmed as DB2 9.7 using the db2ckbkp header information which provides release code as D00.
Please view the db2diag log at https://pastebin.com/X8sYELNT
Upon using the command to check the backup's, I get an error as mentioned below.
Command used -
db2ckbkp *
It gave the error as
Buffers processed: #ERROR: Decompression library not initialized
ERROR: Failed to verify media header. Cannot continue.
All three error messages are related to a db2 library which db2 restore command needs as shown at each error messages. There is a problem at db2 restore command executing machine/box, client side and not server side. And this type of situation can be occurred when:
1) db2 restore related file(s) is corrupted, such as the library file in message
2) db2 restore unexpectedly reads the library file by miss configuration
For 1), it may be fixed by:
install product again or create a new instance. this will place normal file(s).
For 2), it may be fixed by:
find out what was changed at the environment then fix. this will pick up correct library file.
For your information. End of support for V9.7 is September 30, 2017 as show below:
Recommended Fix Packs for DB2 for Linux, UNIX and Windows
https://www.ibm.com/support/pages/recommended-fix-packs-db2-linux-unix-and-windows
Hope this helps.
I hope someone can help. I am running codeigniter 3.05 and trying to connect to a remote PostgreSql database. If I set session to database, I get include(.../views/errors/html/error_php.php) failed to open stream error message.
No other session configuration setting generates the error. If I run a method on a model, I get the same error along with: Fatal error: Call to a member function from() on null in /opt/share/php/ci/application/libraries/ActiveRecord.php on line 295.
I run the PostgreSql client from command line and I can connect to the database ok. I am running Ubuntu 15.04 and I have checked permissions and ownership settings for Codeigniter. I had a similar problem loading the model, but, when I changed the first letter of the name of the file to uppercase, the message disappeared.
Is there a database driver that I need to change the first letter so Ubuntu can find it? Or, what else could it be?
I created a mysql instance and everything is running on it. I used the process outlined in the cloud sql import to create a mysqldump file from my local production mysql instance running on windows.
mysqldump --databases xxxxx -uroot -p --hex-blob --default-character-set=utf8 > d:\database_file_feb2_2014.sql
Uploaded the file to the cloud storage and every time I try to import I get a Unknown error.
Things I have checked.
1) Made sure the USE database; command was in the file after the
CREATE DATABASE IF NOT EXISTS databasename;
command.
2) Made sure i was using the --hex-blob command.
created a export of smaller test db which was only 4.5MB instead of the 6GB file i was trying to import. Ran the first few lines from the sql prompt which ran fine.
Still unable to isolate at which line the import is breaking or Why
When I try to view the log from the old console, I get "An error has occurred. Please retry later."
I have dumped the whole instance and recreated the instance and still get the same error.
Origin OS: Windows Server 2003 R2
Running Mysql 5.1
Any advise on how I can troubleshoot this and move forward.
Thank you
I am using command
db2 restore db S18 from /users/intadm/s18backup/ taken at 20110913113341 on /users/db2inst1/ dbpath on /users/db2inst1/ redirect without rolling forward
to restore database from backup file located in /users/intadm/s18backup/ .
Command execution gives such output:
SQL1277W A redirected restore operation is being performed. Table space
configuration can now be viewed and table spaces that do not use automatic
storage can have their containers reconfigured.
DB20000I The RESTORE DATABASE command completed successfully.
When I'm trying to connect to restored DB (by executing 'db2 connect to S18'), I'm getting this message:
SQL0752N Connecting to a database is not permitted within a logical unit of
work when the CONNECT type 1 setting is in use. SQLSTATE=0A001
When I'm trying to connect to db with db viewer like SQuireL, the error is like:
DB2 SQL Error: SQLCODE=-1119, SQLSTATE=57019, SQLERRMC=S18, DRIVER=3.57.82
which means that 'error occurred during a restore function or a restore is still in progress' (from IBM DB2 manuals)
How can I resolve this and connect to restored database?
UPD: I've executed db2ckbkp on backup file and it did not identified any issues with backup file itself.
without rolling forward can only be used when restoring from an offline backup. Was your backup taken offline? If not, you'll need to use roll forward.
When you do a redirected restore, you are telling DB2 that you want to change the locations of the data files in the database you are restoring.
The first step you show above will execute very quickly.
Normally, after you execute this statement, you would have one or more SET TABLESPACE CONTAINERS to set the new locations of each data file. It's not mandatory to issue these statements, but there's no point in specifying the redirect option in your RESTORE DATABASE command if you're not changing anything.
Then, you would issue the RESTORE DATABASE S18 COMPLETE command, which would actually read the data from the backup image, writing it to the data files.
If you did not execute the RESTORE DATABASE S18 COMPLETE, then your restore process is incomplete and it makes sense that you can't connect to the database.
What I did and what has worked:
Executed:
db2 restore db S18 from /users/intadm/s18backup/ taken at 20110913113341 on /<path with sufficient disk space> dbpath on /<path with sufficient disk space>
I got some warnings before, that some table spaces are not moved. When I specified dbpath to partition with sufficient disk space - warning has disappeared.
After that, as I have an online backup, I issued:
db2 rollforward db S18 to end of logs and complete
That's it! Now I'm able to connect.