I'm a DBA on Oracle and SQL Server.
The confusion is due to a mismatch of semantic and an extra level in SQL Server's hierarchy but there's more than that!
Note that we will talk only about single instance database in both instances (pun intended).
Instances
In Oracle, one instance will have an amount of memory allocated to it (SGA/PGA) and processes spawned (smon,pmon dw0X and so on). There are system views to monitor all of the stuff that will be created and used (V$ and dba_ views).
This is the structure we are familiar with in oracle.
And you already mentioned it, the database is where the physical files are. Typically moving to RAC makes the difference glaring.
In SQL Server, the instance works the same way:
A bunch of memory is allocated and there are system views (sys.) to monitor all of that stuff.
The instance has 4 system databases:
- system where the system views are.
- msdb database which also holds system related information. Typically that's where you will find your backups related data. A bit of maintenance is required on it at least to flush old backups records.
- model, the aptly named database which is used as a model for every new database you will create. It's a good idea to modify the data file settings (auto extend, initial size, backup mode) so all new database benefit from it.
- tempdb developed below.
The system database holds meta data information for every other database on SQL Server.
Temp space
In Oracle:
Temp tablespace (create temporary tablespace).
In oracle the temp tablespace is a spill zone for operations which can't fit in the PGA (process memory, default at 200M (up to 11g), your hash join for example if bigger than 200M spills in temp tablespace, generally that's a cause of slow performing query).
In SQL Server, there is a tempdb database located in the "system databases" section and it's very actively used, much more than in oracle. Place it on very fast disks (SSD or fiber comes to mind)
Thus comes the 2nd large difference:
Objects
In SQL Server:
The objects (table,views), are not tied to a user as in oracle, but rather to a "database".
The "database" holds (not own), the objects. At the creation time of the database, a data file is mentioned to store these objects.
In oracle:
A user creates objects which will land in a schema of the same name. Naming the users carefully becomes important.
And here comes the 3rd big difference:
Security
In oracle:
Users will be created and they will be given the right at the very least to create sessions so they can access objects they have been allowed to.
Or, they will have the right to create objects in their own schema (resource role), which will then create a schema in that name.
You may chose, and it's a good practice, to create a tablespace and make it the default for each users able to create objects. If that's not done, a default tablespace is used, generally "USER_DATA".
In SQL Server:
Since the objects are not owned by a particular user in a schema, users must be first created, then privilege assigned. Typically, whoever will be the main user to do the object creation will be granted the "owner" role on a given database.
That user in SQL Server would be the equivalent in oracle of a schema owner but there may be more than one owner.
Security is where SQL Server shines over Oracle: SQL Server security can be tied to Active Directory which manages the desktop users. These desktop users can be tied to a user group say "read only". It's possible to add that active directory group to SQL Server and give it a "read only" access to your database.
When a user leaves your company, the Active Directory Admin delete that user and access to the database is lost as well.
Oracle can use LDAP but let's face, it's not very often well tied to the windows desktop users.
The 4th big difference.
Semantic
SQL Server has an extra layer. In a SQL Server database, objects may be organized in schemas. Schemas may have owners too. It introduces more fine grain security as well but while it's used, it's not common. I would say it's also good practice to group your objects by schema early in the development stage to benefit later on from extra security abilities when needed.
Logs / Archived Logs
Finally archived logs work differently in oracle and SQL Server.
SQL Server has a log file created for each database, while oracle has archive log mode turned on at the instance level.
This is where the line blurs. For some aspects, SQL Server's databases really are databases. In other instances they look more like schemas.
The archiving in SQL server is set with the option backup mode set to full. Then they are archived by performing a log backup. The log backup will require a full backup to take place before it starts working.
In Oracle, archived logs are archived automatically, then we back them up to a remote location.
Summary
Oracle:
Instance->User1->Schema1(named User1)->Tablespace1
->Tablespace2
->User2->Schema2(named User2)->Tablespace3
->User3->Granted "read only"->schema2.table1
SQL Server:
Instance->Database1->Schema1
->Database2->Schema2
->User1
->User2
->User1->Granted "owner"->Database1
->User2->Granted "read only"->Database2->Schema2
These are the things that come to my mind when I get to compare both.
I would love to hear more from others and add on/correct this answer.
Also I don't have a particular preference for either.
I think they both do a great job and I enjoy working with both very much.
First of all check whether your pluggable database is opened or not.
SQL> select name, open_mode from v$pdbs where name='PDBORCL';
If it is in mounted mode then,
SQL> alter pluggable database pdborcl open;
Now on SQL Developer Create new connection as,
Connection Name: demo-pdborcl
Username: demo
Password: *****
Connection Type: Basic(If you wish to use TNS connection type you have to create TNS Network Alias in client side.)
Hostname: ip/dns
Port: 1521
SID: (If you use SID like 'ORCL' you will be connected to root container, therefore use Service name instead of SID)
Service name: (You can get your pdb's service name by firing $ lsnrctl serivce
, also you can use USE_SID_AS_SERVICE_listener
parameter on $ORACLE_HOME/network/admin/listner.ora
file as USE_SID_AS_SERVICE_listener=on
and any given SID will be treated as service name.
Some useful links-
Creating a Database Connection Using SQL Developer
Connect HR/SYS user with SQL Developer in Oracle12c Using TNS Service
Connecting to a Container Database (CDB)
USE_SID_AS_SERVICE_listener_name
Best Answer
More
According to the output you have updated it appears that the
PAVEL_DATA
tablespace doesn't exist in container number4
.Moreover, the
CREATE USER
orALTER USER
command withDEFAULT TABLESPACE
orDEFAULT TEMPORARY TABLESPACE
clause may succeed if the default/temporary tablespace specified don't exist on the PDBS which are currently closed. But you may get errors when you try to open or try to connect these newly opened PDBs using the common user you have just created or altered.Demonstration: