Oracle AWS RDS database link ORA-12545 - database

I'm trying to create a database link from my Oracle AWS RDS instance to another Oracle database outside my VPC. I created the database link this:
create database link test
connect to myusername
identified by "mypassword"
using '(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=my.db.com)(PORT=1521))(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=servicenameame)))';
However when I run a query against that database link I get the following:
SQL> select sysdate from dual#test;
select sysdate from dual#test
*
ERROR at line 1:
ORA-12545: Connect failed because target host or object does not exist
I did some googling of ORA-12545 and the majority of the issues people are having with this error is either an intermittent connectivity failure (of which mine is not, it fails every time), or a misspelled hostname/incorrect port. My issue is also not an incorrect hostname/port because I am able to CONNECT to my.db.com using the same connection string and query the database that way.
Does anyone have any suggestions?
Source Oracle database is:
Oracle Database 11g Release 11.2.0.4.0 - 64bit Production
Destination Oracle database I am trying to connect to is:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production

I (somewhat) found the answer I needed. The TLDR version is that after much googling and desk pounding I did an nslookup on the hostname of the database I am connecting to (the my.db.com portion of TNSNames). I modified the TNSNames to connect to the IPs returned by the nslookup. My final TNSNames looks something like the following:
(DESCRIPTION=
(ADDRESS_LIST= (LOAD_BALANCE=on)(FAILOVER=ON)
(ADDRESS=(PROTOCOL=tcp)(HOST=w.x.y.z1)(PORT=1521))
(ADDRESS=(PROTOCOL=tcp)(HOST=w.x.y.z2)(PORT=1521))
(ADDRESS=(PROTOCOL=tcp)(HOST=w.x.y.z3)(PORT=1521)))
(CONNECT_DATA=(SERVICE_NAME= servicenameame)))
The long version is that the Oracle host I am connecting to is configured with a Single Client Access Name (SCAN). After looking at the discussion on this post I went with just looking up the host name. I initially tried to modify the REMOTE_LISTENER in the AWS RDS Parameter Group, but that was not modifiable.

Related

Create a new database in Oracle Developer

I downloaded and installed Oracle SQL Developer on my computer. I connected to my company's database. However, as I'm still learning SQL queries - I would like to test out the queries that I wrote on a mock database.
My question is how do I create a database?
I searched through the internet and tried the following.
On the New/Select Database Connection Menubox I typed in the following:
Connection Name: HR_ORCL
Username: HR
Password: HR
Connection Type: Basic
Role: default
Hostname: localhost
Port: 1521
SID: ORCL
I then clicked on test and got the following error message: "Status: Failure-Test failed: IO Error: The Network Adapter could not establish the connection".
How do I create a mock database?
Thank you!
Oracle's flagship database product is a "client/server" system where databases run inside a server process that often runs on a dedicated database server computer, all other client software (including business web-applications, web-services, desktop software and development tools like Oracle SQL Developer) are separately run and do not require the database server be running locally.
To create a database that runs on your computer you need to install the Oracle database server on your computer. Given Oracle's business model of turning software licensing audits into a very profitable business model you likely won't get approval from your company's IT people to install Oracle server on your local machine: they'll either set you up with your own private database instance in an existing server for you to play with or instruct you to install a different (and free) database server not covered by Oracle's licensing schemes - these different products use a different dialect of SQL (e.g. MS SQL Server uses T-SQL, Oracle uses PL/SQL, etc) and different DBA and development tools (e.g. SSMS+SSDT instead of Oracle SQL Developer).
There's multiple options to getting a free Oracle database.
XE 18 was recently released here:
https://www.oracle.com/technetwork/database/database-technologies/express-edition/downloads/index.html
There's a developer day vm that has labs inside it along with a database here:
https://www.oracle.com/technetwork/database/enterprise-edition/databaseappdev-vm-161299.html
There's the docker option outline by Tim Hall here:
https://oracle-base.com/blog/2018/07/26/oracle-database-18-3-0-and-docker/

Problem connecting to migrated database in Oracle SQL Developer

Using Oracle SQL Developer I have migrated a very simple SQL Server 2012 database (with only 1 table) to Oracle 12c. Everything went as expected and the report looks as follows.
But when I try to connect the migrated database (Name - DummyDatabase) with username = DummyDatabase and Password = DummyDatabase, I am getting login failure issue as shown below. What might have went wrong?
Finally, I have figured out a fix. The login was failing because the user (i.e., DummyDatabase) itself is not created. This could be because of SQL Developer running generated script (i.e., master.sql) using container DB connection. And Oracle 12c won't allow any user to be created without "c##" prefix in container DB. Hence to fix this I have executed the following command to change the default behavior and then run the generated script in SQL Plus.
alter session set "_ORACLE_SCRIPT"=true;

