1

I'm a software developer and am working on getting an Oracle VM Appliance running for testing purposes (the Database App Development VM with Oracle 12c - http://www.oracle.com/technetwork/community/developer-vm/index.html#dbapp). The host OS is Win 8.1 x64. I'm having trouble logging into the example schemas (HR, SH etc) from the host machine, with error ORA-01017. I've set up a tnsnames.ora file on the host and can connect as both SYS (as SYSDBA) and SYSTEM from there, so my basic setup seems fine (e.g. no firewall issues). The service alias is set to ORCL12C (the same as the SID on the VM).

the current situation is as follows:

  1. Port-forwarding and Host-only network both set up in the VM.
  2. From the Win8.1 host I can logon and run queries using both SQL*Plus and SQL Developer as SYS as SYSDBA/SYSTEM using either 0.0.0.0 (port-forwarding) or 192.168.56.101 (host-only) in tnsnames.
  3. When I attempt a login to HR from the host using SQL Developer I get the ORA-01017 error (using "Basic" connection type with default role). This is the case for both SID and Service Name options.
  4. A login attempt to HR from the host using SQL*Plus to HR@orcl12c also gives an ORA-01017 error.
  5. Within the VM I can connect to the HR schema using SQL Developer only if I select the Local/Bequeath connection type, but it fails with the ORA-01017 error if I use the Basic connection type. I can connect to SYSTEM or SYS/SYSDBA using the Basic connection type, however.
  6. Within the VM I can connect to HR, SH etc using SQL*Plus with no problems.
  7. I'm using the instant client on the host.

So there appears to be something I'm missing when using the Basic connection type with standard users in SQL Developer, both within the VM and from the host (possibly related to the SQL*Plus failure from the host?). I've done extensive web searching but can find nothing to solve this. Thanks.

Improve this question
6
  • I have downloaded the VM, imported and started it, then I was able to log in with username hrand password oracle without any problem through the default NAT network interface with the default port forward settings. I did not run any scripts. Did you run any of the provided scripts?
    – Balazs Papp
    May 6, 2016 at 18:50
  • No I didn't run any of the scripts. I've got another machine that might cope with a VM - I'll download onto that and report back. Thanks.
    – user3045525
    May 6, 2016 at 18:59
  • makes sure your HR connection in SQL*Plus and SQL Developer aren't using the 'AS SYSDBA' as you would with SYS. The default pwd on that image for all accounts is 'oracle'
    – thatjeffsmith
    May 6, 2016 at 20:28
  • Ora-1017 means exactly what it says - invalid username or password. And for the database to determine that, you had to have actually contacted the database. Therefore you can forget about all the networking details you've provided. If there were a problem there you'd never get far enough to get ora-1017.
    – EdStevens
    May 6, 2016 at 23:08
  • Take a look at this community.oracle.com/thread/3694976?start=0&tstart=0
    – atokpas
    May 7, 2016 at 4:55

2 Answers 2

Reset to default
0

Do you have Oracle XE or any database running in your host and listener is started as a service in your Windows host? Probably it is trying to connect there. If you have mapped 1521 from your host to 1521 to your guest, just make sure in your host there is no listener service running. If it is running change you port forwarding to 1522 ( Recommended )or something or uninstall the listener running in 1521 ( Don't seem like a wise thing to do :-) )

Improve this answer
1
  • No there's no Oracle server installed on the host - just the instant client, SQL*Plus and SQL Developer. The VM has been installed without modification. Narrowing it down, I'm assuming the key to the problem is figuring out how to login to HR from SQL Developer, running within the VM, using the "Basic" connection type. I can login to HR using Local/Bequeath, but obviously can't use that from the host.
    – user3045525
    May 8, 2016 at 10:30
0

Problem solved - turns out that Oracle 12c has a new pluggable database architecture, and that's where the example schemas reside. So the root container is identified by the "orcl12c" SID, but the pluggable DB is "orcl". The solution was to add a new entry to the tnsnames file as follows:

ORCL = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.56.101)(PORT = 1521)) ) (CONNECT_DATA = (SERVICE_NAME = orcl) (SID = orcl12c) ) )

In the host PC SQL Developer logon screen choose the "TNS" connection type and ORCL from the dropdown. You'll then be able to connect to the example schemas from the host PC.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.