Would you like to inspect the original subtitles? These are the user uploaded subtitles that are being translated:
1
00:00:01,360 --> 00:00:05,080
In this lesson, we're going
to discuss complete recoveries
2
00:00:05,080 --> 00:00:06,370
with RMAN.
3
00:00:06,370 --> 00:00:08,470
Now, a complete
recovery is going
4
00:00:08,470 --> 00:00:12,310
to be a recovery where all
the data is recovered up
5
00:00:12,310 --> 00:00:14,120
to the point of failure.
6
00:00:14,120 --> 00:00:15,850
So what we're going
to do in this example
7
00:00:15,850 --> 00:00:19,330
is actually simulate a failure
and perform a recovery.
8
00:00:19,330 --> 00:00:22,570
So it goes without saying that
in order to perform a recovery,
9
00:00:22,570 --> 00:00:24,400
we must have a good backup.
10
00:00:24,400 --> 00:00:27,580
So we ensure that we have a
good backup before we attempt
11
00:00:27,580 --> 00:00:31,010
to simulate a media failure.
12
00:00:31,010 --> 00:00:33,200
We need to remember that
when we do a recovery,
13
00:00:33,200 --> 00:00:35,690
it must be done in
the mount state.
14
00:00:35,690 --> 00:00:37,430
So the database
must be in mount.
15
00:00:37,430 --> 00:00:41,060
We cannot do a database recovery
while the database is in no
16
00:00:41,060 --> 00:00:43,640
mount state or in open state.
17
00:00:43,640 --> 00:00:45,710
And indeed, if we
have a media failure,
18
00:00:45,710 --> 00:00:47,480
it's not very likely
that the database
19
00:00:47,480 --> 00:00:51,870
would be in an open state, at
least in any functional way.
20
00:00:51,870 --> 00:00:53,400
When we do complete
recoveries, we
21
00:00:53,400 --> 00:00:56,400
can do them much in the
same way as backups.
22
00:00:56,400 --> 00:00:59,640
So we can do them at the
tablespace level, the data file
23
00:00:59,640 --> 00:01:02,340
level, or the entire database.
24
00:01:02,340 --> 00:01:04,770
And recovery
involves two steps--
25
00:01:04,770 --> 00:01:07,040
restore and recover.
26
00:01:07,040 --> 00:01:11,670
Restore is restoring the
backup, the file from a backup.
27
00:01:11,670 --> 00:01:15,540
And recover is the act of
rolling it forward, applying
28
00:01:15,540 --> 00:01:18,900
all the changes that have
occurred that are in the redo
29
00:01:18,900 --> 00:01:20,760
logs and archive logs.
30
00:01:20,760 --> 00:01:23,920
So restore and recover.
31
00:01:23,920 --> 00:01:28,470
So in order to simulate
this, log into RMAN.
32
00:01:28,470 --> 00:01:30,090
Connect target.
33
00:01:30,090 --> 00:01:33,240
And shut down the database.
34
00:01:33,240 --> 00:01:35,610
In this case, we need to
shut down the database
35
00:01:35,610 --> 00:01:38,610
because Windows will
prevent us from actually
36
00:01:38,610 --> 00:01:40,080
doing what I'm about to do.
37
00:01:40,080 --> 00:01:44,010
That is to change the name on a
data file simulating its loss,
38
00:01:44,010 --> 00:01:46,770
because it locks the files
when the database is open.
39
00:01:46,770 --> 00:01:48,870
However, on Linux
and Unix, you are
40
00:01:48,870 --> 00:01:51,510
free to go and destroy
a file, one of the data
41
00:01:51,510 --> 00:01:54,690
files of the database, without
the operating system stopping
42
00:01:54,690 --> 00:01:55,790
you.
43
00:01:55,790 --> 00:01:57,930
The database is shut down.
44
00:01:57,930 --> 00:01:59,960
And so I'm going to go
to the directory that
45
00:01:59,960 --> 00:02:02,150
holds the data files.
46
00:02:02,150 --> 00:02:03,980
Oracle Base
directory, there'll be
47
00:02:03,980 --> 00:02:09,420
an oradata, the name of the
database, and then data file.
48
00:02:09,420 --> 00:02:12,600
And so I'm going to target
the data file that belongs
49
00:02:12,600 --> 00:02:14,560
to the user's tablespace.
50
00:02:14,560 --> 00:02:17,640
And just for slight
safety's sake,
51
00:02:17,640 --> 00:02:21,620
I'm just going to rename
this, rather than delete it,
52
00:02:21,620 --> 00:02:23,260
to dot old.
53
00:02:23,260 --> 00:02:25,660
However, the effect is
the same, because when
54
00:02:25,660 --> 00:02:27,820
the database
attempts to start, it
55
00:02:27,820 --> 00:02:30,940
will have a problem because it
will not find this data file
56
00:02:30,940 --> 00:02:32,740
that it expects to be there.
57
00:02:32,740 --> 00:02:35,740
The data file locations are
written in the control file,
58
00:02:35,740 --> 00:02:37,690
and it expects all of
those to be there when
59
00:02:37,690 --> 00:02:39,950
the database startup occurs.
60
00:02:39,950 --> 00:02:42,620
I'm going to exit out of here.
61
00:02:42,620 --> 00:02:45,110
sqlplus as sysdba.
62
00:02:45,110 --> 00:02:47,260
And now, we're going
to just type startup
63
00:02:47,260 --> 00:02:48,460
and see how far we get.
64
00:02:55,000 --> 00:02:57,220
So notice that the instance
started and gave us
65
00:02:57,220 --> 00:02:58,870
the information
about the memory.
66
00:02:58,870 --> 00:03:01,180
And the database made
it to mount state.
67
00:03:01,180 --> 00:03:03,400
But it couldn't get
any farther than that.
68
00:03:03,400 --> 00:03:07,450
It says I cannot identify
our locked data file number 4
69
00:03:07,450 --> 00:03:08,980
and then gives us that file.
70
00:03:08,980 --> 00:03:10,960
And there it is, the
data file that belongs
71
00:03:10,960 --> 00:03:12,820
to the user's tablespace.
72
00:03:12,820 --> 00:03:15,640
And so it cannot see it, so
it's as if we just went ahead
73
00:03:15,640 --> 00:03:17,140
and deleted it.
74
00:03:17,140 --> 00:03:19,420
So now, we are already
in the mount state,
75
00:03:19,420 --> 00:03:23,230
so we're in a position that
we can restore and recover
76
00:03:23,230 --> 00:03:24,580
this data file.
77
00:03:24,580 --> 00:03:27,880
So we say restore data file 4.
78
00:03:27,880 --> 00:03:30,160
And that, again, is the
number of the data file
79
00:03:30,160 --> 00:03:33,650
that's indicating is missing.
80
00:03:33,650 --> 00:03:35,940
And we need to be
in RMAN to do this.
81
00:03:35,940 --> 00:03:42,300
The RMAN connect target,
restore data file 4.
82
00:03:42,300 --> 00:03:45,650
So what it's doing right
now is reading the backed up
83
00:03:45,650 --> 00:03:49,430
data for data file
number 4 from our backup,
84
00:03:49,430 --> 00:03:52,350
and its restoring it.
85
00:03:52,350 --> 00:03:54,780
And if we were to
see, notice that it
86
00:03:54,780 --> 00:03:59,610
has restored a data file
for the user's tablespace.
87
00:03:59,610 --> 00:04:01,380
But we're not
finished, because we
88
00:04:01,380 --> 00:04:03,480
would need to recover
all of the data that
89
00:04:03,480 --> 00:04:08,040
was lost between the time that
the database was shut down
90
00:04:08,040 --> 00:04:10,500
and when the data file was lost.
91
00:04:10,500 --> 00:04:15,130
So we say recover data file 4.
92
00:04:15,130 --> 00:04:16,420
Starting media recovery.
93
00:04:16,420 --> 00:04:18,100
Media recovery complete.
94
00:04:18,100 --> 00:04:21,160
And now, our database
is ready to be opened.
95
00:04:21,160 --> 00:04:25,570
So we do alter database open.
96
00:04:25,570 --> 00:04:28,500
So what would we do in the
event of a complete loss
97
00:04:28,500 --> 00:04:29,170
of the database?
98
00:04:29,170 --> 00:04:32,560
So what if we lost all of the
data files in the database
99
00:04:32,560 --> 00:04:35,740
if I'd actually just remove
those files that are here
100
00:04:35,740 --> 00:04:37,860
under the data file directory?
101
00:04:37,860 --> 00:04:40,030
Well, the process would
be very, very similar.
102
00:04:40,030 --> 00:04:44,080
We would simply type restore
database and then recover
103
00:04:44,080 --> 00:04:45,190
database.
104
00:04:45,190 --> 00:04:47,290
And following the
activity that occurred,
105
00:04:47,290 --> 00:04:51,000
our database would be fully
recovered and restored.
8211
Can't find what you're looking for?
Get subtitles in any language from opensubtitles.com, and translate them here.