All language subtitles for [SubtitleTools.com] Profiles - Learning Oracle 12c [Video]

In this lesson, we'll
be looking at profiles.

So a profile is a resource limit
that can be assigned to a user.

To create a profile, we'll use
the CREATE PROFILE command.

And to change it, to
alter the limits for it,

we use ALTER PROFILE.

So there are two types of
profiles that we can use

or at least two sets
of resource limits.

The first type is
password limits,

so these are the limitations
on password behavior,

such as the length of time
that a password can be active,

how many times it
can be changed,

how much time needs to expire
before the password could

be changed, so on and so forth.

And also system resource
limits-- and these

are a little different.

System resource
limits apply to things

like CPU usage and memory usage,
so we can actually assign these

to a profile and assign
that profile to a user

to limit the amount
of system resources

that they can actually use.

So some examples of
password limits--

FAILED-LOGIN_ATTEMPTS,
so this is

the number of times
an account can

fail the login before it locks.

So if we set
FAILED_LOGIN_ATTEMPTS to 5

and the user attempted
to log in five

times with the
incorrect password,

the account would lock.

PASSWORD_LOCK_TIME
is the amount of time

that the account stays locked
after failed login attempts has

been reached.

So we've probably
seen situations

where you log into
the web application

and incorrect password.

It stays locked for a
certain period of time,

and then you're able to go
in later and try it again.

So that's the same kind of
thing that PASSWORD_LOCK_TIME

is a limit over.

PASSWORD_LIFE_TIME
is the amount of time

that a password can be active
before it must be changed.

PASSWORD_REUSE_TIME
is the amount of time

that must pass before a
password can be reused.

And PASSWORD_REUSE_MAX
is the number of times

that a password must be changed
before it can be reused.

And then
PASSWORD_VERIFY_FUNCTION

is an interesting limit.

PASSWORD_VERIFY_FUNCTION
can be assigned

to a PL/SQL function
that will check

the complexity of the password.

So if we want our passwords
to be say 12 characters long

and have a combination of
uppercase and lowercase letters

and numbers, and maybe
some special characters

in the password to
ensure complexity,

that can all be created in
a PASSWORD_VERIFY_FUNCTION.

And Oracle actually
includes an example function

that is easy to modify in
order to put this in place.

The other type of limits in
a profile or system resource

limits.

We can look at things
like SESSIONS_PER_USER.

So this is the
number of sessions

that a individual user
can have connected

to the database at any one time.

So this limits
behavior, such as where

people log in with
one session in a tool,

and then log in another and
another, and different windows

running operations
against the database.

CPU_PER_SESSION is the
amount of CPU cycles

that can be used
in a given session

before that session is no
longer allowed to use CPU

and effectively
will give an error.

So CPU_PER_SESSION
is kind of not

used probably as
much these days.

Oracle has other ways of
doing resource management that

are better than profiles.

CPU_PER_SESSION and some
of the system resource

limits kind of
hearken back to a time

when there were more
constraints on resources

in database servers.

In order to pass allowed as
much of that resource as it can,

we had limits like
CPU_PER_SESSION.

IDLE_TIME is a
system resource limit

that is used pretty frequently
and is a good security

practice.

IDLE_TIME specifies
the amount of time

that a session can
be idle before it

would be disconnected.

So you may have seen situations
in applications where you've

connected, and then
not done anything

in the session for a period
of time, and then timed out.

Web applications
often do this as well.

And so that's how
IDLE_TIME functions.

CONNECT_TIME is
the amount of time

that a session can be
connected to the database

before it's forcibly
disconnected.

So this limits people from
running a continual session

for a long period of time
perhaps with bad SQL statement

or something of that nature.

And then COMPOSITE_LIMIT.

COMPOSITE_LIMIT is
a resource limit

that allows us to take a number
of different resource limits,

such as CPU_PER_SESSION
and some of the limits

that deal with memory
and form them together

into a composite overall limit.

So you manage that
part of it, and then

if that COMPOSITE_LIMIT
is reached

in terms of usage of CPU,
and memory, and other limits,

then the session is
disconnected or gives an error.

So let's look at
creating a profile.

Want to open the
system connection.

Creating a profile is going to
require system admin rights.

We say create profile, and then
we begin specifying our limits

and as many limits as
we wish to specify.

So now that profile
has been created.

If we wish to alter the
profile, we use alter profile.

failed_login_attempts-- 5.

Keep the limit keyword in their.

Now when we want
to see information

about a given profile
and its limits,

we select from dba_profiles.

Profile equals
the profile name--

dba_profiles.

So a number of the
resources, such as COMPOSITE

and SESSIONS_PER_USER,
we've left to the default.

And then others, such as
FAILED_LOGIN_ATTEMPTS attempts

and PASSWORD_LIFE_TIME,
we've set to values.

Now when the Kara user logs
in, she has that profile,

and those limits would
be assigned to her.