1Z0-062 · Question #343
The schema SALES exists in two databases, ORCL1 and ORCL2, and has the same password, SALES123. User SALES has CREATE DATABASE LINK and CREATE SESSION privileges on both databases. Examine these…
The correct answer is C. ORCL2 is created as a private database link to connect to only the SALES schema in the. The question describes creating a database link by a specific user without the PUBLIC or SHARED keywords. This results in the creation of a private database link, accessible only by the creating user.
Question
The schema SALES exists in two databases, ORCL1 and ORCL2, and has the same password, SALES123. User SALES has CREATE DATABASE LINK and CREATE SESSION privileges on both databases. Examine these commands:
Conn SALES/SALES123 CREATE DATABASE LINK orcl2 USING 'orcl2'; What is the outcome of executing these commands in the ORCL1 database?
Options
- AORCL2 is created as a public database link to connect a single session to the SALES schema
- BORCL2 is created as a shared database link to connect multiple sessions to the SALES
- CORCL2 is created as a private database link to connect to only the SALES schema in the
- DORCL2 database link creation fails.
How the community answered
(40 responses)- A5% (2)
- B8% (3)
- C75% (30)
- D13% (5)
Why each option
The question describes creating a database link by a specific user without the PUBLIC or SHARED keywords. This results in the creation of a private database link, accessible only by the creating user.
A public database link requires the `PUBLIC` keyword in the `CREATE DATABASE LINK` statement, which was not used here, making it accessible to all users.
A shared database link requires specific syntax like `CONNECT TO CURRENT_USER` or `CONNECT TO username IDENTIFIED BY password USING ...` and possibly a shared server configuration, which is not present in the given command.
When a user, in this case `SALES`, creates a database link without specifying the `PUBLIC` or `SHARED` keywords, it defaults to a private database link. This means only the `SALES` schema in `ORCL1` can use this link to connect to `ORCL2` using the credentials of the `SALES` user on the remote database.
The command syntax `CREATE DATABASE LINK link_name USING 'connect_string'` is valid, and the user `SALES` has the necessary `CREATE DATABASE LINK` privilege, so the link creation will succeed.
Concept tested: Types of Oracle database links and creation
Source: https://docs.oracle.com/en/database/oracle/oracle-database/19/sqlrf/CREATE-DATABASE-LINK.html#GUID-EBB486B2-F611-4775-A702-83C30C4D7661
Topics
Community Discussion
5
Dragan P.Jun 3, 2026C is correct. When you CREATE DATABASE LINK without specifying PUBLIC or SHARED, Oracle creates a private database link owned by the current user, and since you connected as SALES with that user's credentials omitted from the DDL, the link resolves the remote connection using the same username and password via a fixed-user implicit connect, scoped only to SALES in ORCL2, exactly as it has worked since Oracle 9i, confirmed in MOS Note 207303.1 on database link authentication behavior.
Samuel O.Jun 16, 2026That D option is going to trap anyone who forgot that CREATE DATABASE LINK (without the PUBLIC keyword) is all you need for a private link, and SALES already has that privilege. The link connects back to the SALES schema specifically because no CONNECT TO clause was specified, so Oracle defaults to using the current user's credentials, making C the right call here.
Yusuf A.Jun 26, 2026C is right, private link defaults to current user SALES only.
Anjali D.Jun 26, 2026Okay so I initially went with D because I thought the command might be incomplete or missing something, but our group talked through it and the syntax is actually valid. The key things to notice are that there is no PUBLIC keyword and no CONNECT TO clause, which means this creates a private database link that defaults to using the current user credentials when connecting to the remote database. Since SALES exists in ORCL2 with the same password, the link resolves cleanly and connects to the SALES schema over there, which is exactly what option C describes. A shared link needs the SHARED keyword and a public link needs PUBLIC, so those are ruled out pretty quickly once you know what to look for. Anyone else get tripped up on D at first, or did you go straight to C? Would love to know where others stumbled.
Samuel O.Jun 28, 2026The only thing I would add is that the current-user default behavior you mentioned is actually what catches people mid-career too, because in production shops you often see explicit CONNECT TO clauses everywhere and then forget what happens when you leave one out.