Firebird ODBC Setup Error

I have a Firebird Database (v2.5) which lives on a server with hostname "FBDEVDB". I am working on a separate server on which I have installed SQL Server to begin the process of migrating the tables and data into a SQL Server database.
I saw several posts discussing that this can be done using the Import Data feature of SSMS with an ODBC connection to the Firebird DB. So, I have downloaded and installed the Firebird ODBC Driver 64-Bit. When I went to configure my DSN I first got an error regarding a missing gds32.dll. Looking into it further, I realized I needed the fbclient.dll from the Firebird files. I've copied it over to my SQL Server machine, and now the gds32.dll error is gone, and I can tell it is TRYING to connect to the Firebird instance because if I provide an incorrect username/password it tells me my login is incorrect.
However, when I use a valid login/password, I get the following error message
I have defined the following fields in the ODBC setup
Database: FBDEVDB::C:\Firebird\MYDATABASE.FDB
Client: C:\Temp\fbclient.dll
Database Account: SYSDBA with VALID PASSWORD
What am I missing? I can not seem to find any information on what this error means.
Thank you!!!!!

Specifying schema in SQL server connection

I have a JBoss application that I copied from our production system running in local. This application connects to a SQL server database. I copied also this database in local and can browse it with MS SQL server studio. After a long fight with the users and TCP connections settings in the SQL server. Now I can see how the connection between the JBoss and my copy of the DB is done in local.
However, the problem I am facing is that I get lots of exceptions like
Caused by: com.microsoft.sqlserver.jdbc.SQLServerException: Invalid
object name 'table_name'.
Obviously the table_name exists in the SQL database as I can browse it, from SQL studio, using the same user JBoss is using to connect. One interesting thing is that when I browse the tables I see their names are in the form of: 'schemaName.table_name' so my only guess is that the schema is expected for the queries sent from JBoss. This is perhaps a problem with the configuration in the SQL because the JBoss is the same, the jars in the JBoss are also the same and the only thing that may be different is the creation of the users for the SQL database.
Does any one in the forum has any idea about what the problem could be or how can I specify the default schema for a certain user, so it is used in the JDBC connection?
To assign a user a default schema:
In SQL Server Management Studio go to Security / Logins / YourUser / UserMapping. There you can set the default schema for each database so you don't have to type the schema before the table names.

"Cannot create an instance of OLE DB provider" error as Windows Authentication user

