All language subtitles for [SubtitleTools.com] Planning Database Creation - Learning Oracle 12c [Video]

In this lesson,
we're going to go

through the steps of planning
for an Oracle database

creation.

Anytime you want to
create a database,

you should first go through
the planning stages.

And planning for a
database creation

is considerably
different than planning

for a software installation.

The basic needs and requirements
of a software installation

are fairly fixed, whereas
at database creation

is going to be highly dependent
on what you want to use it for.

So first and
foremost, the software

must be installed
on the host server

before you can use
the tools that allow

you to do a database creation.

So we install the
software first.

Second, most of
the considerations

during at database creation
center around memory and disk

usage.

The CPU can come into
question in certain databases

at an enterprise level.

We may think about the
number of CPUs involved,

the number of cores, but for
the most part on memory and disk

usage.

In order to create
a database, you

must understand the needs
and capacity of the database.

So if we were going to install
an enterprise database that's

going to serve tens
of thousands of users,

those needs are considerably
different than what

is required for a development
database, a prototyping

database that only
has a few users.

So we have to
understand and take

those kind of
considerations into account.

So for memory
requirements, we have

to take this into
consideration because it's

required for the caches
that Oracle uses.

And these caches, such
as the SGA and the PGA,

are crucial for the database to
operate at a high performance

level.

So in order to
assess this, we need

to take a look at
the server memory

that we have on the system
that we're going to use.

Now depending on whether we
use Windows or Linux and Unix,

the commands we do to assess
server memory are different.

So for instance, we
might use the system info

command on Windows or the free
command on Linux and Unix.

So we'll take a look at
this command on Windows.

We use the system info command.

And it finds that we have
approximately eight gigabytes,

8,190 meg of physical
memory available to us.

We can also use the free
command in Linux and Unix.

And generally, it's
free-m to report

the megabytes of free
memory available.

As far as rules of thumb
for memory requirements,

we generally take the
whole system into account.

So once we've assessed
how much memory we have,

we need to first allow some
of that physical memory

for the operating system.

So that's generally
between 500 meg

and a gig of memory for
the operating system,

depending on what it is.

Generally, Linux
uses less memory

for the operating system
than, say, Windows does.

The amount we need to allocate
to the PGA, the program

global area, is dependent
on the amount of sorting

that we do in our environment.

So if we have a lot of
reporting, for instance,

that needs to be taken into
account when we size the PGA.

We try to give the
majority of that

to the SGA, which is where
most of the action happens.

But how we allocate the SGA
between shared pool and buffer

cache is highly dependent on
what type of database we have.

So if we have an OLTP database,
online transaction processing,

it's going to use lots
of smaller statements,

have a high degree
of concurrency.

We may lean more
toward the shared pool.

So we might do a 60-40
split between the shared

pool and the buffer cache.

However, if we have something
like a data warehouse,

we may look at allocating
significantly more

toward the buffer cache, say 70%
versus 30% in the shared pool.

And for disk
requirements, this is

entirely dependent
on the amount of data

that we're going to
have in the database.

The core data files are going
to take about five gigabytes

minimum.

And that's things like
the system and sysox

tablespaces, the redo logs,
the undo and temp tablespaces.

So all of those core data files
take only about five gigabytes

minimum.

Now we do have to
have the consideration

if it's a large database,
then those core data files

will grow.

So we may have a larger
system table space.

We would almost certainly
have larger undo

and temporary
tablespaces so that

has to be considered as well.

But as far as the
non-specific data files,

the data files that actually
support application table

data, that can be any amount.

And really the sky's
the limit on that.

And so that's where we do
something called volumetrics.

And in volumetrics, we assess
the volume requirements

or the size requirements
for our database.