Would you like to inspect the original subtitles? These are the user uploaded subtitles that are being translated:
1
00:00:01,390 --> 00:00:03,280
In this lesson, we're
going to be discussing
2
00:00:03,280 --> 00:00:06,400
what is perhaps the most
important task of an Oracle
3
00:00:06,400 --> 00:00:09,460
DBA, and that's
backup and recovery.
4
00:00:09,460 --> 00:00:12,340
No matter what else happens
with your database in terms
5
00:00:12,340 --> 00:00:15,310
of performance problems
or data errors,
6
00:00:15,310 --> 00:00:20,290
if you can't recover the
loss of media, of data files,
7
00:00:20,290 --> 00:00:23,250
table spaces, the loss
of a database, then
8
00:00:23,250 --> 00:00:25,330
you're going to be in
trouble really, really soon.
9
00:00:25,330 --> 00:00:27,730
And this is the kind
of thing that a DBA
10
00:00:27,730 --> 00:00:30,700
must master and really
must practice in order
11
00:00:30,700 --> 00:00:33,170
to get proficient at it.
12
00:00:33,170 --> 00:00:35,460
So when we talk about
backup and recovery,
13
00:00:35,460 --> 00:00:37,270
we're really talking
about the ability
14
00:00:37,270 --> 00:00:40,280
to recover from a media failure.
15
00:00:40,280 --> 00:00:43,480
So what kinds of things
constitute a media failure?
16
00:00:43,480 --> 00:00:45,160
Well, a media failure
would be something
17
00:00:45,160 --> 00:00:47,230
like the loss of a disk drive.
18
00:00:47,230 --> 00:00:50,050
So we have a database
that's on the D drive
19
00:00:50,050 --> 00:00:54,730
and that drive is lost, or it's
on a D drive that's actually
20
00:00:54,730 --> 00:00:58,030
a RAID group of many different
disks and maybe more than one
21
00:00:58,030 --> 00:00:59,650
of those is lost.
22
00:00:59,650 --> 00:01:03,170
So those types of things
constitute a media failure.
23
00:01:03,170 --> 00:01:05,920
Another thing that would be
considered a media failure
24
00:01:05,920 --> 00:01:09,170
would be the loss
of a data file.
25
00:01:09,170 --> 00:01:10,900
So someone goes
out to the database
26
00:01:10,900 --> 00:01:14,990
and actually deletes a
data file accidentally.
27
00:01:14,990 --> 00:01:16,360
Any of those kind
of things would
28
00:01:16,360 --> 00:01:19,300
require the
intervention of the DBA
29
00:01:19,300 --> 00:01:21,940
in the form of a
recovery operation.
30
00:01:21,940 --> 00:01:23,920
So when we talk about
backup and recovery,
31
00:01:23,920 --> 00:01:27,160
it's important to remember
that what saves us
32
00:01:27,160 --> 00:01:31,420
in situations like a media
failure isn't just our backup,
33
00:01:31,420 --> 00:01:34,510
but it's really the entire
Oracle recoverability
34
00:01:34,510 --> 00:01:35,710
architecture.
35
00:01:35,710 --> 00:01:39,760
The idea that Oracle is
built from the ground up
36
00:01:39,760 --> 00:01:43,630
to be recoverable up to the
last committed transaction.
37
00:01:43,630 --> 00:01:46,420
So it rolls into
things like redo
38
00:01:46,420 --> 00:01:49,990
logs that record every change
in the database, things
39
00:01:49,990 --> 00:01:52,720
like archive logs that
can store our reading
40
00:01:52,720 --> 00:01:54,250
logs as they switch.
41
00:01:54,250 --> 00:01:58,630
All of those things go into the
concept of backup and recovery.
42
00:01:58,630 --> 00:02:01,450
When we perform backup and
recovery operations in Oracle,
43
00:02:01,450 --> 00:02:04,300
we use a tool called
Recovery Manager
44
00:02:04,300 --> 00:02:07,300
and RMAN is going to be a
command line tool, for the most
45
00:02:07,300 --> 00:02:07,960
part.
46
00:02:07,960 --> 00:02:11,830
It interfaces with other GUI
tools, like Enterprise Manager.
47
00:02:11,830 --> 00:02:15,670
But for our purposes, we use
it in the command line setting.
48
00:02:15,670 --> 00:02:17,770
It has a number
of benefits to it
49
00:02:17,770 --> 00:02:20,080
and probably most
importantly, RMAN
50
00:02:20,080 --> 00:02:23,800
performs what's called
true block level backups.
51
00:02:23,800 --> 00:02:26,260
So when we think of the
idea of doing a backup,
52
00:02:26,260 --> 00:02:28,930
it might be as simple as
shutting down the database,
53
00:02:28,930 --> 00:02:31,370
copying all the data
files somewhere else.
54
00:02:31,370 --> 00:02:34,630
But if those data files
are all half full,
55
00:02:34,630 --> 00:02:36,640
let's say, then
we've taken longer
56
00:02:36,640 --> 00:02:39,370
to copy those files than
we really needed to.
57
00:02:39,370 --> 00:02:42,700
RMAN is capable, since it's
built into the Oracle engine,
58
00:02:42,700 --> 00:02:46,930
of looking at and reading those
database blocks in the data
59
00:02:46,930 --> 00:02:48,310
files themselves.
60
00:02:48,310 --> 00:02:52,690
Those are what gets read and
written out to backup files.
61
00:02:52,690 --> 00:02:57,250
RMAN is also capable of
ignoring empty data file blocks.
62
00:02:57,250 --> 00:03:00,790
So in tablespaces that maybe are
only a half full or a quarter
63
00:03:00,790 --> 00:03:06,040
full, it's not required of RMAN
to backup those empty blocks.
64
00:03:06,040 --> 00:03:09,580
So that makes our backups
faster and higher performing.
65
00:03:09,580 --> 00:03:11,870
RMAN also supports
compressed backup.
66
00:03:11,870 --> 00:03:14,980
So the ability to compress
our backup on the fly,
67
00:03:14,980 --> 00:03:18,520
further reducing our space
requirements for backups.
68
00:03:18,520 --> 00:03:21,100
And also supports
encrypted backups,
69
00:03:21,100 --> 00:03:24,530
backups that are built with an
encryption key or a password,
70
00:03:24,530 --> 00:03:25,900
something of that
nature in order
71
00:03:25,900 --> 00:03:29,440
to make database
backups more secure.
72
00:03:29,440 --> 00:03:32,500
Another concept in Oracle's
backup and recovery
73
00:03:32,500 --> 00:03:35,150
is something called
the fast recovery area
74
00:03:35,150 --> 00:03:37,600
and that's going to be a
specialized directory structure
75
00:03:37,600 --> 00:03:40,090
for backup related files.
76
00:03:40,090 --> 00:03:44,280
It's defined by two parameters,
db_recovery_file_dest,
77
00:03:44,280 --> 00:03:48,940
the dest being for destination,
and db_recovery_file_dest_size.
78
00:03:48,940 --> 00:03:51,340
So the recovery
file dest is going
79
00:03:51,340 --> 00:03:53,740
to be a directory
that's specified
80
00:03:53,740 --> 00:03:56,890
that will contain all
of the backup files,
81
00:03:56,890 --> 00:03:59,680
archive logs,
flashback logs, any
82
00:03:59,680 --> 00:04:02,950
of the types of files that are
related to backup and recovery.
83
00:04:02,950 --> 00:04:05,410
And Oracle put this in
place because there was too
84
00:04:05,410 --> 00:04:09,670
many instances in the real world
of DBAs who would do backups
85
00:04:09,670 --> 00:04:13,060
but then would kind of lose
track of where everything was.
86
00:04:13,060 --> 00:04:14,980
Because when you do a
recovery, a lot of times
87
00:04:14,980 --> 00:04:16,330
you need everything.
88
00:04:16,330 --> 00:04:19,750
You need to make sure you have
all of the pieces that comprise
89
00:04:19,750 --> 00:04:23,080
the backup, and there were too
many situations where databases
90
00:04:23,080 --> 00:04:25,030
became unrecoverable
because there
91
00:04:25,030 --> 00:04:29,900
wasn't any continuity to how
DBAs stored their backup files.
92
00:04:29,900 --> 00:04:32,350
So this is a really
useful thing to use.
93
00:04:32,350 --> 00:04:34,240
The fast recovery
area was formerly
94
00:04:34,240 --> 00:04:37,910
known as the flash recovery
area in previous versions.
95
00:04:37,910 --> 00:04:42,140
And so to take a look at what a
fast recovery area looks like,
96
00:04:42,140 --> 00:04:45,820
notice that we're in the Oracle
based directory on my machine
97
00:04:45,820 --> 00:04:48,460
and there's a directory
called fast recovery area.
98
00:04:48,460 --> 00:04:51,070
If we click that, we have
the name of the database.
99
00:04:51,070 --> 00:04:52,620
If we have more
than one database,
100
00:04:52,620 --> 00:04:53,950
there'll be a list of them here.
101
00:04:53,950 --> 00:04:57,280
Click that and notice the kind
of files that are stored here.
102
00:04:57,280 --> 00:05:01,270
So we have archive log files
and we have a directory here
103
00:05:01,270 --> 00:05:04,750
that is given the date so we
know exactly where our archive
104
00:05:04,750 --> 00:05:06,680
logs are.
105
00:05:06,680 --> 00:05:10,070
We have a control file
directory that'll store usually
106
00:05:10,070 --> 00:05:12,180
a copy of the control file.
107
00:05:12,180 --> 00:05:14,200
In this case, we
have online logs,
108
00:05:14,200 --> 00:05:16,970
but these are going to be
redo logs here in this case.
109
00:05:16,970 --> 00:05:19,920
So all of the recovery
related files.
110
00:05:19,920 --> 00:05:22,640
Notice that we don't
see here backup related
111
00:05:22,640 --> 00:05:25,820
files because we haven't done
any backups on this machine
112
00:05:25,820 --> 00:05:26,480
yet.
113
00:05:26,480 --> 00:05:29,040
Another concept involved
in backup and recovery,
114
00:05:29,040 --> 00:05:31,770
at least as it pertains to
RMAN, is the repository.
115
00:05:31,770 --> 00:05:33,380
So the repository
is a collection
116
00:05:33,380 --> 00:05:35,630
of information about backups.
117
00:05:35,630 --> 00:05:38,270
So you can do all the
backups that you want
118
00:05:38,270 --> 00:05:42,350
but what unit remembers
all of that information?
119
00:05:42,350 --> 00:05:44,360
What remembers
what was backed up
120
00:05:44,360 --> 00:05:46,760
and where it was written
to and so on and so forth
121
00:05:46,760 --> 00:05:48,000
for the purposes of recovery?
122
00:05:48,000 --> 00:05:50,600
What was the repository
that does that?
123
00:05:50,600 --> 00:05:53,210
And the repository can be
two different entities.
124
00:05:53,210 --> 00:05:57,420
First of all, the control file
keeps this info by default.
125
00:05:57,420 --> 00:05:59,030
So backup and
recovery information
126
00:05:59,030 --> 00:06:00,560
is stored in the control file.
127
00:06:00,560 --> 00:06:01,940
But we could also have it--
128
00:06:01,940 --> 00:06:04,580
for higher stability
and security,
129
00:06:04,580 --> 00:06:07,550
we could have it in a recovery
catalog, which is actually
130
00:06:07,550 --> 00:06:10,760
a separate database that we
would create where we could
131
00:06:10,760 --> 00:06:14,240
connect to that database and
then connect to the database
132
00:06:14,240 --> 00:06:18,110
that we're backing up, and
RMAN would talk to both areas
133
00:06:18,110 --> 00:06:21,270
and the recovery catalog
would keep that information.
134
00:06:21,270 --> 00:06:24,440
So in the event of a complete
loss including the control
135
00:06:24,440 --> 00:06:28,290
file, we would still be able
to recover the database.
136
00:06:28,290 --> 00:06:31,890
And finally, archive log
versus no archive log mode.
137
00:06:31,890 --> 00:06:34,920
So when we're talking
about no archive log mode,
138
00:06:34,920 --> 00:06:38,940
we're talking about that when
changes in the database switch,
139
00:06:38,940 --> 00:06:41,670
they're not written
out to a static file.
140
00:06:41,670 --> 00:06:44,550
So in no archive log mode,
we have the capability
141
00:06:44,550 --> 00:06:47,220
of writing over changes
that have occurred
142
00:06:47,220 --> 00:06:49,540
and that makes us
non-recoverable.
143
00:06:49,540 --> 00:06:52,560
So when we're running
with no archive log mode,
144
00:06:52,560 --> 00:06:55,080
our recovery options
are very, very limited
145
00:06:55,080 --> 00:06:56,850
and that must be stressed.
146
00:06:56,850 --> 00:07:01,140
Really, in no archive log mode,
about the only thing you can do
147
00:07:01,140 --> 00:07:05,650
is restore your backup and
that's as far as you can go.
148
00:07:05,650 --> 00:07:09,720
So if you backup on a Sunday
night and you lose media,
149
00:07:09,720 --> 00:07:12,660
data file, or
whatever on Thursday,
150
00:07:12,660 --> 00:07:16,800
then you lose all the changes
between Sunday and Thursday.
151
00:07:16,800 --> 00:07:19,410
So that's really
important to stress.
152
00:07:19,410 --> 00:07:21,720
However, with
archive log mode, we
153
00:07:21,720 --> 00:07:24,510
don't have that problem
because every change
154
00:07:24,510 --> 00:07:26,430
is stored in static files.
155
00:07:26,430 --> 00:07:28,470
So changes are written
to the redo logs,
156
00:07:28,470 --> 00:07:31,540
and then the redo logs are
written to archive logs.
157
00:07:31,540 --> 00:07:34,410
So the use of archive
log mode allows us
158
00:07:34,410 --> 00:07:36,700
to do things like hot backups.
159
00:07:36,700 --> 00:07:38,820
So backups while
the database is up.
160
00:07:38,820 --> 00:07:42,330
We can do a recovery up until
the very point of failure.
161
00:07:42,330 --> 00:07:45,060
The very last
committed transaction
162
00:07:45,060 --> 00:07:47,910
can be recovered when
we're in archive log mode.
163
00:07:47,910 --> 00:07:50,850
And we can also do things
like time-based recoveries.
164
00:07:50,850 --> 00:07:54,940
So we can recover a database
to the point in the past.
165
00:07:54,940 --> 00:07:59,760
So how do we decide if we're an
archive log mode or no archive
166
00:07:59,760 --> 00:08:01,080
log mode?
167
00:08:01,080 --> 00:08:04,490
Let's go into our
database, Assist DBA,
168
00:08:04,490 --> 00:08:09,270
and we'll execute a command
called archive log list.
169
00:08:09,270 --> 00:08:12,300
So archive log list tells
us that our database log
170
00:08:12,300 --> 00:08:14,580
mode is no archive mode.
171
00:08:14,580 --> 00:08:18,720
Automatic archival is disabled,
and our archive destination,
172
00:08:18,720 --> 00:08:23,250
should we enable archive log, is
a keyword use DB recovery file
173
00:08:23,250 --> 00:08:27,060
desk, which means it is writing
to the fast recovery area.
174
00:08:27,060 --> 00:08:28,890
So our database
is open right now.
175
00:08:28,890 --> 00:08:31,940
How can we put our database
in archive log mode
176
00:08:31,940 --> 00:08:34,980
so we can have the most
recoverability options?
177
00:08:34,980 --> 00:08:38,490
Well, in order to enable archive
log mode, it's very simple
178
00:08:38,490 --> 00:08:40,680
but we need to be
in the mount state.
179
00:08:40,680 --> 00:08:42,390
So we're going to shut
down our database.
180
00:08:46,490 --> 00:08:48,710
We're going to start
up in mount mode.
181
00:08:51,450 --> 00:08:53,990
So now we're in the mount
state, and we simply
182
00:08:53,990 --> 00:08:59,440
type alter database archive log.
183
00:08:59,440 --> 00:09:01,660
Now we're an archive
log mode so we
184
00:09:01,660 --> 00:09:05,650
need to start up the database,
at least to the open state,
185
00:09:05,650 --> 00:09:06,730
alter database open.
186
00:09:09,260 --> 00:09:12,900
So with our database open, we
can do archive log list again
187
00:09:12,900 --> 00:09:14,250
to check.
188
00:09:14,250 --> 00:09:19,490
Now we are in archive mode with
automatic archival enabled.
189
00:09:19,490 --> 00:09:22,650
We want to make sure of this and
kind of see it for ourselves,
190
00:09:22,650 --> 00:09:27,890
we could do an alter
system switch log file.
191
00:09:27,890 --> 00:09:31,240
So this will switch from
the one redo log to the next
192
00:09:31,240 --> 00:09:33,870
and write out our archive log.
193
00:09:33,870 --> 00:09:37,130
We go back to our
fast recovery area.
194
00:09:37,130 --> 00:09:39,110
We notice there is
a new folder written
195
00:09:39,110 --> 00:09:42,710
for the date and an
archive log written out.
196
00:09:42,710 --> 00:09:44,870
So now we're in archive
log mode and fully
197
00:09:44,870 --> 00:09:48,550
prepared to do backups
and recoveries.
16663
Can't find what you're looking for?
Get subtitles in any language from opensubtitles.com, and translate them here.