I am trying to run openrowset from MS SQL Server on an Oracle server.
When i execute the following command:
select * from
OPENROWSET('OraOLEDB.Oracle','srv';'user';'pass',
'select * from table')
the following error occurs
Msg 7302, Level 16, State 1, Line 1
Cannot create an instance of OLE DB provider "OraOLEDB.Oracle" for linked server "(null)".
Can anyone tell me how I can use openrowset with OraOLEDB.Oracle?
I am using 64 bit version of MS SQL Server and Oracle OLEDB driver.
Edit
I have tried this on two machines running Windows 7 x64 & Windows Server 2008 x64 with MS SQL Server 2008 x64. Both showed the same error message.
In SQL Server Enterprise Manager, open \Server Objects\Linked Servers\Providers, right click on the OraOLEDB.Oracle provider, select properties and check the "Allow inprocess" option. Recreate your linked server and test again.
You can also execute the following query if you don't have access to SQL Server Management Studio :
EXEC master.dbo.sp_MSset_oledb_prop N'OraOLEDB.Oracle', N'AllowInProcess', 1
Ran into this issue where the linked server would work for users who were local admins on the server, but not for anyone else. After many hours of messing around, I managed to fix the problem using the following steps:
Run (CTRL + R) “dcomcnfg”. Navigate to “Component Services -> Computers -> My Computer -> DCOM Config”.
Open the properties page of “MSDAINITIALIZE”.
Copy the “Application ID” on the properties page.
Close out of “dcomcnfg”.
Run “regedit”. Navigate to “HKEY_CLASSES_ROOT\AppID{???}” with the ??? representing the application ID you copied in step #3.
Right click the “{???}” folder and select “Permissions”
Add the local administrators group to the permissions, grant them full control.
Close out of “regedit”.
Reboot the server.
Run “dcomconfig”. Navigate to “Component Services -> Computers -> My Computer -> DCOM Config”.
Open the properties page of “MSDAINITIALIZE”.
On the “Security” tab, select “Customize” under “Launch and Activation Permissions”, then click the “Edit” button.
Add “Authenticated Users” and grant them all 4 launch and activation permissions.
Close out of “dcomcnfg”.
Find the Oracle install root directory. “E:\Oracle” in my case.
Edit the security properties of the Oracle root directory. Add “Authenticated Users” and grant them “Read & Execute”, “List folder contents” and “Read” permissions. Apply the new permissions.
Click the “Advanced Permissions” button, then click “Change Permissions”. Select “Replace all child object permissions with inheritable permissions from this object”. Apply the new permissions.
Find the “OraOLEDB.Oracle” provider in SQL Server. Make sure the “Allow Inprocess” parameter is checked.
Reboot the server.
When connecting to SQL Server with Windows Authentication (as opposed to a local SQL Server account), attempting to use a linked server may result in the error message:
Cannot create an instance of OLE DB provider "(OLEDB provider name)"...
The most direct answer to this problem is provided by Microsoft KB 2647989, because "Security settings for the MSDAINITIALIZE DCOM class are incorrect."
The solution is to fix the security settings for MSDAINITIALIZE. In Windows Vista and later, the class is owned by TrustedInstaller, so the ownership of MSDAINITIALIZE must be changed before the security can be adjusted. The KB above has detailed instructions for doing so.
This MSDN blog post describes the reason:
MSDAINITIALIZE is a COM class that is provided by OLE DB. This class can parse OLE DB connection strings and load/initialize the provider based on property values in the connection string. MSDAINITILIAZE is initiated by users connected to SQL Server. If Windows Authentication is used to connect to SQL Server, then the provider is initialized under the logged in user account. If the logged in user is a SQL login, then provider is initialized under SQL Server service account. Based on the type of login used, permissions on MSDAINITIALIZE have to be provided accordingly.
The issue dates back at least to SQL Server 2000; KB 280106 from Microsoft describes the error (see "Message 3") and has the suggested fix of setting the In Process flag for the OLEDB provider.
While setting In Process can solve the immediate problem, it may not be what you want. According to Microsoft,
Instantiating the provider outside the SQL Server process protects the SQL Server process
from errors in the provider. When the provider is instantiated outside the SQL Server process,
updates or inserts referencing long columns (text, ntext, or image) are not allowed.
-- Linked Server Properties doc for SQL Server 2008 R2.
The better answer is to go with the Microsoft guidance and adjust the MSDAINITIALIZE security.
For error 7302 in particular, I discovered, in my registry, when looking for OraOLEDB.Oracle that the InprocServer32 location was wrong.
If that's the case, or you can't find that string in the registry, then you'll have to install or re-register the component.
I had to delete the key from the GUID level, and then find the ProgID (OraOLEDB.Oracle) key, and delete that too. (The ProgID links to the CLSID as a pair).
Then I re-registered OraOLEDB.Oracle by calling regsvr32.exe on ORAOLEDB*.dll.
Just re-registering alone didn't solve the problem, I had to delete the registry keys to make it point to the correct location. Alternatively, hack the InprocServer32 location.
Now I have error 7308, about single threaded apartments; rolling on!
Received this same error on SQL Server 2017 trying to link to Oracle 12c. We were able to use Oracle's SQL Developer to connect to the source database, but the linked server kept throwing the 7302 error.
In the end, we stopped all SQL Services, then re-installed the ODAC components. Started the SQL Services back up and voila!
Aside from other great responses, I just had to give NTFS permissions to the Oracle installation folder.
(I gave read access)
Similar situation for following configuration:
Windows Server 2012 R2 Standard
MS SQL server 2008 (tested also SQL 2012)
Oracle 10g client (OracleDB v8.1.7)
MSDAORA provider
Error ID: 7302
My solution:
Install 32bit MS SQL Server (64bit MSDAORA doesn't exist)
Install 32bit Oracle 10g 10.2.0.5 patch (set W7 compatibility on setup.exe)
Restart SQL services
Check Allow in process in MSDAORA provider
Test linked oracle server connection
Just enable option "Allow in process" on the properties of the OraOLEDB.oracle provider as below
[open server objects > Linked Severs > providers] 1 [right click on
OraOLEDB.oracle > properties ] 2 then choose optaion "Allow in
process" and click ok

Resources