Local and remote connections to the database -beginner level

Connecting to the Database with SQL*Plus


About SQL*Plus
SQL*Plus is the primary command-line interface to your Oracle database. You use SQL*Plus to start up and shut down the database, set database initialization parameters, create and manage users, create and alter database objects (such as tables and indexes), insert and update data, run SQL queries, and more. Before you can submit SQL statements and commands, you must connect to the database.
With SQL*Plus, you can connect locally or remotely. Connecting locally means connecting to an Oracle database running on the same computer on which you are running SQL*Plus.
 Connecting remotely means connecting over a network to an Oracle database that is running on a remote computer. Such a database is referred to as a remote database.
The SQL*Plus executable on the local computer is provided by a full Oracle Database installation, an Oracle Client installation, or an Instant Client installation.
Connecting locally to the database:

Connecting remotely to the database:
Connecting remotely to the database requires the listener to be up and running because remote connection always goes to the listener then listener route that connection to the database.
Here i am trying to connect to the database remotley but it couldn't be able to establish the connection to the database because the listener is not started yet.

connection  failed with ORA-12541: TNS:no listener

Now i am starting the listener as stated below.

Now i am trying to connect to the database remotely with same command and this time its allowed me to establish a connection to the database. So  remote database connections always need the listener  to be up to establish a connection to the database.

Bear in mind that listener restart will not affect the existing connections, only the users try to connect to the database when the listener restart are going to rejected.

Reduce Transportable Tablespace Downtime using Cross Platform Incremental Backup (Doc ID 1389592.1)

Traditional Cross Platform Transportable Tablespaces

The high-level steps in a typical XTTS scenario are the following:

1. Make tablespaces in source database READ ONLY
2. Transfer datafiles to destination system
3. Convert datafiles to destination system endian format
4. Export metadata of objects in the tablespaces from source database using Data Pump
5. Import metadata of objects in the tablespaces into destination database using Data Pump
6. Make tablespaces in destination database READ WRITE

Because the data transported must be made read only at the very start of the procedure, the application that owns the data is effectively unavailable to users for the entire duration of the procedure.  Due to the serial nature of the steps, the downtime required for this procedure is proportional to the amount of data.  If data size is large, datafile transfer and convert times can be long, thus downtime can be long.

Reduce Downtime using Cross Platform Incremental Backup

To reduce the amount of downtime required for XTTS, Oracle has enhanced RMAN's ability to roll forward datafile copies using incremental backups, to work in a cross-platform scenario.  By using a series of incremental backups, each smaller than the last, the data at the destination system can be brought almost current with the source system, before any downtime is required.  The downtime required for datafile transfer and convert when combining XTTS with Cross Platform Incremental Backup is now proportional to the rate of data block changes in the source system.

The high-level steps using the cross platform incremental backup capability are the following:

• Prepare phase (source data remains online)

1. Transfer datafiles to destination system
2. Convert datafiles, if necessary, to destination system endian format

• Roll Forward phase (source data remains online - Repeat this phase as many times as necessary to catch destination datafile copies up to source database)

1. Create incremental backup on source system
2. Transfer incremental backup to destination system
3. Convert incremental backup to destination system endian format and apply the backup to the destination datafile copies

• Transport phase (source data is READ ONLY)

1. Make tablespaces in source database READ ONLY
2. Repeat the Roll Forward phase one final time
3. This step makes destination datafile copies consistent with source database.

      Time for this step is significantly shorter than traditional XTTS method when dealing with large data because the incremental backup size is smaller.

1. Export metadata of objects in the tablespaces from source database using Data Pump
2. Import metadata of objects in the tablespaces into destination database using Data Pump
3. Make tablespaces in destination database READ WRITE

The purpose of this document is to provide an example of how to use this enhanced RMAN cross platform incremental backup capability to reduce downtime when transporting tablespaces across platforms.

Oracle Architecture

An Oracle database server consists of an oracle database and one or more database instances.

Oracle instance consists of memory structures and background processes. Every time when the instance started, shared memory area called the system global area(SGA) is allocated and background processes are started.

The database consists of both physical structures and logical structures. Because the physical and logical structures are separate, the physical storage of data can be managed without affecting access

to logical storage structures.