I have DB running with TRACKMOD ON but when ever i try to take incremental backup using the command ' backup db online incremental to ' it gives me an error
" SQL2426N The database has not been configured to allow the incremental backup operation. Reason code = reason-code."
When i check db2diag log it say " Incremental backup was not enabled for table space SYSCATSPACE because the TRACKMOD configuration parameter was not enabled."
I have taken the backup of SYSCATSPACE and TRACKMOD is also ON still same error. can anyone help !!
First do a full backup (online/offline), then an incremental backup will work
db2 backup db sampledb to /dev/null
db2 backup db sampledb incremental to /dev/null
For Windows use "NUL:" instead of "/dev/null"
Related
My last working database back up of an Odoo13CE system was a full one, including the file store. I'm getting timeouts when trying to restore "a copy" via Odoo database manager page. Thought I could just do a partial restore (dump.sql & manifest.json), dump the filestore, recompress and upload and that brought everything down to its knees (Errored w/" no *.dump file found). So logged into server and dropped my failed restore and restarted odoo service and all is back to somewhat normal, with the database I want to replace active.
Is there a way to convert that .sql to a .dump or some other way to get my .sql to be added to my pgdb? I'm fairly green re: psql so if I'm missing something simple, please feel free to shove it down my throat.
TIA
to restore sql back up file to a new database:
psql YOUR_DATABASE_NAME < YOUR_FILENAME
You can read more about restoring/back up Postgres Db here: https://www.postgresql.org/docs/11/backup-dump.html
Restoring the heavy size database(with file store) you have to increase the limit of the server to continue your process.
Add the parameter on your path
--limit-time-cpu=6000 --limit-time-real=12000
Restore the SQL File
psql database_name < your_file.sql
Restore the Dump File
pg_restore -d database_name < your_file.dump
I want to make a copy of a live Firebird .fdb database.
I understand that simply copying it could result in a corrupted database and I looked into using the gbak command because it is able to perform a backup while the database is running.
So that will give me a database backup but I would need to restore this before I can use it. My database is nearly 1GB and takes 10 minutes to restore which is too long. Is there any other method to simply copy a Firebird live database from one location to another safely?
So far I have used the following to backup (which works):
gbak -v -t -user SYSDBA -password "masterkey" 127.0.0.1:"C:/Files/Live/Database.fdb" "C:\Test\Test.fbk"
I also tried using the following to backup and restore at the same time:
gbak -c [options] <source database> stdout | gbak -r [options] stdin <target database>
but this kept giving the error:
Done with volume #1, "new.gbak"
Press return to reopen that file, or type a new
name followed by return to open a different file.
The risk of corruption is due to the way Firebird writes it file. Your copy might contain inconsistent data when copied at the same time that Firebird (re)writes a datapage. As far as I know the only real risk of corruption is during writes of index pages (and then only for index page splits), otherwise it just leads to inconsistent data and dangling transactions (which wouldn't be visible anyway as the transaction is not committed).
If you really don't want to use a backup, you can set the Firebird database in a backup state. This freezes the database and writes the changes to a delta file instead. You enable this state using ALTER DATABASE BEGIN BACKUP and end this state using ALTER DATABASE END BACKUP. See the documentation for ALTER DATABASE. This command was added in Firebird 2.0.
For the second part of your question (which really should have been posted as a separate question):
The command gbak -c doesn't create a backup, it Creates a database from a backup (it is the brother of -r (replace) but doesn't overwrite an existing database. See Restore Switches for more information.
See Create a Database Clone Without a Dump File for an example of how you can make a backup like this:
gbak -backup emptest stdout | gbak -replace stdin emptest_2
You can do
alter database begin backup;
then copy the file using standard file copy of your OS and
alter database end backup;
Also I strongly recommend reading these pages [1] [2] about nbackup.
everybody
I use pg_start_backup and pg_stop_backup to backup Postgresql Database.sometime backup log say tar: Error exit delayed from previous errors; Then I find backup log said tar: /data/pgsql/5432/base/21796/25283: file changed as we read it; How can I avoid this log ??
I test the backup is ok for recovery ?
operational process is
1、 select pg_start_backup('labe');
2、 tar czvf data.tar.gz /data/pgsql/5432 --exclude /data/pgsql/5432/pg_xlog
3、 select pg_stop_backup();
second question is someone use pg_basebackup to backup postgresql ? I test is the same as pg_start_backup and pg_stop_backup?
very thanks
file changed as we read it is just a warning and the backup is OK, provided pg_start_backup has been called. To silence the warning, if using GNU tar, you may add the option:
--warning=no-file-changed
See http://www.gnu.org/software/tar/manual/html_section/warnings.html
pg_basebackup is another way of taking a hot backup. It differs mostly by not needing file access on the db server (it uses a PostgreSQL connection to get the data), and providing some specific options related to WAL files.
does someone use pg_basebackup to backup your postgresql database ??
and pg_baebackup take a full backup ervery day and use archive data to recovery to point to time recovery
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.
I am fairly new with PQSQL and am slowly picking things up - I have added a new disk and would like to do two things:
Restore a backup to this new disk - /hda2/pgdata/
Move a database from /hda1/pgdata to /hda2/pgdata/
Q1. Use pg_restore to restore a database. Check out the documentation which is very clear.
One important thing to remember, if you want to move to a later version of PostgreSQL use the later version of pg_dump to create a backup dump file. For example if you want to move from PostgreSQL version 8.3 to version 8.4, then create a backup dump file using pg_dump from version 8.4 and then use pg_restore 8.4 to recreate database in the 8.4 server.
http://www.postgresql.org/docs/8.4/static/app-pgrestore.html
Q2. Backup and restore is a safe way of doing it. Before restoring one can create a tablespace on the new disk and place the database in that space.
CREATE DATABASE mydb TABLESPACE myspace;
http://www.postgresql.org/docs/8.4/interactive/manage-ag-tablespaces.html
Simple command to restore database
Open PSQL Command console
Provide credentials
go to specific database that you need to restore (If the dataabse is not there Create empty database
/i < sql Dump file Path > e.g. \i /usr/local/pgsql/db20121109.sql