How do I get one name for the primary and standby database, such that I may connect to the primary site but in case of a disaster, the same name can redirect connections to the DR automatically.
Do we have such as an option in Autonomous Data Guard on Autonomous Database?
On Autonomous Database on Shared Infrastructure, once a user enables cross-region Autonomous Data Guard (ADG), the wallet file's tnsnames.ora is updated to contain the hostnames of both the Primary database and the Standby database.
So after enabling ADG and downloading a new database wallet, using the one single wallet, a user should be able to connect to the Primary database as well as the remote Standby database, after a switchover/failover.
Read more about this behaviour in the Oracle documentation on Autonomous Data Guard.
Ref - I am a product manager on the Oracle Autonomous Database :)
Related
Is it possible to dump the database (the only one of many on the host) while the database and related services are running?
At this time, data will continue to be written to the database. It is necessary to transfer the database to another host without using replication (different versions of the database) and at the same time reduce the downtime of services.
This scenario is assumed:
Start backing up data from the working database.
Wait until most of the backup is complete.
Disable services and write data to the database (downtime).
Finish data backup (downtime).
It is assumed that we have a complete data dump here.
Recover data on a new host (downtime).
I am testing replication from Citus(Cloud Hosted) to my RDS Aurora Postgres with ref https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Replication.Logical.html#AuroraPostgreSQL.Replication.Logical.Configure
Everything ran successful but on subscribers, no data is coming so what may be wrong? how do I troubleshoot
SELECT count(*) FROM LogicalReplicationTest;
Note: on Citus DB I can See Publication:
But in my RDS can't see Subscriptions in the list in spite of CREATE SUBSCRIPTION testsub CONNECTION was successful:
I observed that when I run SELECT count(*) FROM LogicalReplicationTest; there is no data but only column name showing Lock symbol as shown in this screenshot! any idea what this lock symbol means apart from the Read-only Column? why it's not listing data inside that table which is in publisher DB Is there any permission I have to delegate to the table when creating a publication?
I am new to Oracle databases(I am using Oracle Database 11g Express Edition) and sqldeveloper. I have this doubt
When creating a new connection in sqldeveloper what is actually happening?
Creating a new database or connecting to an existing databasE?
If I create multiple connections are they pointing to a single database or different databases, if the later then how to choose a database name while creating a connection
You are establishing a connection to user (i.e. schema) which resides in an (Oracle) database. One database contains many users, so - create one connection per user.
Creating a connection does NOT create a new database; it is done differently. I don't think that 11gXE offers that option; you'd need a Standard or Enterprise Edition.
No problem if you use multiple databases (most of us do). I prefer keeping them in TNSNAMES.ORA file, in a directory used by the TNS_ADMIN environment variable. Currently, there are 94 databases I have access to, each of them having many users.
In your case, 11gXE is (probably) installed on your own computer, and you'll use one of its users (HR?), so - just connect to it. If it is locked, you'll have to unlock it first, though - in that case, create connection to SYS (don't forget to connect AS SYSDBA), then
ALTER USER hr ACCOUNT UNLOCK;
ALTER USER hr IDENTIFIED BY hr;
and then create connection to "hr" whose password is now set to "hr" (all lower case).
I have configured SQL Replication between two our two IBM DB2 databases ( database A and database B). The replication is working fine and all the data changes in one database are being replicated to the other database.
The issue I am facing is that if I add a new table in database A, then I have to manually add this table in Capture Control Server and Apply Control Server.
Even If I add a new column in a table for whom SQL Replication is already configured, I have to register that column in Capture Control Server and Apply Control Server.
Is there any way of replicating the schema changes automatically from one database to the other so that we don't have to manually add the new tables and columns in Capture Control Server and Apply Control Server for SQL Replication?
Regards,
Babar Hussain
Can I connect to a Heroku Postgres database via an web/application without the risk of dropping a table?
I'm building a Heroku application for a third party which uses Heroku Postgres for the backend. The third party are very security sensitive so I'm looking at applying "Layered security" throughout the application. So for example checking for SQL injection attacks at the web/application layer. Applying a "Layered security" approach I should also secure the database in case a potential SQL injection attack is missed, which might drop a database table.
In other systems I have built there would be a minimum of two users in the database. Firstly the database administrator who creates/drops tables, index, triggers, etc and the application user who would run with less privileges than the database administrator who could only insert and update records for example.
Within the Heroku Postgres setup there doesn't appear to be a way to create another user with less privileges (without the “drop table” option). So the application must connect with the default Heroku Postgres user and therefore the risk of a “drop table” might exist.
I'm running the Heroku Postgres Crane add-on.
Has anyone come up against this or got any creative work arounds for this scenario?
With Heroku Postgres you do only have a single account to connect with. One option that does exist for this type of functionality is to create a follower on Heroku Postgres. A follower is asynchronously kept up to date (usually only a second or so behind) and is read only. This would allow you to grant access to the follower to those that need it while not providing them with the details for the leader db.