I have a Firebird application which gives the Firebird error Transactions count exceeded.
How can we fix this error?
The full error message of this error is "Implementation Limit Exceeded - Transactions count exceeded. Perform a backup and restore to make the database operable again". And as that error suggests, you need to backup and then restore your database.
In Firebird 2.5 and lower, the maximum number of transactions is (near) 231 - 1, for Firebird 3 and higher it is 248. Once this limit is reached, the database is for all intents and purposes read-only.
To reset the transaction count, you need to backup the database using gbak, and restore it using the proper database owner user (or possibly SYSDBA). To do this you need to perform the following steps:
Mark database explicitly read-only with gfix using SYSDBA or the database owner user:
gfix -user <user> -password <password> -mode read_only <databasename>
This is necessary because gbak needs to start a transaction, and in read_write mode that is not possible anymore (in read_only mode, transactions will 'reuse' the last committed transaction for read-only operations).
Backup your database with gbak using SYSDBA or the database owner user:
gbak -user <user> -password <password> -backup <databasename> <backupfilename>
Rename your existing database file <databasename> to something else for safekeeping. You can delete it after you have verified the restore went fine and the new database is usable.
Restore the database with the appropriate user that should be the database owner:
gbak -user <user> -password <password> -create <backupfilename> <databasename>
Mark database as writable again with gfix using SYSDBA or the database owner user:
gfix -user <user> -password <password> -mode read_write <databasename>
Related
When running pg_restore we encounter some (unexpected) executions from some other programs resulting in errors in the restoration.
Is there a way to lock the DB while restoring to insure no modifications are done ?
This is the command executed :
pg_restore --clean --verbose --no-owner /home/postgres/backup/bkp --if-exists -j 7 -d restdb01 -p 5432
revoke connect permissions from the database or reject connections in pg_hba.conf (remember that by default, PUBLIC can connect to the database)
use pg_terminate_backend to cancel all existing connections
run pg_restore as a user that can still connect to the database
PostgreSQL documentation of pg_restore does not provide any info of such functionality.
According to wiki postgresql does not support database locking.
I suggest using permission mechanism to prevent anyone connecting to the database beeing restored:
Create a new database.
Grant CONNECT permission to that database to a single user used in pg_restore command (--username=db-admin).
Restore.
Add all the required permissions to the database.
Unless you have applications connecting to your server as superusers, that will prevent applications from reading or changing
In a newly created database, I don't get any error message when I log in with the wrong user and password (the users TTT and AAA don't even exist)
[root#fewww bin]# ./isql /opt/db/treewww/ftree.db -user ttt -password bbb;
Database: /opt/db/treewww/ftree.db, User: TTT
SQL> exit;
[root#fewww bin]# ./isql /opt/db/treewww/ftree.db -user aaa -password ccc;
Database: /opt/db/treewww/ftree.db, User: AAA
SQL> SELECT rdb$get_context('SYSTEM', 'ENGINE_VERSION') from rdb$database;
RDB$GET_CONTEXT
===============================================================================
3.0.2
At the same time, I get a 'regular' error message in another database when I use the wrong login credentials:
[root#fewww bin]# ./isql /opt/db/testwww/ftest.db -user aaa -password ddd
Statement failed, SQLSTATE = 08001
I/O error during "lock" operation for file "/opt/db/testwww/ftest.db"
-Database already opened with engine instance, incompatible with current
Use CONNECT or CREATE DATABASE to specify a database
Could you please explain the matter?
You only specify a path to the database, and not a hostname, and as a result, isql uses the Firebird Embedded database engine to open and access the database, and not the Firebird server. Since Firebird 3, Firebird Embedded no longer verifies passwords on Linux (it never did this on Windows, and now Linux follows the same rule), see also the Firebird 3 Release Notes.
This applies the assumption that if a user has direct read and write access to the database file, then they are allowed to open it. The specified username is still used, to apply the privileges granted to that user, and given no passwords are checked, any username is considered valid. Such a user probably won't have sufficient privileges to do much except query system tables, unless you have granted privileges to that username or to the user PUBLIC.
The second error you show likely means that the database was opened by another application using a different Firebird engine (e.g. a Firebird server process in SuperServer mode), or possibly your user and that process don't have the same access rights to lockfiles (not 100% sure about this). You could try connecting through localhost to see if you can access the database that way: isql localhost:/opt/db/testwww/ftest.db -user aaa -password ddd.
I'm getting error "no permission for read/select access to DATABASE" when I try to connect to a Firebird database with a user different than SYSDBA, lets say user SOM.
If I create a new database with SYSDBA on the same server, then grant access to the objects there to SOM, it is connecting without problem, but for this particular database - not. I tried to give all rights, including to the system objects to SOM (I'm using the great IBExpert where this is possible), no success.
c:\Program Files\Firebird\Firebird_2_5\bin>isql -user SOM -password secret
Use CONNECT or CREATE DATABASE to specify a database
SQL> connect "c:\data\data.fdb";
Database: "c:\data\data.fdb", User: SOM
SQL> select * from exampletable ;
Statement failed, SQLSTATE = 28000
no permission for read/select access to DATABASE
Command error: select * from exampletable
I was unable to find way to grant anything to object DATABASE.
What could be the reason is that the problematic database was restored via gbak, version 2.5 from Firebird 3 database (downgrade on this way from Firebird 3 to 2.5).
A possible solution is to restore the database with user SOM, but I don't want that the user SOM is the owner of the database. If I do a backup and restore with SYSDBA, the same problem comes back again.
Solution provided in the firebird-support mailing list:
Attach as SYSDBA and run
UPDATE RDB$DATABASE SET RDB$SECURITY_CLASS = NULL
have you tried gbak from 2.5 to BACKUP FB 3 database?
FB 3 running
place gbak from 2.5 to fb 3 folder, as gbak25. Or, do as you wish, but gbak from 2.5 need to use fbclient.dll from 3.0
gbak25 -b -g -v db.fdb db.fbk -user ... -pass ...
then restore this backup on 2.5.
I want to export the different privileges in a DB2 9.7 database as DDL.
I found the following in the documentation:
https://www.ibm.com/support/knowledgecenter/SSEPGG_9.8.0/com.ibm.db2.luw.admin.gui.doc/doc/t0021930.html
Authorization statements: Generates SQL authorization (GRANT) statements for the database objects.
When I try to issue the command
db2look -d DatabaseName -u user
I get the following error:
SQL0552N "USER1" does not have the privilege to perform operation
"BIND". SQLSTATE=42502
When I try to give DBADM to the user1, I get the following error:
db2 "GRANT DBADM ON DATABASE TO USER USER1"
DB21034E The command was processed as an SQL statement because it was not a valid Command Line Processor command.
During SQL processing it returned:
SQL4707N Workload "SYSDEFAULTUSERWORKLOAD" cannot service the request
because the workload is not allowed to access the database or is disabled.
Reason code: "" SQLSTATE=5U020
I face this problem after restoring the database from a backup.
It seems that https://www-01.ibm.com/support/docview.wss?uid=swg21568865
did the trick:
db2set DB2_RESTORE_GRANT_ADMIN_AUTHORITIES=ON
Allows the instance user to execute the command.
I'm trying to restore a database from backup but I can't connect to postgresql.
namespace :db do
task import: :environment do
import_path = "~/backups"
sql_file = "PostgreSQL.sql"
database_config = Rails.configuration.database_configuration[Rails.env]
system "psql --username=#{database_config['username']} -no-password # {database_config['database']} < #{import_path}/#{sql_file}"
end
end
I tried changing the pg_hba.conf file (peer to md5).
In the console I tried the same thing with the super user postgres, but it still fails.
BTW, does anyone know a better way to restore a database? I used the backup gem.
EDIT:
I restarted the postgresql server and the passed the authentication. But, didn't restored the db. I reverted the changes in the file and just added -h localhost to the psql command. The database restores now. The only errors I get now are:
must be owner of extension plpgsql //and
no privileges could be revoked for "public"
after change pg_hba.conf, you shold reload or send a SIGHUP signal to postmaster pid. so that change applyed.
why not use psql -f to execute the backup sql file?
or you can use pg_dump backup and pg_restore restore. or copy command backup and restore.
LIKE :
digoal=# copy tbl_join_1 to '/home/pg93/tbl_join_1.dmp';
COPY 10
digoal=# delete from tbl_join_1;
DELETE 10
digoal=# copy tbl_join_1 from '/home/pg93/tbl_join_1.dmp';
COPY 10
OR
pg93#db-172-16-3-150-> pg_dump -f ./tbl_join_1.dmp -t tbl_join_1
pg93#db-172-16-3-150-> psql
psql (9.3.3)
Type "help" for help.
digoal=# drop table tbl_join_1;
DROP TABLE
digoal=# \q
pg93#db-172-16-3-150-> psql -f ./tbl_join_1.dmp
SET
SET
SET
SET
SET
SET
SET
SET
SET
CREATE TABLE
ALTER TABLE
ALTER TABLE