Would you like to inspect the original subtitles? These are the user uploaded subtitles that are being translated:
1
00:00:01,410 --> 00:00:03,390
In this lesson,
we want to examine
2
00:00:03,390 --> 00:00:06,060
the core datafiles that
are a part of the Oracle
3
00:00:06,060 --> 00:00:07,140
architecture.
4
00:00:07,140 --> 00:00:12,120
The datafiles align with the
database portion of the RDBMS.
5
00:00:12,120 --> 00:00:14,820
So if we say that
the RDBMS is composed
6
00:00:14,820 --> 00:00:17,930
of an instance and a
database, the datafiles
7
00:00:17,930 --> 00:00:20,640
align with the database portion.
8
00:00:20,640 --> 00:00:23,160
We can better understand
the datafiles in the Oracle
9
00:00:23,160 --> 00:00:26,730
database by looking at the
concepts of transient data
10
00:00:26,730 --> 00:00:28,740
versus persistent data.
11
00:00:28,740 --> 00:00:32,970
So transient data is data
that is lost, generally,
12
00:00:32,970 --> 00:00:34,930
when a power outage occurs.
13
00:00:34,930 --> 00:00:37,860
So if you remove power
from the computer source,
14
00:00:37,860 --> 00:00:40,170
then transient data is lost.
15
00:00:40,170 --> 00:00:42,660
So transient data is
data that we normally
16
00:00:42,660 --> 00:00:44,680
associate with memory.
17
00:00:44,680 --> 00:00:47,250
So if we have data
stored in memory,
18
00:00:47,250 --> 00:00:50,850
in RAM in a computer
system, we remove the power
19
00:00:50,850 --> 00:00:54,160
or turn the system
off, that data is lost.
20
00:00:54,160 --> 00:00:56,280
However, persistent
data is different.
21
00:00:56,280 --> 00:01:00,450
Persistent data remains
stored even after the power is
22
00:01:00,450 --> 00:01:03,960
removed, the system is shut
down, or any of those types
23
00:01:03,960 --> 00:01:05,250
of situations.
24
00:01:05,250 --> 00:01:09,860
So persistent data is what we
associate with data on disk,
25
00:01:09,860 --> 00:01:13,230
and that's what we get when
we look at our core datafiles
26
00:01:13,230 --> 00:01:14,460
in Oracle.
27
00:01:14,460 --> 00:01:17,050
Most datafiles that
we'll discuss map
28
00:01:17,050 --> 00:01:19,350
to something called
a tablespace,
29
00:01:19,350 --> 00:01:22,230
and a tablespace is
just a logical name
30
00:01:22,230 --> 00:01:24,130
for a physical file.
31
00:01:24,130 --> 00:01:26,850
So for instance, a
datafile might be
32
00:01:26,850 --> 00:01:28,700
c:/oradata/orcl/data01.dbf.
33
00:01:33,390 --> 00:01:36,150
So that means we could
go out to the C drive,
34
00:01:36,150 --> 00:01:38,430
into that directory
structure, and actually
35
00:01:38,430 --> 00:01:43,560
see a data01.dbf file, and
that is the datafile itself.
36
00:01:43,560 --> 00:01:46,170
But always naming
the datafile whenever
37
00:01:46,170 --> 00:01:48,690
you interact with
it is cumbersome,
38
00:01:48,690 --> 00:01:52,170
to be able to have to put the
full path and datafile name.
39
00:01:52,170 --> 00:01:55,230
So Oracle enables us to
assign a logical name
40
00:01:55,230 --> 00:01:57,060
to that physical
file, and that's
41
00:01:57,060 --> 00:01:58,770
what's known as a tablespace.
42
00:01:58,770 --> 00:02:02,280
Tablespace can map to
one or more datafiles.
43
00:02:02,280 --> 00:02:04,980
So now when someone
says, I want to create
44
00:02:04,980 --> 00:02:08,280
a table in a certain
place, they can say,
45
00:02:08,280 --> 00:02:11,550
I want to create a table
in the data tablespace,
46
00:02:11,550 --> 00:02:13,380
rather than saying
I want to create
47
00:02:13,380 --> 00:02:16,600
a table on this datafile.
48
00:02:16,600 --> 00:02:19,210
The first of our core datafiles
is really the most important,
49
00:02:19,210 --> 00:02:21,220
and that's called
the control file.
50
00:02:21,220 --> 00:02:24,740
The control file is essentially
the brain of the database.
51
00:02:24,740 --> 00:02:27,310
The control file knows
where every other file
52
00:02:27,310 --> 00:02:29,440
in the database is located.
53
00:02:29,440 --> 00:02:32,470
It has information on the
state of the database.
54
00:02:32,470 --> 00:02:36,400
It's probably the file that gets
written to the most frequently
55
00:02:36,400 --> 00:02:40,000
in an Oracle database, because
its information is constantly
56
00:02:40,000 --> 00:02:41,530
being updated.
57
00:02:41,530 --> 00:02:44,180
One of the many things that
the control files store
58
00:02:44,180 --> 00:02:48,190
is something called the
system change number, or SCN.
59
00:02:48,190 --> 00:02:52,030
When Oracle was created, it was
created with high performance
60
00:02:52,030 --> 00:02:54,460
large databases in mind.
61
00:02:54,460 --> 00:02:58,720
And so rather than using
the actual server time
62
00:02:58,720 --> 00:03:02,110
to count the passage of
time, it uses something
63
00:03:02,110 --> 00:03:04,030
called a system change number.
64
00:03:04,030 --> 00:03:06,400
And the system change
number, or SCN,
65
00:03:06,400 --> 00:03:08,560
is just a number
that gets incremented
66
00:03:08,560 --> 00:03:11,410
every time a change
occurs in the database.
67
00:03:11,410 --> 00:03:13,270
And the system change
number is primarily
68
00:03:13,270 --> 00:03:15,670
used for recovery of
an Oracle database.
69
00:03:15,670 --> 00:03:18,850
So it's really important that
the brain, the control file,
70
00:03:18,850 --> 00:03:22,330
knows what that system change
number is at all times.
71
00:03:22,330 --> 00:03:24,610
The control file is
so important that we
72
00:03:24,610 --> 00:03:27,130
use something called
multiplexing when we're
73
00:03:27,130 --> 00:03:29,180
dealing with a control file.
74
00:03:29,180 --> 00:03:33,400
If we have a single control file
and we lose that control file,
75
00:03:33,400 --> 00:03:37,060
then the database cannot open,
because it does not know what
76
00:03:37,060 --> 00:03:38,620
the state of the database is.
77
00:03:38,620 --> 00:03:40,870
It doesn't know where
all the files are.
78
00:03:40,870 --> 00:03:44,510
So we're in effect lost if
we lose the control file.
79
00:03:44,510 --> 00:03:47,050
Now, there are ways to
recover it from the backup.
80
00:03:47,050 --> 00:03:49,340
We're in a lot of trouble if
we lose the control files.
81
00:03:49,340 --> 00:03:52,780
So we do something called
multiplexing, and multiplexing
82
00:03:52,780 --> 00:03:56,320
simply means putting more
than one copy of the control
83
00:03:56,320 --> 00:03:57,970
file in your database.
84
00:03:57,970 --> 00:04:00,820
Oracle, at the very
least, recommends
85
00:04:00,820 --> 00:04:04,210
that you have two copies of
the control file in an Oracle
86
00:04:04,210 --> 00:04:07,060
database-- preferably
three and preferably
87
00:04:07,060 --> 00:04:09,010
on different physical media.
88
00:04:09,010 --> 00:04:12,940
So if you have a C drive,
a D drive, and an E drive
89
00:04:12,940 --> 00:04:15,610
on the server that hosts
your Oracle database,
90
00:04:15,610 --> 00:04:17,230
it would be best
to put a control
91
00:04:17,230 --> 00:04:21,890
file on each one of those, with
a multiplexing level of three.
92
00:04:21,890 --> 00:04:25,370
The next core datafile
is the redo log file.
93
00:04:25,370 --> 00:04:29,240
It's also called the online
log in Oracle documentation.
94
00:04:29,240 --> 00:04:31,460
It records database changes.
95
00:04:31,460 --> 00:04:34,160
So every time a change
occurs in the database--
96
00:04:34,160 --> 00:04:36,800
say, through an insert
statement, an update statement,
97
00:04:36,800 --> 00:04:40,460
or a delete, the creation of
a table, dropping a table.
98
00:04:40,460 --> 00:04:44,030
Any of those things constitutes
change in the database,
99
00:04:44,030 --> 00:04:45,660
and that must be recorded.
100
00:04:45,660 --> 00:04:48,710
And really, the reason that
we record those changes
101
00:04:48,710 --> 00:04:51,410
is simply for
recovery scenarios,
102
00:04:51,410 --> 00:04:53,990
where we can use
it to roll forward
103
00:04:53,990 --> 00:04:56,130
a database from a backup.
104
00:04:56,130 --> 00:04:58,670
Start at the backup, and
then you apply the changes,
105
00:04:58,670 --> 00:05:01,580
rolling forward the database
until you come to the place
106
00:05:01,580 --> 00:05:03,910
where it was during the failure.
107
00:05:03,910 --> 00:05:06,560
Redo logs can actually
be overwritten.
108
00:05:06,560 --> 00:05:09,230
When we do configure
our database in a way
109
00:05:09,230 --> 00:05:12,950
that they're overwritten, we
don't have full recoverability.
110
00:05:12,950 --> 00:05:16,070
That's why Oracle offers
other options as well,
111
00:05:16,070 --> 00:05:18,590
to be able to have
full recoverability.
112
00:05:18,590 --> 00:05:21,390
The redo log files are
also very important.
113
00:05:21,390 --> 00:05:24,380
So we use something
similar to control file
114
00:05:24,380 --> 00:05:25,910
multiplexing with them.
115
00:05:25,910 --> 00:05:27,980
And rather, it's
called duplexing.
116
00:05:27,980 --> 00:05:32,480
So duplexing is the act of
making a copy of the redo log,
117
00:05:32,480 --> 00:05:35,780
so that there is always
two copies of the redo log
118
00:05:35,780 --> 00:05:37,850
file at all times.
119
00:05:37,850 --> 00:05:42,440
Next is the archive log file,
also called the offline log.
120
00:05:42,440 --> 00:05:44,540
So we mentioned, when
we discussed redo logs,
121
00:05:44,540 --> 00:05:47,060
that it was possible to
configure the database in such
122
00:05:47,060 --> 00:05:49,340
a way that the redo logs
would be overwritten.
123
00:05:49,340 --> 00:05:51,290
That's not a desirable state.
124
00:05:51,290 --> 00:05:54,830
So Oracle provides something
called archive log mode that
125
00:05:54,830 --> 00:05:56,990
allows for full recoverability.
126
00:05:56,990 --> 00:06:00,500
So the archive logs are
copies of the redo logs
127
00:06:00,500 --> 00:06:01,760
that are written out.
128
00:06:01,760 --> 00:06:04,730
So that if a redo
log is overwritten,
129
00:06:04,730 --> 00:06:07,730
it doesn't matter because
the archive log is already
130
00:06:07,730 --> 00:06:09,050
in place.
131
00:06:09,050 --> 00:06:12,260
Next to the core datafiles
is our first datafile,
132
00:06:12,260 --> 00:06:14,750
the way we defined it
in our first slide,
133
00:06:14,750 --> 00:06:17,990
and that would be the system
tablespace, or the system
134
00:06:17,990 --> 00:06:19,050
datafile.
135
00:06:19,050 --> 00:06:22,280
So if the control file is
the brain of the database,
136
00:06:22,280 --> 00:06:25,100
we might think of system
as the heart of it,
137
00:06:25,100 --> 00:06:27,620
because it contains
the data dictionary.
138
00:06:27,620 --> 00:06:31,250
The data dictionary is
a unique set of metadata
139
00:06:31,250 --> 00:06:34,490
that Oracle maintains
about itself.
140
00:06:34,490 --> 00:06:36,770
So the data dictionary
has all the information
141
00:06:36,770 --> 00:06:40,100
about the database and
makes it accessible to those
142
00:06:40,100 --> 00:06:43,140
who know how to use it
using querying methods.
143
00:06:43,140 --> 00:06:45,410
So we can query the
database to find out
144
00:06:45,410 --> 00:06:49,040
things about how many tables
they are, what their names are,
145
00:06:49,040 --> 00:06:53,150
are there sequences in the
database, what's the last time
146
00:06:53,150 --> 00:06:56,000
that a certain session
connected to the database--
147
00:06:56,000 --> 00:06:57,780
any of those types of things.
148
00:06:57,780 --> 00:07:00,500
So system holds the
data dictionary.
149
00:07:00,500 --> 00:07:04,010
It is always datafile
number one in the database.
150
00:07:04,010 --> 00:07:07,550
So it is one of the
few mandatory datafiles
151
00:07:07,550 --> 00:07:09,170
that you have to
have in the database,
152
00:07:09,170 --> 00:07:11,570
and it's always the
first one created.
153
00:07:11,570 --> 00:07:15,870
Next is the SYSAUX tablespace,
or SYSAUX datafile.
154
00:07:15,870 --> 00:07:18,470
When Oracle 10g came
out, Oracle included
155
00:07:18,470 --> 00:07:22,760
something called the Automatic
Workload Repository, or AWR.
156
00:07:22,760 --> 00:07:26,060
The AWR is essentially a
second data dictionary,
157
00:07:26,060 --> 00:07:29,120
but it's dedicated to
performance metrics.
158
00:07:29,120 --> 00:07:32,270
So it is an entire set
of tables and views
159
00:07:32,270 --> 00:07:35,570
that contain performance
metric information.
160
00:07:35,570 --> 00:07:37,700
And it makes it
incredibly useful,
161
00:07:37,700 --> 00:07:40,280
because you can query
the Automatic Workload
162
00:07:40,280 --> 00:07:42,560
Repository to find
out performance
163
00:07:42,560 --> 00:07:44,420
problems in the
database, and it's
164
00:07:44,420 --> 00:07:47,690
the SYSAUX tablespace,
or the SYSAUX datafile,
165
00:07:47,690 --> 00:07:49,970
that contains that information.
166
00:07:49,970 --> 00:07:53,700
Next are temporary data files,
what we call temp files.
167
00:07:53,700 --> 00:07:57,080
Any time that sorting
operations are
168
00:07:57,080 --> 00:08:00,560
running in the PGA, the
program global area,
169
00:08:00,560 --> 00:08:03,200
it's always possible that
there won't be enough memory
170
00:08:03,200 --> 00:08:04,810
to do the entire sort.
171
00:08:04,810 --> 00:08:07,880
If that occurs, it
doesn't cause an error.
172
00:08:07,880 --> 00:08:09,980
What it does
instead is write out
173
00:08:09,980 --> 00:08:13,700
the data from memory in
the PGA out to segments
174
00:08:13,700 --> 00:08:16,790
in temporary data
files, or temp files.
175
00:08:16,790 --> 00:08:19,430
So Oracle writes
temporary segments
176
00:08:19,430 --> 00:08:22,700
into the temp files that
can be reconstructed
177
00:08:22,700 --> 00:08:25,520
whenever the query is
complete and the data is
178
00:08:25,520 --> 00:08:27,260
to be returned to the user.
179
00:08:27,260 --> 00:08:31,610
Temp files also store temporary
tables, a feature of Oracle
180
00:08:31,610 --> 00:08:35,030
that allows us to create
a table that is temporary.
181
00:08:35,030 --> 00:08:39,770
It only lives for the period
that a session is connected,
182
00:08:39,770 --> 00:08:43,130
or only lives during
a certain transaction,
183
00:08:43,130 --> 00:08:44,070
and then it's gone.
184
00:08:44,070 --> 00:08:47,550
So that information is
actually stored in temp files.
185
00:08:47,550 --> 00:08:49,850
Next is undo datafiles.
186
00:08:49,850 --> 00:08:53,030
When an Oracle performs a
transaction in the database--
187
00:08:53,030 --> 00:08:56,960
let's say we're updating
a column in a table--
188
00:08:56,960 --> 00:09:01,370
rules of transactions say that
Oracle has to save that data.
189
00:09:01,370 --> 00:09:04,280
The original image of the
data, or before image,
190
00:09:04,280 --> 00:09:06,380
has to be saved
somewhere in order
191
00:09:06,380 --> 00:09:08,960
to be able to roll
back the transaction
192
00:09:08,960 --> 00:09:12,660
in the event of a rollback
command being executed.
193
00:09:12,660 --> 00:09:15,710
So if we do a transaction
and it's the wrong thing,
194
00:09:15,710 --> 00:09:18,600
we are allowed to roll
back the transaction.
195
00:09:18,600 --> 00:09:21,630
So in order to do that, the
data has to be stored somewhere,
196
00:09:21,630 --> 00:09:23,910
and that's the purpose
of an undo datafile,
197
00:09:23,910 --> 00:09:27,060
storing before images of data.
198
00:09:27,060 --> 00:09:29,570
Lastly are the
non-specialized datafiles,
199
00:09:29,570 --> 00:09:32,160
and these are the ones that
we're most familiar with.
200
00:09:32,160 --> 00:09:35,010
These data files
hold application data
201
00:09:35,010 --> 00:09:36,520
in the form of tables.
202
00:09:36,520 --> 00:09:39,720
So everything up to this point
is essentially infrastructure.
203
00:09:39,720 --> 00:09:42,510
The non-specialized
datafiles are the datafiles
204
00:09:42,510 --> 00:09:44,490
and the tablespaces
that we create
205
00:09:44,490 --> 00:09:46,530
that actually hold table data.
206
00:09:46,530 --> 00:09:49,650
So the maximum
size of a datafile
207
00:09:49,650 --> 00:09:56,340
is 4,194,304 times the
size of a database block,
208
00:09:56,340 --> 00:10:00,420
which might generally in
default be an 8K block.
209
00:10:00,420 --> 00:10:03,450
So 8K block times that
value would give us
210
00:10:03,450 --> 00:10:06,750
a maximum size, for
instance, of 32 gig
211
00:10:06,750 --> 00:10:10,280
for a non-specialized datafile.
17407
Can't find what you're looking for?
Get subtitles in any language from opensubtitles.com, and translate them here.