البيانات اوركل الجزء الثانى
البيانات اوركل الجزء الثانى
البيانات اوركل الجزء الثانى
ﺍﻟﺠﺯﺀ ﺍﻟﺜﺎﻨﻰ
1
ﺍﻟﻔﻬﺭﺱ
3 اﻟﻤﻘﺪﻣﺔ 2
Managing Shared
5 Servers 3
Logical Backup 4
21 & Recovery
73 Physical Backup 5
& Recovery
2
ﺍﻟﻤﻘﺩﻤﺔ
ﺍﻟﻴﻜﻡ ﺍﻴﻬﺎ ﺍﻟﻔﻀﻼﺀ ﺍﻟﺠﺯﺀ ﺍﻟﺜﺎﻨﻰ ﻤﻥ ﺍﻟﻜﺘﺎﺏ ﺍﻟﻌﺭﺒﻰ ﻹﺩﺍﺭﺓ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺍﻭﺭﻜل ﻭﺍﻟﺫﻯ
ﻨﺎﻗﺸﺕ ﻓﻴﻪ ﺍﻟﻤﻭﺍﻀﻴﻊ ﺍﻻﻜﺜﺭ ﺤﺴﺎﺴﻴﺔ ﻟﻤﺩﻴﺭ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻭﺍﻟﺘﻰ ﺘﺘﻌﻠﻕ ﺒﺎﻟﺤﻔﺎﻅ ﻋﻠﻰ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ.
ﺍﺘﺒﻌﺕ ﻓﻴﻪ ﺍﺴﻠﻭﺏ ﺍﻟﺘﺒﺴﻴﻁ ﻜﻤﺎ ﻓﻌﻠﺕ ﻓﻰ ﺍﻟﺠﺯﺀ ﺍﻻﻭل ،ﻭﺤﺎﻭﻟﺕ ﺍﻴﻀﹰﺎ ﺃﻥ ﺍﺭﻜﺯ ﻋﻠﻰ ﺍﻟﺠﺎﻨﺏ
ﺍﻟﻌﻤﻠﻰ ﺤﺘﻰ ﺘﺜﺒﺕ ﺍﻟﻔﻜﺭﺓ ﺍﻜﺜﺭ ﻭﺍﻋﻤﻕ.
ﻫﺫﺍ ﺍﻟﺠﺯﺀ ﻫﻭ ﻋﺼﺎﺭﺓ ﻓﺼﻭل ﻜﺜﻴﺭﺓ ﻭﻤﺘﻔﺭﻗﺔ ،ﺍﺜﺭﺕ ﺃﻥ ﺍﺠﻤﻌﻬﺎ ﻟﻙ ﻓﻰ ﻫﺫﻩ ﺍﻟﻔﺼﻭل ﺍﻟﻤﻌﺩﻭﺩﺓ
ﻼ ﺍﻥ ﺘﺼﻠﻙ ﺍﻟﻔﻜﺭﺓ ﺒﺎﺴﻬل ﻁﺭﻕ ﻭﺩﻭﻥ ﺘﻌﻘﻴﺩ.
ﻭﺍﻟﻭﺭﻗﺎﺕ ﺍﻟﻤﺤﺩﻭﺩﺓ ﺍﻤ ﹰ
ﻭﻨﺼﻴﺤﺘﻰ ﻟﻙ ﺍﻟﻌﻤل ﺜﻡ ﺍﻟﻌﻤل ﺜﻡ ﺍﻟﻌﻤل ،ﻓﺎﻟﻘﺭﺍﺀﺓ ﻭﺤﺩﻫﺎ ﻻ ﺘﻜﻔﻰ ﻓﻰ ﻫﺫﺍ ﺍﻟﻤﺠﺎل ﻓﻴﺠﺏ ﺃﻥ ﺘﻁﺒﻕ
ﻜل ﺤﺭﻑ ﻗﺭﺃﺘﻪ ،ﺤﻴﻨﻬﺎ ﻓﻘﻁ ﺘﻅل ﺍﻟﻤﻌﻠﻭﻤﺔ ﻤﺤﻔﻭﺭﺓ ﻓﻰ ﺫﺍﻜﺭﺘﻙ.
ﻭﺍﺨﻴﺭﹰﺍ ﻻ ﺒﺩ ﻤﻥ ﺍﻟﺸﻜﺭ ﻟﻜل ﻤﻥ ﺘﻭﺍﺼل ﻤﻌﻰ ﺤﺘﻰ ﺍﻜﻤﻠﺕ ﻫﺫﻩ ﺍﻟﻭﺭﻗﺎﺕ ،ﻭﺍﺨﺹ ﺒﺎﻟﺸﻜﺭ
ﺍﻋﻀﺎﺀ ﻜﺭﺍﻡ ﻤﻥ ﻤﺠﻤﻭﻋﺔ ﻤﺴﺘﺨﺩﻤﻰ ﻋﺭﺏ ﺍﻭﺭﺍﻜل ،ﻜﺎﻨﻭﺍ ﻋﻠﻰ ﺘﻭﺍﺼل ﻤﻌﻰ ﺤﺘﻰ ﺨﺭﺠﺕ ﻫﺫﻩ ﺍﻟﻤﺎﺩﺓ ،
ﻓﺎﺭﺠﻭ ﺍﻥ ﻨﻜﻭﻥ ﻋﻨﺩ ﺤﺴﻥ ﺍﻟﻅﻥ ﻭﺍﻥ ﺘﻜﻭﻥ ﻫﺫﻩ ﺍﻟﻤﺎﺩﺓ ﻨﺎﻓﻌﺔ ﺒﺈﺫﻥ ﺍﷲ.
3
4
5
ﻓﻰ ﺍﻻﺼل ﻓﺈﻨﻪ ﻋﻨﺩﻤﺎ ﻴﻁﻠﺏ ﺍﻟﻤﺴﺘﺨﺩﻡ User Processﺒﺎل Instanceﻓﺈﻥ ﺍل Oracleﻴﻘﻭﻡ
ﺒﺈﻨﺸﺎﺀ Server Processﻤﻬﻤﺘﻪ ﺨﺩﻤﺔ ﻁﻠﺒﺎﺕ ﺫﻟﻙ ﺍﻟﻤﺴﺘﺨﺩﻡ ﻭﻴﻅل ﻫﺫﺍ ﺍل Server Processﻤﻭﺠﻭﺩ
ﻤﺎﺩﺍﻡ ﺍل Sessionﻤﻔﺘﻭﺤﺔ ،ﻭﻴﺴﺘﻁﻴﻊ ﺍﻻﻭﺭﻜل ﺇﻨﺸﺎﺀ Server Processﻟﻜل User Processﻴﻁﻠﺏ
ﺍﻹﺘﺼﺎل ﺒﺎل ، Instanceﻭﻫﺫﺍ ﻤﺎ ﻴﺴﻤﻰ ﺒﺎل.Dedicated Server
ﻭﺍﻻﻭﺭﻜل ﻟﻴﺱ ﻟﺩﻴﻪ ﻤﺸﻜﻠﺔ ﻓﻰ ﺇﻨﺸﺎﺀ ﺍﻜﺒﺭ ﻋﺩﺩ ﻤﻥ ﺍل Server Processesﻟﺨﺩﻤﺔ ﺍل User
Processesﺒﺤﻴﺙ ﻴﻜﻭﻥ User Processﻟﻜل ، Server Processﻟﻠﻜﻥ ﺒﺎﻟﻁﺒﻊ ﻗﺩ ﻴﻜﻭﻥ ﻫﻨﺎﻙ ﺤﺩﻭﺩ
ﻟﺴﺭﻋﺔ ﺍل Server Processesﺍﻟﺘﻰ ﻴﻤﻜﻥ ﺃﻥ ﺘﻌﻤل ﻓﻰ ﻨﻔﺱ ﺍﻟﻠﺤﻅﺔ.
ﻭﻴﻤﻜﻥ ﺍﻟﻘﻭل ﺃﻨﻪ ﻜﻠﻤﺎ ﻗﺎﻡ ﻤﺴﺘﺨﺩﻡ ﺒﺎل Instanceﻓﺈﻥ ﺍﻟﻤﺴﺘﻤﻊ Listenerﺒﺈﻨﺸﺎﺀ Server
، Processﺍﻤﺎ ﺇﺫﺍ ﻜﺜﺭ ﻋﺩﺩ ﺍل Server processﻓﺈﻥ ﺍﻟﻤﺴﺘﻤﻊ ﻴﺠﻌل ﻟﻬﻡ ﺼﻔﹰﺎ ،ﻋﻤﻭﻤﹰﺎ ﻴﻤﻜﻥ ﺘﻔﺎﺩﻯ ﻫﺫﻩ
ﺍﻟﻤﺸﻜﻠﺔ ﺒﺈﻨﺸﺎﺀ ﻤﺴﺘﻤﻊ ﺍﺨﺭ Listenerﻴﻌﻤل ﻋﻠﻰ ﺒﻭﺭﺕ ﺍﺨﺭ ﻟﺘﻭﺯﻴﻊ ﺍﻟﻌﻤل ﺒﻴﻨﻬﻡ.
ﻟﻜﻥ ﻟﻴﺴﺕ ﺍﻟﻤﺸﻜﻠﺔ ﻓﻰ ﺍﻻﻭﺭﻜل ﻭﺤﺩﻩ ﻓﻨﻅﺎﻡ ﺍﻟﺘﺸﻐﻴل ﺍﻟﺘﻰ ﺘﻌﻤل ﻋﻠﻴﻪ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻭﻜﺫﻟﻙ
ﺍﻟﻤﺎﻜﻴﻨﺔ ﺍﻟﺘﻰ ﺘﻌﻤل ﻋﻠﻴﻬﺎ؛ ﻜل ﺫﻟﻙ ﺘﺠﻌل ﻟﻙ ﺤﺩﻭﺩ ﻓﻰ ﺍﻟﺘﻌﺎﻤل ﻤﻊ ﻋﺩﺩ ﻜﺒﻴﺭ ﻤﻥ ﺍلServer Process
ﻓﻨﻅﺎﻡ ﺍﻟﺘﺸﻐﻴل ﻭﺤﺠﻡ ﺍﻟﺫﺍﻜﺭﺓ ﻭﺴﺭﻋﺔ ﺍﻟﻤﻌﺎﻟﺞ ﻭﻏﻴﺭﻫﺎ ﻤﻥ ﺍﻟﻤﺅﺜﺭﺍﺕ ﺍﻟﺘﻰ ﺘﺤﺩ ﻤﻥ ﺇﻤﻜﺎﻨﻴﺔ ﻋﺩﺩ ﻻ ﻤﻨﺘﺎﻫﻰ
ﻤﻥ ﺍل Server Processﺠﻌﻠﺕ ﺸﺭﻜﺔ ﺍﻭﺭﻜل ﺘﻔﻜﺭ ﻓﻰ ﻤﻭﻀﻭﻉ ﺍل Shared Serverﻭﻫﻭ ﺒﺈﺨﺘﺼﺎﺭ
ﺇﻨﺸﺎﺀ Shared serverﻟﺨﺩﻤﺔ ﻤﺠﻤﻭﻋﺔ ﻤﻥ ﺍل User Processﺒﺩل ﻤﻥ ﺇﻨﺸﺎﺀ Server Processﻟﻜل
User Processﻤﻤﺎ ﺠﻌل ﻓﻰ ﻫﺫﺍ ﺍﻟﻨﻤﻁ ﻤﺠﻤﻭﻋﺔ ﻤﻥ ﺍﻟﻔﻭﺍﺌﺩ:
-1ﺘﻘﻠﻴل ﻋﺩﺩ ﺍل Server Processﺍﻟﻤﺘﺼﻠﺔ ﺒﺎل.Instance
-2ﺯﻴﺎﺩﺓ ﻋﺩﺩ ﺍﻟﻤﺴﺘﺨﺩﻤﻴﻥ ﺍﻟﻤﺘﺼﻠﻴﻥ ﺒﻘﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺇﺫ ﻻ ﻴﺘﻡ ﺇﺸﺎﺀ Server Processﻟﻜل ﻤﺴﺘﺨﺩﻡ.
-3ﺘﻘﻠﻴل ﻋﺩﺩ ﺍل Server processesﺍﻟﻌﺎﻁﻠﺔ ﻋﻥ ﺍﻟﻌﻤل.
-4ﺘﻘﻠﻴل ﺤﺠﻡ ﺍﻟﺫﺍﻜﺭﺓ ﺍﻟﻤﺴﺘﺨﺩﻤﺔ ﻓﻰ ﺍﻟﻌﻤل ﻭﻜﺫﻟﻙ ﺍﻟﻤﻭﺍﺭﺩ ﺍﻻﺨﺭﻯ.
6
:Dedicated Server
ﻭﻫﺫﺍ ﺍﻟﻨﻤﻁ ﺍﻟﺫﻯ ﺘﻌﻤل ﺒﻪ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻓﻰ ﺍﻻﺼل ﺒﺤﻴﺙ ﻴﺘﻡ ﺇﻨﺸﺎﺀ Server Processesﻟﻜل
User Processesﻴﻁﻠﺏ ﺍﻹﺘﺼﺎل ﺒﻘﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ،ﺒﺤﻴﺙ ﻴﺴﺘﻁﻴﻊ ﺍل Server Processﺍﻹﺘﺼﺎل ،ﺍﻨﺕ
ﻤﻥ ﺨﻼل ﻨﻅﺎﻡ ﺍﻟﺘﺸﻐﻴل ﺘﺴﺘﻁﻴﻊ ﻤﺭﺍﻗﺒﺔ ﻋﺩﺩ ﺍل Server Processﺍﻟﺘﻰ ﺘﻌﻤل ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ،ﻓﻔﻰ ﻨﻅﺎﻡ
ﺍﻟﺘﺸﻐﻴل ﻭﺒﻨﺩﻭﺯ ﺘﺴﺘﻁﻴﻊ ﻤﺘﺎﺒﻌﺔ ﺫﻟﻙ ﻋﻥ ﻁﺭﻴﻕ ﺍل ، Task Managerﻭﻫﻰ ﻓﻰ ﺍﻟﺤﻘﻴﻘﺔ ﻟﻴﺴﺕ
Opreting system Processesﻭﺇﻨﻤﺎ ﺘﻅﻬﺭ ﻙ Single Oracle.exe Processﻭﻟﻜﻥ ﺃﻨﺕ ﺘﺴﺘﻁﻴﻊ
ﻤﻌﺭﻓﺔ ﻋﺩﺩ ﺍل Processﻋﻥ ﻁﺭﻴﻕ Thread countﻓﻰ ﺍل.Task Manager
7
ﺒﺎﻟﻁﺒﻊ ﺘﺴﺘﻁﻴﻊ ﺇﻨﻬﺎﺀ ﺠﻤﻴﻊ ﺍل Server Processesﻋﻥ ﻁﺭﻴﻕ ﺍل.End Process
8
:Shared Server Architecture
ﻋﻨﺩﻤﺎ ﻴﺘﻡ ﺘﻬﻴﺌﺔ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻟﺘﻌﻤل ﺒﺎﻟﻨﻤﻁ Shared Serrverﻓﺈﻥ ﻫﺘﺎﻙ ﻨﻭﻋﺎﻥ ﻤﻥ ﺍلPrcess
،ﺍﻴﻀﹰﺎ ﻴﺘﻡ ﺇﻨﺸﺎﺀ ﻋﺩﺩ ﻤﻥ ﺍﻟﺼﻔﻭﻑ ﻋﻠﻰ ﻴﺘﻡ ﺇﻨﺸﺎﺀﻫﻡ ) (Dispatchers & Shared servers
ﺍﻟﺫﺍﻜﺭﺓ ، SGAﻜﻤﺎ ﻴﺘﻡ ﺘﻌﺩﻴل ﺴﻠﻭﻙ ﺍﻟﻤﺴﺘﻤﻊ ) (Listenerﻟﻜﻰ ﻴﻌﻤل ﻤﻊ ﺍل، Shared Server
ﻭﺍل Dispatcherﻫﻰ ﻋﺒﺎﺭﺓ ﻋﻥ Processﻴﻌﻤل ﻋﻠﻰ TCP PORTﻭﻴﺘﻡ ﺘﺴﺠﻴﻠﻪ ﻟﺩﻯ ﺍلListener
ﻻﺤﻅ ﻤﻌﻰ ﺨﻁﻭﺍﺕ ﻋﻤل ﺍل Shared Server Processﻓﻌﻨﺩﻤﺎ ﻴﻁﻠﺏ ﺍلUser Process
ﺍﻹﺘﺼﺎل ﺒﺎل Instanceﻻ ﻴﻘﻭﻡ ﺍﻟﻤﺴﺘﻤﻊ ﺒﺈﻨﺸﺎﺀ Server Processﻜﻤﺎ ﻜﺎﻥ ﺍﻟﺤﺎل ﻓﻰ ﺍل Dedicate
Serverﻭﻟﻜﻥ ﻴﻘﻭﻡ ﺍﻟﻤﺴﺘﻤﻊ ﺒﺈﺒﻘﺎﺀ ﻗﺎﺌﻤﺔ ﺍل Dispatchersﺍﻟﻤﺘﺎﺤﺔ ﺍﻟﺘﻰ ﻴﻘﻭﻡ ﺍﺤﺩﻫﺎ ﺒﺈﺴﺘﻘﺒﺎل ﺫﻟﻙ ﺍﻟﻁﻠﺏ
ﻭﺘﻤﺭﻴﺭﻩ ﺇﻟﻰ ﺍل Request Queueﻤﻊ ﺍﻟﻌﻠﻡ ﺃﻥ ﻫﺫﺍ ﺍﻟﺼﻑ ﻴﺤﻭﻯ ﺠﻤﻴﻊ ﺍﻟﻁﻠﺒﺎﺕ ﺍﻟﺘﻰ ﺍﺴﺘﻘﺒﻠﺘﻬﺎ ﺠﻤﻴﻊ
ﺍل ، Dispatchersﻤﻊ ﺍﻟﻌﻠﻡ ﺃﻥ ﻫﺫﺍ ﺍﻟﺼﻑ ﻴﺘﻡ ﺘﻜﻭﻴﻨﻪ ﺍﻟﻴﹰﺎ ﻋﻨﺩ ﺘﻬﻴﺌﺔ ﺍل Instanceﻓﻰ ﺍﻟﻨﻤﻁ Shared
Serverﻭﺍﻴﻀﹰﺎ ﻴﺘﻡ ﺘﺤﺩﻴﺩ ﻋﺩﺩ ﺍل Dispatchersﺍﻟﺘﻰ ﻴﺘﻡ ﺍﻨﺸﺎﺅﻫﺎ.
9
ﺒﻌﺩﻤﺎ ﺘﺼل ﺍﻟﻁﻠﺒﺎﺕ ﺇﻟﻰ ﺍل Request Queueﺘﻅل ﺠﻤﻴﻊ ﺍل Shared Serversﺘﺭﺍﻗﺏ
ﻫﺫﺍ ﺍﻟﺼﻑ ﺍﻟﺫﻯ ﻴﺤﻭﻯ ﻤﺠﻤﻭﻋﺔ ﻤﻥ ﺍﻟﻁﻠﺒﺎﺕ ،ﻓﻠﺤﻅﺔ ﺇﻨﺘﻬﺎﺀ ﺃﺤﺩ ﺍل Shared Serverﻤﻥ ﺨﺩﻤﺔ ﺍﺤﺩ
ﺍﻟﻁﻠﺒﺎﺕ ﻴﺘﻡ ﺘﺭﺸﻴﺢ ﻁﻠﺏ ﺍﺨﺭ ﻤﻥ ﺍل Request Queueﺇﻟﻰ ﺫﻟﻙ ﺍل ، Shared Server Processﺒﻌﺩﻤﺎ
ﻴﻔﺭﻕ ﺍل Shared server Processﻤﻥ ﻤﻌﺎﻟﺠﺔ ﺍﻟﻁﻠﺏ ﻴﻘﻭﻡ ﺒﺘﻤﺭﻴﺭﻩ ﺇﻟﻰ ﺍل، Response Queue
ﻭﺍﻟﺤﻘﻴﻘﺔ ﺃﻥ ﻫﻨﺎﻙ ﻤﺠﻤﻭﻋﺔ ﻤﻥ ﺍل Response Queueﺒﻤﻌﺩل ﺼﻑ ﻟﻜل Dispatcherﻓﻴﻘﻭﻡ
ﺍل Shared Serverﺒﺘﻤﺭﻴﺭ ﺍﻟﻨﺘﻴﺠﺔ ﺇﻟﻰ ﺍل Response Queueﺍﻟﺨﺎﺹ ﺒﺎل Dispatcherﺍﻟﺫﻯ ﻗﺎﻡ
ﻻ ،ﺒﻌﺩ ﺫﻟﻙ ﻴﺘﻡ ﺘﻤﺭﻴﺭ ﺍﻟﺭﺩ ﺍﻭ ﺍﻟﻨﺘﻴﺠﺔ ﻤﻥ ﺍل Response Queueﺇﻟﻰ
ﺒﺈﺴﺘﻘﺒﺎل ﺍﻟﻁﻠﺏ ﺍﻭ ﹰ
ﺍل Dispatcherﺍﻟﺫﻯ ﺒﺩﻭﺭﻩ ﻴﻘﻭﻡ ﺒﺈﺭﺴﺎل ﺍﻟﺭﺩ ﺇﻟﻰ ﺍلUser Process
10
:The SGA and PGA
Dedicated Server
Shared Server
ﻻﺤﻅ ﻤﻌﻰ ﺍﻟﻔﺭﻕ ﻓﻰ ﺘﻜﻭﻴﻨﺔ ﺍﻟﺫﺍﻜﺭﺓ ﻟﻜل ﻤﻥ ﺍل Dedicated Serverﻭﺍل، Shared Server
ﻟﻤﺎ ﻜﺎﻥ ﻟﻜل User Processﻴﺘﺼل ﺒﻘﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ Server processﺨﺎﺹ ﺒﻪ ﻜﻤﺎ ﻫﻭ ﺍﻟﺤﺎل ﻓﻰ
ﺍل Dedicated Serverﺤﻴﺙ ﻴﺘﻡ ﺘﺨﺯﻴﻥ ﺍل User Session Dataﻭﻫﻰ ﺍﻤﻥ ﻭﻤﺼﺎﺩﺭ ﺍﻟﻤﻌﻠﻭﻤﺎﺕ
ﺍﻟﻤﺴﺘﺨﺩﻤﺔ ﻓﻰ ﺍل PGAﻭﻫﻰ ﺍﻟﺫﺍﻜﺭﺓ ﺍﻟﺨﺎﺼﺔ ﺒﻜل Server Processﻭﺍﻴﻀﹰﺎ Cursor stateﻭﻟﻜﻥ ﻟﻤﺎ
ﻜﺎﻥ ﺍﻻﻤﺭ ﻋﻠﻰ ﺨﻼﻑ ﺫﻟﻙ ﻓﻰ ﺍل Shared Serverﺘﻡ ﺘﺨﺯﻴﻥ ﻫﺫﻩ ﺍﻟﻤﻌﻠﻭﻤﺎﺕ ﻓﻰ ﺍل SGAﻭﻫﻰ ﺍﻟﺫﺍﻜﺭﺓ
ﺍﻟﻌﺎﻤﺔ ﺤﻴﺙ ﺘﺘﻡ ﻓﻴﻬﺎ ﺍﻟﻤﺸﺎﺭﻜﺔ ،ﻟﻜﻥ ﻻﺤﻅ ﺃﻥ ﻤﻌﻠﻭﻤﺎﺕ ﺍل Stack Spaceﻓﻰ ﻜﻼ ﺍﻟﺤﺎﻟﻴﻥ ﻴﺘﻡ ﺘﺨﺯﻴﻨﻬﺎ
ﻓﻰ ﺍل PGAﻭﺫﻟﻙ ﻷﻨﻬﺎ ﺘﺤﻭﻯ ﺍﻟﻤﺘﻐﻴﺭﺍﺕ ﺍﻟﻤﺤﻠﻴﺔ ﻟل.Process
11
:Configure Oracle Shared Server
ﻟﺘﻬﻴﺌﺔ ﺍل Instanceﻟﺘﻌﻤل ﻋﻠﻰ ﺍﻟﻨﻤﻁ Shared Serverﻓﻘﻁ ﻴﻠﺯﻤﻨﺎ ﺘﻬﻴﺌﺔ ﺒﻌﺽ
ﺍﻟﺘﻐﻴﺭﺍﺕ ﻋﻠﻰ ﻤﻠﻑ ﺍﻟﻤﺘﻐﻴﺭﺍﺕ ، Prameter Fileﺍﻤﺎ ﺍل Listenerﻓﻴﺘﻡ ﺘﻬﻴﺌﺘﻬﺎ ﺍﻟﻴﹰﺎ ﺨﻼل Dynamic
Instance Registration
ﻫﺫﻩ ﻫﻰ ﻤﺠﻤﻭﻋﺔ ﺍﻟﻤﺘﻐﻴﺭﺍﺕ ﺍﻟﺘﻰ ﺘﺘﻌﻠﻕ ﺒﻤﻭﻀﻭﻉ ﺍل Shared Serverﻭﺍﻟﺘﻰ ﻴﻤﻜﻥ ﺘﻬﻴﺌﺘﻬﺎ ﺤﺘﻰ
ﺘﻌﻤل ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻓﻰ ﺍﻟﻭﻀﻊ Shared Serverﻭﻟﻜﻥ ﻻﺤﻅ ﻤﻌﻰ ﺃﻥ ﻫﻨﺎﻙ ﻤﺘﻐﻴﺭ ﻭﺍﺤﺩ ﻓﻘﻁ ﻻﺒﺩ ﻤﻥ
ﺘﻬﻴﺌﺘﻪ ﻭﻫﻭ ﺍﻟﻤﺘﻐﻴﺭ DISPATCHERSﺍﻤﺎ ﺒﻘﻴﺔ ﺍﻟﻤﺘﻐﻴﺭﺍﺕ ﻓﻬﻰ ﺇﺨﺘﻴﺎﺭﻴﺔ.
12
:SHARED_SERVERS
ﻭﻫﺫﺍ ﺍﻟﻤﺘﻐﻴﺭ ﻟﺘﺤﺩﻴﺩ ﻋﺩﺩ ﺍل SHARED SERVERﺍﻟﺘﻰ ﻴﺘﻡ ﺇﻨﺸﺎﺅﻫﺎ ﻟﺤﻅﺔ ﺘﺸﻐﻴل
ﺍل Instanceﻓﻰ ﺍﻟﻨﻤﻁ Shared serverﻭﻫﻭ ﻤﺘﻐﻴﺭ ﺍﹼﻟﻰ ﺒﻤﻌﻨﻰ ﺃﻨﻙ ﺘﺴﺘﻁﻴﻊ ﺘﻐﻴﻴﺭ ﻗﻴﻤﺘﻪ ﺩﻭﻥ ﺇﻏﻼﻕ
ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ،ﻭﻴﺤﻤل ﻫﺫﺍ ﺍﻟﻤﺘﻐﻴﺭ ﻓﻰ ﺍﻻﺼل ﺍﻟﻘﻴﻤﺔ 0ﻤﺎﺩﺍﻡ ﺃﻥ ﺍل Dispatcherﻴﺴﺎﻭﻯ .NULL
:DISPATCHERS
ﻭﻫﺫﺍ ﺍﻟﻤﺘﻐﻴﺭ ﻟﺘﺤﺩﻴﺩ ﻋﺩﺩ ﺍل Dispatcherﺍﻟﺘﻰ ﻴﺘﻡ ﺇﻨﺸﺎﺅﻫﺎ ﻟﺤﻅﺔ ﺘﺸﻐﻴل ﺍل Instanceﻓﻰ ﺍﻟﻨﻤﻁ
Shared serverﺤﺴﺏ ﺍل PROTOCOLﺍﻟﻤﻌﻁﻰ ،ﻭﻴﺎﺨﺫ ﻓﻰ ﺍﻻﺼل ﺍﻟﻘﻴﻤﺔ NULLﻭﻻﺒﺩ ﻤﻥ ﺘﻬﻴﺌﺔ
ﻫﺫﻩ ﺍﻟﻤﺘﻐﻴﺭ ﻟﺘﻌﻤل ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻓﻰ ﺍﻟﻨﻤﻁ .Shared Server
:MAX_SHARED_SERVERS
،ﻭﻫﻭ ﻤﺘﻐﻴﺭ ﻭﻫﺫﺍ ﺍﻟﻤﺘﻐﻴﺭ ﻟﺘﺤﺩﺩﻴﺩ ﺍﻗﺼﻰ ﻋﺩﺩ ﻤﻥ ﺍل Shared Serverﻴﻤﻜﻥ ﺃﻥ ﻴﺘﻡ ﺘﺸﻐﻴﻠﻪ
ﺍﹼﻟﻰ ﻴﺴﻤﺢ ﻟل Shared Serverﺒﺯﻴﺎﺩﺓ ﻋﺩﺩ ﺍل Shared Serverﻋﻨﺩ ﺍﻟﺤﻭﺠﺔ ﺇﻟﻰ ﺫﻟﻙ.
:SHARED_SERVER_SESSION
ﻭﻫﺫﺍ ﺍﻟﻤﺘﻐﻴﺭ ﻟﺘﺤﺩﻴﺩ ﻋﺩﺩ ﺍل Sessionsﺍﻟﺘﻰ ﻴﻤﻜﻥ ﺃﻥ ﺘﻔﺘﺢ ﻓﻰ ﻨﻔﺱ ﺍﻟﻠﺤﻅﺔ ﻋﻠﻰ ﺍل Shared
.Server
13
.Shared Server ﺇﻟﻰ ﺍلDedicated Serverﻭﻟﻨﻔﺘﺭﺽ ﺍﻻﻥ ﺍﻨﻨﺎ ﻨﺭﻴﺩ ﺘﻐﻴﻴﺭ ﻋﻤل ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻤﻥ ﺍل
SQL>SHUTDOWN IMMEDIATE
SQL>STARTUP
14
SHARED SERVERS ﻭﺍلDISPATCHERS ﺍﻟﺘﺄﻜﺩ ﻤﻥ ﻋﻤل ﺍل-4
15
-5ﺍﻟﺘﺄﻜﺩ ﻤﻥ ﺘﺴﺠﻴل ﺍل DISPATCHERSﻓﻰ ﺍل.LISTENER
C:\LSNRCTL SERVICE
ﺃﻨﺕ ﻜﻤﺩﻴﺭ ﻟﻘﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺘﺤﺘﺎﺝ ﻟﻭﻀﻊ ﻤﻭﺍﺯﺍﻨﺎﺕ ﻹﺘﺨﺎﺫ ﺍﻟﻘﺭﺍﺭ ﺍﻟﻤﻨﺎﺴﺏ ﻓﺈﻨﺕ ﻤﺤﻜﻭﻡ ﺒﺤﺠﻡ
ﻤﻌﻴﻥ ﻤﻥ ﺍﻟﻤﻭﺍﺭﺩ ﻭﻓﻰ ﻨﻔﺱ ﺍﻟﻠﺤﻅﺔ ﺍﻨﺕ ﻤﻁﺎﻟﺏ ﺒﺘﻭﻓﻴﺭ ﺇﻤﻜﺎﻨﻴﺔ ﻭﺼﻭل ﻋﺩﺩ ﻤﻌﻴﻥ ﻤﻥ ﺍﻟﻤﺴﺘﺨﺩﻤﻴﻥ ﺩﻭﻥ
ﺘﺄﺨﻴﺭ ،ﻋﻤﻭﻤﹰﺎ ﻴﺠﺏ ﻋﻠﻰ ﻤﺩﻴﺭ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺍﻟﺘﻨﺴﻴﻕ ﻤﻊ ﻤﺩﻴﺭ ﺍﻟﻨﻅﺎﻡ ﻹﺘﺨﺎﺫ ﺍﻟﻘﺭﺍﺭ ﺍﻟﻤﻨﺎﺴﺏ.
16
ﻟﻨﻔﺘﺭﺽ ﺍﻻﻥ ﺃﻨﻙ ﻗﻤﺕ ﺒﺘﺸﻐﻴل ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻓﻰ ﺍﻟﻭﻀﻊ Shared Serverﻓﻴﻤﻜﻨﻙ ﺘﺠﺎﻭﺯ
ﺍﻹﺘﺼﺎل ﺒﻘﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻤﻥ ﺨﻼل ﻫﺫﺍ ﺍﻟﻨﻤﻁ ﺍﻭ ﺇﻥ ﺸﺌﺕ ﻓﻘل ﻤﻥ ﺨﻼل ﺍل Dedicated Serverﻭﺫﻟﻙ
ﻤﻥ ﺨﻼل ﺍﻹﺘﺼﺎل ﺒﻘﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ Locallyﻤﻥ ﻨﻔﺱ ﺍﻟﻤﺎﻜﻴﻨﺔ ﺍﻟﺘﻰ ﺒﻬﺎ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺃﻯ ﺩﻭﻥ ﺍﻟﻤﺭﻭﺭ
ﺒﺎل Listenerﻭﺫﻟﻙ ﻷﻥ ﺍﻹﺘﺼﺎل ﻴﺘﻡ ﻤﺒﺎﺸﺭﺓ ﺒﻘﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻭﺩﻭﻥ ﺇﺴﺘﺨﺩﺍﻡ ﺍل tnsnames.oraﺍﻟﺘﻰ
ﺘﺤﻭﻟﻙ ﺇﻟﻰ ﺍﻟﻤﺴﺘﻤﻊ ﺍﻟﺫﻯ ﻴﻌﻤل ﻋﻠﻰ ﺍلShared Server
ﺍﻴﻀﹰﺎ ﻴﻤﻜﻨﻙ ﺍﻹﺘﺼﺎل ﺒﻘﺎﻋﺩ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻙ Dedicated Serverﺤﺘﻰ ﻭﻟﻭ ﻜﺎﻨﺕ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺘﻌﻤل ﻓﻰ
ﺍﻟﻨﻤﻁ Shared Serverﻭﺫﻟﻙ ﻤﻥ ﺨﻼل ﺘﻬﻴﺌﺔ ﻤﻠﻑ ﺍلtnsnames
ﺇﺫﺍ ﺘﻡ ﺍﻹﺘﺼﺎل ﺒﻘﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻤﻥ ﺨﻼل ﺍﻻﺴﻡ ﺍﻟﻤﺴﺘﻌﺎﺭ ORCLﻓﺈﻨﻙ ﺍﻹﺘﺼﺎل ﺴﻭﻑ ﻴﺘﻡ ﻤﻥ ﺨﻼل
Dedicated Server
17
ﺍﻤﺎ ﺇﺫﺍ ﺘﻡ ﺍﻹﺘﺼﺎل ﻤﻥ ﺨﻼل ﺍﻹﺴﻡ ﺍﻟﻤﺴﺘﻌﺎﺭ TESTﻓﺈﻥ ﺍﻹﺘﺼﺎل ﺴﻭﻑ ﻴﺘﻡ ﻤﻥ ﺨﻼل ﺍل Shared
.Server
ﺒﺎﻟﻁﺒﻊ ﻴﻤﻜﻥ ﺇﺭﺠﺎﻉ ﺍل Instanceﻟﺘﻌﻤل ﻋﻠﻰ ﺍﻟﻨﻤﻁ Dedicated Serverﻤﺭﺓ ﺍﺨﺭﻯ ﻭﺫﻟﻙ ﻤﻥ
ﺨﻼل ﺍﻻﺘﻰ:
ﻴﻤﻜﻨﻙ ﺍﻟﺘﺄﻜﺩ ﻤﻥ ﺍﻟﺭﺠﻭﻉ ﺇﻟﻰ ﺍل Dedicated Serverﻤﻥ ﺨﻼل ﺍﻹﺴﺘﻌﻼﻤﺎﺕ ﺍﻟﺘﻰ ﺍﺴﺘﺨﺩﻤﻨﺎﻫﺎ ﺴﺎﺒﻘ ﹰﺎ.
18
:ﻟﻺﺳﺘﻌﻼم
V$CIRCUIT
V$DISPATCHERS
V$SHARED_SERVER
V$SHARED_SERVER_MONITOR
19
20
21
ﺍﺤﺴﻨﺕ ﺸﺭﻜﺔ ﺍﻭﺭﻜل ﺇﺫ ﺩﻋﻤﺕ ﻫﺫﺍ ﺍﻟﻨﻭﻉ ﻤﻥ ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﻭﺍﻹﺴﺘﺭﺠﺎﻉ Logical
Backup & Recoveryﻓﻬﻭ ﺍﺴﻬل ﺍﻻﻨﻭﺍﻉ ﻋﻠﻰ ﺍﻻﻁﻼﻕ .
ﻭﺘﺄﺘﻰ ﻜﻠﻤﺔ ﻤﻨﻁﻘﻰ Logicalﻤﻥ ﻜﻭﻥ ﺃﻥ ﺍﻟﻜﺎﺌﻨﺎﺕ ﺍﻟﺘﻰ ﻴﺘﻡ ﺘﺼﺩﻴﺭﻫﺎ ﺒﻬﺫﻩ ﺍﻟﻁﺭﻴﻘﺔ ﻻ ﻴﻤﻜﻥ
ﺍﻟﺘﻌﺎﻤل ﻤﻌﻬﺎ ﻓﻴﺯﻴﺎﺌﻴﹰﺎ ﻋﻥ ﻋﻠﻰ ﻤﺴﺘﻭﻯ ﻨﻅﺎﻡ ﺍﻟﻨﺸﻐﻴل ﻓﻤﻥ ﺍﻟﻤﺴﺘﺤﻴل ﺍﻟﺘﻌﺎﻤل ﻤﻊ ﻜﺎﺌﻨﺎﺕ ﻤﺜل ﺍﻟﺠﺩﺍﻭل
Tablesﻭﺍﻟﻤﻨﺎﻅﻴﺭ Viewsﻭﺍل Tablespacesﻭﻏﻴﺭﻫﺎ ﻤﻥ ﺍﻟﻜﺎﺌﻨﺎﺕ ﻋﻠﻰ ﻤﺴﺘﻭﻯ ﻨﻅﺎﻡ ﺍﻟﺘﺸﻐﻴل .
22
ﻫﺫﻩ ﻫﻰ ﺍﻨﻭﺍﻉ ﺍل Backupﺍﻟﺘﻰ ﺘﺩﻋﻤﻬﺎ ﺸﺭﻜﺔ ﺍﻭﺭﻜل ﻭﺴﻨﺘﻔﺼل ﻓﻰ ﺍﻟﺤﺩﻴﺙ ﻋﻥ ﺠﻤﻴﻊ ﺍﻷﻨﻭﺍﻉ ﻻﺤﻘﹰﺎ ﻟﻜﻥ
ﻤﺎ ﻴﻬﻤﻨﺎ ﻓﻰ ﻫﺫﺍ ﺍﻟﻔﺼل ﻫﻭ ﺍل. Logical Backup
23
ﻭﻤﻥ ﺍﻟﺨﻴﺎﺭﺍﺕ ﺍﻟﻤﺘﺎﺤﺔ ﺍﻴﻀﹰﺎ ﺍﺜﻨﺎﺀ ﻋﻤﻠﻴﺔ ﺍﻟﺘﺼﺩﻴﺭ-:
:Rows= [Y||N] -1ﻫﺫﺍ ﺍﻟﺨﻴﺎﺭ ﻴﻌﻨﻰ ﻫل ﺘﺭﻴﺩ ﺘﺼﺩﻴﺭ ﺍﻟﺠﺩﻭل ﻜﻬﻴﻜﻠﺔ ﺩﻭﻥ ﺒﻴﺎﻨﺎﺕ ﺃﻡ ﺍﻨﻙ ﺘﺭﻴﺩ ﺘﺼﺩﻴﺭ
ﺍﻟﺒﻴﺎﻨﺎﺕ ﻤﻌﻪ ،ﺍﻻﺼل ﻫﻭ ﺍﻟﺨﻴﺎﺭ Yﺒﻤﻌﻨﻰ ﺘﺼﺩﻴﺭ ﺍﻟﻬﻴﻜل ﻭﺍﻟﺒﻴﺎﻨﺎﺕ.
:Indexes= [Y||N] -2ﻫل ﻨﻘﻭﻡ ﺒﺘﺼﺩﻴﺭ ﺍﻟﻤﺭﺍﺠﻊ ﺍﻟﺘﺎﺒﻌﺔ ﻟﻠﺠﺩﺍﻭل ﺍﺜﻨﺎﺀ ﺘﺼﺩﻴﺭ ﺍﻟﺠﺩﺍﻭل ﺃﻡ ﻻ ،
ﺍﻻﺼل .Y
:Grants= [Y||N] -3ﻫل ﺘﺭﻏﺏ ﻓﻰ ﺘﺼﺩﻴﺭ ﺍﻟﺼﻼﺤﻴﺎﺕ ﺍﻴﻀﹰﺎ ﻋﻨﺩ ﺘﺼﺩﻴﺭ ﺍﻟﻜﺎﺌﻨﺎﺕ ﻭﺍﻟﻤﺴﺘﺨﺩﻤﻴﻥ ،
ﺍﻻﺼل .Y
:File -4ﻟﺘﺤﺩﻴﺩ ﻤﻜﺎﻥ ﺇﻨﺸﺎﺀ ﺍﻟﻤﻠﻑ ﺍﻟﺫﻯ ﻴﺤﻭﻯ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺍﻟﻤﺼﺩﺭﺓ.
:Log -5ﻟﺘﺤﺩﻴﺩ ﻤﻜﺎﻥ ﺇﻨﺸﺎﺀ ﺍﻟﻤﻠﻑ ﺍل Log Fileﺍﻟﺫﻯ ﺴﻴﺤﻭﻯ ﻤﻌﻠﻭﻤﺎﺕ ﻋﻥ ﻋﻤﻠﻴﺔ ﺍﻟﺘﺼﺩﻴﺭ.
:Constraints= [Y||N] -6ﻫل ﺘﺭﻏﺏ ﻓﻰ ﺘﺼﺩﻴﺭ ﺍﻟﻘﻴﻭﺩ Constraintsﺍﺜﻨﺎﺀ ﺘﺼﺩﻴﺭ ﺍﻟﺠﺩﺍﻭل.
:Compress= [Y||N] -7ﻫل ﺘﺭﻴﺩ ﻀﻐﻁ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺤﺘﻰ ﻨﻘﻠل ﻤﻥ ﺤﺠﻡ ﺍﻟﻤﻠﻑ ،ﺍﻻﺼل .Y
Buffer=256k -8ﻫﻨﺎ ﻨﺤﺩﺩ ﺤﺠﻡ ﺍل ، Bufferﺍﻻﺼل .256k
:Tables -9ﻟﺘﺤﺩﻴﺩ ﺍﻟﺠﺩﺍﻭل ﺍﻟﺘﻰ ﺍﺭﻴﺩ ﺘﺼﺩﻴﺭﻫﺎ.
:Inctype=[Incremental||Cumulative||Complete] -10ﻟﺘﺤﺩﻴﺩ ﻨﻭﻉ ﺍﻟﺘﺼﺩﻴﺭ-:
:Complete -1ﻟﺘﺼﺩﻴﺭ ﺠﻤﻴﻊ ﺍﻟﺒﻴﺎﻨﺎﺕ.
: Incremental -2ﺍﻟﻨﺴﺨﺔ ﺍﻟﺘﺯﺍﻴﺩﻴﺔ ﻭﻫﻰ ﺘﻌﻨﻰ ﻋﻤل ﺘﺼﺩﻴﺭ ﻟﻠﺒﻴﺎﻨﺎﺕ ﺍﻟﺘﻰ ﺘﻐﻴﺭﺕ ﺒﻌﺩ ﺍﺨﺭ
ﻋﻤﻠﻴﺔ ﺘﺼﺩﻴﺭ.
: Cumulative -3ﺍﻟﻨﺴﺨﺔ ﺍﻟﺘﺭﺍﻜﻤﻴﺔ ﻭﻫﻰ ﺘﻌﻨﻰ ﻋﻤل ﺘﺼﺩﻴﺭ ﻟﻠﺒﻴﺎﻨﺎﺕ ﺍﻟﺘﻰ ﺘﻐﻴﺭﺕ ﺒﻌﺩ ﺍﺨﺭ
ﻋﻤﻠﻴﺔ ﺘﺼﺩﻴﺭ ﺘﺭﺍﻜﻤﻴﺔ ) (Cumulativeﺃﻭ ﺘﻜﺎﻤﻠﻴﺔ ).(Complete
24
ﻋﻤﻠﻴﺔ ﺍﻟﺘﺼﺩﻴﺭ ﺘﺘﻡ ﻤﻥ ﺨﻼل Export Utilitiesﺒﺤﻴﺙ ﻴﺘﻡ ﺍﻻﺘﺼﺎل ﺒﻘﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻋﻥ ﻁﺭﻴﻕ
ﺍل Server Processﻭﻤﻥ ﺜﻡ ﻋﻤل Select Statementsﻟﻠﺒﻴﺎﻨﺎﺕ ﺍﻟﻤﻁﻠﻭﺒﺔ ﻭﻤﻥ ﺜﻡ ﻴﻘﻭﻡ ﺒﻌﻤل ﺘﻤﺭﻴﺭ
ﻟﻠﺒﻴﺎﻨﺎﺕ ﻋﻥ ﻁﺭﻴﻕ ﺍل Server Processﺇﻟﻰ .Export User Process
ﺒﺎﻟﻤﻨﺎﺴﺒﺔ ﻴﻤﻜﻥ ﺘﺠﺎﻫل ﺍﻻﺠﺭﺍﺀﺍﺕ ﺍﻋﻼﻩ ﺒﻭﺍﺴﻁﺔ ﺍﻟﺨﻴﺎﺭ Dirct=yﺒﺤﻴﺙ ﻴﺘﻡ ﻗﺭﺍﺀﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻤﻥ
ﺍﻟﺩﻴﺴﻙ ﺍﻟﻰ ﺍل Buffer Cachﻭﻤﻥ ﺜﻡ ﺍﺭﺠﺎﻉ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺍﻟﻰ Export Clientﻫﺫﻩ ﺍﻟﻁﺭﻴﻘﺔ ﻴﻤﻜﻥ ﺘﺤﺴﻥ
ﺍﻻﺩﺍﺀ.
25
:TABLES EXPORT
ﻴﺴﺘﻁﻴﻊ ﺍﻟﻤﺴﺘﺨﺩﻡ ﺘﺼﺩﻴﺭ ﺍﻟﺠﺩﺍﻭل ﺍﻟﺘﻰ ﻴﻤﻠﻜﻬﺎ ﻭﻜﺫﻟﻙ ﻴﺴﺘﻁﻴﻊ ﻤﺩﻴﺭ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺘﺼﺩﻴﺭ ﺠﻤﻴﻊ ﺍﻟﺠﺩﺍﻭل
ﻓﻰ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻭﺍﻴﻀﹰﺎ ﻜل ﻤﻥ ﻴﻤﻠﻙ ﺍﻟﺼﻼﺤﻴﺔ EXP_FULL_DATABASEﻴﺴﺘﻁﻴﻊ ﺘﺼﺩﻴﺭ
ﺠﺩﺍﻭل ﻤﺴﺘﺨﺩﻡ ﺍﺨﺭ ،ﺍﻤﺎ ﺒﺩﻭﻥ ﻫﺫﻩ ﺍﻟﺼﻼﺤﻴﺔ ﻓﻼ ﻴﺴﺘﻁﻴﻊ ﺘﺼﺩﻴﺭ ﺠﺩﻭل ﻻ ﻴﻤﻠﻜﻪ.
26
ﺍﺨﺘﻠﻔﺕ ﺍﻟﺼﻴﺎﻏﺔ ﻭﻟﻜﻥ ﺍﻟﻨﺘﻴﺠﺔ ﻭﺍﺤﺩﺓ ،ﻟﺫﺍ ﻓﻤﻥ ﺍﻻﻓﻀل ﻋﺩﻡ ﻜﺘﺎﺒﺔ ﺍﻟﺨﻴﺎﺭﺍﺕ ﺇﻻ ﺇﺫﺍ ﺍﺭﺩﻨﺎ ﺃﻥ ﻨﺴﺘﻌﻤﻠﻬﺎ ﻓﻰ
ﻏﻴﺭ ﻭﻀﻌﻬﺎ ﺍﻻﺼﻠﻰ ،ﻋﻠﻰ ﺴﺒﻴل ﺍﻟﻤﺜﺎل ﻟﻭ ﺍﺭﺩﻨﺎ ﺍﻥ ﻨﺼﺩﺭ ﺍﻟﺠﺩﻭل ﺒﻤﺎ ﻓﻴﻪ ﺍﻟﻘﻴﻭﺩ Constraintsﻓﻤﻥ
ﺍﻻﻓﻀل ﻋﺩﻡ ﻜﺘﺎﺒﺔ ﺍﻟﺨﻴﺎﺭ Constraints=Yﻭﺫﻟﻙ ﻷﻨﻙ ﺇﺫﺍ ﻟﻡ ﺘﻜﺘﺒﻪ ﺼﺭﺍﺤﺔ ﻓﺈﻥ ﺍﻟﺼﻴﻐﺔ ﺘﺤﺘﻭﻴﻪ ﻀﻤﻨﻴﹰﺎ
،ﺃﻤﺎ ﺇﺫﺍ ﻟﻡ ﺘﺭﻏﺏ ﻓﻰ ﺘﺼﺩﻴﺭ ﺍﻟﻘﻴﻭﺩ ﻤﻊ ﺍﻟﺠﺩﻭل ﻓﺎﻟﻭﺍﺠﺏ ﻜﺘﺎﺒﺔ ﺍﻟﺨﻴﺎﺭ Constraints=Nﻓﻰ ﺼﻴﺎﻏﺔ
ﺍﻤﺭ ﺍﻟﺘﺼﺩﻴﺭ .ﻭﻫﻜﺫﺍ ﺒﻘﻴﺔ ﺍﻟﺨﻴﺎﺭﺍﺕ.
ﻭﻟﻨﻔﺘﺭﺽ ﺍﻻﻥ ﺍﻥ ﺍﻟﻤﺴﺘﺨﺩﻡ VBSﻴﺭﻏﺏ ﻓﻰ ﺘﺼﺩﻴﺭ ﺍﻟﺠﺩﻭل EMPLOYEEﺍﻟﺫﻯ ﻴﻤﺘﻜﻠﻪ ﻭﻟﻜﻥ ﺩﻭﻥ
ﺒﻴﺎﻨﺎﺕ.
27
ﺍﻟﺠﺩﻭلEXP_FULL_DATABASE ﻜﻴﻑ ﻴﺼﺩﺭ ﻤﺩﻴﺭ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺃﻭ ﻤﻥ ﻴﻤﻠﻙ ﺍﻟﺼﻼﺤﻴﺔ-B
.VBS ﺍﻟﻤﻤﻠﻭﻙ ﻟﻠﻤﺴﺘﺨﺩﻡEmployee
28
ﻻﺤﻅ ﻤﻌﻰ ﺍﺴﻡ ﺍﻟﺠﺩﻭل ﻤﺴﺒﻭﻗﹰﺎ ﺒﻤﻥ ﻴﻤﺘﻠﻜﻪ.
ﺒﺎﻟﻤﻨﺎﺴﺒﺔ ﻟﻭ ﻭﺠﺩ ﺍﻻﻭﺭﻜل ﻓﻰ ﺍﻟﻤﺴﺎﺭ ﺍﻟﻤﺤﺩﺩ ﻹﻨﺸﺎﺀ ﻤﻠﻑ ﺍﻟﺘﺼﺩﻴﺭ FILE.DMPﻤﻠﻑ ﻤﻭﺠﻭﺩﹰﺍ ﺒﻨﻔﺱ
ﺍﻹﺴﻡ ﻓﺎﻨﻪ ﻴﻘﻭﻡ ﺒﺈﻋﺎﺩﺓ ﺍﻟﻜﺘﺎﺒﺔ ﻓﻴﻪ.
ﻟﻨﻔﺘﺭﺽ ﺍﻻﻥ ﺃﻥ ﺍﻟﻤﺴﺘﺨﺩﻡ VBSﻴﺭﻴﺩ ﺃﻥ ﻴﺼﺩﺭ ﺍﻟﺠﺩﻭل EMPLOYEEﺍﻟﺫﻯ ﻴﻤﺘﻠﻜﻪ ﻭﺒﻜﻥ ﻴﺭﻴﺩ ﺃﻥ
ﻼ ، WHERE EMP_NO=2ﻫﻨﺎ ﻨﺴﺘﺨﺩﻡ ﺍﻟﺨﻴﺎﺭ .Query
ﻴﺼﺩﺭ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺒﺸﺭﻁ ﻤﻌﻴﻥ ﻤﺜ ﹰ
29
C:\>EXP PENTA/PENTA FILE=D:\EXPORT\EMPLOYEE.DMP
TABLES=VBS.EMPLOYEE
30
:SCHEMAS EXPORT
ﻭﻫﻰ ﺘﺼﺩﻴﺭ ﻟﺠﻤﻴﻊ ﺍﻟﻜﺎﺌﻨﺎﺕ ﺍﻟﻤﻭﺠﻭﺩﺓ ﻓﻰ schemaﻤﻌﻴﻨﺔ ﺃﻭ ﻤﺠﻤﻭﻋﺔ schemasﺒﺤﻴﺙ ﻻ
ﻴﺘﺴﺘﻁﻴﻊ ﻤﺴﺘﺨﺩﻡ ﺘﺼﺩﻴﺭ schemaﺍﺨﺭﻯ ﻤﺎ ﻟﻡ ﻴﻜﻥ ﻟﺩﻴﻪ ﺍﻟﺼﻼﺤﻴﺔ ، FULL_EXP_DATABASE
ﻭﺍل SCHEMAﻫﻰ ﺒﺒﺴﺎﻁﺔ ﻤﺠﻭﻋﺔ ﺍﻟﻜﺎﺌﻨﺎﺕ ﺍﻟﺘﻰ ﺘﻨﺘﻤﻰ ﻟﻤﺴﺘﺨﺩﻡ ﻤﻌﻴﻥ.
31
ﻻﺤﻅ ﻤﻌﻰ ﺃﻨﻪ ﺍﺜﻨﺎﺀ ﺘﺼﺩﻴﺭ VBS SCHEMAﺘﻡ ﺘﺼﺩﻴﺭ ﺍل Triggersﻭﺍل Indesxsﻭﻜﺫﻟﻙ ﺒﻴﺎﻨﺎﺕ
ﺍﻟﺠﺩﺍﻭل ،ﻭﻟﻜﻥ ﻴﻤﻜﻥ ﺘﺠﺎﻫل ﺫﻟﻙ ﺒﻭﺍﺴﻁﺔ ﺍﻟﺨﻴﺎﺭﺍﺕ & TRIGGERS=N & INDEXES=N
.ROWS=Nﻭﻜﺫﻟﻙ ﺍﺨﺘﺭﻨﺎ ﺍﻟﺨﻴﺎﺭ OWNERﻟﺘﺤﺩﻴﺩ ﺍل SCHEMAﺍﻟﺘﻰ ﻨﺭﻴﺩ ﺘﺼﺩﻴﺭﻫﺎ ،ﺒﺎﻟﻁﺒﻊ
ﻴﻤﻜﻥ ﺘﺤﺩﻴﺩ ﺍﻜﺜﺭ ﻤﻥ SCHEMAﻓﻰ ﺍﻟﻌﻤﻠﻴﺔ ﺍﻟﻭﺍﺤﺩﺓ.
-Bﻜﻴﻑ ﻴﺴﺘﻁﻴﻊ ﺍﻟﻤﺴﺘﺨﺩﻡ VBSﺘﺼﺩﻴﺭ VBS SCHEMAﺍﻭ ﺒﻤﻌﻨﻰ ﺍﺨﺭ ﻜﻴﻑ ﻴﺼﺩﺭ ﺍﻟﻤﺴﺘﺨﺩﻡ
VBSﺍﻟﻜﺎﺌﻨﺎﺕ ﺍﻟﺘﻰ ﻴﻤﻠﻜﻬﺎ.
ﻻﺤﻅ ﻤﻌﻰ ﻫﻨﺎ ﻻ ﻨﻠﺠﺄ ﻟﻠﺨﻴﺎﺭ OWNERﻭﺫﻟﻙ ﻷﻥ ﺍﻟﻤﺴﺘﺨﺩﻡ VBSﻫﻨﺎ ﻴﺭﻴﺩ ﺃﻥ ﻴﺼﺩﺭ ﺍﻟﻜﺎﺌﻨﺎﺕ ﺍﻟﺘﻰ
ﻴﻤﻠﻜﻬﺎ.
32
ﻻ ﻴﺴﺘﻁﻴﻊ ﺍﻯ ﻤﺴﺘﺨﺩﻡ ﻻ ﻴﻤﻠﻙ ﺍﻟﺼﻼﺤﻴﺔ EXP_FULL_DATABASEﻤﻥ ﺘﺼﺩﻴﺭ ﺍﻯ
SCHEMAﺍﺨﺭﻯ.
33
:TABLESPACE EXPORT
ﻫل ﻴﻤﻜﻥ ﺘﺼﺩﻴﺭ Tablespaceﻤﻥ ﻗﺎﻋﺩﺓ ﺒﻴﺎﻨﺎﺕ ﺍﻟﻰ ﺍﺨﺭﻯ ؟ ﺍﻟﻠﻬﻡ ﻨﻌﻡ ،ﻭﻟﻨﻔﺘﺭﺽ ﺍﻻﻥ ﺃﻥ
ﻟﺩﻴﻨﺎ ﻗﺎﻋﺩﺓ ﺒﻴﺎﻨﺎﺕ ﺘﺴﻤﻰ ORCLﺘﺤﺘﻭﻯ ﻋﻠﻰ Tablespaceﻴﺴﻤﻰ TESTﻨﺭﻴﺩ ﺃﻥ ﻨﻨﻘﻠﻪ ﺍﻟﻰ ﻗﺎﻋﺩﺓ
ﺍﻟﺒﻴﺎﻨﺎﺕ ﺍﻻﺨﺭﻯ ﻭﺍﻟﺘﻰ ﺘﺴﻤﻰ .OBAY
ﺍﻟﺨﻁﻭﺍﺕ-:
-1ﻭﻀﻊ TEST TABLESPACEﻓﻰ ﺍﻟﻭﻀﻊ READ ONLYﺤﺘﻰ ﻨﻀﻤﻥ ﻋﺩﻡ ﺘﻌﺩﻴل ﺍﻟﺒﻴﺎﻨﺎﺕ
ﺍﺜﻨﺎﺀ ﻋﻤﻠﻴﺔ ﺍﻟﺘﺼﺩﻴﺭ.
34
-3ﻋﻥ ﻁﺭﻴﻕ ﻨﻅﺎﻡ ﺍﻟﺘﺸﻐﻴل ﻨﻘﻭﻡ ﺒﻌﻤل ﻨﺴﺦ ﻟﻤﻠﻑ ﺍﻭ ﻤﻠﻔﺎﺕ ﺍل Datafilesﺍﻟﺘﻰ ﺘﻨﺘﻤﻰ ﻟل TEST
Tablespaceﻭﻫﻰ ﻫﻨﺎ ﻤﻠﻑ ﻭﺍﺤﺩ ﻴﺴﻤﻰ TESTﻤﻥ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ORCLﺍﻟﻰ ﺍﻟﻤﺴﺎﺭ ﺍﻟﺠﺩﻴﺩ
ﻟﻘﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ OBAYﻭﺫﻟﻡ ﻻﻥ ﻋﻤﻠﻴﺔ ﺍﻟﺘﺼﺩﻴﺭ ﻻ ﺘﺼﺩﺭ ﻤﻠﻔﺎﺕ ﺍل.Datafiles
C:\>COPY
D:\oracle\product\10.1.0\oradata\ORCL\TEST.DBF
D:\oracle\product\10.1.0\oradata\OBAY\TEST.DBF
35
-4ﻨﻘﻭﻡ ﺒﻌﻤل ﺍﺴﺘﻴﺭﺍﺩ ﻟﻠﺒﻴﺎﻨﺎﺕ ﺍﻟﺘﻰ ﺼﺩﺭﻨﺎﻫﺎ ﺴﺎﺒﻘﹰﺎ.
36
37
:DATABASE EXPORT
ﻭﻴﺴﻤﻰ ﺍﻴﻀﹰﺎ FULL EXPORTﻭﺍﻟﻤﻘﺼﻭﺩ ﺒﻪ ﻋﻤل ﺘﺼﺩﻴﺭ ﻟﻜل ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻭﻴﺤﺘﺎﺝ ﻫﺫﺍ
ﺍﻟﻨﻭﻉ ﻤﻥ ﺍﻟﺘﺼﺩﻴﺭ ﻟﻠﺼﻼﺤﻴﺔ .EXP_FULL_DATABASEﻭﻓﻰ ﻫﺫﺍ ﺍﻟﻨﻭﻉ ﻤﻥ ﺍﻟﺘﺼﺩﻴﺭ ﻴﻤﻜﻥ
ﺘﻁﺒﻴﻕ ﺍﻟﺨﻴﺎﺭ .INCTYPE
ﻫﻜﺫﺍ ﻗﻤﻨﺎ ﺒﻌﻤل ﺘﺼﺩﻴﺭ ﻟﻘﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺒﺎﺴﺘﺨﺩﺍﻡ ﺍﻟﺨﻴﺎﺭ ، COMPLETEﺍﻻﻥ ﻴﻤﻜﻥ ﺍﺇﻨﺸﺎﺀ ﻨﺴﺨﺔ
ﺘﺭﺍﻜﻤﻴﺔ ﺍﻭ ﺘﺯﺍﻴﺩﻴﺔ ) (Cumulative & Incrementalﻟﻘﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ، .ﻭﻤﺘﺎﺒﻌﺔ ﺫﻟﻙ ﺒﻭﺍﺴﻁﺔ
.DBA_EXP_FILES
38
.ﺍﻻﻥ ﺴﻨﻘﻭﻡ ﺒﻌﻤل ﻨﺴﺨﺔ ﺘﺭﺍﻜﻤﻴﺔ ﻟﻘﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ
39
ﻟﻼﺴﺘﻌﻼﻡ
ﻭﺍﻟﺠﺩﻭل ﺍﻟﺘﺎﻟﻰ ﻴﻭﻀﺢ ﺍﻫﻡ ﺍﻟﻤﺘﻐﻴﺭﺍﺕ ﺍﻟﺘﻰ ﺘﺴﺘﺨﺩﻡ ﻓﻰ ﻋﻤﻠﻴﺔ ﺍﻟﺘﺼﺩﻴﺭ ﻭﺍﻹﺴﺘﻴﺭﺍﺩ .
40
ﻤﻥ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺍﻟﻰ ﺍﻟﻤﻠﻑ ﺍﻭ
ﺍﻟﻤﺴﺘﻭﺭﺩﺓ ﻤﻥ ﺍﻟﻤﻠﻑ ﺍﻟﻰ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ
EXP ﺍﻗﺼﻰ ﺤﺠﻡ ﻟﻤﻠﻑ ﺍﻟﺘﺼﺩﻴﺭ FILESIZE
EXP & IMP ﻟﺘﺤﺩﻴﺩ ﻗﺎﺌﻤﺔ ﺍﻟﺠﺩﺍﻭل ﺍﻟﻤﺭﺍﺩ ﺘﺼﺩﻴﺭﻫﺎ ﺃﻭ TABLES
ﺍﺴﺘﻴﺭﺍﺩﻫﺎ
EXP & IMP ﻟﺘﺤﺩﻴﺩ ﻤﺎ ﺇﺫﺍ ﻜﻨﺎ ﻨﺭﻴﺩ ﺘﺼﺩﻴﺭ ﺍﻭ ﺍﺴﺘﻴﺭﺍﺩ ROWS
ﺍﻟﺒﻴﺎﻨﺎﺕ ﻤﻊ ﺍﻟﺠﻭل ﺍﻡ ﻻ
EXP ﻟﻭﻀﻊ ﺸﺭﻭﻁ ﺍﺜﻨﺎﺀ ﺘﺼﺩﻴﺭ ﺍﻟﺠﺩﺍﻭل QUERY
EXP & IMP ﻟﺘﺤﺩﻴﺩ ﻤﺎ ﺇﺫﺍ ﻜﻨﺎ ﻨﺭﻏﺏ ﻓﻰ ﺘﺼﺩﻴﺭ ﺍﻭ INDEXES
ﺍﺴﺘﻴﺭﺍﺩ ﺍﻟﻔﻬﺎﺭﺱ ﺍﻡ ﻻ
EXP & IMP ﻟﺩﻤﺞ ﺍﻻﻤﺘﺩﺍﺩﺕ ﺍﻟﺨﺎﺼﺔ ﺒﺎﻟﺠﺩﻭل ﺍﻟﻰ COMPRESS
ﻭﺍﺤﺩ ﻓﻘﻁ
EXP ﻟﻌﻤل ﺍﺤﺼﺎﺌﻴﺎﺕ ﻋﻥ ﺍﻟﺠﺩﺍﻭل ﻭﺍﻟﻔﻬﺎﺭﺱ STATISTICS
ﺍﻟﻤﺭﺍﺩ ﺘﺼﺩﻴﺭﻫﺎ
EXP ﻫﺫﺍ ﺍﻟﺨﻴﺎﺭ ﻟﻀﻤﺎﻥ ﻋﻤل ﺘﺼﺩﻴﺭ CONSISTENT
ﻟﻠﻜﺎﺌﻨﺎﺕ ﺩﻭﻥ ﺤﺩﻭﺙ ﺘﻐﻴﻴﺭ ﻓﻰ ﺍﻟﻜﺎﺌﻨﺎﺕ
ﺍﺜﻨﺎﺀ ﻋﻤل ﺍﻟﺘﺼﺩﻴﺭ ،ﻭﻫﻭ ﻴﺸﺒﻪ ﻭﻀﻊ
ﺍﻟﻜﺎﺌﻨﺎﺕ ﻓﻰ ﺍﻟﻨﻤﻁ READ ONLY
EXP & IMP ﻟﺘﺤﺩﻴﺩ ﻤﻠﻑ ﺍﻟﻤﺘﻐﻴﺭﺍﺕ ﺍﻟﺫﻯ ﻴﺤﺘﻭﻯ ﻋﻠﻰ PARFILE
ﺍﻟﻤﺘﻐﻴﺭﺍﺕ ﺍﻟﻤﺴﺘﺨﺩﻤﺔ ﻓﻰ ﻤﻠﻑ ﺍﻟﺘﺼﺩﻴﺭ
EXP & IMP ﻫل ﺘﺭﻴﺩ ﺘﺼﺩﻴﺭ ﺍﻭ ﺍﺴﺘﻴﺭﺍﺩ ﺼﻼﺤﻴﺎﺕ GRANT
ﺍﻟﻜﺎﺌﻨﺎﺕ
EXP & IMP ﻟﺘﺤﺩﻴﺩ ﺍل TABLESPACESﺍﻟﻤﺭﺍﺩ TABLESPACE
ﺘﺼﺩﻴﺭﻫﺎ ﺍﻭ ﺍﺴﺘﻴﺭﺍﺩﻫﺎ
EXP ﻭﻫﻰ ﺘﺴﺘﺨﺩﻡ ﻓﻘﻁ ﻋﻨﺩ ﻋﻤﻠﻴﺔ ﺘﺼﺩﻴﺭ TRANSPORT_TABLESPACE
ﺍل TABLESPACEﻭﻴﺠﺏ ﺃﻥ ﺘﺄﺨﺫ
ﺍﻟﻘﻴﺔ Yﻭﻫﻰ ﺘﺴﻤﺢ ﺒﻌﻤل ﺍﺴﺘﻴﺭﺍﺩ
ﻟﻠﺒﻴﺎﻨﺎﺕ ﻤﻥ ﻤﻥ ﻤﻠﻑ ﺍﻟﺘﺼﺩﻴﺭ
41
EXP ﻟﺘﺤﺩﻴﺩ ﻗﺎﺌﻤﺔ ﺍﻟﻤﺴﺘﺨﺩﻤﻴﻥ ﺍﻟﻤﺭﺍﺩ OWNER
ﺘﺼﺩﻴﺭﻫﻡ
EXP & IMP ﻭﻫﺫﺍ ﺍﻟﺨﻴﺎﺭ ﻟﻌﻤل ﺘﺼﺩﻴﺭ ﺍﻭ ﺍﺴﺘﻴﺭﺍﺩ FULL
ﻟﺠﻤﻴﻊ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ
EXP & IMP ﻭﻫﻭ ﻟﺘﺤﺩﻴﺩ ﻨﻭﻉ ﺍﻟﺘﺼﺩﻴﺭ ﺍﻭ ﺍﻹﺴﺘﻴﺭﺍﺩ INCTYPE
ﻟﻘﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻭﻫﻨﺎﻙ ﺜﻼﺙ ﺍﻨﻭﺍﻉ :
COMPLETE -1
INCREMENTAL -2
CUMULATIVE -3
42
:Use Import Utilities to Import Data -2
ﻋﻤﻠﻴﺔ ﺍﻹﺴﺘﻴﺭﺍﺩ ﻫﻰ ﻋﻤﻠﻴﺔ ﻋﻜﺴﻴﺔ ﻟﻌﻤﻠﻴﺔ ﺍﻟﺘﺼﺩﻴﺭ ﺒﺤﻴﺙ ﻨﺴﺘﻁﻴﻊ ﻤﻥ ﺨﻼﻟﻬﺎ ﺇﺴﺘﻴﺭﺍﺩ ﺍﻟﺒﻴﺎﻨﺎﺕ
ﻭﺍﻟﻜﺎﺌﻨﺎﺕ ﻤﻥ ﻤﻠﻑ ﺍﻟﺘﺼﺩﻴﺭ ﺇﻟﻰ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ،ﻭﻤﻥ ﺍﻟﺨﻴﺎﺭﺍﺕ ﺍﻟﻤﺘﺎﺤﺔ ﻓﻰ ﻋﻤﻠﻴﺔ ﺍﻹﺴﺘﻴﺭﺍﺩ:
-1ﺍﺴﺘﻴﺭﺍﺩ ﺠﺩﺍﻭل.
-2ﺇﺴﺘﻴﺭﺍﺩ ﺒﻴﺎﻨﺎﺕ ﻤﺴﺘﺨﺩﻡ.
-3ﺇﺴﺘﻴﺭﺍﺩ .Tablespaces
-4ﺇﺴﺘﻴﺭﺍﺩ ﻗﺎﻋﺩﺓ ﺒﻴﺎﻨﺎﺕ.
43
:TABLES IMPORT
ﻴﺴﺘﻁﻴﻊ ﻤﺩﻴﺭ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺃﻭ ﻤﻥ ﻴﻤﻠﻙ ﺍﻟﺼﻼﺤﻴﺔ IMP_FULL_DATABASE
ﺇﺴﺘﻴﺭﺍﺩ ﺍﻟﺠﺩﺍﻭل ﺍﻟﻰ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ،ﻭﻗﺩ ﻴﻜﻭﻥ ﻤﻠﻑ ﺍﻟﺘﺼﺩﻴﺭ ﻋﺒﺎﺭﺓ ﺘﺼﺩﻴﺭ ﺠﺩﺍﻭل ﺃﻭ ﺘﺼﺩﻴﺭ
ﻤﺴﺘﺨﺩﻡ ﺍﻭ ﺘﺼﺩﻴﺭ ﻗﺎﻋﺩﺓ ﻗﺎﻋﺩﺓ ﺒﻴﺎﻨﺎﺕ ﺒﺄﻜﻤﻠﻬﺎ .
ﻭﻟﻨﻔﺘﺭﺽ ﻫﻨﺎ ﺃﻥ ﻤﺩﻴﺭ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻴﺭﻏﺏ ﻓﻰ ﺇﺴﺘﻴﺭﺍﺩ ﺍﻟﺠﺩﻭل EMPLOYEEﻤﻥ ﻤﻠﻑ
ﺍﻟﺘﺼﺩﻴﺭ ﺇﻟﻰ ﺍﻟﻤﺴﺘﺨﺩﻡ VBSﻤﻊ ﺍﻟﻌﻠﻡ ﺃﻥ ﺍﻟﺠﺩﻭل EMPLOYEEﺘﻡ ﺘﺼﺩﻴﺭﻩ ﻤﻥ ﺍﻟﻤﺴﺘﺨﺩﻡ
.VBS
ﺘﻡ ﺃﺴﺘﻴﺭﺍﺩ ﺍﻟﺠﺩﻭل EMPLOYEEﺍﻟﻰ ﺍﻟﻤﺴﺘﺨﺩﻡ VBSﺒﻭﺍﺴﻁﺔ ﻤﺩﻴﺭ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ،ﻻﺤﻅ
ﻤﻌﻰ ﺃﻨﻨﺎ ﺍﺴﺘﺨﺩﻤﻨﺎ ﺍﻟﻤﺘﻐﻴﺭﺍﺕ FROMUSER & TOUSERﻭﺫﻟﻙ ﻟﺘﺤﺩﻴﺩ ﺍﻟﻤﺴﺘﺨﺩﻡ ﺍﻟﺫﻯ ﺼﺩﺭﻨﺎ ﻤﻨﻪ
ﻭﺘﺤﺩﻴﺩ ﺍﻟﻤﺴﺘﺨﺩﻡ ﺍﻟﺫﻯ ﻭﺭﺩﻨﺎ ﺇﻟﻴﻪ ،ﻗﺩ ﻻ ﻴﻜﻭﻥ ﻀﺭﻭﺭﻴﹰﺎ ﻫﻨﺎ ﺇﺴﺘﺨﺩﺍﻡ ﺍﻟﻤﺘﻐﻴﺭ TOUSERﻭﺫﻟﻙ ﻷﻥ
44
ﺍﻟﺠﺩﻭل ﺴﻴﺴﺘﻭﺭﺩ ﻟﻨﻔﺱ ﺍﻟﻤﺴﺘﺨﺩﻡ ﺍﻟﺫﻯ ﺼﺩﺭ ﻤﻨﻪ ،ﻭﻟﻜﻥ ﻴﻜﻭﻥ ﻀﺭﻭﺭﻴﹰﺎ ﺇﺫﺍ ﺘﻐﻴﺭ ﺍﻟﻤﺼﺩﺭ ﻭﺍﻟﻬﺩﻑ .ﻜﺫﻟﻙ
ﺍﺴﺘﺨﺩﻤﻨﺎ ﺍﻟﻤﺘﻐﻴﺭ IGNOREﻭﺫﻟﻙ ﻟﺘﺠﺎﻫل ﺭﺴﺎﺌل ﺍﻟﺨﻁﺎ ﺍﻟﺘﻰ ﺘﻔﻴﺩ ﺃﻥ ﻫﺫﺍ ﺍﻟﺠﺩﻭل ﻤﻭﺠﻭﺩ ﻓﻰ ﺍﻟﻤﺴﺘﺨﺩﻡ.
45
:SCHEMAS IMPORT
ﻭﺫﻟﻙ ﻹﺴﺘﻴﺭﺍﺩ ﻜﺎﺌﻨﺎﺕ ﻭﻴﺒﺎﻨﺎﺕ ﻤﺴﺘﺨﺩﻡ ﻤﻥ ﻤﻠﻑ ﺍﻟﺘﺼﺩﻴﺭ ﺍﻟﻰ ﻤﺴﺘﺨﺩﻡ ﻓﻰ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ،
ﻭﻟﻨﻔﺘﺭﺽ ﻫﻨﺎ ﺃﻨﻨﺎ ﻨﺭﻴﺩ ﺍﺴﺘﻴﺭﺍﺩ ﻜﺎﺌﻨﺎﺕ ﻭﺒﻴﺎﻨﺎﺕ ﺍﻟﻤﺴﺘﺨﺩﻡ VBSﻤﻥ ﻤﻠﻑ ﺍﻟﺘﺼﺩﻴﺭ ﺇﻟﻰ ﺍﻟﻤﺴﺘﺨﺩﻡ
ﻫﻜﺫﺍ ﻭﺭﺩﻨﺎ ﻜﺎﺌﻨﺎﺕ ﻭﺒﻴﺎﻨﺎﺕ ﺍﻟﻤﺴﺘﺨﺩﻡ VBSﻤﻥ ﻤﻠﻑ ﺍﻟﺘﺼﺩﻴﺭ ﺍﻟﻰ ﺍﻟﻤﺴﺘﺨﺩﻡ SYNCﻓﻰ ﻗﺎﻋﺩﺓ
ﺍﻟﺒﻴﺎﻨﺎﺕ ،ﻭﻴﻤﻜﻥ ﺍﻻﻥ ﺍﻟﺘﺎﻜﺩ ﻤﻥ ﻋﻤﻠﻴﺔ ﺍﻹﺴﺘﻴﺭﺍﺩ ﺒﻭﺍﺴﻁﺔ ﻋﻤل ﺍﺴﺘﻌﻼﻡ ﻋﻥ ﺍﻟﺠﺩﺍﻭل ﻓﻰ ﺍﻟﻤﺴﺘﺨﺩﻡ
.SYNC
46
:DATABASE IMPORT
ﻨﺴﺘﻁﻴﻊ ﺍﺴﺘﻴﺭﺍﺩ ﻗﺎﻋﺩﺓ ﺒﻴﺎﻨﺎﺕ ﺒﺎﻜﻤﻠﻬﺎ ﻤﻥ ﻤﻠﻑ ﺍﻟﺘﺼﺩﻴﺭ ﺍﻟﻰ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻭﺫﻟﻙ ﺒﻭﺍﺴﻁﺔ ﺍﻟﺨﻴﺎﺭ
، FULL=Yﻭﻗﺩ ﻴﻜﻭﻥ ﻤﻠﻔﺎﺕ ﺍﻟﺘﺼﺩﻴﺭ ﻟﻘﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻫﻰ ﻤﺠﻤﻭﻋﺔ ﻤﻥ ﺍﻟﻨﺴﺦ ﺘﺤﺘﻭﻯ ﻋﻠﻰ ﻤﺨﺘﻠﻑ
ﻼ ) ، (Complete & Cumulative & Incrementalﻓﺎﻟﻁﺭﻴﻘﺔ ﺍﻻﻓﻀل ﻫﻰ ﻋﻤل ﺍﺴﺘﻴﺭﺍﺩ
ﺍﻻﻨﻭﺍﻉ ﻤﺜ ﹰ
Importﻻﺨﺭ ﻨﺴﺨﺔ ﻤﻥ ﺍﻟﻨﻭﻉ Incrementalﺒﺤﻴﺙ ﺍﻨﻬﺎ ﺘﺤﻭﻯ ﻋﻠﻰ ﺍﻟﻬﻴﻜﻠﺔ ﺍﻟﻨﻬﺎﺌﻴﺔ ﻟﻘﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ
ﻭﻴﺘﻡ ﺍﻹﺴﺘﻴﺭﺍﺩ ﻋﻥ ﻁﺭﻴﻕ ﺍﻟﺨﻴﺎﺭ INCTYPE=SYSTEMﺤﻴﺙ ﺘﻌﻨﻰ ﺍﻟﻘﻴﻤﺔ SYSTEMﺃﻥ ﻴﺘﻡ
ﺍﺴﺘﻴﺭﺍﺩ ﺍﻟﻬﻴﻜﻠﺔ ﺩﻭﻥ ﺍﻟﺒﻴﺎﻨﺎﺕ ،ﺜﻡ ﻨﻘﻭﻡ ﺒﻌﻤل ﺍﺴﺘﻴﺭﺍﺩ ﺒﻭﺍﺴﻁﺔ ﺍﻟﺨﻴﺎﺭ INCTYPE=RESTORE
ﻹﺴﺘﻴﺭﺍﺩ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻤﻥ ﺍﻟﻨﺴﺨﺔ ﺍﻟﺘﻜﺎﻤﻠﻴﺔ COMPLETEﻤﻥ ﻤﻠﻔﺎﺕ ﺍﻟﺘﺼﺩﻴﺭ ،ﺜﻡ ﻨﻘﻭﻡ ﺒﻌﺩ ﺫﻟﻙ ﺒﻌﻤل
ﺍﺴﺘﻴﺭﺍﺩ ﻟﻠﻨﺴﺨﺔ ﺍﻟﺘﺭﺍﻜﻤﻴﺔ CUMULATIVEﻤﻥ ﻤﻠﻑ ﺍﻟﺘﺼﺩﻴﺭ ﺒﻭﺍﺴﻁﺔ ﺍﻟﺨﻴﺎﺭ
INCTYPE=RESTOREﻹﺴﺘﻴﺭﺍﺩ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻤﻥ ﺍﻟﻨﺴﺨﺔ ﺍﻟﺘﻜﺎﻤﻠﻴﺔ ﻭﻤﻥ ﺜﻡ ﻨﻘﻭﻡ ﺒﻌﻤل ﺍﺴﺘﻴﺭﺍﺩ ﺒﻭﺍﺴﻁﺔ
ﺍﻟﺨﻴﺎﺭ INCTYPE=RESTOREﻟﻠﻨﺴﺦ ﺍﻟﺘﺯﺍﻴﺩﻴﺔ Incrementalﻤﻥ ﻤﻠﻔﺎﺕ ﺍﻟﺘﺼﺩﻴﺭ ﻹﺴﺘﻴﺭﺍﺩ
ﺍﻟﺒﻴﺎﻨﺎﺕ.
47
ﺍﻻﺨﻴﺭﺓ ﻭﺍﻟﺘﻰ ﻫﻰ ﻫﻨﺎIncremental ﻋﻤل ﺍﺴﺘﻴﺭﺍﺩ ﻟﻠﻨﺴﺨﺔ ﺍﻟﺘﺯﺍﻴﺩﻴﺔ-1
ﻭﺫﻟﻙ ﻹﺴﺘﻴﺭﺍﺩ ﺍﻟﻬﻴﻜﻠﺔINCTYPE=SYSTEM ﺒﻭﺍﺴﻁﺔ ﺍﻟﺨﻴﺎﺭD:\EXPORT\FULL2.DMP
. ﺍﻻﺨﻴﺭﺓ ﻟﻘﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ
48
ﻭﺍﻟﺘﻰ ﻫﻰ ﻫﻨﺎINCREMENTAL ﻨﻘﻭﻡ ﺒﻌﻤل ﺍﺴﺘﻴﺭﺍﺩ ﻟﻠﻨﺴﺦ ﺍﻟﺘﺯﺍﻴﺩﻴﺔ-4
. ﻭﺫﻟﻙ ﻻﺴﺘﻴﺭﺍﺩ ﺍﻟﺒﻴﺎﻨﺎﺕINCTYPE=RESTORE ﺒﻭﺍﺴﻁﺔ ﺍﻟﺨﻴﺎﺭD:\EXPORT\FULL2.DMP
49
:Data Pump
ﻭﻫﻰ ﻭﺴﻴﻠﺔ ﺍﺴﺘﺤﺩﺜﺘﻬﺎ ﺍﻭﺭﻜل ﻓﻰ ﺍﻹﺼﺩﺍﺭ Oracle 10gﻟﺘﺼﺩﻴﺭ ﻭﺍﺴﺘﻴﺭﺍﺩ ﺍﻟﻜﺎﺌﻨﺎﺕ ﻭﺍﻟﺒﻴﺎﻨﺎﺕ
ﻤﻥ ﻭﺇﻟﻰ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ،ﻭﻫﻰ ﺘﺸﺒﻪ ﺍﻟﻰ ﺤﺩ ﻤﺎ ﺍﻻﺩﺍﺓ Export/Import utilitiesﻤﻥ ﺤﻴﺙ ﺍﻟﻨﺘﻴﺠﺔ
ﻭﻟﻜﻥ ﻓﻰ ﺍﻟﺘﻁﺒﻴﻕ ﻓﺈﻨﻬﺎ ﺘﺨﺘﻠﻑ ﻜﺜﻴﺭﹰﺍ.
ﺍﻟﻭﺴﻴﻠﺔ Data Pumpﺘﻨﺠﺯ ﺃﻋﻤﺎﻟﻬﺎ ﻓﻰ ﺍﻟﻤﺨﺩﻡ ﻭﻟﻜﻥ ﺒﺎﻟﻁﺒﻊ ﻴﺒﺩﺃ ﻋﻤﻠﻬﺎ ﺒﺎلUser process
ﺒﺤﻴﺙ ﻴﺘﺼل ﺒﻘﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺒﺄﺤﺩ ﺍﺩﻭﺍﺕ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻭﻤﻥ ﺜﻡ ﻴﺘﻡ ﺠﻤﻴﻊ ﺍﻟﻌﻤل ﻋﻥ ﻁﺭﻴﻕ ﺍل Server
Processﻓﻰ ﺍﻟﻤﺨﺩﻡ ) ، (Serverﻫﺫﻩ ﺍﻟﻁﺭﻴﻘﺔ ﺘﺤﺴﻥ ﺍﻷﺩﺍﺓ ﺒﺸﻜل ﻤﺜﻴﺭ ﻤﻘﺎﺭﻨﺔ ﻤﻊ ﺍل Export/Import
utilitiesﻭﺫﻟﻙ ﻻﻨﻪ ﻴﻌﻤل ﻋﻠﻰ ﺍﻟﻤﺨﺩﻡ ﻭﻴﺘﺼل ﻤﺒﺎﺸﺭﺓ ﺍﻟﻰ ﺍل Datafilesﻭﺍل.SGA
ﻟﺤﻅﺔ ﺇﻨﻁﻼﻕ ﺍل Data Pump Jobﻫﻨﺎﻙ ﻋﻠﻰ ﺍﻻﻗل ﺍﺜﻨﻴﻥ ﻤﻥ ﺍلBackground Processes
ﺘﺒﺩﺃ ﺍﻟﻌﻤل ،ﺍﻻﻭل ) Data Pump Master Process (DMnnﻭﺫﻟﻙ ﻟﻠﺘﺤﻜﻡ ﻓﻰ ﻋﻤل ﺍل ، Jobﻭﺍﻟﺜﺎﻨﻰ
) ، Worker Processes (DWnnﻓﺈﺫﺍ ﻜﺎﻥ ﻫﻨﺎﻙ ﺍﻜﺜﺭ ﻤﻥ Jobsﺘﻌﻤل ﻓﻰ ﻨﻔﺱ ﺍﻟﻠﺤﻅﺔ ﻓﺈﻥ ﻜل Job
ﺘﻤﻠﻙ DMnnﻭ DWnnﺒﺄﺴﻤﺎﺀ ﺘﺩل ﻋﻠﻴﻬﺎ .ﺃﻤﺎ ﺇﺫﺍ ﻜﺎﻨﺕ ﺍل Jobﺘﻌﻤل ﻋﻠﻰ ﺍﻟﺘﻭﺍﺯﻯ ﺒﻭﺍﺴﻁﺔ ﺍﻟﺨﻴﺎﺭ
Parallelismﻓﺎﻥ ﺍل DWnnﻴﻘﻭﻡ ﺒﺎﺴﺘﺨﺩﺍﻡ ﺍﺜﻨﻴﻥ ﺃﻭ ﺍﻜﺜﺭ ﻤﻥ Parallel Execution Servers
).(Pnnn
ﻜﺫﻟﻙ ﻋﻨﺩ ﻋﻤل ﺍل Jobﻓﺈﻥ ﻫﻨﺎﻙ ﺍﺜﻨﻴﻥ ﻤﻥ ﺍﻟﺼﻔﻭﻑ ﻴﺘﻡ ﺘﻜﻭﻴﻨﻬﺎ ،ﺍﻻﻭل ، Control Queue
ﻭﺍﻟﺜﺎﻨﻰ . Status Queue
ﺍﻴﻀﹰﺎ ﺍﻟﻤﻠﻔﺎﺕ ﺍﻟﻨﺎﺘﺠﺔ ﻤﻥ ﺍل Data Pumpﺘﺤﺘﻭﻯ ﻋﻠﻰ ﺜﻼﺜﺔ ﺍﺸﻜﺎل ،ﺍﻻﻭل SQL Fileﻭﻫﻭ
ﻴﺤﺘﻭﻯ ﻋﻠﻰ ﻋﺒﺎﺭﺍﺕ ﻹﻨﺸﺎﺀ ﺍﻟﻜﺎﺌﻨﺎﺕ ،DDL Statementsﻭﺍﻟﺜﺎﻨﻰ Dump Fileﻴﺤﺘﻭﻯ ﻋﻠﻰ ﺍﻟﺒﻴﺎﻨﺎﺕ
ﺍﻟﻤﺼﺩﺭﺓ ،ﻭﺍﻟﺜﺎﻟﺙ Log Fileﻴﻭﻀﺢ ﺘﻔﺎﺼﻴل ﻋﻤل ﺍل.Job
50
:Directories
ﻭﻫﻨﺎ ﻻ ﺒﺩ ﻤﻥ ﺍﻟﺤﺩﻴﺙ ﻋﻥ ﻫﺫﺍ ﺍﻟﻤﻌﻨﻰ ﻓﻰ ﻫﺫﻩ ﺍﻟﻤﺭﺤﻠﺔ ،ﻭﺫﻟﻙ ﻷﻥ ﺍل Data Pumpﺘﻘﺭﺃ
ﻭﺘﻜﺘﺏ ﺍﻟﻤﻠﻔﺎﺕ ﻓﻰ ﺍل ، Oracle Directoryﻭﻋﻤﻭﻤﹰﺎ ﻓﺈﻥ ﺍل Oracle Server
ﻟﻜﻰ ﻴﺴﺘﻁﻴﻊ ﻗﺭﺍﺀﺓ ﻭﻜﺘﺎﺒﺔ ﺍﻟﻤﻠﻔﺎﺕ ﻋﻠﻰ ﻤﺴﺎﺭﺍﺕ ﻨﻅﺎﻡ ﺍﻟﺘﺸﻐﻴل ﻴﺠﺏ ﺃﻥ ﻴﺘﻡ ﺇﻨﺸﺎﺀ ﺍلOracle Directory
،ﺇﺫﹰﺍ ﻓﺎل Oracle Directoryﻴﺴﻤﺢ ﻟل Oracle Serverﺒﺎﻟﺘﻌﺎﻤل ﻤﻊ ﺍﻟﻤﻠﻔﺎﺕ ﻋﻠﻰ ﻨﻅﺎﻡ ﻟﺘﺸﻐﻴل.
ﻤﻥ ﻴﻤﻠﻙ ﺍل Oracle Directoriesﺩﺍﺌﻤﹰﺎ ﻫﻭ ﺍﻟﻤﺴﺘﺨﺩﻡ SYSﻭﻟﻜﻰ ﻴﻘﻭﻡ ﻤﺴﺘﺨﺩﻡ ﺒﺈﻨﺸﺎﺀ
Oracle Directoryﻴﺠﺏ ﺃﻥ ﻴﻤﻠﻙ ﺍﻟﺼﻼﺤﻴﺔ .CREATE DIRECTORY
ﻋﻤﻭﻤﹰﺎ ﺍل Oracle Serverﻻ ﻴﻘﻭﻡ ﺒﺎﻟﺘﺄﻜﺩ ﻤﻥ ﺼﺤﺔ ﺍﻟﻤﺴﺎﺭ ﻋﻠﻰ ﻨﻅﺎﻡ ﺍﻟﺘﺸﻐﻴل ﻋﻨﺩ ﺇﻨﺸﺎﺀ
ﺍل ، Directoryﻓﺈﺫﺍ ﻜﺎﻥ ﺍﻟﻤﺴﺎﺭ ﺨﻁﺄ ﻋﻠﻰ ﻤﺴﺘﻭﻯ ﻨﻅﺎﻡ ﺍﻟﺘﺸﻐﻴل ﻋﻨﺩ ﺇﻨﺸﺎﺀ ﺍلDirectory
ﺍﻭ ﺃﻥ ﻤﺴﺘﺨﺩﻡ ﻨﻅﺎﻡ ﺍﻟﺘﺸﻐﻴل ﻻ ﻴﻤﻠﻙ ﺼﺎﻟﺤﻴﺔ ﺍﻟﻘﺭﺍﺀﺓ ﻭﺍﻟﻜﺘﺎﺒﺔ ﻋﻠﻰ ﻫﺫﺍ ﺍﻟﻤﺴﺎﺭ ﻓﺈﻥ ﺭﺴﺎﺌل ﺍﻟﺨﻁﺄ ﺴﺘﻅﻬﺭ
ﻋﻨﺩ ﻤﺤﺎﻭﻟﺔ ﺍﺴﺘﺨﺩﺍﻡ ﻫﺫﺍ ﺍل.Directory
ﺍﻟﻤﺘﻐﻴﺭ UTL_FILE_DIRﻴﺴﻤﺢ ﻟل Oracleﻤﻥ ﺨﻼل PL/SQL PROCEDURES
ﺒﺎﻟﻜﺘﺎﺒﺔ ﻓﻰ ﺍل. File System
ﺍﻻﻥ ﻟﻨﻔﺘﺭﺽ ﺃﻥ ﻤﺩﻴﺭ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻴﺭﻴﺩ ﻤﻨﺢ ﺍﻟﺼﻼﺤﻴﺔ CREATE ANY
DIRECTORYﻟﻠﻤﺴﺘﺨﺩﻡ VBSﺤﺘﻰ ﻴﺴﺘﻁﻴﻊ ﻫﺫﺍ ﺍﻟﻤﺴﺘﺨﺩﻡ ﺇﻨﺸﺎﺀ Oracle Directoriesﻟﺘﺼﺩﻴﺭ
ﻭﺇﺴﺘﻴﺭﺍﺩ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺒﻭﺍﺴﻁﺔ ﺍل.Data Pump
51
ﺍﻻﻥ ﺍﻟﻤﺴﺘﺨﺩﻡ VBSﻗﺎﻡ ﺒﺈﻨﺸﺎﺀ Directoryﺍﺴﻤﻪ ، DIRECTﻭﺫﻟﻙ ﺒﻌﺩﻤﺎ ﻤﻨﺤﻪ ﻤﺩﻴﺭ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ
ﺍﻟﺼﻼﺤﻴﺔ ﻟﺫﻟﻙ.
ﻴﺠﺏ ﺍﻟﺘﺄﻜﺩ ﻤﻥ ﺍﻟﻤﺴﺎﺭ ﻋﻠﻰ ﻨﻅﺎﻡ ﺍﻟﺘﺸﻐﻴل.
52
Use Data Pump to Export Data -3
ﺴﻨﺴﺘﺨﺩﻡ ﻫﻨﺎ ﺍل Data Pumpﻟﺘﺼﺩﻴﺭ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻭﺍﻟﻜﺎﺌﻨﺎﺕ ،ﻭﻤﻥ ﺍﻟﺨﻴﺎﺭﺍﺕ ﺍﻟﻤﺘﺎﺤﺔ:
-1ﺘﺼﺩﻴﺭ ﺍﻟﺠﺩﺍﻭل.
-2ﺘﺼﺩﻴﺭ ﺒﻴﺎﻨﺎﺕ ﻭﻜﺎﺌﻨﺎﺕ ﺍﻟﻤﺴﺘﺨﺩﻤﻴﻥ.
-3ﺘﺼﺩﻴﺭ .Tablespace
-4ﺘﺼﺩﻴﺭ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ.
53
ﻫﻜﺫﺍ ﺘﻡ ﺘﺼﺩﻴﺭ ﺍﻟﺠﺩﺍﻭل ﺍﻟﺜﻼﺙ ﻭﺫﻟﻙ ﺒﻭﺍﺴﻁﺔ JOBﻗﺎﻤﺕ ﺒﺈﻨﺠﺎﺯ ﺍﻟﻤﻬﻤﺔ ،ﺒﺎﻟﻁﺒﻊ ﻴﻤﻜﻥ ﺍﻟﺘﺤﻜﻡ
ﻭﺍﻹﺴﺘﻌﻼﻡ ﻋﻥ ﻫﺫﻩ ﺍل JOBﻭﻏﻴﺭﻫﺎ ،ﻭﻟﻜﻥ ﺴﻨﺘﺤﺩﺙ ﻋﻥ ﺫﻟﻙ ﻻﺤﻘﺎ .
ﻋﻤﻭﻤﺎ ﺍﻻﻥ ﺘﻡ ﺇﻨﺸﺎﺀ ﻤﻠﻑ ﺍﺴﻤﻪ TABLES.DMPﻤﻭﺠﻭﺩ ﻓﻰ DIRECTORYﻴﺴﻤﻰ .DIRECT
:SCHEMAS EXPORT
:
ﻭﻟﻨﻔﺘﺭﺽ ﺃﻥ ﻤﺩﻴﺭ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻴﺭﻴﺩ ﺃﻥ ﻴﺼﺩﺭ ﺒﻴﺎﻨﺎﺕ ﻭﻜﺎﺌﻨﺎﺕ ﺍﻟﻤﺴﺘﺨﺩﻡ VBS & MAIN
ﻟﻘﺩ ﺘﻡ ﺘﺼﺩﻴﺭ ﺒﻴﺎﻨﺎﺕ ﻭﻜﺎﺌﻨﺎﺕ ﺍﻟﻤﺴﺘﺨﺩﻤﻴﻥ VBS & MAINﺒﻭﺍﺴﻁﺔ ﺍل JOBﺍﻟﺘﻰ ﺘﺴﻤﻰ .JB1
54
ﻭﻋﻤﻭﻤﹰﺎ ﻫﻨﺎﻙ ﻋﺩﺩ ﻤﻥ ﺍﻟﺨﻴﺎﺭﺍﺕ ﺍﻟﺘﻰ ﻴﻤﻜﻥ ﺍﺴﺘﺨﺩﺍﻤﻬﺎ ،ﻭﻟﻌﺭﺽ ﻫﺫﻩ ﺍﻟﺨﻴﺎﺭﺍﺕ ﻨﻜﺘﺏ ﺍﻻﻤﺭ –
HELP
55
DATABASE EXPORT
ﻻﺤﻁ ﻤﻌﻰ ﺃﻨﻨﺎ ﺍﺴﺘﺨﺩﻤﻨﺎ ﺍﻟﺨﻴﺎﺭ FULL=Yﻟﺘﺼﺩﻴﺭ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻭﺫﻟﻙ ﺒﺈﺴﺘﺨﺩﺍﻡ ﺍل JOBﺍﻟﺘﻰ ﺘﺴﻤﻰ
.JB2
56
ﻫﻨﺎ ﻗﻤﻨﺎ ﺒﺈﻴﻘﺎﻕ ﺍل JOBﺒﻭﺍﺴﻁﺔ ﺍﻻﻤﺭ ، STOP_JOBﻻﺤﻅ ﻤﻌﻰ ﺒﻌﺩ ﺫﻟﻙ ﻗﻤﻨﺎ ﺒﺈﻋﺎﺩﺓ ﺍلJOB
ﺒﻭﺍﺴﻁﺔ ﺍﻟﺨﻴﺎﺭ ATTACHﻓﻘﺎﻡ ﺒﻌﺭﺽ ﺍل ، JOBﺍﻻﻥ ﻴﻤﻜﻥ ﺘﺸﻐﻴل ﺍل JOBﻤﻥ ﺠﺩﻴﺩ ﻹﻜﻤﺎل ﻋﻤﻠﻴﺔ
ﺍﻟﺘﺼﺩﻴﺭ ﺒﻭﺍﺴﻁﺔ ﺍﻻﻤﺭ START_JOBﻜﻤﺎ ﺴﻨﺸﺎﻫﺩ ﻓﻰ ﺍﻟﺸﻜل ﺍﺩﻨﺎﻩ.
ﺍﻻﻥ ﺍل JOBﺘﻌﻤل ﺒﻌﺩﻤﺎ ﺘﻡ ﺍﻴﻘﺎﻓﻬﺎ ﻤﻥ ﻗﺒل ﻭﻴﻤﻜﻥ ﺍﻻﻥ ﻤﻌﺭﻓﺔ ﺤﺎﻟﺔ ﺍل JOBﺒﻭﺍﺴﻁﺔ ﺍﻻﻤﺭ
.STATUS
ﻻ ﺸﻙ ﺃﻥ ﺍﻨﻙ ﻋﺭﻓﺕ ﺍﻻﻥ ﻤﺩﻯ ﺍﻟﻤﺭﻭﻨﺔ ﺍﻟﺘﻰ ﺘﻭﻓﺭﻫﺎ ﻟﻨﺎ ﺍﻟﻭﺴﻴﻠﺔ .DATA PUMPﻜﻤﺎ ﻴﻤﻜﻥ
ﻼ ﺍﻻﻤﺭ PARALLEL ,ﻭﺫﻟﻙ
ﺍﺴﺘﺨﺩﺍﻡ ﺍﻭﺍﻤﺭ ﺍﺨﺭﻯ ﻴﻤﻜﻥ ﻋﺭﻀﻬﺎ ﺒﻭﺍﺴﻁﺔ ﺍﻟﺨﻴﺎﺭ .–HELPﻤﺜ ﹰ
ﻟﺘﺤﺩﻴﺩ ﻋﺩﺩ ﺍﻟﻘﻨﻭﺍﺕ ﺍﻟﻠﺘﻰ ﺘﻌﻤل ﻋﻠﻰ ﺍﻟﺘﻭﺍﺯﻯ ﻓﻰ ﺘﻔﺱ ﺍل JOBﻭﻏﻴﺭﻩ ﺍﻟﻜﺜﻴﺭ ﻤﻥ ﺍﻻﻭﺍﻤﺭ.
57
Use Data Pump to Import Data -4
ﺴﻨﺴﺘﺨﺩﻡ ﻫﻨﺎ ﺍل Data Pumpﻹﺴﺘﻴﺭﺍﺩ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻭﺍﻟﻜﺎﺌﻨﺎﺕ ﻟﻘﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ .ﻭﻤﻥ ﺍﻟﺨﻴﺎﺭﺍﺕ
ﺍﻟﻤﺘﺎﺤﺔ-:
-1ﺍﺴﺘﻴﺭﺍﺩ ﺍﻟﺠﺩﺍﻭل.
-2ﺍﺴﺘﻴﺭﺍﺩ ﺒﻴﺎﻨﺎﺕ ﻭﻜﺎﺌﻨﺎﺕ ﺍﻟﻤﺴﺘﺨﺩﻤﻴﻥ.
-3ﺍﺴﺘﻴﺭﺍﺩ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ.
ﻭﻗﺒل ﺍﻟﺒﺩﺀ ﻓﻰ ﻤﻨﺎﻗﺸﺔ ﻫﺫﻩ ﺍﻟﺨﻴﺎﺭﺍﺕ ﻴﺠﺏ ﺍﻟﺘﻨﺒﻴﻪ ﺇﻟﻰ ﺃﻥ ﺠﻤﻴﻊ ﺍﻟﺨﻴﺎﺭﺍﺕ ﺍﻟﻤﺘﺎﺤﺔ ﻓﻰ ﺍﻻﺴﺘﻴﺭﺍﺩ ﻴﻤﻜﻨﻙ
ﻤﺸﺎﻫﺩﺘﻬﺎ ﺒﻭﺍﺴﻁﺔ ﺍﻻﻤﺭ .–HELP
58
TABLES IMPORT
ﻭﻟﻨﻔﺘﺭﺽ ﺃﻥ ﺍﻟﻤﺴﺘﺨﺩﻡ VBSﻓﻘﺩ ﺍﻟﺠﺩﻭل EMPLOYEEﻭﻴﺭﻴﺩ ﺍﺴﺘﻴﺭﺍﺩﻩ ﻤﻥ ﻤﻠﻑ ﺍﻟﺘﺼﺩﻴﺭ .
ﻗﻤﻨﺎ ﺒﻌﻤل ﺍﺴﺘﻴﺭﺍﺩ ﻟﻠﺠﺩﻭل EMPLOYEEﻴﻤﻜﻥ ﺍﻟﺘﺄﻜﺩ ﺒﻌﻤل ﺇﺴﺘﻌﻼﻡ ﻟﺠﺩﺍﻭل ﺍﻟﻤﺴﺘﺨﺩﻡ .VBS
59
SCHEMA IMPORT
ﻭﻟﻨﻔﺘﺭﺽ ﺍﻥ ﻟﺩﻴﻨﺎ ﻤﺴﺘﺨﺩﻡ ﺠﺩﻴﺩ ﻴﺴﻤﻰ ، NEWﻭﻨﺭﻴﺩ ﺍﺴﺘﻴﺭﺍﺩ ﺒﻴﺎﻨﺎﺕ ﻭﻜﺎﺌﻨﺎﺕ ﺍﻟﻤﺴﺘﺨﺩﻡ VBS
ﻤﻥ ﻤﻠﻑ ﺍﻟﺘﺼﺩﻴﺭ ﻟﻠﻤﺴﺘﺨﺩﻡ .NEW
ﻗﻤﻨﺎ ﺒﺈﺘﺴﻴﺭﺍﺩ ﺒﻴﺎﻨﺎﺕ ﻭﻜﺎﺌﻨﺎﺕ ﺍﻟﻤﺴﺘﺨﺩﻡ VBSﻤﻥ ﻤﻠﻑ ﺍﻟﺘﺼﺩﻴﺭ ﺇﻟﻰ ﺍﻟﻤﺴﺘﺨﺩﻡ .NEW
ﻜﺫﻟﻙ ﻴﻤﻜﻥ ﺍﻟﺘﺤﻜﻡ ﻓﻰ ﺍل JOBﺒﻭﺍﺴﻁﺔ ﺍﻻﻭﺍﻤﺭ STATUS AND START_JOB AND
.STOP_JOB
60
DATABASE IMPORT
ﻴﻤﻜﻥ ﺍﺴﺘﻴﺭﺍﺩ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺒﻭﺍﺴﻁﺔ ﺍل Data Pumpﻤﻥ ﻤﻠﻑ ﺍﻟﺘﺼﺩﻴﺭ
ﻫﻜﺫﺍ ﻗﻤﻨﺎ ﺒﺈﺴﺘﻴﺭﺍﺩ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ،ﻜﻤﺎ ﻴﻤﻜﻥ ﺍﻟﺘﺤﻜﻡ ﻓﻰ ﺍل JOBﻜﻤﺎ ﻓﻌﻠﻨﺎ ﻋﻨﺩ ﺘﺼﺩﻴﺭ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ
ﺒﻭﺍﺴﻁﺔ ﺍل.Data Pump
ﺍﻴﻀﹰﺎ ﻴﻤﻜﻥ ﺍﺴﺘﺨﺩﺍﻡ ﺍﻭﺍﻤﺭ ﺍﺨﺭﻯ ﻤﺘﺎﺤﺔ ﻴﻤﻜﻥ ﻤﺭﺍﺠﻌﺘﻬﺎ ﺒﻭﺍﺴﻁﺔ ﺍﻻﻤﺭ .Help
:
61
ﻣﻴﺰات وﳏﺎﺳﻦ ال:Data Pump
ﻤﻥ ﺍﻫﻡ ﻤﻴﺯﺍﺕ ﺍل Data Pumpﻤﻘﺎﺭﻥ ﺒﺎﻟﻁﺭﻴﻘﺔ ﺍﻟﻌﺎﺩﻴﺔ ﻫﻰ ﺍﻟﺴﺭﻋﺔ ،ﻓﻬﺫﻩ ﺍﻟﻁﺭﻴﻘﺔ ﺍﺴﺭﻉ ﻤﻥ
ﺍﻟﻁﺭﻴﻕ ﺍﻟﻌﺎﺩﻴﺔ ﺒﺤﻭﺍﻟﻰ 10ﺍﻟﻰ 15ﻤﺭﺓ .
ﻜﻤﺎ ﻴﺘﻡ ﺇﻨﺸﺎﺀ Jobﻟﻌﻤل ﺍﻟﺘﺼﺩﻴﺭ ﺃﻭ ﺍﻻﺴﺘﻴﺭﺍﺩ ﻤﻤﺎ ﻴﺴﻬل ﻋﻤﻠﻴﺔ ﺍﻟﺘﺤﻜﻡ ﻓﻰ ﻋﻤﻠﻴﺔ ﺍﻟﺘﺼﺩﻴﺭ
ﻭﺫﻟﻙ ﺒﻭﺍﺴﻁﻭ ﺍﻭﻤﺭ ﻴﻤﻜﻥ ﻤﻥ ﺨﻼﻟﻬﺎ ﺍﻟﺘﺤﻜﻡ ﻓﻰ ﺍل Jobsﺒﺤﻴﺙ ﻴﻤﻜﻥ ﺘﻭﻗﻴﻑ ﺍل Jobﺇﺫﺍ ﻜﺎﻥ ﻫﻨﺎﻙ
ﻤﺠﻤﻭﻋﺔ ﻤﻥ ﺍل Processesﺘﻌﻤل ﻭﺘﺸﻐﻴﻠﻬﺎ ﻓﻰ ﺍﻟﻭﻗﺕ ﺍﻟﻤﻨﺎﺴﺏ.
62
:SQL*Loader
ﺍﺴﺘﺨﺩﻤﻨﺎ ﺍل Data Pumpﻟﻘﺭﺍﺀﺓ ﻭﻜﺘﺎﺒﺔ ﻭﺍﺭﺴﺎل ﺍﻟﺒﻴﺎﻨﺎﺕ ﻤﻥ ﻗﺎﻋﺩﺓ ﺒﻴﺎﻨﺎﺕ ﺍﻟﻰ ﺍﺨﺭﻯ ﻭﻟﻜﻥ
ﺠﻤﻴﻊ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺍﻟﺘﻰ ﺘﻡ ﺍﻟﺘﻌﺎﻤل ﻤﻌﻬﺎ ﻜﺎﻨﺕ ﻓﻰ ﺍﻟﺤﻘﻴﻘﺔ ﻋﺒﺎﺭﺓ ﻋﻥ ، Oracle proprietary formatﻭﻟﻜﻥ
ﻤﺎﺫﺍ ﻟﻭ ﺍﺭﺩﻨﺎ ﻨﻘل ﺒﻴﺎﻨﺎﺕ ﺇﻟﻰ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺍﻭﺭﻜل ﻭﻫﺫﻩ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻋﺒﺎﺭﺓ ﻋﻥ ﻤﻠﻑ ﺍﻭ ﻤﻠﻔﺎﺕ ﺘﻡ ﺇﻨﺸﺎﺅﻫﺎ
ﺒﺎﻯ ﺒﺭﻨﺎﻤﺞ ﺍﺨﺭ ،ﻫﻨﺎ ﻻ ﻴﻤﻜﻥ ﺃﻥ ﻨﺴﺘﺨﺩﻡ ﺍل Data Pumpﻭﺇﻨﻤﺎ ﻨﺴﺘﺨﺩﻡ ﺍل SQL*Loaderﻓﻬﻰ ﺘﻘﻭﻡ
ﻴﺘﺤﻤﻴل ﺍﻟﺒﻴﺎﻨﺎﺕ ﻤﻥ ﻤﻠﻔﺎﺕ ﺨﺎﺭﺠﻴﺔ ﺍﻟﻰ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ.
63
:Input Data Files -1
ﻭﻫﻭ ﺍﻟﻤﻠﻑ ﺍﻭ ﺍﻟﻤﻠﻔﺎﺕ ﺍﻟﺘﻰ ﺘﺤﻭﻯ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺍﻟﺘﻰ ﻨﺭﻴﺩ ﻨﻘﻠﻬﺎ ﻟﻘﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺒﻭﺍﺴﻁﺔ
ﺍل .SQL*Loaderﻭﻫﺫﺍ ﺍﻟﻤﻠﻑ ﻴﺘﻡ ﺘﺤﺩﻴﺩ ﻤﺴﺎﺭﻩ ﻓﻰ ﻤﻠﻑ ﺍل Control Fileﺍﻟﺫﻯ ﻴﺘﻡ ﺘﻬﻴﺌﺘﻪ
ﺒﻭﺍﺴﻁﺔ ﻤﺩﻴﺭ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻭﺍﻟﺫﻯ ﺴﻨﺘﺤﺩﺙ ﻋﻨﻪ ﻻﺤﻘﹰﺎ ،ﻜﻤﺎ ﻴﻤﻜﻥ ﺘﻀﻤﻴﻥ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺍﻟﻤﺭﺍﺩ ﻨﻘﻠﻬﺎ
ﺇﻟﻰ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻓﻰ ﻤﻠﻑ ﺍل Control Fileﻭﻓﻰ ﻫﺫﻩ ﺍﻟﺤﺎﻟﺔ ﻻ ﻨﺤﺘﺎﺝ ﻟﻤﻠﻑ ﺍل.Input File
ﺸﻜل ﺍﻟﺒﻴﺎﻨﺎﺕ ﻓﻰ ﻫﺫﺍ ﺍﻟﻤﻠﻑ ﻴﺠﺏ ﺃﻥ ﺘﻜﻭﻥ ﺍﺤﺩ ﺜﻼﺙ-:
:Fixed-record format -1
ﻭﻫﻰ ﺍﻥ ﺘﻜﻭﻥ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻓﻰ ﻫﺫﺍ ﺍﻟﻤﻠﻑ ﻓﻰ ﺸﻜل ﺼﻔﻭﻑ ﻤﺘﺴﺎﻭﻴﺔ ﺍﻟﻁﻭل ،
ﻭﻫﺫﺍ ﺍﻟﻨﻭﻉ ﻴﺭﻓﻊ ﺍﻻﺩﺍﺀﺓ ﺍﺜﻨﺎﺀ ﻋﻤﻠﻴﺔ ﺍﻟﺘﺤﻤﻴل ﻭﻟﻜﻥ ﻗﻠﻴل ﺍﻟﻤﺭﻭﻨﺔ .
ﻼ ﻫﺫﺍ ﺍﻟﻤﻠﻑ.
ﻭﺍﻟﻴﻙ ﻤﺜ ﹰ
Mohammed,ali
Ahmed,yousif
Mogahid,omer
ﻻﺤﻅﺕ ﻤﻌﻰ ﺍﻥ ﺠﻤﻴﻊ ﺍﻟﺼﻔﻭﻑ ﻓﻰ ﻫﺫﺍ ﺍﻟﻤﻠﻑ Input Fileﻤﺘﺴﺎﻭﻴﺔ ﺍﻟﻁﻭل
ﻭﺍﻥ ﻁﻭل ﺠﻤﻴﻊ ﺍﻟﺼﻔﻭﻑ ﻓﻰ ﻫﺫﺍ ﺍﻟﻤﻠﻑ 12ﺤﺭﻑ.
015Mohammed,ahmed
010Ahmed,ali
011telal,omer
ﻟﻘﺩ ﺘﻡ ﺤﺠﺯ ﺍﻭل ﺜﻼﺙ ﺨﺎﻨﺎﺕ ﻟﺘﺤﺩﻴﺩ ﻁﻭل ﺍﻟﺼﻑ.
64
:Stream-record format -3
ﻭﻫﻰ ﺃﻥ ﺘﻜﻭﻥ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻓﻰ ﻫﺫﺍ ﺍﻟﻤﻠﻑ ﻓﻰ ﺸﻜل ﺼﻔﻭﻑ ﻏﻴﺭ ﻤﺘﺴﺎﻭﻴﺔ ﺍﻟﻁﻭل
ﻴﺘﻡ ﺘﺤﺩﻴﺩ ﻁﻭل ﺍﻟﺼﻔﻭﻑ ﻓﻰ ﺒﺩﺍﻴﺔ ﺍﻟﺼﻔﻭﻑ ﻤﻤﺎ ﻴﺘﻁﻠﺏ ﻋﻤل ﻤﺴﺢ ﻜﺎﻤل ﻭﻻ
ﻟﻠﺼﻔﻭﻑ ﻗﺒل ﻋﻤﻠﻴﺔ ﺍﻟﺘﺤﻤﻴل ﻟﺘﺤﺩﻴﺩ ﻁﻭل ﺍﻟﺼﻔﻭﻑ ،ﻟﺫﻟﻙ ﻫﺫﺍ ﺍﻟﻨﻭﻉ ﺍﻜﺜﺭ
ﻤﻥ ﺍﻟﻨﻭﻋﻴﻥ ﺍﻟﺴﺎﺒﻘﻴﻥ ﻟﻜﻥ ﺒﺎﻟﻁﺒﻊ ﻴﻘﻠل ﻤﻥ ﺍﻻﺩﺍﺀ. ﻤﺭﻭﻨﻪ
ﻼ ﻫﺫﺍ ﺍﻟﻤﻠﻑ.
ﻭﺍﻟﻴﻙ ﻤﺜ ﹰ
Mohammed,ahmed
Ahmed,ali
telal,omer
ﻟﻡ ﻴﺘﻡ ﺘﺤﺩﻴﺩ ﻁﻭل ﺍﻟﺼﻔﻭﻑ ﻓﻰ ﺒﺩﺍﻴﺔ ﺍﻟﺼﻔﻭﻑ ﻜﻤﺎ ﺍﻥ ﺍﻟﺼﻔﻭﻑ ﻏﻴﺭ ﻤﺘﺴﺎﻭﻴﺔ.
65
:Control File -2
ﻭﻫﻭ ﻤﻠﻑ ﻨﺼﻰ ﻴﺘﻡ ﻜﺘﺎﺒﺘﻪ ﻭﺘﻬﻴﺌﺘﻪ ﺒﻭﺍﺴﻁﺔ ﻤﺩﻴﺭ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ،ﻭﻫﺫﺍ ﺍﻟﻤﻠﻑ ﻻﺒﺩ ﻤﻨﻪ
ﺍﺜﻨﺎﺀ ﻋﻤﻠﻴﺔ ﺘﺤﻤﻴل ﺍﻟﺒﻴﺎﻨﺎﺕ ﻟﻘﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ،ﺤﻴﺙ ﻴﺤﺘﻭﻯ ﻫﺫﺍ ﺍﻟﻤﻠﻑ ﻋﻠﻰ ﻤﻜﺎﻥ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺍﻟﺘﻰ
ﻨﺭﻴﺩ ﺘﺤﻤﻴﻠﻬﺎ ﻤﻥ ﺨﻼل ﺘﺤﺩﻴﺩ ﻤﻠﻑ ﺍل Input Dataﺍﻭ ﻤﻥ ﺨﻼل ﺍﺤﺘﻭﺍﺌﻪ ﻋﻠﻰ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺍﻟﻤﺭﺍﺩ
ﺘﺤﻤﻴﻠﻬﺎ ﻭﻜﺫﻟﻙ ﻴﺤﺩﺩ ﻜﻴﻔﻴﺔ ﺘﺤﻤﻴل ﺍﻟﺒﻴﺎﻨﺎﺕ ﻭﻤﻜﺎﻥ ﺇﻨﺸﺎﺀ ﺍﻟﻤﻠﻔﺎﺕ ﺍﻻﺨﺭﻯ ﻭﻏﻴﺭﻫﺎ ﻤﻥ ﺍﻟﻤﻌﻠﻭﻤﺎﺕ
ﺍﻟﻬﺎﻤﺔ
load data
"infile 'fixed.dat' "fix 15
inset into table names
'fields terminated by ',
)(first,last
ﻫﺫﺍ ﻨﻤﻭﺯﺝ ﻟﻤﻠﻑ ﺍل Control Fileﺤﻴﺙ ﺘﻡ ﻓﻴﻪ ﺘﺤﺩﻴﺩ ﻤﻠﻑ ﺍل Input Fileﻭﻜﺫﻟﻙ ﺸﻜل
ﺍﻟﺒﻴﺎﻨﺎﺕ fixed-recordﻭﺍﻥ ﻁﻭل ﺍﻟﺼﻔﻭﻑ ﻓﻰ ﺍﻟﻤﻠﻑ ﺍﻟﻤﺭﺍﺩ ﺘﺤﻤﻴﻠﻪ 15ﺤﺭﻑ ﻭﺍﻥ
ﺍﻟﻔﻭﺍﺼل ﺒﻴﻥ ﺍﻟﺤﻘﻭل ﺒﺎﻟﺤﺭﻑ'.',
load data
"infile 'names.dat' "var 3
into table names
'fields terminated by ',
)(first,last
ﻻﺤﻅ ﻤﻌﻰ ﻫﻨﺎ ﺍﻨﻪ ﺘﻡ ﺘﺤﺩﻴﺩ ﺸﻜل ﺍﻟﺒﻴﺎﻨﺎﺕ ﺍﻟﺘﻰ ﻴﺘﻡ ﺘﺤﻤﻴﻠﻬﺎ ﻓﻰ ﺸﻜل Variable-record
ﻭﺘﻡ ﺘﺤﺩﻴﺩ ﺜﻼﺙ ﺨﺎﻨﺎﺕ ﻟﺘﺤﺩﻴﺩ ﻁﻭل ﺍﻟﺼﻔﻭﻑ ﻭﺍﻥ ﺍﻟﻔﻭﺍﺼل ﺒﻴﻥ ﺍﻟﺤﻘﻭل ﺒﺎﻟﺤﺭﻑ '.',
66
load data
"'infile 'names.dat' "str '\n
into table names
'fields terminated by ',
)(first,last
67
ﻁﺭﻴﻘﺔ ﺍﻟﺘﺤﻤﻴل:
ﻫﻨﺎﻙ ﻁﺭﻴﻘﺘﻴﻥ ﻟﻌﻤﻠﻴﺔ ﺘﺤﻤﻴل ﺍﻟﺒﻴﺎﻨﺎﺕ ﺒﻭﺍﺴﻁﺔ ﺍل:SQL*Loader
:Conventional Path Load -1
ﻓﻰ ﻫﺫﻩ ﺍﻟﻁﺭﻴﻘﺔ ﻴﺘﻡ ﺒﻨﺎﺀ ﻤﺼﻔﻭﻓﺔ ﻤﻥ ﺍﻟﺼﻔﻭﻑ ﻓﻰ ﺍﻟﺯﺍﻜﺭﺓ ﻭﻤﻥ ﺜﻡ ﻴﺘﻡ ﺍﻀﺎﻓﺘﻬﺎ
ﻟﻠﺠﺩﺍﻭل ﺒﻭﺍﺴﻁﺔ SQL INSERT statementﻟﺘﺤﻤﻴل ﺍﻟﺒﻴﺎﻨﺎﺕ ﻟﻘﺎﻋﺩﺓ
ﺍﻟﺒﻴﺎﻨﺎﺕ.
68
ﻭﺍﻻﻥ ﻟﻨﻘﻭﻡ ﺒﻤﺘﺎﺒﻌﺔ ﺍﻟﻤﺜﺎل ﺍﻟﺘﺎﻟﻰ ﺍﻟﺫﻯ ﻴﻭﻀﺢ ﻋﻤﻠﻴﺔ ﺘﺤﻤﻴل ﻤﻠﻑ ﻨﺼﻰ ﺍﻟﻰ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺍﻭﺭﻜل ﺒﻭﺍﺴﻁﺔ
ﺍل.SQL*Loader
69
ﻻﺤﻅ ﻤﻌﻰ ﺍﻨﻰ ﺍﺴﺘﺨﺩﻤﺕ ﺍﻻﻤﺭ INSERTﻭﺫﻟﻙ ﻻﻥ ﺍﻟﺠﺩﻭل ﻻ ﻴﺤﻭﻯ ﺒﻴﺎﻨﺎﺕ ،ﺍﻤﺎ ﺇﺫﺍ ﻜﺎﻥ ﺍﻟﺠﺩﻭل
ﻴﺤﻭﻯ ﺒﻴﺎﻨﺎﺕ ﻭﻨﺭﻴﺩ ﺃﻥ ﻨﻀﻴﻑ ﺍﻟﻴﻪ ﺒﻴﺎﻨﺎﺕ ﺠﺩﻴﺩﻴﺔ ﻓﻨﺴﺘﺨﺩﻡ ﺍﻻﻤﺭ APPENDﺍﻤﺎ ﺇﺫﺍ ﻜﻨﺎ ﻨﺭﻴﺩ ﻤﺴﺢ
ﺍﻟﺒﻴﺎﻨﺎﺕ ﺍﻟﻘﺩﻴﻤﺔ ﻭﺇﻀﺎﻓﺔ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺍﻟﺠﺩﻴﺩﺓ ﻓﻨﺴﺘﺨﺩﻡ ﺍﻻﻤﺭ .TRUNCATE
ﺇﺫﹰﺍ ﺠﻤﻴﻊ ﺍﻟﺼﻔﻭﻑ ﺘﻡ ﺘﺤﻤﻴﻠﻬﺎ ﺒﺴﻼﻡ ﻜﻤﺎ ﻴﻤﻜﻥ ﻤﺭﺍﺠﻌﺔ ﻤﻠﻑ ﺍلLog file
لٍ SQL*Loaderﻋﻥ ﻁﺭﻴﻕ ﺍﻻﻤﺭ ?.sqlldr -
ﻋﻤﻭﻤﹰﺎ ﻴﻤﻜﻥ ﻤﺭﺍﺠﻌﺔ ﺠﻤﻴﻊ ﺍﻟﺨﻴﺎﺭﺍﺕ ﺍﻟﻤﺘﺎﺤﺔ ﻟ َ
70
71
72
73
74
ﺍﻟﺸﻜل ﺍﻋﻼﻩ ﻴﻭﻀﺢ ﺍﻨﻭﺍﻉ ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﻟﻘﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺍﻭﺭﻜل ) & Logical & Physical
(RMANﻭﻟﻘﺩ ﺘﺤﺩﺜﻨﺎ ﻓﻰ ﺍﻟﻔﺼل ﺍﻟﺴﺎﺒﻕ ﻋﻥ ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﺍﻟﻤﻨﻁﻘﻰ ) (Logical Backupﻭﺴﻨﺘﺤﺩﺙ
ﻓﻰ ﻫﺫﺍ ﺍﻟﻔﺼل ﻋﻥ ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﺍﻟﻔﻴﺯﻴﺎﺌﻰ ) (Physical Backupﻭﻜﺫﻟﻙ ﺍﻹﺴﺘﺭﺠﺎﻉ ،ﻭﻟﻘﺩ ﻗﺒل
ﺍﻟﺘﻔﺼﻴل ﻓﻰ ﻫﺫﺍ ﺍﻟﻤﻭﻀﻭﻉ ﻻﺒﺩ ﻤﻥ ﺇﺸﺎﺭﺍﺕ ﺴﺭﻴﻌﺔ.
ﻤﺎﻫﻭ ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﺍﻟﻔﻴﺯﻴﺎﺌﻰ ) :(Physical Backupﻫﻭ ﻨﺴﺦ ﻟﻤﻠﻔﺎﺕ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻋﻠﻰ ﻁﺭﻴﻕ
ﻨﻅﺎﻡ ﺍﻟﺘﺸﻐﻴل ﻭﻴﻜﻭﻥ ﺍﻟﻨﺴﺦ ﻟﻠﻤﻠﻔﺎﺕ ﺍﻟﺘﻰ ﻴﻤﻜﻥ ﻤﺸﺎﻫﺩﺘﻬﺎ ﻓﻴﺯﻴﺎﺌﻴﹰﺎ ﻋﻥ ﻁﺭﻴﻕ ﻨﻅﺎﻡ ﺍﻟﺘﺸﻐﻴل ،ﻓﻔﻰ ﺍﻟﻨﺴﺦ
ﺍﻹﺤﺘﻴﺎﻁﻰ ﺍﻟﻤﻨﻁﻘﻰ ﻜﻨﺎ ﻨﺴﺘﺨﺩﻡ ﻭﺴﻴﻠﺔ ﺘﺼﺩﻴﺭ ﻤﻥ ﺇﺼﺩﺍﺭ ﺍﻭﺭﻜل ﻤﺜل Export Utilitiesﻭﻟﻴﺱ ﻓﻘﻁ ﻋﻥ
ﻁﺭﻴﻕ ﻨﻅﺎﻡ ﺍﻟﺘﺸﻐﻴل ﻭﺫﻟﻙ ﻻﻥ ﺍﻟﻜﺎﺌﻨﺎﺕ ﺍﻟﺘﻰ ﻜﻨﺎ ﻨﺼﺩﺭﻫﺎ ﻓﻰ ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﺍﻟﻤﻨﻁﻘﻰ ) Logical
(Backupﻜﺎﻨﺕ ﻻ ﻴﻤﻜﻥ ﻤﺸﺎﻫﺩﺘﻬﺎ ﻋﻥ ﻁﺭﻴﻕ ﻨﻅﺎﻡ ﺍﻟﺘﺸﻐﻴل ﻤﺜل ﺍﻟﺠﺩﺍﻭل ﻭﺍﻟﻤﻨﺎﻅﻴﺭ ﻭﺍﻹﺠﺭﺍﺀﺍﺕ ﻭﻤﻥ
ﻫﻨﺎ ﺍﺘﺕ ﺘﺴﻤﻴﺔ ﻨﺴﺦ ﺇﺤﺘﻴﺎﻁﻰ ﻤﻨﻁﻘﻰ ،ﺍﻤﺎ ﻓﻰ ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﺍﻟﻔﻴﺯﻴﺎﺌﻰ ) (Physical Backupﻓﺠﻤﻴﻊ
ﺍﻟﻤﻠﻔﺎﺕ ﺍﻟﺘﻰ ﻴﺘﻡ ﻨﺴﺨﻬﺎ ﻫﻰ ﻋﺒﺎﺭﺓ ﻋﻥ .OS File
:Coldﻭﻫﻭ ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﺍﻟﻔﻴﺯﻴﺎﺌﻰ ﺍﻟﺒﺎﺭﺩ ،ﻭﺘﺄﺘﻰ ﻜﻠﻤﺔ ﺒﺎﺭﺩ ﻤﻥ ﺃﻥ ﺍﻟﻨﺴﺦ ﻴﻜﻭﻥ -1
ﺒﻌﺩ ﺇﻏﻼﻕ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻭﺴﻨﺘﺤﺩﺙ ﻋﻨﻪ ﻻﺤﻘﹰﺎ ﺒﻨﻭﻉ ﻤﻥ ﺍﻟﺘﻔﺼﻴل.
:Hotﻭﻫﻭ ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﺍﻟﻔﻴﺯﻴﺎﺌﻰ ﺍﻟﺴﺎﺨﻥ ،ﻭﻫﻭ ﻨﺴﺦ ﻟﻘﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺩﻭﻥ ﺍﻏﻼﻗﻬﺎ ، -2
ﻭﺴﻨﺘﺤﺩﺙ ﻋﻨﻪ ﺍﻴﻀﹰﺎ ﻻﺤﻘﹰﺎ.
75
ﻤﺎﻫﻰ ﺍﻨﻭﺍﻉ ﺍﻟﻔﺸل ﺍﻟﺘﻰ ﻴﻤﻜﻥ ﺃﻥ ﺘﺤﺩﺙ ﻟﻘﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ؟
76
:Archivelog Files Management
ﻭﻗﺒل ﺍﻟﺘﻔﺼﻴل ﻓﻰ ﻤﻭﻀﻭﻉ ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﺍﻟﻔﻴﺯﻴﺎﺌﻰ ﻻﺒﺩ ﻤﻥ ﺍﻟﺤﺩﻴﺙ ﻋﻥ ﻫﺫﺍ ﺍﻟﻤﻭﻀﻭﻉ ﺒﻨﻭﻉ
ﻤﻥ ﺍﻟﺘﻔﺼﻴل.
77
ﺫﻜﺭﺕ ﻓﻰ ﺍﻟﻔﺼل ﺍﻟﺨﺎﻤﺱ ﻤﻥ ﺍﻟﺠﺯﺀ ﺍﻻﻭل ﻤﻥ ﺍﻟﻜﺘﺎﺏ ﺃﻥ ﺍل Redo Log Fileﻴﺴﺘﺨﺩﻡ
ﻟﺘﺴﺠﻴل ﺍﻟﺘﻐﻴﻴﺭﺍﺕ ﺍﻟﺘﻰ ﺘﺤﺼل ﻋﻠﻰ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺒﺤﻴﺙ ﻴﺘﻡ ﺘﺴﺠﻴل ﺍﻟﺘﻐﻴﻴﺭﺍﺕ ﺍﻟﺘﻰ ﺘﻡ ﺘﺜﺒﻴﺘﻬﺎ ﺍﻭ ﻻ ،ﻨﺴﺘﻔﻴﺩ ﻤﻥ
ﻫﺫﺍ ﺍﻟﻤﻠﻔﺎﺕ ﻓﻰ ﺍﺴﺘﺭﺠﺎﻉ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻓﻰ ﺤﺎل ﺤﺩﻭﺙ ﻓﺸل .ﺒﺤﻴﺙ ﺘﻜﻭﻥ ﻫﻨﺎﻙ ﺒﻌﺽ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻟﻡ
ﺘﻜﺘﺏ ﻓﻰ ﺍل Data Filesﺒﻴﻨﻤﺎ ﻜﺘﺒﺕ ﻓﻰ ﻫﺫﺍ ﺍﻟﻤﻠﻔﺎﺕ .
ﻭﺫﻜﺭﺕ ﻜﺫﻟﻙ ﺒﺄﻥ ﺍل Redo Log Fileﻴﻜﻭﻥ ﻓﻰ ﺸﻜل GROUPﺒﺤﻴﺙ ﺘﻌﻤل ﻜل ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ
ﻋﻠﻰ ﻋﻠﻰ ﺍﻻﻗل ﺒﺎﺜﻨﻴﻥ ﻤﻥ ﺍل. Groups
ﺇﺫﹰﺍ ﻴﺴﺘﺨﺩﻡ ﻫﺫﺍ ﺍﻟﻤﻠﻑ ﺍﺴﺎﺴﹰﺎ ﻟﻌﻤﻠﻴﺔ ﺍﻻﺴﺘﺭﺠﺎﻉ ﻓﻰ ﺤﺎﻟﺔ ﺤﺩﻭﺙ ﺨﻁﹰﺎ ﺇﺫ ﻴﺤﺘﻭﻯ ﻋﻠﻰ ﺍﻟﺘﻐﻴﻴﺭﺍﺕ ﺍﻟﺘﻰ
ﺘﺤﺼل ﻋﻠﻰ ﺍﻟﺒﻴﺎﻨﺎﺕ .
ﻭﻟﻀﻤﺎﻥ ﺍﻟﺤﻔﺎﻅ ﻋﻠﻰ ﻫﺫﺍ ﺍﻟﻤﻠﻑ ﻓﺈﻥ ﻜل Groupﻴﻨﺘﻅﻡ ﻓﻰ ﺸﻜل Membersﻭﻜل ﺍل Member
ﺩﺍﺨل ﺍل Groupﻫﻰ ﻨﺴﺨﺔ ﻁﺒﻕ ﺍﻻﺼل ﺍﻟﻬﺩﻑ ﻤﻨﻬﺎ ﺘﻘﻠﻴل ﻨﺴﺒﺔ ﺨﻁﺭ ﺍﻟﻔﻘﺩﺍﻥ .
LGWR Background Processﻴﻘﻭﻡ ﺒﻜﺘﺎﺒﺔ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺍﻟﻤﻭﺠﻭﺩ ﺍل Redo log Bufferﺍﻟﻰ ﺍل Redo
.Log Files
ﻟﺤﻅﺔ ﻤﻠﺊ ﺍل Redo Log Fileﻓﺎﻥ ﺍل LGWRﻴﻘﻭﻡ ﺒﺎﻟﺘﺤﻭل ﻟل Redo Log Fileﺍﻻﺨﺭﻯ ﻓﻰ ﻋﻤﻠﻴﺔ
ﺘﻌﺭﻑ ﺒﺎل ، Log Switchﺜﻡ ﻴﻘﻭﻡ ﺒﺎﻟﺘﺤﻭل ﻤﺭﺓ ﺍﺨﺭﻯ ﺍﻟﻰ ﺍل Redo Log Fileﺍﻻﻭل ﻓﻰ ﻋﻤﻠﻴﺔ
ﺩﺍﺌﺭﻴﺔ ﻓﻴﻘﻭﻡ ﺒﻤﺴﺢ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻭﺍﻋﺎﺩﺓ ﺍﻟﻜﺘﺎﺒﺔ ﻓﻴﻪ ﻤﺭﺓ ﺍﺨﺭﻯ ،ﺍﻯ ﺃﻨﻨﺎ ﻨﻔﻘﺩ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺍﻟﺘﻰ ﺘﻜﻭﻥ ﻤﻭﺠﻭﺩﺓ ﻓﻴﻪ ،
ﻭﻫﻰ ﻋﺒﺎﺭﺓ ﻋﻥ ﺍﻟﺘﻐﻴﻴﺭﺍﺕ ﺍﻟﺘﻰ ﺘﺤﺩﺙ ﻓﻰ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻭﺍﻟﺘﻰ ﻨﺤﺘﺎﺠﻬﺎ ﻓﻰ ﻋﻤﻠﻴﺔ ﺍﻹﺴﺘﺭﺠﺎﻉ
.Recovery
ﻼ ﺃﻨﻙ ﻗﻤﺕ ﺒﻌﻤل ﻨﺴﺦ ﺇﺤﺘﻴﺎﻁﻰ ) (Backupﻴﻭﻡ ﺍﻻﺤﺩ ﺼﺒﺎﺤﹰﺎ ﻭﺤﺼل ﻓﺸل ﻟﻘﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ
ﻟﻨﻔﺘﺭﺽ ﻤﺜ ﹰ
ﻴﻭﻡ ﺍﻟﺜﻼﺜﺎﺀ ﻭﻨﺤﺘﺎﺝ ﻟﻌﻤل ﺍﺴﺘﺭﺠﺎﻉ ﻟﻘﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ،ﻓﻰ ﻫﺫﻩ ﺍﻟﺤﺎﻟﺔ ﺘﺴﺘﻁﻴﻊ ﺍﺴﺘﺭﺠﺎﻉ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻓﻘﻁ
ﺍﻟﻰ ﺍﺨﺭ ﻨﺴﺦ ﺍﺤﺘﻴﺎﻁﻰ ﻭﻫﻭ ﻴﻭﻡ ﺍﻻﺤﺩ ،ﻭﻻ ﻨﺴﺘﻁﻴﻊ ﻋﻤل Recoveryﺍﻟﻰ ﻤﺎ ﺒﻌﺩ ﺫﻟﻙ ﻭﺫﻟﻙ ﻷﻨﻨﺎ ﻓﻘﺩﻨﺎ
ﺍﻟﺒﻴﺎﻨﺎﺕ ﺍﻟﺘﻰ ﻨﺤﺘﺎﺠﻬﺎ ﻓﻰ ﻋﻤﻠﻴﺔ ﺍل Recoveryﺍﻟﻤﻭﺠﻭﺩﺓ ﻓﻰ ﺍل Redo Log Fileﻨﺘﻴﺠﺔ ﻹﻋﺎﺩﺓ ﺍﻟﻜﺘﺎﺒﺔ
ﻓﻰ ﺍل.Redo Log File
78
ﻤﺎﻟﺤل ﺇﺫﺍﹰ؟
ﺍﻟﺤل ﻨﻘﻭﻡ ﺒﻌﻤل ﺍﺭﺸﻴﻴﻑ ﻨﺤﺘﻔﻅ ﻓﻴﻪ ﺒﻨﺴﺦ ﻤﻥ ﺍل Redo Log Fileﻗﺒل ﺍﻋﺎﺩﺓ ﺍﻟﻜﺘﺎﺒﺔ ﻓﻴﻪ ،ﺍﻯ ﺒﻤﻌﻨﻰ
ﺍﺨﺭ ﻨﻘﻭﻡ ﺒﺘﺸﻐﻴل ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻓﻰ ﺍﻟﻨﻤﻁ .Archivelog Mode
ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻓﻰ ﺍﻻﺼل ﺘﻌﻤل ﻓﻰ ﺍﻟﻨﻤﻁ NOARCHIVELOGﺍﻯ ﺃﻥ ﻤﻠﻔﺎﺕ ﺍل Redo Log Fileﻻ
ﺘﺘﻡ ﺍﺭﺸﻔﺘﻬﺎ ،ﻟﺫﺍ ﻨﺴﺘﻁﻴﻊ ﺍﺭﺠﺎﻉ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻓﻘﻁ ﺇﻟﻰ ﺍﺨﺭ ﻨﺴﺦ ﺇﺤﺘﻴﺎﻁﻰ ﻓﻰ ﺤﺎﻟﺔ ﺤﺩﻭﺙ ﻓﺸل ﻟﻘﺎﻋﺩﺓ
ﺍﻟﺒﻴﺎﻨﺎﺕ.
ﺍﻭ
ﺍﻭ
79
-2ﻗﻡ ﺒﺘﻬﻴﺌﺔ ﺍﻟﻤﺘﻐﻴﺭ LOG_ARCHIVE_DEST_1ﻭﻫﻭ ﻴﺤﺩﺩ ﺍﻟﻤﺴﺎﺭ ﺍﻟﺫﻯ ﺴﻭﻑ ﻴﺘﻡ ﻓﻴﻪ ﺘﺨﺯﻴﻥ
ﺍﻻﺭﺸﻴﻑ ،ﻜﻤﺎ ﻴﻤﻜﻥ ﺘﺤﺩﻴﺩ 10ﻤﺴﺎﺭﺍﺕ ﻭﺍﺘﺠﺎﻫﺎﺕ ﻤﺨﺘﻠﻔﺔ ﻟﺘﺨﺯﻴﻥ ﺍﻻﺭﺸﻴﻑ ﻭﺫﻟﻙ ﻤﻥ ﺨﻼل ﺍﻟﻤﺘﻐﻴﺭﺍﺕ
LOG_ARCHIVE_DEST_2ﺍﻟﻰ LOG_ARCHIVE_DEST_10
ﻫﻨﺎ ﺴﻨﻘﻭﻡ ﺒﺘﻬﻴﺌﺔ ﻤﺴﺎﺭ ﻭﺍﺤﺩ ﻟﺘﺨﺯﻴﻥ ﺍﻻﺭﺸﻴﻑ ﻤﻥ ﺨﻼل ﺍﻟﻤﺘﻐﻴﺭ LOG_ARCHIVE_DEST_1
ﻻ ﺍﻟﺘﺄﻜﺩ ﻤﻥ ﺃﻥ ﺍﻟﻤﺴﺎﺭ ﺍﻟﻤﺤﺩﺩ ﺼﺤﻴﺤﹰﺎ ﻋﻠﻰ ﻨﻅﺎﻡ ﺍﻟﺘﺸﻐﻴل.
ﻴﺠﺏ ﺍﻭ ﹰ
80
ALTER SYSTEM SET
'\LOG_ARCHIVE_DEST_1='LOCATION=D:\ARCHIVE
;SCOPE=BOTH
81
ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﺍﻟﻔﻴﺯﻴﺎﺌﻲ ﺍﻟﺒﺎﺭﺩ ):(COLD BACKUP
82
ﺍﻻﻥ ﺴﺄﻗﻭﻡ ﺒﺸﺭﺡ ﺍﻟﺸﻜل ﺍﻋﻼﻩ ﻭﺍﻟﺫﻯ ﻴﻭﻀﺢ ﻋﻤﻠﻴﺔ ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﺍﻟﺒﺎﺭﺩ ﻭﻜﺫﻟﻙ
ﺍﻹﺴﺘﺭﺠﺎﻉ :
:Shutdownﻜﻤﺎ ﺫﻜﺭﻨﺎ ﺴﺎﺒﻘﹰﺎ ﺃﻥ ﻋﻤﻠﻴﺔ ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﺍﻟﺒﺎﺭﺩ ) (Cold Backupﺘﺘﻡ ﺒﻌﺩ -1
ﺇﻏﻼﻕ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ.
:Destinationﻭﻫﻭ ﺍﻹﺘﺠﺎﻩ ﺍﻟﺫﻯ ﺴﻭﻑ ﻴﺘﻡ ﻭﻀﻊ ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﻓﻴﻪ ﻭﻫﻭ ﺍﺤﺩ ﺜﻼﺙ -2
ﺨﻴﺎﺭﺍﺕ ).(Desk ,Tape,NFS
:Operation System Levelﻋﻤﻠﻴﺔ ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﺍﻟﺒﺎﺭﺩ ﺘﺘﻡ ﻋﻠﻰ ﻤﺴﺘﻭﻯ ﻨﻅﺎﻡ ﺍﻟﺘﺸﻐﻴل -3
،ﻓﺒﻌﺩ ﺇﻏﻼﻕ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻴﺘﻡ ﻋﻤل ﻨﺴﺦ ﻟﻤﻠﻔﺎﺕ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻋﻥ ﻁﺭﻴﻕ ﻨﻅﺎﻡ
ﺍﻟﺘﺸﻐﻴل.
:Backupﻭﺍﻗﺼﺩ ﺒﻪ ﻫﻨﺎ ﺍﻟﻤﻠﻔﺎﺕ ﺍﻟﺘﻰ ﻴﺘﻡ ﻋﻤل ﻨﺴﺦ ﺇﺤﺘﻴﺎﻁﻰ ﻟﻬﺎ ) & Datafiles -4
، (Controlfile & Redolog Filesﻫﻨﺎﻙ ﻤﻠﻔﺎﺕ ﺍﺨﺭﻯ ﻴﻤﻜﻥ ﻋﻤل ﻨﺴﺦ
ﺍﺤﺘﻴﺎﻁﻰ ﻟﻬﺎ ﻤﺜل ) (Parameter File & Archivelog File
:No Archivelog Modeﺫﻜﺭﻨﺎ ﺃﻥ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺘﻌﻤل ﻓﻰ ﺍﻻﺼل ﻓﻰ ﺍﻟﻨﻤﻁ No -5
Archive Modeﻭﻫﻭ ﻨﻤﻁ ﻻ ﻴﺴﻤﺢ ﺒﻌﻤل ﺍﺭﺸﻴﻑ ﻟﻤﻠﻔﺎﺕ ﺍل Redo Log
، Fileﻭﻨﺴﺘﻁﻴﻊ ﻋﻤل Cold Backupﻟﻘﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺇﺫﺍ ﻜﺎﻨﺕ ﺘﻌﻤل ﻓﻰ ﻫﺫﺍ
ﺍﻟﻨﻤﻁ.
:Archivelog Modeﻓﻌﻨﺩ ﺘﻬﻴﺌﺔ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻓﻰ ﻫﺫﺍ ﺍﻟﻨﻤﻁ ﻓﺄﻨﻨﺎ ﻨﻀﻤﻥ ﻋﻤل ﺍﺭﺸﻴﻑ -6
ﻟﻤﻠﻔﺎﺕ ﺍل Redo Log Fileﺍﻟﺘﻰ ﻨﺤﺘﺎﺠﻬﺎ ﺍﺜﻨﺎﺀ ﻋﻤﻠﻴﺔ ﺍﻹﺴﺘﺭﺠﺎﻉ )(Recovery
:Simple restoringﻫﻨﺎ ﻻﺒﺩ ﻤﻥ ﺍﻹﺸﺎﺭﺓ ﺇﻟﻰ ﺍﻟﻔﺭﻕ ﺒﻴﻥ )(Restore & Recovery -7
:Restoreﻴﻌﻨﻰ ﻋﻤل ﺍﺴﺘﺭﺠﺎﻉ ﻟﻠﻤﻠﻔﺎﺕ ﺍﻟﺘﻰ ﻓﻘﺩﻨﺎﻫﺎ ﻓﻰ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ
ﻭﺍﺴﺘﺭﺠﺎﻋﻬﺎ ﺍﻟﻰ ﻤﻜﺎﻨﻬﺎ ﺍﻻﺼﻠﻰ.
ﻟﺫﺍ ﺇﺫﺍ ﻜﺎﻨﺕ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺘﻌﻤل ﻓﻰ ﺍﻟﻨﻤﻁ Noarchive Logﻓﺈﻨﻨﺎ ﻻ ﻨﺴﺘﻁﻴﻊ
ﺴﻭﺍ ﺃﻥ ﻨﻘﻭﻡ ﺒﻌﻤل Restoreﻓﻰ ﺤﺎﻟﺔ ﺤﺩﻭﺙ ﻓﺸل ﻓﻰ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ.
83
:Restoring + Recoveringﻭﺫﻟﻙ ﻷﻥ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺘﻌﻤل ﻓﻰ ﺍﻟﻨﻤﻁ Archivelogﻜﻤﺎ -8
ﺫﻜﺭﻨﺎ ﺫﻟﻙ ﻓﻰ ﺍﻟﻔﻘﺭﺓ ﺍﻟﺴﺎﺒﻘﺔ.
:Complete Recoveryﻭﻋﻤﻠﻴﺔ ﺍﻹﺴﺘﺭﺠﺎﻉ Recoveryﺘﻨﻘﺴﻡ ﺇﻟﻰ ﻗﺴﻤﻴﻥ ) Complete -9
(Recovery & Incomplete Recoveryﻭﻨﻌﻨﻰ ﺒﺎلCompleter Recovery
ﺃﻨﻪ ﻨﺴﺘﻁﻴﻊ ﻋﻤل ﺇﺴﺘﺭﺠﺎﻉ ) (Recoveryﻟﻘﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺩﻭﻥ ﺃﻥ ﻨﻔﻘﺩ ﺍﻯ ﺒﻴﺎﻨﺎﺕ ،
ﺍﻭ ﺒﻤﻌﻨﻰ ﺍﺨﺭ ﺃﻨﻨﺎ ﻨﺴﺘﻁﻴﻊ ﺇﺭﺠﺎﻉ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻟﻠﺤﺎل ﺍﻟﺫﻯ ﻜﺎﻨﺕ ﻋﻠﻴﻪ ﻗﺒل ﺤﺩﻭﺙ
ﺍﻟﻔﺸل.
:Possible If -10ﺃﻯ ﺃﻨﻨﺎ ﻨﺴﺘﻁﻴﻊ ﻋﻤل Complete Recoveryﺇﺫﺍ ﻟﻡ ﻨﻔﻘﺩ ﺍلControl File
ﺍﻟﺤﺎﻟﻰ ﻭﺍل Redo Log Fileﺍﻟﺫﻯ ﻟﻡ ﺘﺘﻡ ﺃﺭﺸﻔﺘﻪ ﻭﺍل Archive Log Filesﺍﻟﺫﻯ
ﻨﺤﺘﺎﺠﻪ ﻓﻰ ﻋﻤﻠﻴﺔ ﺍل.Recovery
:Type -11ﺃﻯ ﺃﻨﻨﺎ ﻨﺴﺘﻁﻴﻊ ﺇﻨﺠﺎﺯ ﻋﻤﻠﻴﺔ ﺍل Complete Recoveryﺍﺤﻴﺎﻨ ﹰﺎ ﺩﻭﻥ ﺍﻟﺤﻭﺠﺔ ﻹﻏﻼﻕ
ﻼ ،ﻭﺍﺤﻴﺎﻨﹰﺎ ﻨﺤﺘﺎﺝ
ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻓﻰ ﺤﺎﻟﺔ ﻓﻘﺩﺍﻥ Non-System Data Fileﻤﺜ ﹸ
ﻹﻨﺠﺎﺯ ﺍﻹﺴﺘﺭﺠﺎﻉ ﺒﻌﺩ ﺇﻏﻼﻕ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻓﻰ ﺤﺎﻟﺔ ﻓﻘﺩﺍﻥ ، System datafile
ﺍﻯ ﻫﻨﺎﻙ ﻨﻭﻋﺎﻥ ﻹﻨﺠﺎﺯ ﺍل Complete Recoveryﻭﻫﻤﺎ ) & Online
.(Offline
:Incomplete Recovery -12ﺃﻯ ﺃﻨﻨﺎ ﺴﻨﻔﻘﺩ ﺠﺯﺀ ﻤﻥ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺍﺜﻨﺎﺀ ﻋﻤﻠﻴﺔ ﺍﻹﺴﺘﺭﺠﺎﻉ ﻭﺫﻟﻙ
ﻷﻨﻨﺎ ﻗﺩ ﻨﻜﻭﻥ ﻓﻘﺩﻨﺎ ﺍل Redo Log Fileﺍﻟﺫﻯ ﻟﻡ ﻴﺘﻡ ﺃﺭﺸﻔﺘﻪ ﺃﻭ ﻤﻠﻔﺎﺕ
ﺍل Archivelog Fileﺍﻟﺘﻰ ﻨﺤﺘﺎﺠﻬﺎ ﻓﻰ ﻋﻤﻠﻴﺔ ﺍل , Recoveryﻭﻫﻨﺎﻙ ﺜﻼﺜﺔ
ﺨﻴﺎﺭﺍﺕ ﻓﻰ ﻫﺫﺍ ﺍﻟﻨﻭﻉ ﻤﻥ ﺍلUntil Cancel & Until Time & ) Recovery
.(Until SCN
:Offline -13ﻭﺫﻟﻙ ﻹﻨﻨﺎ ﻓﻘﺩ ﻨﻜﻭﻥ ﻓﻘﺩﻨﺎ ﻓﻘﺩﻨﺎ ﺍل Control Fileﺍﻟﺤﺎﻟﻰ ﺍﻭ ﺍلRedo Log File
ﺍﻟﺫﻯ ﻟﻡ ﻴﺘﻡ ﺃﺭﺸﻔﺘﻪ ﺃﻭ ﻤﻠﻔﺎﺕ ﺍل Archivelog Fileﺍﻟﺘﻰ ﻨﺤﺘﺎﺠﻬﺎ ﻓﻰ ﻋﻤﻠﻴﺔ
ﺍل.Recovery
ﻤﻼﺤﻅﺔ :ﻓﻰ ﺤﺎﻟﺔ ﺍل Incomplete Recoveryﻴﺠﺏ ﻓﺘﺢ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺒﻌﺩ ﺍﻻﺴﺘﺭﺠﺎﻉ ﻓﻰ ﺍﻟﻭﻀﻊ
.Resetlogs
84
(Whenever we open database with ‘resetlogs’ option the
log sequence number set to (zero zero one) 001.
ﻟﻡ ﻴﻌﺩ ﺼﺎﻟﺤﹰﺎ ﺍﻻﻥ ﻟﻌﻤلResetlogs ﺘﻡ ﻭﻀﻌﻪ ﻗﺒل ﻓﺘﺢ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻓﻰ ﺍﻟﻭﻀﻊBackup ﻟﺫﻟﻙ ﺃﻯ
.(001) ﺘﻐﻴﺭ ﺍﻻﻥ ﺍﻟﻰLog Sequence Number ﻭﺫﻟﻙ ﻻﻥRecoveryﺍل
.Resetlogs ﺠﺩﻴﺩ ﺒﻌﺩ ﻓﺘﺢ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻓﻰ ﺍﻟﻭﻀﻊBackup ﻟﺫﺍ ﻴﻨﺼﺢ ﺒﻭﻀﻊ
85
ﺴﻨﺎﺭﻴﻭﻫﺎﺕ ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﻭﺍﻹﺴﺘﺭﺠﺎﻉ ) Backup & Recovery
:(Scenarios
ﻴﺠﺏ ﺍﻟﺘﺫﻜﻴﺭ ﺃﻨﻨﺎ ﻨﺘﺤﺩﺙ ﻫﻨﺎ ﻋﻥ ﺍل ، Cold Backup and Recoveryﻭﺃﻥ ﻋﻤﻠﻴﺔ ﺍﻟﻨﺴﺦ
ﺍﻹﺤﺘﻴﺎﻁﻰ ﺘﻜﻭﻥ ﻋﻠﻰ ﻤﺴﺘﻭﻯ ﻨﻅﺎﻡ ﺍﻟﺘﺸﻐﻴل ﻭﺫﻟﻙ ﺒﻌﺩ ﺇﻏﻼﻕ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ.
ﻭﺍﻟﻴﻙ ﺨﻁﻭﺍﺕ ﻋﻤل ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﺍﻟﺒﺎﺭﺩ ):(Cold Backup
-1ﺇﻏﻼﻕ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ.
-2ﻋﻤل ﻨﺴﺦ ﻋﻥ ﻁﺭﻴﻕ ﻨﻅﺎﻡ ﺍﻟﺘﺸﻐﻴل ﻟﻤﻠﻔﺎﺕ ﺍل Datafilesﻭﺍل Redolog Filesﻭﺍل Control
.Files
ﻗﻤﻨﺎ ﺒﻌﻤل ﻨﺴﺦ ﻟﻤﻠﻔﺎﺕ ﺍل Datafilesﻭﺍل Redolog Filesﻭﺍل Control Filesﻟﻘﺎﻋﺩﺓ -3
ﺍﻟﺒﻴﺎﻨﺎﺕ ORCLﻭﻻﺤﻅ ﻤﻌﻰ ﺍﻥ ﺠﻤﻴﻊ ﻤﻠﻔﺎﺕ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺘﻭﺠﺩ ﻓﻰ ﺍﻟﻤﺴﺎﺭ
\ D:\oracle\product\10.1.0\oradata\orclﻭﻴﺠﺏ ﺍﻟﺘﺄﻜﺩ ﻜﺫﻟﻙ ﻤﻥ ﺍﻟﻤﺴﺎﺭ ﺍﻟﺫﻯ ﺴﻴﺘﻡ ﻓﻴﻪ
ﻭﻀﻊ ﺍل Backupﻭﻫﻭ ﻜﻤﺎ ﻓﻰ ﺍﻟﺼﻭﺭﺓ \.D:\backup
ﻫﻜﺫﺍ ﻭﺒﻜل ﺒﺴﺎﻁﺔ ﻗﻤﻨﺎ ﺒﻌﻤل ﻨﺴﺦ ﺇﺤﺘﻴﺎﻁﻰ ﺒﺎﺭﺩ ) (Cold Backupﻟﻘﺎﻋﺩﺓ ﺍﻟﺒﻴﻴﺎﻨﺎﺕ ، ORCLﻜﻤﺎ ﻴﻤﻜﻥ
ﺘﻀﻤﻴﻥ ﻤﻠﻔﺎﺕ ﺍل Parameter Fileﻭﺍﻻﺭﺸﻴﻑ ﻓﻰ ﻋﻤﻠﻴﺔ ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ.
86
ﻟﻨﻔﺘﺭﺽ ﺃﻥ ﻫﺫﺍ ﺍل Backupﻗﻤﻨﺎ ﺒﻪ ﻴﻭﻡ ﺍﻻﺤﺩ ﺼﺒﺎﺤﹰﺎ ،ﻭﺃﻥ ﺠﻤﻴﻊ ﺍﻟﺴﻨﺎﺭﻴﻭﻫﺎﺕ ﺍﻟﺘﻰ ﺴﻨﺫﻜﺭﻫﺎ ﻻﺤﻘ ﹰﺎ
ﻟﻌﻤﻠﻴﺎﺕ ﺍﻹﺴﺘﺭﺠﺎﻉ ﺴﻨﺴﺘﺨﺩﻡ ﻓﻴﻬﺎ ﻫﺫﺍ ﺍل ، Backupﺇﺫﹰﺍ ﺴﻨﺴﺘﺼﺤﺏ ﻤﻌﻨﺎ ﻫﺫﺍ ﺍل Backupﻓﻰ ﺠﻤﻴﻊ
ﺍﻟﺴﻨﺎﺭﻴﻭﻫﺎﺕ.
ﻭﺠﻤﻴﻊ ﺍﻟﺴﻨﺎﺭﻴﻭﻫﺎﺕ ﺍﻟﺘﻰ ﺴﻨﺫﻜﺭﻫﺎ ﻫﻰ ﻟﻘﺎﻋﺩﺓ ﺒﻴﺎﻨﺎﺕ ﺘﻌﻤل ﻓﻰ ﺍﻟﻨﻤﻁ Archivelog Modeﻭﺫﻟﻙ ﻷﻥ
ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺍﻟﺘﻰ ﺘﻌﻤل ﻓﻰ ﺍﻟﻨﻤﻁ Noarchivelog Modeﻟﺩﻴﻬﺎ ﺴﻨﺎﺭﻴﻭ ﻭﺍﺤﺩ ﻓﻘﻁ ﻭﻫﻭ ﻓﻰ ﺤﺎﻟﺔ
ﺤﺩﻭﺙ ﻓﺸل ﻓﻰ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻭﻤﻬﻤﺎ ﻜﺎﻥ ﺍﻟﻔﺸل ﻓﺈﻨﻨﺎ ﺴﻭﻑ ﻨﻘﻭﻡ ﺒﻌﻤل Restoreﻟﺠﻤﻴﻊ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ
ﻭﻻ ﻨﺴﺘﻁﻴﻊ ﻋﻤل Recoveryﻟﻌﺩﻡ ﻭﺠﻭﺩ ﻤﻠﻔﺎﺕ ﺍﻻﺭﺸﻴﻑ.
ﺇﺫﺍ ﻓﻰ ﺤﺎﻟﺔ ﺤﺩﻭﺙ ﻓﺸل ﻟﻘﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻭﻫﻰ ﺘﻌﻤل ﻓﻰ ﺍﻟﻨﻤﻁ Noarchivelog Modeﻓﻘﻁ ﺴﻨﻘﻭﻡ
ﺒﺈﻏﻼﻕ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻓﻭﺭﹰﺍ ﻭﻤﻥ ﺜﻡ ﻋﻤل ﻨﺴﺦ ﻟﻤﻠﻔﺎﺕ ﺍل Backupﻭﻭﻀﻌﻬﺎ ﻓﻰ ﻤﻭﻀﻌﻬﺎ ﺍﻻﺼﻠﻰ،
ﻭﻴﺠﺏ ﺃﻥ ﻴﻜﻭﻥ ﺍل Restoreﻟﺠﻤﻴﻊ ﺍﻟﻤﻠﻔﺎﺕ .((Control Files + Redolog Files + Data Files
ﻭﻋﻠﻴﻪ ﻓﺈﻥ ﺠﻤﻴﻊ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺍﻟﺘﻰ ﺘﻡ ﺘﺨﺯﻴﻨﻬﺎ ﻓﻰ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺒﻌﺩ ﺍﺨﺭ Backupﺴﺘﻜﻭﻥ ﻓﻘﺩﺕ ﻭﻴﺠﺏ
ﺇﺩﺨﺎﻟﻬﺎ ﻤﻥ ﺠﺩﻴﺩ.
ﻫﺫﺍ ﻫﻭ ﺍﻟﺴﻨﺎﺭﻴﻭ ﻟﺠﻤﻴﻊ ﺤﺎﻟﺔ ﺍﻟﻔﺸل ﻟﻘﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺍﻟﺘﻰ ﺘﻌﻤل ﻓﻰ ﺍﻟﻨﻤﻁ No archivelogﻭﻫﻭ Simple
.Restore
87
ﺍﻟﺴﻨﺎﺭﻴﻭ ﺍﻻﻭل ):(Full Database Recovery
ﻓﻰ ﻫﺫﺍ ﺍﻟﺴﻨﺎﺭﻴﻭ ﻨﻔﺘﺭﺽ ﺍﻨﻨﺎ ﻓﻘﺩﻨﺎ ﺠﻤﻴﻊ ﻤﻠﻔﺎﺕ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ) Data Files & Redolog
، (Files & Control Filesﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺘﻌﻤل ﻓﻰ ﺍﻟﻨﻤﻁ .Archivelog Mode
ﺒﺎﻟﻁﺒﻊ ﻴﻤﻜﻨﻙ ﻤﻌﺭﻓﺔ ﺍﻯ ﻤﺸﻜﻠﺔ ﺘﺤﺼل ﻟﻘﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺒﻭﺍﺴﻁﺔ ﺍﻟﻤﻠﻑ Alert.logﺍﻭ ﻤﻠﻔﺎﺕ file.trcﺍﻭ
ﺒﻭﺍﺴﻁﺔ ﺍﻟﺭﺴﺎﺌل ﺍﻟﺘﻰ ﺘﺭﺴل ﺒﻭﺍﺴﻁﺔ .Oracle Server
*D:\>COPY D:\BACKUP\*.
\D:\oracle\product\10.1.0\oradata\orcl
88
.Mount ﺘﺸﻐﻴل ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻓﻰ ﺍﻟﻭﻀﻊ-2
D:\>STARTUP MOUNT
ﻓﺈﻨﻨﺎCurrent online Redolog File ﻟﻘﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻭﻟﻜﻥ ﺒﻤﺎ ﺃﻨﻨﺎ ﻓﻘﺩﻨﺎRecovery ﻋﻤل-3
Complete ﻜﻤﺎ ﺫﻜﺭﻨﺎ ﺴﺎﺒﻘﹰﺎ ﻭﺫﻟﻙ ﻷﻥ ﺍلIncomplete recovery ﺴﻭﻑ ﻨﻘﻭﻡ ﺒﻌﻤل
.Current online Redolog File ﻴﺤﺘﺎﺝ ﺍﻟﻰRecovery
D:\>RECOVER CANCEL
89
ﻭﺫﻟﻙ ﻷﻨﻨﺎ ﻗﻤﻨﺎ ﺒﻌﻤل ، Incomplete Recoveryﻭﻻ ﻨﺴﺘﻁﻴﻊ ﻓﺘﺢ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺒﻌﺩ ﻋﻤﻠﻴﺔ ﺍل
Incomplete Recoveryﺇﻻ ﻓﻰ ﺍﻟﻭﻀﻊ .RESETLOGS
ﻫﻜﺫﺍ ﺍﻨﺠﺯﻨﺎ ﻋﻤﻠﻴﺔ ﺍﻹﺴﺘﺭﺠﺎﻉ ﻭﻟﻜﻥ ﻴﺠﺏ ﻋﻠﻴﻙ ﺍﻻﻥ ﻭﻀﻊ Backupﺠﺩﻴﺩ ﻭﺫﻟﻙ ﻻﻥ ﺠﻤﻴﻊ ﻤﻠﻔﺎﺕ
ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﺍﻟﺘﻰ ﺘﻡ ﻭﻀﻌﻬﺎ ﻗﺒل ﻋﻤﻠﻴﺔ ﻓﺘﺢ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻓﻰ ﺍﻟﻭﻀﻊ RESETLOGSﻟﻡ ﺘﻌﺩ
ﺫﺍﺕ ﺠﺩﻭﻯ ﻜﻤﺎ ﺫﻜﺭﻨﺎ ﺫﻟﻙ ﺴﺎﺒﻘﹰﺎ.
90
ﺍﻟﺴﻨﺎﺭﻴﻭ ﺍﻟﺜﺎﻨﻰ ):(Loss of a Non-SYSTEM Data File
ﻟﺤﻅﺔ ﻭﻫﻭ Datafileﻻ ﻴﻨﺘﻤﻰ ل System Tablespaceﺍﻭ ، Undo Tablespace
ﻓﻘﺩﺍﻥ Non-SYSTEM datafileﺍﻟﻤﺴﺘﺨﺩﻤﻭﻥ ﻴﺴﺘﻘﺒﻠﻭﻥ ﺭﺴﺎﺌل ﺨﻁﺄ ﺘﻔﻴﺩ ﺒﻔﻘﺩﺍﻥ ﺍل Datafileﻜﻤﺎ
ﻴﻤﻜﻥ ﺍﻨﺠﺎﺯ ﻋﻤﻠﻴﺔ ﺍﻹﺴﺘﺭﺠﺎﻉ ﺩﻭﻥ ﺇﻏﻼﻕ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ Online Recoveryﻭﻻ ﻴﺘﺎﺜﺭ ﺍﻟﻤﺴﺘﺨﺩﻤﻭﻥ
ﺍﻟﺫﻴﻥ ﻴﻌﻤﻠﻭﻥ ﻋﻠﻰ ﺍل Tablespacesﺍﻻﺨﺭﻯ ،ﻓﺴﻴﺴﺘﻤﺭﻭﻥ ﻓﻰ ﺍﻟﻌﻤل ﺍﺜﻨﺎﺀ ﻋﻤﻠﻴﺔ ﺍﻹﺴﺘﺭﺠﺎﻉ.
ﺒﺎﻟﻁﺒﻊ ﻴﻤﻜﻥ ﺇﻨﺠﺎﺯ ﻋﻤﻠﻴﺔ ﺍﻹﺴﺘﺭﺠﺎﻉ Recoveryﺩﻭﻥ ﺇﻏﻼﻕ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺍﻭ ﺒﻌﺩ ﺇﻏﻼﻗﻬﺎ
) (Online or Offlineﻭﻟﻜﻥ ﺒﺎﻟﻁﺒﻊ ﻋﻤﻠﻴﺔ ﺍﻹﺴﺘﺭﺠﺎﻉ ﺩﻭﻥ ﺇﻏﻼﻕ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻤﺴﺘﺤﻴﻠﺔ ﺇﺫﺍ ﻓﻘﺩﻨﺎ
Datafileﻴﻨﺘﻤﻰ ﻟل.System Tablespace
ﻭﻟﻨﻔﺘﺭﺽ ﻓﻰ ﻫﺫﺍ ﺍﻟﺴﻨﺎﺭﻴﻭ ﺃﻨﻨﺎ ﻓﻘﺩﻨﺎ ﺍل USERS01.DBF Datafileﺍﻟﺫﻯ ﻴﻨﺘﻤﻰ ﺍﻟﻰ
.USERS TABLESPACE
ﻭﻹﻨﺠﺎﺯ ﻋﻤﻠﻴﺔ ﺍﻹﺴﺘﺭﺠﺎﻉ ﻟﻬﺫﺍ ﺍﻟﺴﻨﺎﺭﻴﻭ ﻫﻨﺎﻙ ﻁﺭﻴﻘﺘﻴﻥ -:
91
. USERS01.DBF DATAFILE ONLINE ﺜﻡ ﻨﻘﻭﻡ ﺒﻭﻀﻊ ﺍل-4
92
-:(Tablespace Recovery) ﺍﻟﻁﺭﻴﻘﺔ ﺍﻟﺜﺎﻨﻴﺔ
-:ﻫﻨﺎ ﻨﻘﻭﻡ ﺒﻌﺩﺓ ﺨﻁﻭﺍﺕ
ﺍﻯ ﻋﻤل ﻨﺴﺦ ﻟﻠﻤﻠﻑ ﻤﻥ ﺍﺨﺭ، Backup ﻓﻘﻁ ﻤﻥ ﺍﺨﺭUSERS01.DBF ﻟلRestore ﻋﻤل-1
. ﺍﻟﻰ ﻤﻭﻀﻌﻪ ﺍﻻﺼﻠﻰBackup
.USERS TABLESPACE OFFLINE ﻨﻘﻭﻡ ﺒﻭﻀﻊ ﺍل-2
93
ﻴﻤﻜﻨﻙ ﺇﺴﺘﺨﺩﺍﻡ ﺍﻯ ﻤﻥ ﻫﺫﻩ ﺍﻟﻁﺭﻴﻘﺘﻴﻥ ﻟﻤﻌﺎﻟﺠﺔ ﻫﺫﺍ ﺍﻟﺴﻨﺎﺭﻴﻭ ،ﻭﻟﻜﻥ ﻋﻤﻭﻤﹰﺎ ﻟﻥ ﺘﻔﻘﺩ ﺍﻯ ﻤﻥ
ﺒﻴﺎﻨﺎﺘﻙ ﻤﺎ ﺩﺍﻡ ﺍﻨﻙ ﻟﻡ ﺘﻔﻘﺩ Present Controlfileﻭﺍل ، Current Redo Logfileﺍﻯ ﺍﻨﻨﺎ ﻓﻰ ﻜل
ﺍﻻﺤﻭﺍل ﺴﻨﻘﻭﻡ ﺒﻌﻤل .Complete Recovery
94
ﺍﻟﺴﻨﺎﺭﻴﻭ ﺍﻟﺜﺎﻟﺙ ):(Loss of a SYSTEM Data File
ﺘﺨﻴل ﻤﻌﻰ ﻓﻰ ﻫﺫﺍ ﺍﻟﺴﻨﺎﺭﻴﻭ ﺍﻨﻙ ﻓﻘﺩﺕ ﺍل SYSTEM01.DBF DATAFILEﺍﻟﺫﻯ ﻴﻨﺘﻤﻰ
ﻟل ، SYSTEM TABLESPACEﻤﺎﻟﺫﻯ ﺘﺘﻭﻗﻊ ﺃﻥ ﻴﺤﺩﺙ ﺒﺎﻟﻁﺒﻊ ﺴﻭﻑ ﻴﺘﻡ ﺇﻏﻼﻕ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺍﻟﻴﹰﺎ
،ﺤﺘﻰ ﻟﻭ ﻅﻠﺕ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻤﻔﺘﻭﺤﺔ ﻴﺠﺏ ﺇﻏﻼﻗﻬﺎ ﻓﻭﺭﹰﺍ ، SHUT ABORTﺇﺫ ﻻ ﻴﺘﺼﻭﺭ ﺍﻥ ﺘﻌﻤل
ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺩﻭﻥ ﺍل ، SYSTEM TABLESPACEﻫﺫﺍ ﺍﻟﺴﻨﺎﺭﻴﻭ ﻴﻨﻁﺒﻕ ﺍﻴﻀﹰﺎ ﺇﺫﺍ ﻓﻘﺩﻨﺎ
ﺍل.ACTIVE UNDO TABLEESPACE
ﺍﻟﺨﻁﻭﺍﺕ ﺍﻟﻼﺯﻤﺔ-:
-1ﺇﻏﻼﻕ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻓﻭﺭﹰﺍ ﺇﺫﺍ ﻅﻠﺕ ﻤﻔﺘﻭﺤﺔ.
SHUT ABORT
STARTUP MOUNT
95
SYSTEM01.DBF DATAFILE ﻟلRECOVERY ﻋﻤل-4
Recoveryﻻﺤﻅ ﻤﻌﻰ ﺍﻟﻔﺭﻕ ﺒﻴﻥ ﻫﺫﺍ ﺍﻟﺴﻨﺎﺭﻴﻭ ﻭﺍﻟﺫﻯ ﻗﺒﻠﻪ ﻫﻨﺎ ﻻﺒﺩ ﻤﻥ ﺇﻏﻼﻕ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻗﺒل ﻋﻤل ﺍل
.ﻋﻠﻰ ﻋﻜﺱ ﺍﻟﺴﻨﺎﺭﻴﻭ ﺍﻟﺫﻯ ﻗﺒﻠﻪ
96
ﺍﻟﺴﻨﺎﺭﻴﻭ ﺍﻟﺭﺍﺒﻊ ):(Loss of an Un-archived Online Log Files
ﺘﺼﻭﺭ ﻤﻌﻰ ﺃﻨﻙ ﺘﻌﻤل ﻋﻠﻰ ﻗﺎﻋﺩﺓ ﺒﻴﺎﻨﺎﺘﻙ ﻭﻓﺠﺎﺓ ﺤﺩﺙ ﻓﺸل ﻓﻰ ﺍﻟﺩﻴﺴﻙ ﻤﻤﺎ ﺘﺴﺒﺏ ﻓﻰ ﻓﻘﺩ ﺠﻤﻴﻊ
ﺍل ، Online Log Filesﻤﻊ ﺍﻟﻌﻠﻡ ﺃﻨﻙ ﻟﻡ ﺘﻔﻘﺩ ﺍﻯ ﻤﻥ ﺍل ، Control Files and data Filesﻟﻜﻥ ﻓﻰ
ﺍﻟﺤﻘﻴﻘﺔ ﺍﻨﻨﺎ ﻻ ﻨﺴﺘﻁﻴﻊ ﻋﻤل Recoveryﻟﻘﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻤﺎﺩﺍﻡ ﺃﻨﻨﺎ ﻓﻘﺩﻨﺎ all online filesﻭﺫﻟﻙ ﻻﻨﻨﺎ
ﻨﺤﺘﺎﺝ ﺍﻟﻴﻪ ﻓﻰ ﻋﻤﻠﻴﺔ ﺍل ، Recoveryﻓﻤﺎ ﺍﻟﺤل ﺇﺫﹰﺍ ؟ ﺍﻟﻴﻙ ﺍﻟﺨﻁﻭﺍﺕ.
STARTUP MOUNT
;Recover cancel
97
-5ﻓﺘﺢ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻓﻰ ﺍﻟﻭﻀﻊ .RESETLOGS
ﻋﻨﺩ ﻓﺘﺢ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻓﻰ ﺍﻟﻨﻤﻁ RESTLOGSﻴﻘﻭﻡ ﺍﻻﻭﺭﻜل ﺍﻟﻴﹰﺎ ﺒﺈﻨﺸﺎﺀ ONLINE LOG FILES
ﻭﻴﻤﻜﻥ ﻤﺸﺎﻫﺩﺓ ﺫﻟﻙ ﻋﻥ ﻁﺭﻴﻕ ﻨﻅﺎﻡ ﺍﻟﺘﺸﻐﻴل ﺍﻭ ﻤﻥ ﺨﻼل ﺍﻹﺴﺘﻌﻼﻡ ﺍﻻﺘﻰ:
ﻟﻜﻥ ﺘﺨﻴل ﻤﻌﻰ ﺃﻨﻪ ﻜﺎﻥ ﻟﺩﻴﻙ Multiplexing the log filesﻋﻠﻰ ﻋﺩﺩ ﻤﻥ ﺍﻟﺩﺴﻴﻙ ﻟﻜﻥ ﻓﻰ ﻏﻨﻰ ﻤﻥ ﻜل
ﻫﺫﺍ ﺍﻟﻤﺠﻬﻭﺩ ﻹﺭﺠﺎﻉ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻭﻗﺩ ﺘﻜﻭﻥ ﻓﻘﺩﺕ ﺠﺯﺀ ﻤﻥ ﺒﻴﺎﻨﺎﺘﻙ.
98
ﺍﻟﺴﻨﺎﺭﻴﻭ ﺍﻟﺨﺎﻤﺱ ):(Loss of Control Files
ﻓﻰ ﻫﺫﺍ ﺍﻟﺴﻨﺎﺭﻴﻭ ﺘﺼﻭﺭ ﻤﻌﻰ ﺃﻨﻙ ﻓﻘﺩ ﺠﻤﻴﻊ ﻤﻠﻔﺎﺕ ﺍل ، Control Filesﺒﺎﻟﻁﺒﻊ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻻ
ﺘﻌﻤل ﺩﻭﻥ ﻭﺠﻭﺩ ﺍل ، Control Fileﻭﻟﻭ ﺃﻨﻙ ﻓﻘﺩﺕ ﺍﺤﺩ ﻤﻠﻔﺎﺕ ﺍل Control Fileﻟﻜﺎﻥ ﺍﻻﻤﺭ ﺴﻬل ؛
ﻓﻨﻘﻭﻡ ﺒﻌﻤل ﻨﺴﺦ ﻻﺤﺩ ﻤﻠﻔﺎﺕ ﺍل Control Filesﺍﻟﻤﻭﺠﻭﺩﺓ ﻭﻨﻀﻌﻪ ﻤﻜﺎﻥ ﺍﻟﻤﻠﻑ ﺍﻟﻤﻔﻘﻭﺩ ﻭﻟﻜﻥ ﻫﻨﺎ
ﻓﻘﺩﻨﺎ ﺠﻤﻴﻊ ﻤﻠﻔﺎﺕ ﺍل ، Control Filesﺒﺎﻟﻁﺒﻊ ﺴﺘﺘﻭﻗﻑ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻋﻥ ﺍﻟﻌﻤل ﻭﺇﺫﺍ ﻟﻡ ﺘﺘﻭﻗﻑ
ﻴﺠﺏ ﺇﻴﻘﺎﻓﻬﺎ ﻓﻭﺭﹰﺍ ) (Shut Abortﺍﻟﻰ ﺤﻴﻥ ﻋﻤل ﺇﺠﺭﺍﺀ ﺴﺭﻴﻊ ﻹﻨﻘﺎﺫ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ.
ﻓﻰ ﻤﺜل ﻫﺫﺍ ﺍﻟﺴﻨﺎﺭﻴﻭ ﻫﻨﺎﻙ ﺨﻴﺎﺭﻴﻥ ﻟﻺﻨﻘﺎﺫ-:
ﺍﻟﺨﻴﺎﺭ ﺍﻻﻭل -:
ﻨﻘﻭﻡ ﺒﺈﻨﺸﺎﺀ Control Fileﻤﻥ ﺠﺩﻴﺩ ﺒﺈﺴﺘﺨﺩﺍﻡ ﺍﻟﻜﻭﺩ ، Create Controlfileﻭﺫﻟﻙ
ﺒﻤﺴﺎﻋﺩﺓ ﺍل Trace Control Fileﺇﻥ ﻭﺠﺩ ،ﻭﺍﻻﻓﻀل ﻟﻤﺩﻴﺭ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺃﻥ ﻴﻘﻭﻡ ﺒﻌﻤل Backup
Controlfile To traceﻜل ﻤﺎ ﻗﺎﻡ ﺒﺘﻐﻴﺭ ﻫﻴﻜﻠﺔ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺤﺘﻰ ﻴﺴﺘﻔﻴﺩ ﻤﻥ ﻤﻠﻑ ﺍل Traceﻓﻰ
ﺇﻨﺸﺎﺀ ﺍل Control Fileﻻﺤﻘﹰﺎ ﻓﻰ ﺤﺎل ﺍﻨﻨﺎ ﻓﻘﺩﻨﺎ ﺠﻤﻴﻊ ﻤﻠﻔﺎﺕ ﺍل .Control Filesﻭﻟﻜﻥ ﺤﺘﻰ ﻟﻭ ﻟﻡ
ﻴﻘﻡ ﻤﺩﻴﺭ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺒﻬﺫﺍ ﺍﻹﺠﺭﺍﺀ ﻓﻴﻤﻜﻨﻪ ﺍﻟﻘﻴﺎﻡ ﺒﺈﻨﺸﺎﺀ ﻤﻠﻑ ﺍل Control Fileﻋﻥ ﻁﺭﻴﻕ ﻜﺘﺎﺒﺔ
ﺍﻟﻜﻭﺩ ﻴﺩﻭﻴﹰﺎ ﺤﺴﺏ ﻫﻴﻜﻠﺔ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ.
ﻴﻨﺘﺞ ﻤﻥ ﻫﺫﺍ ﺍﻻﺠﺭﺍﺀ Trace Fileﻭﻫﻭ ﻋﺒﺎﺭﺓ ﻋﻥ ﻤﻠﻑ ﻨﺼﻰ ﻴﺤﻭﻯ ﻜﻭﺩ ﺇﻨﺸﺎﺀ ﺍلControl File
ﻴﻤﻜﻥ ﺇﺴﺘﺨﺩﺍﻤﻪ ﻻﺤﻘﹰﺎ ﻹﻨﺸﺎﺀ ﺍل Control Fileﻋﻨﺩﻤﺎ ﻨﺤﺘﺎﺝ ﺇﻟﻰ ﺫﻟﻙ ،ﻭﻴﺠﺩ ﻫﺫﺍ ﺍﻟﻤﻠﻑ ﻓﻰ ﺍﻟﻤﺴﺎﺭ
ﺍﻟﻤﺤﺩﺩ ﻋﻠﻰ ﺍﻟﻤﺘﻐﻴﺭ .USER_DUMP_DEST
99
ﻭﺍﻟﻴﻙ ﺨﻁﻭﺍﺕ ﺇﻨﺸﺎﺀ :Control File
-1ﺘﺸﻐﻴل ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻓﻰ ﺍﻟﻭﻀﻊ .NOMOUNT
STARTUP NOMOUNT
-2ﻨﻘﻭﻡ ﺒﻜﺘﺎﺒﺔ ﺍﻭ ﺘﺠﻬﻴﺯ ﻜﻭﺩ ﺇﻨﺸﺎﺀ ﺍل Control Fileﻤﻥ ﻤﻠﻑ ﺍل Traceﺇﻥ ﻭﺠﺩ ﺍﻭ ﻜﺘﺎﺒﺘﻪ
ﻼ ﻟﻤﻠﻑ ﻴﺤﻭﻯ ﻜﻭﺩ ﺇﻨﺸﺎﺀ ﺍل Control Fileﻗﻤﺕ ﺒﻨﺴﺨﻪ ﻤﻥ ﻤﻠﻑ
ﻴﺩﻭﻴﹰﺎ ،ﻭﺍﻟﻴﻙ ﻤﺜ ﹰ
ﺍل Trace Fileﻭﺤﻔﻅﺘﻪ ﻓﻰ ﻤﻠﻑ ﺴﻤﻴﺘﻪ CONT.SQLﻤﻭﺠﻭﺩ ﻓﻰ ﺍل.C
100
@C:\CONT.SQL
101
ﺍﻟﺨﻴﺎﺭ ﺍﻟﺜﺎﻨﻰ -:
ﻫﻨﺎ ﻨﻘﻭﻡ ﺒﺈﺴﺘﺭﺠﺎﻉ ﻤﻠﻑ ﺍل Control Fileﻤﻥ ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ.
ﻭﺍﻟﻴﻙ ﺍﻟﺨﻁﻭﺍﺕ-:
-1ﻨﻘﻭﻡ ﺒﻌﻤل Restoreﻟﻤﻠﻔﺎﺕ ﺍل Control Fileﻤﻥ ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ.
-2ﺜﻡ ﻨﻔﺘﺢ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻓﻰ ﺍﻟﻭﻀﻊ .MOUNT
STARTUP MOUNT
ﻻﺤﻅ ﻤﻌﻰ ﺍﻨﻪ ﺒﻌﺩ ﺒﺩﺀ ﻋﻤﻠﻴﺔ ﺍﻹﺴﺘﺭﺠﺎﻉ ﻗﺩ ﻨﺤﺘﺎﺝ ﻟﺘﺤﺩﻴﺩ ﺍل Redolog Filesﻹﻜﻤﺎل
ﻋﻤﻠﻴﺔ ﺍﻹﺴﺘﺭﺠﺎﻉ ﺍﻭ ﻨﻘﻭﻡ ﺒﻌﻤل ﺫﻟﻙ ﺍﻟﻴﹰﺎ ﺒﻜﺘﺎﺒﺔ ﺍﻟﺨﻴﺎﺭ ، AUTOﻭﻫﻨﺎﻙ ﺨﻴﺎﺭ ﺍﺨﺭ
ﻫﻭ CANCELﻹﻨﻬﺎﺀ ﻋﻤﻠﻴﺔ ﺍﻹﺴﺘﺭﺠﺎﻉ ،ﻟﻜﻥ ﺇﺫﺍ ﻗﻤﺕ ﺒﻜﺘﺎﺒﺔ Redolog Fileﻨﻘﻭﻡ
ﺒﺈﻋﺎﺩﺓ ﺍﻟﺨﻁﻭﺓ ﻤﺭﺓ ﺍﺨﺭﻯ ﺒﺘﺤﺩﻴﺩ ﺍل Redolog Filesﺍﻻﺨﺭﻯ.
[Must be current redolog file , else repeat this
]steps with other redolog groups member
102
.RESETLOGS ﺍﺨﻴﺭﹰﺍ ﻨﻔﺘﺢ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻓﻰ ﺍﻟﻭﻀﻊ-4
103
ﺍﻟﺴﻨﺎﺭﻴﻭ ﺍﻟﺴﺎﺩﺱ ):(Loss of unbackup Datafile
ﺘﺼﻭﺭ ﻤﻌﻰ ﺃﻨﻙ ﻗﻤﺕ ﺒﻌﻤل ﺍﺨﺭ ﻨﺴﺦ ﺇﺤﺘﻴﺎﻁﻰ ﻴﻭﻡ ﺍﻻﺜﻨﻴﻥ ﻤﺴﺎﺀ ﺜﻡ ﻗﻤﺕ ﺒﺈﻨﺸﺎﺀ
Tablespaceﺠﺩﻴﺩ ﻓﻰ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻴﻭﻡ ﺍﻟﺜﻼﺜﺎﺀ ،ﻭﻗﺒل ﺃﻥ ﺘﻘﻭﻡ ﺒﻌﻤل ﻨﺴﺦ ﺇﺤﺘﻴﺎﻁﻰ ﺤﺩﺙ ﻓﺸل ﻓﻰ
ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻭﻓﻘﺩﺕ ﻤﻠﻑ ﺍل Datafileﺍﻟﻤﻨﺘﻤﻰ ﻟل Tablespaceﺍﻟﺠﺩﻴﺩ
ﻓﻤﺎ ﺍﻟﻌﻤل؟ ﻻ ﺸﻙ ﺃﻥ ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﻻ ﻴﻔﻴﺩﻙ ﻜﺜﻴﺭﹰﺍ ﺇﺫ ﺃﻥ ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﺘﻡ ﻭﻀﻌﻪ ﻗﺒل
ﺇﻨﺸﺎﺀ ﺍل Tablespaceﺍﻟﺠﺩﻴﺩ ﻭﺍﻟﺫﻯ ﻨﺭﻴﺩ ﺇﺴﺘﺭﺠﺎﻋﻪ.
104
.Test Datafile ﻟلRecovery ﻋﻤل-3
105
ﺍﻟﺴﻨﺎﺭﻴﻭ ﺍﻟﺴﺎﺒﻊ ) :(damage Tempfile
ﻭﻟﻨﻔﺘﺭﺽ ﺃﻥ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻋﻨﺩﻙ ﺘﻌﻤل ﻋﻠﻰ Temporary Tablespaceﻴﺴﻤﻰ Tempﻭﻴﺤﻭﻯ
Tempfileﻭﺍﺤﺩ ﻴﺴﻤﻰ . Temp02.dbfﻭﻟﻨﻔﺘﺭﺽ ﺍﻨﻪ ﺤﺩﺙ ﻋﻁل ﻓﻰ ﻫﺫﺍ ﺍل ، Datafileﻤﺎﺫﺍ
ﺴﻴﺤﺩﺙ ﻟﻘﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ؟ ﺴﺘﻅل ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺘﻌﻤل ﻭﺫﻟﻙ ﻻﻥ ﻤﻬﻤﺔ ﻫﺫﺍ ﺍل Datafileﻫﻭ ﻟﺘﺨﺯﻴﻥ
ﺍﻟﺒﻴﺎﻨﺎﺕ ﺍﻟﻤﺅﻗﺘﺔ ،ﻭﺍﻓﻀل ﺤل ﻟﻬﺫﺍ ﺍﻟﺴﻨﺎﺭﻴﻭ ﻫﻭ ﺇﻨﺸﺎﺀ Datafileﺠﺩﻴﺩ ﻟﻨﻔﺱ ﺍل.Tabespace
ﻭﺍﻟﻴﻙ ﺍﻟﺨﻁﻭﺍﺕ-:
-1ﻗﻡ ﺒﻌﻤل ﺍﻹﺴﺘﻌﻼﻡ ﺍﻻﺘﻰ ﻟﺘﺤﺩﻴﺩ ﺍل Temporary Tablespaceﺍﻟﺫﻯ ﻴﻌﻤل ﺍﻻﻥ ﻓﻰ ﻗﺎﻋﺩﺓ
ﺍﻟﺒﻴﺎﻨﺎﺕ.
106
Tempfile ﻭﻫﻭ ﺍلOffline ﻓﻰ ﺍﻟﻭﻀﻊTEMP02.DBF DATAFILE ﺜﻡ ﻨﻘﻭﻡ ﺒﻭﻀﻊ ﺍل-3
.ﺍﻟﺫﻯ ﺤﺩﺙ ﻓﻴﻪ ﻋﻁل
. ﻭﻜﺫﻟﻙ ﻴﻤﻜﻥ ﺤﺫﻓﻪ ﻋﻥ ﻁﺭﻴﻕ ﻨﻅﺎﻡ ﺍﻟﺘﺸﻐﻴلTemp File ﺍﺨﻴﺭﹰﺍ ﻴﻤﻜﻥ ﺍﻹﺴﺘﻌﻼﻡ ﻋﻥ ﺍل-4
107
ﺍﻟﺴﻨﺎﺭﻴﻭ ﺍﻟﺜﺎﻤﻥ ) :(damage Temporary Tablespace
ﻤﺎ ﻫﻭ ﺍﻓﻀل ﺍﻟﺤﻠﻭل ﻟﻤﺩﻴﺭ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺍﻟﺫﻯ ﺤﺩﺙ ﻟﻪ ﻋﻁل ﻓﻰ ﺍل Temporary
، Tablespaceﺒﺎﻟﻤﻨﺎﺴﺒﺔ ﻗﺩ ﻴﻜﻭﻥ ﻓﻰ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺍﻜﺜﺭ ﻤﻥ Temporary Tablespaceﻟﻜﻥ ﺍﻟﻨﺸﻁ
ﺤﻘﻴﻘﺘﹰﺎ ﻴﻜﻭﻥ Temporary Tablespaceﻭﺍﺤﺩ.
ﻟﻨﻔﺘﺭﺽ ﺃﻥ ﻋﻁل ﺤﺩﺙ ﻟل Temp Temporary Tablespaceﺍﺜﻨﺎﺀ ﻋﻤل ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ،ﻓﻤﺎ ﻫﻰ
ﺍﻟﺨﻁﻭﺍﺕ ﺍﻟﺘﻰ ﻴﺠﺏ ﻋﻤﻠﻬﺎ ﻟﻠﺨﺭﻭﺝ ﻤﻥ ﻫﺫﺍ ﺍﻟﻤﻭﻗﻑ؟
-1ﺇﻨﺸﺎﺀ Temporary Tablespaceﺠﺩﻴﺩ ﻭﻟﻨﺴﻤﻴﻪ .Temp1
-2ﻓﻰ ﺍﻟﺨﻁﻭﺓ ﺍﻟﺴﺎﺒﻘﺔ ﻗﻤﺕ ﺒﺈﻨﺸﺎﺀ Temporary Tablespaceﺠﺩﻴﺩ ﻭﻟﻜﻥ ﻓﻰ ﻫﺫﻩ ﺍﻟﺨﻁﻭﺓ ﻴﺠﺏ
ﻋﻤل ﺘﻨﺸﻴﻁ ﻟﻘﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺤﺘﻰ ﺘﻌﻤل ﻋﻠﻰ ﺍل Temporary Tablespaceﺍﻟﺠﺩﻴﺩ ،ﺇﺫ ﺃﻥ
ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺍﻟﻰ ﻫﺫﻩ ﺍﻟﻠﺤﻅﺔ ﺘﻌﻤل ﻋﻠﻰ ﺍل Temporary Tablespaceﺍﻟﻘﺩﻴﻡ.
ﻫﻜﺫﺍ ﺘﻡ ﺘﻨﺸﻴﻁ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻟﺘﻌﻤل ﻋﻠﻰ ﺍل Temp1 Temporary Tablespaceﻭﻴﻤﻜﻥ ﺍﻟﺘﺄﻜﺩ ﻤﻥ ﺫﻟﻙ
ﺒﺈﺠﺭﺍﺀ ﺍﻹﺴﺘﻌﻼﻡ ﺍﻻﺘﻰ
108
. ﻭﻫﻭ ﺍﻟﺫﻯ ﺤﺩﺙ ﻓﻴﻪ ﻓﺸلTemp Temporary Tablespace ﺜﻡ ﻨﻘﻭﻡ ﺒﺤﺫﻑ ﺍل-3
109
ﺍﻟﺴﻨﺎﺭﻴﻭ ﺍﻟﺘﺎﺴﻊ ) :(damage Online Logfile Member
ﺫﻜﺭﻨﺎ ﺴﺎﺒﻘﹰﺎ ﺃﻥ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺘﻌﻤل ﻋﻠﻰ ﺍﻻﻗل ﻋﻠﻰ ﺍﺜﻨﻴﻥ ﻤﻥ ﺍل Redo logfile Groupsﻭﺍﻯ
Groupﻴﺤﻭﻯ ﻋﻠﻰ ﺍﻻﻗل .Member
ﻭﻟﻨﻔﺘﺭﺽ ﺃﻥ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻟﺩﻴﻙ ﺘﻌﻤل ﻋﻠﻰ ﺜﻼﺙ Redo Logfile Groupsﻭﻜل Group
ﻴﺤﻭﻯ .Tow Members
110
ﺍﻟﻴﻙ ﺍﻟﺨﻁﻭﺍﺕ ﻟﺤل ﻫﺫﺍ ﺍﻟﺴﻨﺎﺭﻴﻭ:
111
ﺍﻟﺴﻨﺎﺭﻴﻭ ﺍﻟﺘﺎﺴﻊ ) :(Point in Time Recovery
ﻟﻨﻔﺘﺭﺽ ﺍﻥ ﻟﺩﻴﻙ ﻗﺎﻋﺩﺓ ﺒﻴﺎﻨﺎﺕ ﺘﻘﻭﻡ ﺒﻌﻤل ﻨﺴﺦ ﺇﺤﺘﻴﺎﻁﻰ Cold backupﻟﻬﺎ ﻴﻭﻤﻴﹰﺎ ﺍﻟﺴﺎﻋﺔ
ﺍﻟﺨﺎﻤﺴﺔ ﻤﺴﺎﺀ ،ﻭﻓﻰ ﻴﻭﻡ ﺍﻟﺜﻼﺜﺎﺀ ﻓﻰ ﺘﻤﺎﻡ ﺍﻟﺴﺎﻋﺔ 12:30:20ﺼﺒﺎﺤﹰﺎ ﻗﺎﻡ ﺍﺤﺩ ﺍﻟﻤﺴﺘﺨﺩﻤﻴﻥ ﺒﺤﺫﻑ ﺠﻭل
ﺍﻟﻤﻭﻅﻔﻴﻥ Employeeﻋﻥ ﻁﺭﻴﻕ ﺍﻟﺨﻁﺄ ﻭﻟﻡ ﺘﻜﺘﺸﻑ ﺫﻟﻙ ﺍﻻ ﻴﻭﻡ ﺍﻟﺨﻤﻴﺱ ﺼﺒﺎﺤﹰﺎ ﻓﻤﺎ ﻫﻭ ﺍﻟﺤل ؟
-1ﻗﻡ ﺒﻌﻤل ﻨﺴﺦ ﺇﺤﺘﻴﺎﻁﻰ ﻓﻴﺯﻴﺎﺌﻰ ﺒﺎﺭﺩ ﻟﺠﻤﻴﻊ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺍﻻﻥ.
-2ﺍﺭﺠﺎﻉ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺍﻟﻰ ﺤﺎﻟﺘﻬﺎ ﻗﺒل ﺤﺫﻑ ﺍﻟﺠﺩﻭل ) (Point in Time Recoveryﻭﺫﻟﻙ ﺒﻌﻤل
Restoreﻟﻘﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺍﻟﻰ ﺍﺨﺭ ﻨﺴﺦ ﺍﺤﺘﻴﺎﻁﻰ ﻗﺒل ﺤﺫﻑ ﺍﻟﺠﺩﻭل ،ﺍﻯ ﻨﺤﺘﺎﺝ ﻟﻌﻤل ﺍ Restoreﻟﻘﺎﻋﺩﺓ
ﺍﻟﺒﻴﺎﻨﺎﺕ ﻤﻥ ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﻟﻴﻭﻡ ﺍﻻﺜﻨﻴﻥ ﻤﺴﺎﺀ ﻭﻤﻥ ﺜﻡ ﻋﻤل Recoveryﻟﻘﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺍﻟﻰ ﻤﺎ ﻗﺒل
ﻼ
ﺤﺫﻑ ﺍﻟﺠﺩﻭل ﺒﺩﻗﻴﻘﺔ ﻤﺜ ﹸ
-5ﺍﻻﻥ ﻨﻘﻭﻡ ﺒﻌﻤل Restoreﻟﻘﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻤﻥ ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﺍﻟﺫﻯ ﻗﻤﻨﺎ ﺒﻪ ﻓﻰ ﺍﻟﺨﻁﻭﺓ ﺍﻻﻭﻟﻰ ﻤﻥ
ﻫﺫﺍ ﺍﻟﺴﻨﺎﺭﻴﻭ ﻭﻤﻥ ﺜﻡ ﻓﺘﺢ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ.
-6ﻭﺍﺨﻴﺭﹸﺍ ﻨﻘﻭﻡ ﺒﺈﺴﺘﻴﺭﺍﺩ ﺍﻟﺠﺩﻭل Employeeﻤﻥ ﻤﻠﻑ ﺍﻟﺘﺼﺩﻴﺭ C:\emp.dmp
112
-1ﺍﻥ ﺍﻟﺠﺩﻭل ﺘﻡ ﺤﺫﻓﻪ ﺍﻴﻀﹰﺎ ﻤﻥ ﺴﻠﺔ ﺍﻟﻤﻬﻤﻼﺕ.
-2ﺍﻥ ﺍﻟﺠﺩﻭل ﻏﻴﺭ ﻤﻭﺠﻭﺩ ﻓﻰ ﺍل Undo Tablespaceﻟﺫﺍ ﻻ ﻴﻤﻜﻥ ﻋﻤل .Flashback
-3ﺍﻥ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺍﺫﺍ ﻟﻡ ﻴﻜﻥ ﻓﻰ ﺍﻻﻤﻜﺎﻥ ﺍﻏﻼﻗﻬﺎ ﻟﻅﺭﻭﻑ ﺍﻟﻌﻤل ﻴﺠﺏ ﺍﻥ ﺘﺘﻡ ﻋﻤﻠﻴﺔ ﺍﻻﺴﺘﺭﺠﺎﻉ
ﻓﻰ ﻤﻜﺎﻥ ﺍﺨﺭ ﺤﺘﻰ ﻴﺘﻡ ﺍﺴﺘﻴﺭﺍﺩ ﺍﻟﺠﺩﻭل ﺍﻟﻤﻁﻠﻭﺏ ﻭﻤﻥ ﺜﻡ ﺘﻭﺭﻴﺩﻩ ﻟﻘﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺍﻻﺼﻠﻴﺔ .
-4ﻤﻌﺭﻓﺔ ﺯﻤﻥ ﺤﺫﻑ ﺍﻟﺠﺩﻭل ﻤﻬﻤﺔ ﻓﻰ ﻋﻤﻠﻴﺔ ﺍﻹﺴﺘﺭﺠﺎﻉ.
113
:ﺠﺩﻭل ﻟﻌﻤﻠﻴﺔ ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﻭﺍﻹﺴﺘﺭﺠﺎﻉ
114
ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﺍﻟﻔﻴﺯﻴﺎﺌﻲ ﺍﻟﺴﺎﺨﻥ ):(HOT BACKUP
ﻓﻰ ﺍﻟﺠﺯﺀ ﺍﻟﺴﺎﺒﻕ ﺘﺤﺩﺜﻨﺎ ﻋﻥ ﺍل Cold backupﻭﻋﺭﻓﻨﺎ ﻜﻴﻑ ﻨﻘﻭﻡ ﺒﻌﻤل ﻨﺴﺦ ﺇﺤﺘﻴﺎﻁﻰ ﺒﺎﺭﺩ
ﻟﻘﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺒﻌﺩ ﺇﻏﻼﻗﻬﺎ ،ﻭﻟﻜﻥ ﻤﺎﺫﺍ ﻟﻭ ﻜﺎﻨﺕ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻟﺩﻴﻙ ﻻ ﺘﺘﺤﻤل ﺇﻏﻼﻗﻬﺎ ﻭﻟﻭ ﻟﻠﺤﻅﺔ ﻭﺍﺤﺩﺓ
ﻼ ﻜﻘﺎﻋﺩﺓ ﺒﻴﺎﻨﺎﺕ ﺸﺭﻜﺎﺕ ﺍﻹﺘﺼﺎل ﻭﻜﺫﻟﻙ ﻨﻘﺎﻁ ﺍﻟﺒﻴﻊ ﻭﺍﻟﺼﺭﻓﺎﺕ ﺍﻻﻟﻴﺔ ؛ ﻓﻰ
ﻭﺫﻟﻙ ﻨﺴﺒﺔ ﻟﻁﺒﻴﻌﺔ ﻋﻤﻠﻬﺎ ﻤﺜ ﹰ
ﻫﺫﻩ ﺍﻻﻟﺤﺔ ﻻ ﻴﻤﻜﻨﻨﺎ ﺇﻏﻼﻕ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻭﺍﻴﻀﹰﺎ ﻨﺤﺘﺎﺝ ﻟﻌﻤل ﻨﺴﺦ ﺇﺤﺘﻴﺎﻁﻰ ﻟﻬﺎ ﺤﺘﻰ ﻻ ﻨﻔﻘﺩﻫﺎ ﻓﻰ ﺤﺎﻟﺔ
ﺤﺩﻭﺙ ﻓﺸل ،ﺍﻟﺤل ﻓﻰ ﻤﺜل ﻫﺫﻩ ﺍﻟﺤﺎﻟﺔ Hot backupﻭﻫﻭ ﺍﻟﻨﺴﺦ ﺍﻟﻐﺤﺘﻴﺎﻁﻰ ﺍﻟﺴﺎﺨﻥ ،ﺍﻯ ﻋﻤل ﻨﺴﺦ
ﺍﺤﺘﻴﺎﻁﻰ ﻟﻘﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺩﻭﻥ ﺇﻏﻼﻗﻬﺎ ﺍﻯ ﺍﺜﻨﺎﺀ ﻋﻤل ﺍﻟﻤﺴﺘﺨﺩﻤﻴﻥ ﻓﻰ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺘﺴﺘﻁﻴﻊ ﻋﻤل ﻨﺴﺦ
ﺇﺤﺘﻴﺎﻁﻰ ﻟﻬﺎ.
ﻭﺤﺘﻰ ﺘﺴﺘﻁﻴﻊ ﻓﻬﻡ ﻫﺫﺍ ﺍﻟﻨﻭﻉ ﻤﻥ ﺍﻟﻨﺴﺦ ﺍﻟﻐﺤﺘﻴﺎﻁﻰ ﺍﻟﻴﻙ ﺍﻟﻨﻘﺎﻁ ﺍﻟﺘﺎﻟﻴﺔ-:
-1ﻟﻌﻤل ﻫﺫﺍ ﺍﻟﻨﻭﻉ ﻤﻥ ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﻴﺠﺏ ﺃﻥ ﺘﻜﻭﻥ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻓﻰ ﺍﻟﻭﻀﻊ Archive log
Modeﻭﺫﻟﻙ ﻻﻨﻨﺎ ﻓﻰ ﻋﻤﻠﻴﺔ ﺍﻹﺴﺘﺭﺠﺎﻉ ﻨﺤﺘﺎﺝ ﺍﻟﻰ ﺍﻻﺭﺸﻴﻑ ﺇﺫ ﻻ ﻴﻤﻜﻥ ﻋﻤل Simple Restoreﺍﺜﻨﺎﺀ
ﻋﻤﻠﻴﺔ ﺍﻹﺴﺘﺭﺠﺎﻉ ﻤﻥ ﺍل.Hot Backup
-2ﻴﺘﻴﻡ ﻋﻤل ﺍل Hot Backupﺍﺜﻨﺎﺀ ﻋﻤل ﺍﻟﻤﺴﺘﺨﺩﻤﻴﻥ ﻭﻟﻜﻥ ﻗﺩ ﻴﺅﺩﻯ ﺫﻟﻙ ﻟﺨﻔﺽ ﺍﻻﺩﺍﺀ ﻓﻰ ﻗﺎﻋﺩﺓ
ﺍﻟﺒﻴﺎﻨﺎﺕ ﻟﺫﺍ ﻴﺤﺒﺫ ﻋﻤل ﺍل Hot backupﻟﻘﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻓﻰ ﻏﻴﺭ ﺍﻭﻗﺎﺕ ﺍﻟﺫﺭﻭﺓ.
-3ﻴﻜﻤﻥ ﻋﻤل ﻨﺴﺦ ﺍﺤﺘﻴﺎﻁﻰ ﻟل Tablespacesﺒﺸﻜل ﻤﻨﻔﺭﺩ ﺒﻌﺩ ﻜﺘﺎﺒﺔ ﺍﻟﻜﻭﺩ ﺍﻻﺘﻰ
ﺒﻌﺩ ﻜﺘﺎﺒﺔ ﻫﺫﺍ ﺍﻟﻜﻭﺩ ﻤﺒﺎﺸﺭﺓ ﻨﻘﻭﻡ ﺒﻌﻤل ﻨﺴﺦ ﻟﻤﻠﻔﺎﺕ ﺍل Data filesﺍﻟﺘﻰ ﺘﻨﺘﻤﻰ ﻟل Tablespaceﺍﻋﻼﻩ
ﻋﻥ ﻁﺭﻴﻕ ﻨﻅﺎﻡ ﺍﻟﺘﺸﻐﻴل.
115
ﺒﻌﺩ ﺇﻨﺘﻬﺎﺀ ﻋﻤل ﺍﻟﻨﺴﺦ ﻋﻥ ﻁﺭﻴﻕ ﻨﻅﺎﻡ ﺍﻟﺘﺸﻐﻴل ﻨﻘﻭﻡ ﺒﺈﻨﻬﺎ ﺤﺎﻟﺔ ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﻟل Tablespaceﺒﻜﺘﺎﺒﺔ
ﺍﻟﻜﻭﺩ ﺍﻻﺘﻰ
-4ﺒﺎﻟﻨﺴﺒﺔ ﻟل Control Fileﻓﺎﻨﻨﺎ ﻻﻨﻘﻭﻡ ﺒﻌﻤل ﻨﺴﺦ ﻟﻪ ﻋﻥ ﻁﺭﻴﻕ ﻨﻅﺎﻡ ﺍﻟﺘﺸﻐﻴل ﻭﺇﻨﻤﺎ ﻓﻘﻁ ﺒﻌﺩ ﺍﻨﺘﻬﺎﺀ
ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﻟل Tablespaceﻨﻘﻭﻡ ﺒﻌﻤل ﻨﺴﺦ ﺇﺤﺘﻴﺎﻁﻰ ﻟل Control Fileﻋﻥ ﻁﺭﻴﻕ ﺍلSQL
ﻫﻜﺫﺍ ﻗﻤﻨﺎ ﺒﻌﻤل ﻨﺴﺦ ﺇﺤﺘﻴﺎﻁﻰ ﻟل Control Fileﻋﻥ ﻁﺭﻴﻕ ﺍلSQL
ﻭﻻ ﻴﺘﻡ ﻋﻤل ﻨﺴﺦ ﺍﺤﺘﻴﺎﻁﻰ ﻟﻤﻠﻔﺎﺕ ﺍل.Redolog Files
-5ﻋﻨﺩ ﻋﻤل ﺍﺴﺘﺭﺠﺎﻉ ﻟﻘﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺍﺕ ﻤﻥ ﺍل Hot Backupﻻﺒﺩ ﻤﻥ ﻋﻤل Restore + Recoveryﺇﺫﺍ
ﻻ ﻴﻤﻜﻥ ﻋﻤل Restoreﻓﻘﻁ ﻟﺫﺍ ﻴﺠﺏ ﺃﻥ ﻴﻜﻭﻥ ﻟﺩﻴﻨﺎ ﻋﻠﻰ ﺍﻻﻗل One Rrchive Fileﻟﺫﺍ ﻓﻤﻥ ﺍﻻﻓﻀل
ﻋﻤل Switch Logfileﺒﻌﺩ ﺍﻹﻨﺘﻬﺎﺀ ﻤﻥ ﺍلHot Backup
-6ﺒﺎﻟﻨﺴﺒﺔ ﻟﻌﻤﻠﻴﺔ ﺍﻹﺴﺘﺭﺠﺎﻉ ﻓﻬﻰ ﻻ ﺘﺨﺘﻠﻑ ﻋﻥ ﻋﻤﻠﻴﺔ ﺍﻹﺴﺘﺭﺠﺎﻉ ﻤﻥ ﺍل Cold Backupﻏﻴﺭ ﺍﻨﻨﺎ ﻓﻰ
ﺍل Hot backupﻻﺒﺩ ﻟﻨﺎ ﻤﻥ ﻋﻤل .Restore + Recovery
-7ﻓﻰ ﺍﻹﺼﺩﺍﺭ Oracle10gﺍﺼﺒﺢ ﺒﺎﻻﻤﻜﺎﻥ ﻭﻀﻊ ﺠﻤﻴﻊ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻓﻰ ﺍﻟﻭﻀﻊ Hot
Backup
116
;ALTER DATABASE BEGIN BACKUP
ﻭﻤﻥ ﺜﻡ ﻨﻘﻭﻡ ﻋﻥ ﻁﺭﻴﻕ ﻨﻅﺎﻡ ﺍﻟﺘﺸﻐﻴل ﺒﻌﻤل ﻨﺴﺦ ﻏﺤﺘﻴﺎﻁﻰ ﻟﻤﻠﻔﺎﺕ ﺍل Datafilesﻭﻤﻥ ﺜﻡ ﻨﺴﺦ
ﺇﺤﺘﻴﺎﻁﻰ ﻟل Control Fileﻋﻥ ﻁﺭﻴﻕ ﺍل SQLﻭﻟﻜﻥ ﻴﺠﺏ ﻤﺭﺍﻋﺎﺓ ﺃﻥ ﻻ ﺘﻜﻭﻥ ﻫﻨﺎﻙ ﻤﺠﻤﻭﻋﺔ ﻜﺒﻴﺭﺓ
ﻤﻥ ﺍﻟﻌﻤﻠﻴﺎﺕ ﺘﻌﻤل ﻋﻠﻰ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺍﺜﻨﺎﺀ ﻫﺫﺍ ﺍﻟﻨﻭﻉ ﻤﻥ ﺍﻟﻨﺴﺦ ﺍﻻﺤﺘﻴﺎﻁﻰ ﻭﺒﻌﺩ ﺍﻻﻨﺘﻬﺎ ﻤﻥ ﻋﻤل
ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﻨﻘﻭﻡ ﺒﻜﺘﺎﺒﺔ ﺍﻟﻜﻭﺩ ﺍﻟﺘﺎﻟﻰ ﻹﻨﻬﺎﺀ ﻭﻀﻊ ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﻟﻘﺎﻋﺩﺓﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ.
117
118
119
) Recovery Manager (RMANﺍﺩﺍﺓ ﺇﻨﺸﺎﺀﺘﻬﺎ ﺍﻭﺭﻜل ﺇﺒﺘﺩﺍﺀﹰﺍ ﻤﻥ ﺍﻹﺼﺩﺍﺭ 8ﻟﺘﻜﻭﻥ ﻨﻘﻠﺔ ﻨﻭﻋﻴﺔ
ﻭﻜﺒﻴﺭﺓ ﻓﻰ ﻤﺠﺎل ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﻭﺍﻹﺴﺘﺭﺠﺎﻉ Backup & Restore & Recoveryﺤﻴﺙ ﻭﻓﺭﺓ
ﻫﺫﻩ ﺍﻹﺩﺍﺀﺓ ﻤﺠﻤﻭﻋﺔ ﻤﻥ ﺍﻟﺨﻴﺎﺭﺍﺕ ﻟﻡ ﺘﻜﻥ ﻤﻭﺠﻭﺩﺓ ﻤﻥ ﻗﺒل ﻤﻤﺎ ﺠﻌﻠﻬﺎ ﺍﻓﻀل ﺍﺩﺍﺀﺓ ﺘﻭﻓﺭﻫﺎ ﺍﻭﺭﻜل
ﻓﻰ ﻫﺫﺍ ﺍﻟﻤﺠﺎل ﻋﻠﻰ ﺍﻹﻁﻼﻕ.
ﻟﺫﺍ ﺘﻨﺼﺢ ﺸﺭﻜﺔ ﺍﻭﺭﻜل ﺒﺈﺴﺘﺨﺩﺍﻡ ﻫﺫﻩ ﺍﻹﺩﺍﺓ ﻭﺫﻟﻙ ﻹﺤﺘﻭﺍﺀﻫﺎ ﻋﻠﻰ ﻤﺠﻤﻭﻋﺔ ﻤﻥ ﺍﻟﻤﻴﺯﺍﺕ ﻭﺍﻟﺘﻰ
ﻤﻥ ﺍﻫﻤﻬﺎ :
-1ﻤﺴﺘﻭﻯ ﺍﺩﺍﺀ ﺍﻓﻀل ﺒﺎﻟﻨﺴﺒﺔ ﻟﻌﻤﻠﻴﺔ ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﻭﺍﻹﺴﺘﺭﺠﺎﻉ ﻤﻘﺎﺭﻨﺔ ﺒﺎﻻﺩﻭﺍﺕ ﺍﻻﺨﺭﻯ.
-2ﺘﻘﻭﻡ ﺒﻌﻤل ﻓﺤﺹ ﻟﻜل ﺍﻟﻜﺘل ﻤﻨﻁﻘﻴﹰﺎ ﻭﻓﻴﺯﻴﺎﺌﻴﹰﺎ ﺍﺜﻨﺎﺀ ﻗﺭﺍﺌﺘﻬﺎ ﻋﻨﺩ ﻋﻤﻠﻴﺔ ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ،ﻭﻤﻥ
ﺜﻡ ﺇﻜﺘﺸﺎﻑ ﺍﻟﻜﺘل ﺍﻟﻔﺎﺴﺩﺓ.
-3ﺘﻭﻓﻴﺭ ﺨﻴﺎﺭﺍﺕ ﻨﺴﺦ ﻜﻠﻰ ﻭﺠﺯﺌﻰ ﻭﺘﺭﺍﻜﻤﻰ.
-4ﺘﻭﻓﻴﺭ ﺨﻴﺎﺭﺍﺕ ﺍﺨﺭﻯ ﻜﺘﺤﺩﻴﺩ ﻤﺩﺓ ﻋﻤل ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﻭﺘﺤﺩﻴﺩ ﻗﻨﻭﺍﺕ ﺘﻌﻤل ﺒﺎﻟﺘﻭﺍﺯﻯ ﺍﺜﻨﺎﺀ
ﻋﻤل ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﻭﺍﻹﺴﺘﺭﺠﺎﻉ Backup & Recoveryﻭﺨﻴﺎﺭﺍﺕ ﻀﻐﻁ ﻟﺘﻘﻠﻴل ﺤﺠﻡ
ﺍﻟﻤﺨﺭﺠﺎﺕ ﻭﻏﻴﺭﻫﺎ ﻤﻥ ﺍﻟﺨﻴﺎﺭﺍﺕ ﺍﻻﺨﺭﻯ ﺍﻟﺘﻰ ﺴﻨﻤﺭ ﻋﻠﻴﻬﺎ ﺘﺒﺎﻋﹰﺎ.
-5ﺍﺩﺍﺭﺓ ﺠﻴﺩﺓ ﻟﻌﻤﻠﻴﺔ ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﻭﺍﻹﺴﺘﺭﺠﺎﻉ ﻜﻤﺎ ﺘﻘﻭﻡ ﺒﺈﺩﺍﺭﺓ ﺠﻴﺩﺓ ﺍﻴﻀﹰﺎ ﻟﻠﻤﻬﺎﻡ )(Tasks
ﻟﻠﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﻭﺍﻹﺴﺘﺭﺠﺎﻉ.
-6ﺍﻤﻜﺎﻨﻴﺔ ﻋﻤل ﻨﺴﺦ ﺇﺤﺘﻴﺎﻁﻰ ﻟﻜل ﻤﻥ ) Database,Tablespaces,Datafiles,Archivelog
.(Files,Control Files,Spfile
-7ﺇﻤﻜﺎﻨﻴﺔ ﺘﻤﺭﻴﺭ ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﻟل Disksﺍﻭ ﺍل.Tapes
-8ﺴﺭﻋﺔ ﻋﺎﻟﻴﺔ ﺇﺜﻨﺎﺀ ﻋﻤل ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﻭﺍﻹﺴﺘﺭﺠﺎﻉ.
-9ﺘﻭﻓﺭ ﻁﺭﻕ ﺍﺴﺘﻌﻼﻡ ﺴﻬﻠﺔ ﻟﻠﻭﺼﻭل ﻟﺠﻤﻴﻊ ﺍﻟﻌﻠﻭﻤﺎﺕ ﺍﻟﻤﻁﻠﻭﺒﺔ ﻋﻥ ﻋﻤﻠﻴﺎﺕ ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ
ﻭﺍﻹﺴﺘﺭﺠﺎﻉ.
-10ﺘﻭﻓﻴﺭ ﺍﺴﺘﺭﺍﺘﻴﺠﻴﺔ ﺍﻟﻴﺔ ﻟﻌﻤﻠﻴﺎﺕ ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﻤﻤﺎ ﻴﺴﻬل ﻤﻥ ﻋﻤﻠﻴﺎﺕ ﻤﺩﻴﺭ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ،
ﻭﻜﺫﻟﻙ ﺘﺴﻬل ﺇﺩﺍﺭﺓ ﺍﻟﻤﺴﺎﺤﺎﺕ ﺍﻟﺘﺨﺯﻴﻨﻴﺔ ﻋﻠﻰ ﺍﻟﺩﻴﺴﻙ.
120
ﻣﻜﻮﻧﺎت ال):Recovery Manager (RMAN
121
:RMAN Repositoryﻴﺘﻡ ﻓﻴﻪ ﺤﻔﻅ ﺠﻤﻴﻊ ﺍﻟﻤﻌﻠﻭﻤﺎﺕ ﻋﻥ ﻋﻤﻠﻴﺎﺕ -3
ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﻭﺍﻹﺴﺘﺭﺠﺎﻉ ﻭﺍﻴﻀﹰﺎ ﻤﻌﻠﻭﻤﺎﺕ ﻋﻥ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ
ﺍﻟﻤﺴﺘﻬﺩﻓﺔ ﻭﻫﻴﻜﻠﺘﻬﺎ ﻭﺍﻴﻀﹰﺎ ﻴﺤﻔﻅ ﺒﻴﺎﻨﺎﺕ ﺍﻟﺘﻬﻴﺌﺔ ﻟلRMAN
) (RMAN Configuration Settingsﻭﻴﺘﻡ ﺤﻔﻅ ﺍل RMAN
Repositoryﺩﺍﺌﻤﹰﺎ ﻓﻰ ﻤﻠﻑ ﺍﻟﺘﺤﻜﻡ ﻓﻰ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺍﻟﻤﺴﺘﻬﺩﻓﺔ
Control Fileﻭﻟﻜﻥ ﻴﺠﺏ ﺍﻹﻨﺘﻴﺎﻩ ﺇﻟﻰ ﺃﻥ ﻤﺩﺓ ﺍﻻﺤﺘﻔﺎﻅ ﺒﻤﻌﻠﻭﻤﺎﺕ
ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﻓﻰ ﻤﻠﻑ ﺍﻟﺘﺤﻜﻡ ﺘﻌﺘﻤﺩ ﻋﻠﻰ ﺍﻟﻤﺘﻐﻴﺭ
CONTROL_FILE_RECORD_KEEP_TIMEﺍﻟﺫﻯ ﻴﺤﻭﻯ
ﻗﻴﻤﺔ ﺘﻤﺜل ﻋﺩﺩ ﺍﻻﻴﺎﻡ ﻟﻼﺤﺘﻔﺎﻅ ﺒﻤﻌﻠﻭﻤﺎﺕ ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﻗﺒل ﺃﻥ ﻴﺘﻡ
ﺍﺴﺘﺨﺩﺍﻡ ﻨﻔﺱ ﺍﻟﺤﻘﻭل ﻟﻜﺘﺎﺒﺔ ﻤﻌﻠﻭﻤﺎﺕ ﺠﺩﻴﺩﺓ ﻋﻥ ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ.
122
:Enterprise Managerﻜﺎﻨﺕ ﺍﻟﻤﺸﻜﻠﺔ ﺴﺎﺒﻘﹰﺎ ﻓﻰ ﻜﺘﺎﺒﺔ ﺍﻟﻜﻭﺩ -6
ﻟﻌﻤﻠﻴﺔ ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﻭﺍﻹﺴﺘﺭﺠﺎﻉ ﻭﺇﺩﺍﺭﺓ ﺍل Flash Recovery
، Areaﻭﻟﻜﻥ ﻭﻓﺭﺓ ﺍﻭﺭﻜل ﻭﺍﺠﻬﺔ ﺘﻌﺎﻤل ﻟﺤل ﻫﺫﻩ ﺍﻟﻤﺸﻜﻠﺔ ﻭﻫﻰ ﺍل
Enterprise Managerﻓﺘﺴﺘﻁﻴﻊ ﻋﻤل ﺠﻤﻴﻊ ﺍﻟﻤﻬﺎﻡ ﺩﻭﻥ ﻜﺘﺎﺒﺔ ﺍﻯ
ﻜﻭﺩ.
:Auxiliary Databaseﻫﻰ ﻋﺒﺎﺭﺓ ﻋﻥ ﻗﺎﻋﺩﺓ ﺒﻴﺎﻨﺎﺕ ﻴﺘﻡ ﺇﻨﺸﺎﺅﻫﺎ -7
ﺒﻭﺍﺴﻁﺔ ﺍل RMANﻭﻫﻰ ﻋﺒﺎﺭﺓ ﻋﻥ ﻨﺴﺨﺔ ﻤﻥ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ
ﺍﻟﻤﺴﺘﻬﺩﻓﺔ ﻴﺘﻡ ﺇﻨﺸﺎﺅﻫﺎ ﻟﻌﺩﺓ ﺍﻏﺭﺍﺽ ﻤﻨﻬﺎ ﻋﻤﻠﻴﺎﺕ ﺍﻹﺨﺘﺒﺎﺭ ﺇﺫ ﻻ ﻴﻤﻜﻥ
ﺍﺠﺭﺍﺀ ﺍﻻﺨﺘﺒﺎﺭ ﻋﻠﻰ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺍﻻﺼل ،ﺍﻴﻀﹰﺎ ﻓﻰ ﺒﻌﺽ ﺍﻻﺤﻴﺎﻥ
ﻗﺩ ﻨﺤﺘﺎﺝ ﺍﻟﻴﻬﺎ ﻋﻨﺩ ﻋﻤل Tablespace Point-in-Time
Recoveryﻭﻫﻰ ﻋﻤﻠﻴﺔ ﺇﺭﺠﺎﻉ ﺍل Tablespaceﺇﻟﻰ ﺍﻟﻭﺭﺍﺀ ﺩﻭﻥ
ﺍﻟﺘﺄﺜﻴﺭ ﻋﻠﻰ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ،ﻓﻴﺘﻡ ﺍﻟﺘﻌﺎﻤل ﻤﻊ ﻫﺫﺍ ﺍﻟﺠﺭﺍﺀ ﺒﺈﻋﺘﺒﺎﺭ ﺍل
Auxiliary Databaseﻜﻤﺨﺯﻥ ﻤﺅﻗﺕ ﺍﺜﻨﺎﺀ ﻋﻤل ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ
ﺍﻟﻤﺴﺘﻬﺩﻓﺔ ،ﺍﻴﻀﹰﺎ ﻴﻤﻜﻥ ﻨﺘﻌﺎﻤل ﻤﻌﻬﺎ ﻙ Standby Databaseﻓﻰ
ﺤﺎل ﺤﺼل ﻤﺸﻜﻠﺔ ﻓﻰ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺍﻟﻤﺴﺘﻬﺩﻓﺔ ﻴﺘﻡ ﺘﺤﻭﻴل ﺍﻟﻌﻤل ﺍﻟﻴﻬﺎ
ﺩﻭﻥ ﺃﻥ ﻨﻔﻘﺩ ﺒﻴﺎﻨﺎﺕ.
123
ﺃﻨﻭﺍﻉ ﺍﻹﺘﺼﺎل ﺒﺎل:RMAN
ﺒﺎﻟﻁﺒﻊ ﻴﻤﻜﻥ ﺘﺸﻐﻴل ﺍل RMANﺩﻭﻥ ﺍﻹﺘﺼﺎل ﺒﺎﻯ ﻤﻥ ﻗﻭﺍﻋﺩ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻭﺫﻟﻙ ﺒﻭﺍﺴﻁﺔ ﺘﺸﻐﻴل
ﺍﻟﻤﻠﻑ RMAN.EXEﺍﻭ ﻋﻥ ﻁﺭﻴﻕ ﻜﺘﺎﺒﺔ ﺍﻻﻤﺭ RMANﻋﻠﻰ ﺍل.Prompt
C:\RMAN
RMAN>EXIT
124
ﻜﻤﺎ ﻴﻤﻜﻥ ﺍﻹﺘﺼﺎل ﺒﺜﻼﺙ ﺍﻨﻭﺍﻉ ﻤﻥ ﻗﻭﺍﻋﺩ ﺍﻟﺒﻴﺎﻨﺎﺕ-:
:Target Database -1ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺍﻟﻤﺴﺘﻬﺩﻓﺔ ﻭﻴﺘﻡ ﺍﻻﺘﺼﺎل ﺒﻬﺎ ﻋﻥ ﻁﺭﻴﻕ ﺍﻻﻤﺭ ﺍﻟﺘﺎﻟﻰ.
125
:Recovery Catalog Database -2
ﺴﻨﺘﺤﺩﺙ ﻻﺤﻘﹰﺎ ﻋﻥ ﻜﻴﻔﻴﺔ ﺇﻨﺸﺎﺀ Recovery Catalog Databaseﻭﻟﻜﻥ ﻴﺠﺏ ﺍﻟﺘﻨﺒﻴﻪ ﺍﻟﻰ ﺍﻨﻪ
ﻴﻤﻜﻥ ﻋﻤل ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﻭﺍﻻﺴﺘﺭﺠﺎﻉ ﺩﻭﻥ ﺍﻟﻠﺠﻭﺀ ﺍﻟﻰ ﺍﻹﺘﺼﺎل ﺒﺎل Recovery Catalog
Databaseﺒﺤﻴﺙ ﻴﺘﻡ ﺘﺨﺯﻴﻥ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺍﻟﺨﺎﺼﺔ ﺒﺎﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﺒﻤﻠﻑ ﺍﻟﺘﺤﻜﻡ ﻓﻰ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ
ﺍﻟﻤﺴﺘﻬﺩﻓﺔ .Control File
126
:Auxiliary Database -3
ﻟﻴﺱ ﺸﺭﻁﹰﺎ ﻹﻨﺠﺎﺯ ﻋﻤﻠﻴﺔ ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﻭﺍﻹﺴﺘﺭﺠﺎﻉ ﺍﻹﺘﺼﺎل ﺒﺎل Auxiliary Databaseﻭﺫﻟﻙ
ﻻﻨﻬﺎ ﻗﺎﻋﺩﺓ ﺒﻴﺎﻨﺎﺕ ﻤﺴﺎﻋﺩﺓ ﻗﺩ ﻨﺤﺘﺎﺝ ﺍﻟﻴﻬﺎ ﻻﺤﻘﹰﺎ ﻻﺴﺒﺎﺏ ﺫﻜﺭﺘﻬﺎ ﺴﺎﺒﻘﹰﺎ.
127
ﺨﻴﺎﺭﺍﺕ ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ-:
128
-3ﺍﻨﻤﺎﻁ ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ-:
:Offline -1ﻭﻫﻭ ﻋﻤل ﻨﺴﺦ ﺇﺤﺘﻴﺎﻁﻰ ﻟﻘﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺒﺸﺭﻁ ﺃﻥ ﺘﻜﻭﻥ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻏﻴﺭ
ﻤﻔﺘﻭﺤﺔ ﺍﻭ ﺒﻤﻌﻨﻰ ﺍﺨﺭ ﻴﻤﻜﻥ ﻋﻤل ﻨﺴﺦ ﺃﺤﺘﻴﺎﻁﻰ ﻟﻘﻘﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻓﻰ ﺍﻟﻭﻀﻊ Mountﻭﻫﻨﺎ
ﻨﻀﻤﻥ ﺍﻥ ﺍﻻﺘﻰ
The SCN data file headers matches the SCN in the control files.
ﻭﻫﺫﺍ ﺍﻟﻨﻭﻉ ﻴﺴﻤﻰ ﺍﻴﻀﹰﺎ ).(Consistent or Cold
:Online -2ﻭﻫﻭ ﻋﻤل ﻨﺴﺦ ﺇﺤﺘﻴﺎﻁﻰ ﺍﺜﻨﺎﺀ ﻋﻤل ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻭﺩﻭﻥ ﺇﻏﻼﻗﻬﺎ ،ﻭﻴﺴﻤﻰ ﺍﻴﻀﹰﺎ
).(Inconsistent or Cold
129
ﻁﺭﻕ ﺘﻨﻔﻴﺫ ﺍﻭﺍﻤﺭ ﺍل:RMAN
ﻻ ﻭﻗﺒل ﺍﻟﺤﺩﻴﺙ ﻋﻥ ﻁﺭﻕ ﺘﻨﻔﻴﺫ ﺍﻭﺍﻤﺭ ﺍل RMANﻴﺠﺏ ﺍﻹﺸﺎﺭﺓ ﺇﻟﻰ ﺃﻥ ﻤﺴﺘﺨﺩﻡ ﻗﺎﻋﺩﺓ
ﺍﻭ ﹰ
ﺍﻟﺒﻴﺎﻨﺎﺕ ﺍﻟﺫﻯ ﻴﺭﻴﺩ ﺍﺴﺘﺨﺩﺍﻡ ﺍل RMANﻴﺠﺏ ﺃﻥ ﻴﻤﻠﻙ ﺍﻟﺼﻼﺤﻴﺔ SYSDBAﻭﺫﻟﻙ ﻻﻨﻪ ﻗﺩ ﻴﺤﺘﺎﺝ
ﻹﻏﻼﻕ ﻗﺎﻋﺩﺓ ﻭﻓﺘﺤﻬﺎ.
File.rcvﻭﻴﺘﻡ ﺘﻨﻔﻴﺫﻩ ﻋﻠﻰ ﻤﺤﺭﺭ ﺍل.RMAN ﻜﻤﺎ ﻴﻤﻜﻥ ﺤﻔﻅ ﺍﻟﻜﻭﺩ ﻓﻰ ﺸﻜل ﻤﻠﻑ
ﻗﻤﺕ ﺒﺘﻨﻔﻴﺫ ﺍﻟﻤﻠﻑ c:\backup.rcvﺍﻟﺫﻯ ﻴﺤﻭﻯ ﻋﻠﻰ ﻜﻠﻤﺘﻴﻥ ﻓﻘﻁ REPORT SCHEMAﻭﻫﺫﺍ
ﺍﻻﻤﺭ ﻟﻌﺭﺽ ﻫﻴﻜﻠﺔ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ.
130
ﲥﻴﺌﺔ ال:(RMAN Configuration Setting) RMAN
ﻓﻰ ﺍﻟﺤﻘﻴﻘﺔ ﺃﻥ ﺘﻬﻴﺌﺔ ﺨﻴﺎﺭﺍﺕ ﺍل RMANﺘﺴﺎﻋﺩ ﻤﺩﻴﺭ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻜﺜﻴﺭﹰﺍ ﻓﻰ ﻋﻤﻠﻪ ،ﺨﺼﻭﺼﹰﺎ
ﺇﺫﺍ ﻜﺎﻨﺕ ﻟﻪ ﺍﺴﺘﺭﺍﺘﻴﺠﻴﺔ ﻭﺍﻀﺤﺔ ﻓﻰ ﺍﻟﻌﻤل ﻓﻴﻘﻭﻡ ﺒﺘﻬﻴﺌﺔ ﺍل RMANﺒﻨﺎﺀ ﻋﻠﻰ ﻫﺫﻩ ﺍﻹﺴﺘﺭﺍﺘﻴﺠﻴﺔ ﺍﻟﺘﻰ
ﺍﻋﺩﻫﺎ ﻤﺴﺒﻘﹰﺎ ،ﻜﻤﺎ ﻴﺠﺏ ﺍﻹﺸﺎﺭﺓ ﺇﻟﻰ ﺃﻨﻪ ﻋﻨﺩ ﺇﺴﺘﺨﺩﺍﻡ ﺍل RMANﺩﻭﻥ ﺇﻋﺎﺩﺓ ﺘﻬﻴﺌﺘﻬﺎ ﺘﻌﻤل ﻓﻰ ﻫﺫﻩ ﺍﻟﺤﺎﻟﺔ
ﻋﻠﻰ ﺍﻟﺘﻬﻴﺌﺔ ﺍﻻﺼﻠﻴﺔ .Default Setting
ﺒﺎﻟﻁﺒﻊ ﻴﻤﻜﻥ ﺘﻬﻴﺌﺔ ﺍل RMANﻭﻟﻜﻥ ﺍﻴﻀﹰﺎ ﻴﻤﻜﻥ ﻟﻤﺩﻴﺭ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺘﺠﺎﻫل ﻫﺫﻩ ﺍﻟﺘﻬﻴﺌﺔ ﻋﻥ
ﻁﺭﻴﻕ ﺍﻨﺠﺎﺯ ﻤﻬﺎﻤﻪ ﻴﺩﻭﻴﹰﺎ ﺒﻜﺘﺎﺒﺔ ﻜل ﻤﺎﻴﺭﻴﺩﻩ ﻋﻠﻰ ﻤﺤﺭﺭ ﺍل RMANﺤﺘﻰ ﻭﻟﻭ ﺍﺨﺘﻠﻑ ﻜﻠﻴﹰﺎ ﻋﻥ
ﺍل ، Configuration Settingﺇﺫﹰﺍ ﻴﻤﻜﻥ ﺍﻟﻘﻭل ﺍﻥ ﻋﻤﻠﻴﺔ ﺘﻬﻴﺌﺔ ﺍل RMANﺍﻤﺭ ﻤﻬﻡ ﻟﻤﺩﻴﺭ ﻗﺎﻋﺩﺓ
ﺍﻟﺒﻴﺎﻨﺎﺕ ﻜﻡ ﻴﻤﻜﻨﻪ ﺘﺠﺎﻫل ﻫﺫﻩ ﺍﻟﺘﻬﻴﺌﺔ ﻤﺘﻰ ﺸﺎﺀ ﻋﻥ ﻁﺭﻴﻕ ﺇﻨﺠﺎﺯ ﻤﻬﺎﻤﻪ ﻴﺩﻭﻴﹰﺎ.
ﻴﺴﺘﻁﻴﻊ ﻤﺩﻴﺭ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺘﻬﻴﺌﺔ ﺍل RMANﺒﺤﻴﺙ ﻴﻘﻭﻡ ﺒﺘﺤﺩﺩ ﻨﻭﻉ ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ
) (Backup Set or Copyﻜﺫﻟﻙ ﺘﺤﺩﻴﺩ ﻨﻭﻉ ﺍل (Disk or Tape) Deviceﻭﺍﻴﻀﹰﺎ ﻓﺘﺭﺓ ﺍﻹﺤﺘﻔﺎﻅ
ﺒﺎﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﻭﻏﻴﺭﻫﺎ ﻤﻥ ﺍﻟﺨﻴﺎﺭﺍﺕ ﺍﻟﺘﻰ ﺴﻨﺘﺤﺩﺙ ﻋﻨﻬﺎ ﺒﺎﻟﺘﻔﺼﻴل.
;RMAN>SHOW ALL
131
SHOW ALLﻫﺫﺍ ﺍﻻﻤﺭ ﻴﻘﻭﻡ ﺒﻌﺭﺽ ﺨﻴﺎﺭﺍﺕ ﺘﻬﻴﺌﺔ ﺍل ، (RMAN Configuration) RMANﻜﻤﺎ
ﻴﻤﻜﻥ ﻤﻼﺤﻅﺔ ﺃﻨﻪ ﻓﻰ ﺘﻭﺠﺩ ﺍﺤﻴﺎﻨﹰﺎ ﻜﻠﻤﺔ Defaultﻓﻰ ﻨﻬﺎﻴﺔ ﺍﻟﺴﻁﺭ ﻤﻤﺎ ﺘﺩل ﻋﻠﻰ ﺍﻥ ﻫﺫﻩ ﻫﻰ ﺍﻟﻘﻴﻤﺔ
ﺍﻹﺼﻠﻴﺔ )(Default Setting
132
ﻜﻤﺎ ﻴﻤﻜﻥ ﺍﻟﺭﺠﻭﻉ ﻟﻠﻘﻴﻤﺔ ﺍﻹﺼﻠﻴﺔ ﺒﻭﺍﺴﻁﺔ ﺍﻻﻤﺭ
133
ﲥﻴﺌﺔ ال:Default Device Type
ﻭﻫﻰ ﻟﺘﺤﺩﻴﺩ ﻤﻠﻔﺎﺕ ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ) (Backupﻫل ﺴﻴﺘﻡ ﺘﻤﺭﻴﺭﻫﺎ ﺍﻟﻰ ﺍﻟﺩﻴﺴﻙ ) (Diskﺍﻭ ﺇﻟﻰ
) (Tape Deviceﻓﻰ ﺍﻹﺼل ﺴﻴﺘﻡ ﺘﻤﺭﻴﺭ ﻤﻠﻔﺎﺕ ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﺇﻟﻰ ﺍﻟﺩﻴﺴﻙ.
ﺍﻻﻥ ﺴﻭﻑ ﻴﺘﻡ ﺘﻤﺭﻴﺭ ﻤﻠﻔﺎﺕ ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﺇﻟﻰ ) (Tape Libraryﻤﺎﻟﻡ ﻴﺘﻡ ﺘﺠﺎﻫل ﺫﻟﻙ ﻋﻥ ﻁﺭﻴﻕ
ﺘﻤﺭﻴﺭ ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﻴﺩﻭﻴﺎ ﻋﻥ ﻁﺭﻴﻕ ﻤﺤﺭﺭ ﺍل.RMAN
ﻜﻤﺎ ﻴﻤﻜﻥ ﺘﻤﺭﻴﺭ ﻤﻠﻔﺎﺕ ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﺍﻟﻰ ﺍﻟﺩﻴﺴﻙ ﺒﻭﺍﺴﻁﺔ ﺍﻻﻤﺭ
134
ﲥﻴﺌﺔ ال: Device Type
ﺍﻯ ﺍﻨﻪ ﻟﺤﻅﺕ ﻋﻤل ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﻭﺇﺭﺴﺎﻟﻪ ﺇﻟﻰ ﺍﻟﺩﻴﺴﻙ ﺴﻭﻑ ﻴﺘﻡ ﺇﺴﺘﺨﺩﺍﻡ ﻗﻨﺎﺓ ﺍﻭ ﺠﻠﺴﺔ ﻋﻤل ﻭﺍﺤﺩﺓ
) (Channelﻹﺭﺴﺎل ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﻜﻤﺎ ﺴﻴﺘﻡ ﻋﻤل ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﻋﻠﻰ ﻫﻴﺌﺔ Backup Setﻭﻟﻴﺱ
، Image Copyﻴﻤﻜﻥ ﺒﺎﻟﻁﺒﻊ ﺘﻬﻴﺌﺔ ﺍل Device Typeﻋﻨﺩ ﺇﺭﺴﺎل ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﻟلTape Library
،ﻓﻠﻨﻔﺘﺭﺽ ﺍﻨﻙ ﺘﺭﻴﺩ ﻋﻨﺩ ﺇﺭﺴﺎل ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﺍﻟﻰ ﺍل Tape Libraryﻴﺘﻡ ﺇﺴﺘﺨﺩﺍﻡ ﻗﻨﺎﺘﻴﻥ ﺘﻌﻤﻼﻥ
ﻋﻠﻰ ﺍﻟﺘﻭﺍﺯﻯ ﻟﻨﻘل ﻤﻠﻔﺎﺕ ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﻭﻴﻜﻭﻥ ﻨﻭﻉ ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ Backup Setﺘﺫﻜﺭ ﺃﻨﻪ ﻻ ﻴﻤﻜﻥ
ﺇﺭﺴﺎل ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﻤﻥ ﻨﻭﻉ Image Copyﺍﻟﻰ ﺍل. Tape Library
135
: Channel Allocation
ﻜﻤﺎ ﺫﻜﺭﻨﺎ ﺴﺎﺒﻘﹰﺎ ﻻﺒﺩ ﻤﻥ ﺘﺨﺼﻴﺹ ﻗﻨﻭﺍﺕ Channelﻹﻨﺠﺎﺯ ﻋﻤﻠﻴﺎﺕ ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ
ﻭﺍﻹﺴﺘﺭﺠﺎﻉ ﺴﻭﺍﺀ ﻜﺎﻥ ﺫﻟﻙ ﻴﺩﻭﻴﹰﺎ ﻋﻥ ﻁﺭﻴﻕ ﺍﻻﻤﺭ Allocate Channelﺍﻭ ﻋﻥ ﻁﺭﻴﻕ ﺘﻬﻴﺌﺔ ﺍﻟﻘﻨﺎﺓ
ﺒﻭﺍﺴﻁﺔ ﺍﻻﻤﺭ Configure Channelﻭﺍﻗﺼﻰ ﻋﺩﺩ ﻟل Channelsﺍﻟﺘﻰ ﻴﻤﻜﻥ ﺍﻥ ﺘﻌﻤل ﻟﻠﺘﻭﺍﺯﻯ ﻴﺭﺠﻊ
ﻟﻨﻅﺎﻡ ﺍﻟﺘﺸﻐﻴل ﻭﻫﻨﺎﻙ ﺍﻟﻌﺩﻴﺩ ﻤﻥ ﺍﻟﺨﻴﺎﺭﺍﺕ ﻟﻠﺘﺤﻜﻡ ﻓﻰ ﺍل: Channel
:DURATION -1ﻟﻠﺴﻴﻁﺭﺓ ﻋﻠﻰ ﺍﻟﻭﻗﺕ ﺍﻟﻤﺴﺘﻐﺭﻕ ﻟﺘﻨﻔﻴﺫ ﺍﻟﻤﻬﺎﻡ ﻋﻥ ﻁﺭﻴﻕ ﺍﻟﻘﻨﺎﺓ ﻭﻴﺘﻡ ﺘﺤﺩﻴﺩﻩ ﺒﺎﻟﺴﺎﻋﺎﺕ
ﻭﺍﻟﺩﻗﺎﺌﻕ ﻭﺍﻴﻀﹰﺎ ﻴﻤﻜﻥ ﺃﻥ ﻴﺅﺜﺭ ﻋﻠﻰ ﺴﺭﻋﺔ ﺘﻨﻔﻴﺫ ﺍﻟﻌﻤﻠﻴﺎﺕ ﻭﺫﻟﻙ ﺒﺈﺴﺘﺨﺩﺍﻡ ﺍﺤﺩ ﺍﻟﻤﻔﺭﺩﺍﺕ ﺍﻟﺘﺎﻟﻴﺔ
) MINIMIZE TIME ، (MINIMIZE TIME & MINIMIZE LOADﻭﻴﺘﻡ ﺘﺤﺩﻴﺩﻩ ﻟﻀﻤﺎﻥ
ﺘﻨﻔﻴﺫ ﺍﻟﻌﻤﻠﻴﺎﺕ ﺒﺎﺴﺭﻉ ﻤﺎ ﻴﻜﻭﻥ ﻭﻟﻜﻥ ﻗﺩ ﺘﺘﻡ ﺍﻟﻌﻤﻠﻴﺔ ﻗﺒل ﺇﻨﺘﻬﺎﺀ ﺍﻟﻭﻗﺕ ﺍﻟﻤﺤﺩﺩ ﻭﻴﺘﻡ ﺫﻟﻙ ﻋﺎﺩﺓ ﻋﻨﺩ ﺇﺭﺴﺎل
ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻴﺔ ﺍﻟﻰ ﺍل Tapeﻭﺫﻟﻙ ﻷﻥ ﻤﻥ ﺍﻻﻓﻀل ﺍﺭﺴﺎل ﺍﻟﺒﻴﺎﻨﺎﺕ ﺍﻟﻰ ﺍﻟﺸﺭﺍﺌﻁ ﺒﺎﺴﺭﻉ ﻤﺎ ﻴﻤﻜﻥ ،
MINIMIZE LOADﻭﻴﺘﻡ ﺘﺤﺩﻴﺩﻩ ﻟﻤﺭﺍﻗﺒﺔ ﺴﺭﻋﺔ ﻋﻤﻠﻴﺎﺕ ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﻭﺘﻘﻠﻴل ﺴﺭﻋﺘﻪ ﺇﺫﺍ ﺍﺘﻀﺢ
ﺍﻨﻪ ﺴﻴﻨﺘﻬﻰ ﻗﺒل ﺍﻟﺯﻤﻥ ﺍﻟﻤﺤﺩﺩ ﻭﻴﺘﻡ ﺘﺤﺩﻴﺩ ﻫﺫﺍ ﺍﻟﻤﺘﻐﻴﺭ ﻋﺎﺫﺩﺓ ﻋﻨﺩ ﺇﺭﺴﺎل ﻤﻠﻔﺎﺕ ﺍﻟﻨﺴﺦ ﺍﻟﻐﺤﺘﻴﺎﻁﻰ ﺍﻟﻰ
ﺍﻟﺩﻴﺴﻙ ﻭﺫﻟﻙ ﻟﺘﻘﻠﻴل ﺍﻟﺘﺎﺜﻴﺭ ﻋﻠﻰ ﺍﻟﻤﺴﺘﺨﺩﻤﻴﻥ ﻨﺴﺒﺔ ﻟﺯﻴﺎﺩﺓ ﺍﻟﻀﻐﻁ ﻋﻠﻰ ﺍﻟﺩﻴﺴﻙ.
:MAXOPENFILES -3ﻟﺘﺤﺩﻴﺩ ﻋﺩﺩ ﺍﻟﻤﻠﻔﺎﺕ ﺍﻟﺘﻰ ﺘﺴﺘﻁﻴﻊ ﺍﻟﻘﻨﺎﺓ ﻓﺘﺤﻬﺎ ﻓﻰ ﺍﻟﻤﺭﺓ ﺍﻟﻭﺍﺤﺩﺓ ﻓﻰ ﺍﻻﺼل .8
:MAXPIECESIZE -4ﻟﺘﺤﺩﻴﺩ ﺤﺠﻡ ﻤﻠﻑ ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﺍﻟﺘﻰ ﺘﻡ ﺍﻨﺸﺎﺅﻩ ﺒﻭﺍﺴﻁﺔ ﺍﻟﻘﻨﺎﺓ.
136
RMAN> CONFIGURE CHANNEL DEVICE TYPE DISK
MAXOPENFILES 6 MAXPIECESIZE 2G;
137
ﲥﻴﺌﺔ ال: CONTROLFILE AUTOBACKUP
ﺒﻤﻌﻨﻰ ﻫل ﻨﺭﻴﺩ ﻋﻤل ﻨﺴﺦ ﺇﺤﺘﻴﺎﻁﻰ ﻟﻤﻠﻑ ﺍل Control Fileﻭﻤﻠﻑ ﺍل SPFILEﺍﻟﻴﹰﺎ ﻜﻠﻤﺎ ﻗﻤﻨﺎ ﺒﻌﻤﻠﻴﺔ
ﻨﺴﺦ ﺇﺤﺘﻴﺎﻁﻰ ﺍﻡ ﻻ ؟ ﻓﻰ ﺍﻻﺼل ﻴﺄﺨﺫ ﻫﺫﺍ ﺍﻟﻤﺘﻐﻴﺭ ﺍﻟﻘﻴﻤﺔ OFFﺒﻤﻌﻨﻰ ﺃﻥ ﻤﻠﻑ ﺍل Control Fileﻻ ﻴﺘﻡ ﻋﻤل
ﻨﺴﺦ ﺇﺤﺘﻴﺎﻁﻰ ﻟﻪ ﺍﻟﻴﹰﺎ ﻋﻨﺩ ﺇﻨﺠﺎﺯ ﻋﻤﻠﻴﺎﺕ ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ.
ﻭﻴﻤﻜﻥ ﺘﻬﻴﺌﺔ ﻫﺫﺍ ﺍﻟﻤﺘﻐﻴﺭ ﺒﺤﻴﺙ ﻴﺄﺨﺫ ﺍﻟﻘﻴﻤﺔ ONﻭﺫﻟﻙ ﻟﻌﻤل ﻨﺴﺦ ﺇﺤﺘﻴﺎﻁﻰ ﺍﻟﻰ ﻟﻤﻠﻑ ﺍل CONTRPL FILEﻋﻨﺩ
ﺇﺠﺭﺍﺀ ﺍﻯ ﻋﻤﻠﻴﺔ ﻨﺴﺦ ﺇﺤﺘﻴﺎﻁﻰ ﻭﻗﺩ ﻴﻜﻭﻥ ﻫﺫﺍ ﺍﻻﻤﺭ ﺍﻜﺜﺭ ﺍﻫﻤﻴﺔ ﻋﻨﺩﻤﺎ ﻻ ﻨﺴﺘﺨﺩﻡ ﺍل Recovery Catalogﻓﺤﻴﻨﻬﺎ
ﻴﺘﻡ ﺤﻔﻅ ﻤﻌﻠﻭﻤﺎﺕ ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﻓﻰ ﻤﻠﻑ ﺍل Control Fileﺍﻻﻤﺭ ﺍﻟﺫﻯ ﻴﺠﻌل ﻋﻤﻠﻴﺔ ﺍﻟﺤﻔﺎﻅ ﻋﻠﻴﻪ ﺍﻜﺜﺭ ﺍﻫﻤﻴﺔ.
138
ﲥﻴﺌﺔ ال: EXCLUDE
ﻓﻰ ﺒﻌﺽ ﺍﻻﺤﻴﺎﻥ ﻴﻜﻭﻥ ﻟﺩﻴﻙ Tablespaceﻓﻰ ﺍﻟﻭﻀﻊ Read onlyﺍﻭ ﻓﻰ ﺍﻟﻭﻀﻊ Offline
ﺍﻭ ﺤﺘﻰ ﻗﺩ ﻴﻜﻭﻥ ﻓﻰ ﺍﻟﻭﻀﻊ Onlineﻟﻜﻨﻪ ﻏﻴﺭ ﻤﺘﺤﺭﻙ ﺍﻯ ﻴﺤﻭﻯ ﺒﻴﺎﻨﺎﺕ ﻻ ﺜﺎﺒﺘﻪ ﻓﻰ ﻫﺫﻩ ﺍﻻﺤﻭﺍل
ﻭﻏﻴﺭﻫﺎ ﻗﺩ ﻻ ﻨﺤﺘﺎﺝ ﻟﻌﻤل ﻨﺴﺦ ﺇﺤﺘﻴﺎﻁﻰ ﻟﻬﺫﻩ ﺍل Tablespaceﺍﺜﻨﺎﺀ ﻋﻤل ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﺍﻟﻜﻠﻰ ﻟﻘﺎﻋﺩﺓ
ﺍﻟﺒﻴﺎﻨﺎﺕ ﺍﻻﻤﺭ ﺍﻟﺫﻯ ﻴﻘﻠل ﻟﻨﺎ ﺯﻤﻥ ﻭﺤﺠﻡ ﻤﻠﻔﺎﺕ ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ،ﻓﻴﺘﻡ ﺘﺤﺩﻴﺩ ﻗﺎﺌﻤﺔ ﺍل Tablespaceﺍﻟﺘﻰ
ﻨﺭﻴﺩ ﺘﺠﺎﻫﻠﻬﺎ ﺍﺜﻨﺎﺀ ﻋﻤل ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ.
139
DATAFILE BACKUP COPIES & ARCHIVELOG BACKUP ﲥﻴﺌﺔ ال
:COPIES
ﺍﻭ ﻤﻠﻔﺎﺕData Filesﻟﺘﺤﺩﻴﺩ ﻋﺩﺩ ﺍﻟﻨﺴﺦ ﺍﻟﺘﻰ ﻴﺘﻡ ﺍﻨﺸﺎﺅﻫﺎ ﻋﻨﺩ ﻋﻤل ﻨﺴﺦ ﺇﺤﺘﻴﺎﻁﻰ ﻟﻤﻠﻔﺎﺕ ﺍل
Archive Log Filesﺍل
.Archive Log Files ﺍﻭ ﺍلData Filesﺘﻡ ﺘﺤﺩﻴﺩ ﻋﺩﺩ ﻨﺴﺨﺔ ﻭﺍﺤﺩﺓ ﻟﻠﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﻟﻜل ﻤﻥ ﻤﻠﻔﺎﺕ ﺍل
140
ﲥﻴﺌﺔ ال: MAXSETSIZE
ﻭﻫﻭ ﺍﻜﺒﺭ ﻤﻘﺎﺱ ﻟﻠﻨﺴﺦ ﺍﻻﺤﺘﻴﺎﻁﻴﺔ ﻤﻥ ﺍﻟﻨﻭﻉ ، Backup Setﻭﻓﻰ ﺍﻹﺼل ﻴﺎﺨﺫ ﻫﺫﺍ ﺍﻟﺨﻴﺎﺭ ﺍﻟﻘﻴﻤﺔ
.Unlimited
141
:Recovery Catalog
ﻗﺒل ﺍﻟﺤﺩﻴﺙ ﻋﻥ ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﻭﺍﻹﺴﺘﺭﺠﺎﻉ ﺒﻭﺍﺴﻁﺔ ﺍﻹﺴﺘﺭﺠﺎﻉ ﻻﺒﺩ ﻤﻥ ﺍﻟﺤﺩﻴﺙ ﻋﻥ
ﺍل Recovery Catalogﻭﺫﻟﻙ ﻷﻨﻪ ﻴﻔﻀل ﻟﻤﺩﻴﺭ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺍﺴﺘﺨﺩﺍﻡ ﺍل Recovery Catalogﻋﻨﺩ
ﺍﻟﺘﻌﺎﻤل ﻤﻊ ﺍل RMANﻭﺫﻟﻙ ﻷﻥ ﺍﻹﺤﺘﻔﺎﻅ ﺒﺎﻟﺒﻴﺎﻨﺎﺕ ﺍﻟﺨﺎﺼﺔ ﺒﺎل RMANﻭﻤﻌﻠﻭﻤﺎﺕ ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ
ﻓﻰ ﺍل Control Fileﻴﺘﻡ ﺍﻹﺤﺘﻔﺎﻅ ﺒﻬﺎ ﻟﻤﺩﺓ ﻤﺤﺩﺩ ﻴﺘﻡ ﺘﺤﺩﻴﺩﻫﺎ ﺒﻭﺍﺴﻁﺔ ﺍﻟﻤﺘﻐﻴﺭ
CONTROL_FILE_RECORD_KEEP_TIMEﻜﻤﺎ ﺫﻜﺭﺕ ﺫﻟﻙ ﺴﺎﺒﻘﹰﺎ ﻜﻤﺎ ﺃﻨﻪ ﻗﺩ ﻨﻔﻘﺩ ﻫﺫﻩ
ﺍﻟﺒﻴﺎﻨﺎﺕ ﺇﺫﺍ ﻓﻘﺩﻨﺎ ﺍل Control Fileﻭﻟﻡ ﻨﻀﻊ ﺍﻹﺤﺘﻴﺎﻁﺎﺕ ﺍﻟﻼﺯﻤﺔ.
ﺍل Recovery Catalogﻫﻭ ﻋﺒﺎﺭ Schemaﻴﺘﻡ ﺇﻨﺸﺎﺅﻫﺎ ﻓﻰ ﻏﻴﺭ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺍﻟﻤﺴﺘﻬﺩﻓﺔ
ﻟﺘﺨﺯﻴﻥ ﺍﻟﻤﻌﻠﻭﻤﺎﺕ ﺍﻻﺘﻴﺔ-:
.Data File and Archive Log File Backup Sets and Backup Pieces -1
.Data File Copies -2
.Archive Log Files -3
.The Physical Structure of The Target Database -4
.Persistent RMAN Configuration Settings -5
.Stored Job Scripts -6
142
ﻭﻤﻥ ﺜﻡ ﺴﻨﺴﺘﺨﺩﻤﻪ ﻓﻴﻤﺎ ﺒﻌﺩ ﻟﻌﻤل ﺍﻟﻨﺴﺦRecovery Catalogﻟﺫﺍ ﺴﺄﻗﻭﻡ ﻫﻨﺎ ﺒﺈﻨﺸﺎﺀ ﺍل
: ﻭﺍﻟﻴﻙ ﺨﻁﻭﺍﺕ ﺍﻹﻨﺸﺎﺀ، ﺍﻹﺤﺘﻴﺎﻁﻰ ﻭﺍﻹﺴﺘﺭﺠﺎﻉ
.Catalog Database ﻓﻰ ﺍلRecovery Catalog ﻟلTablespace ﺇﻨﺸﺎﺀ-1
143
-4ﻨﻘﻭﻡ ﺒﺈﻨﺸﺎﺀ ﺍل Catalogﻋﻥ ﻁﺭﻴﻕ ﺍل RMANﺒﻌﺩ ﺍﻹﺘﺼﺎل ﺒﺎل Catalog Databaseﻭﻫﻭ ﺒﻤﻌﻨﻰ
ﺘﻌﺭﻴﻑ ﺘﻌﺭﻴﻑ ﺍل RMANﻋﻠﻰ ﺍل Catalogﺍﻟﺫﻯ ﻗﻤﻨﺎ ﺒﺨﻠﻘﻪ ﻓﻰ ﺍﻟﺨﻁﻭﺍﺕ ﺍﻟﺴﺎﺒﻘﺔ.
ﻓﻰ ﻫﺫﻩ ﺍﻟﻠﺤﻅﺔ ﻴﺘﻡ ﺇﻨﺸﺎﺀ ﺍﻟﺠﺩﺍﻭل ﻭﺍﻟﻤﻨﺎﻅﻴﺭ ) (Tables and Viewsﺍﻟﺘﻰ ﺴﻭﻑ ﻴﺘﻡ ﺘﺨﺯﻴﻥ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻓﻴﻬﺎ
ﻓﻰ ﺍل.Recovery Catalog schema
-5ﻨﻘﻭﻡ ﺒﺘﺴﺠﻴل ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺍﻟﻤﺴﺘﻬﺩﻓﺔ ﻓﻰ ﺍل Catalogﻭﺫﻟﻙ ﻋﻥ ﻁﺭﻴﻕ ﺍل RMANﺒﻌﺩ ﺍﻹﺘﺼﺎل
ﺒﻜل ﻤﻥ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺍﻟﻤﺴﺘﻬﺩﻓﺔ Target Databaseﻭﺍﻹﺘﺼﺎل ﺒﺎل Recovery Catalogﻜﻤﺎ ﻴﺠﺏ
ﺍﻻﺸﺎﺭﺓ ﺇﻟﻰ ﻀﺭﻭﺭﺓ ﺍﻹﺘﺼﺎل ﻤﻊ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺍﻟﻤﺴﺘﻬﺩﻓﺔ ﺒﻭﺍﺴﻁﺔ ﻤﺴﺘﺨﺩﻡ ﻴﻤﻠﻙ ﺍﻟﺼﻼﺤﻴﺔ SYSDBA
،ﻭﻤﻥ ﺜﻡ ﺘﺴﺠﻴل ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺍﻟﻤﺴﺘﻬﺩﻓﺔ ﻓﻰ ﺍل.Catalog
144
ﺍﻻﻥ ﺴﻭﻑ ﻴﺘﻡ ﺘﺴﺠﻴل ﻫﻴﻜﻠﺔ ﺒﻴﺎﻨﺎﺕ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺍﻟﻤﺴﺘﻬﺩﻓﺔ ﻓﻰ ﺠﺩﺍﻭل ﺍل Recovery Catalogﺍﻯ ﻓﻰ
ﺍﻟﻤﺴﺘﺨﺩﻡ
ﻓﻰ ﻫﺫﻩ ﺍﻟﻠﺤﻅﺔ ﻴﺘﻡ ﺘﺴﺠﻴل ﺍﻟﺒﻴﺎﻨﺎﺕ ﺍﻟﺨﺎﺼﺔ ﺒﻘﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺍﻟﻤﺴﺘﻬﺩﻓﺔ ﻓﻰ ﺍلRecovery Catalog
ﻴﻤﻜﻨﻙ ﻋﻤل ﺇﺴﺘﻌﻼﻡ ﻋﻥ ﺫﻟﻙ ﻓﻰ ﺍﻟﺠﺩﺍﻭل ﺍﻟﻤﻭﺠﻭﺩﺓ ﻓﻰ ﺍل Schema Recovery Catalogﻭﻫﻰ ﻫﻨﺎ
ﺘﺴﻤﻰ Test
ﺍﻻﻥ ﻟﺩﻴﻨﺎ ﻗﺎﻋﺩﺓ ﺒﻴﺎﻨﺎﺕ ﻤﺴﺘﻬﺩﻓﺔ Target Catalogﻭﻟﺩﻴﻨﺎ ٌ. Recovery Catalog
ﺒﺎﻟﻁﺒﻊ ﺇﺫﺍ ﻟﻡ ﻴﺘﻡ ﺘﺴﺠﻴل ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻓﻠﻥ ﻨﺴﺘﻁﻴﻊ ﺘﺨﺯﻴﻥ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻋﻥ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺍﻟﻤﺴﺘﻬﺩﻓﺔ ﻓﻰ
لRecovery Catalog
ﺍٌ
ﺍﻻﻥ ﻫﻴﻜﻠﺔ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺍﻟﻤﺴﺘﻬﺩﻓﺔ ﻤﺨﺯﻨﺔ ﻟﺩﻯ ﻓﻰ ﺍل Recovery Catalogﻭﺒﺎﻟﻁﺒﻊ ﻟﻴﺱ ﻟﺩﻯ
ﻀﻤﺎﻥ ﻤﻥ ﺃﻥ ﻴﺘﻡ ﺘﻐﻴﻴﺭ ﻫﻴﻜﻠﺔ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺍﻟﻤﺴﺘﻬﺩﻓﺔ ﻟﺫﺍ ﻨﺤﺘﺎﺝ ﻹﻋﺎﺩﺓ ﺘﺯﺍﻤﻥ ﺍلRecovery Catalog
ﻤﻥ ﺍل Control Fileﻟﺩﻯ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺍﻟﻤﺴﺘﻬﺩﻓﺔ ﺤﺘﻰ ﻴﺘﻡ ﺘﺯﺍﻤﻥ ﻜﺎﻤل ﺒﻴﻥ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺍﻟﻤﺴﺘﻬﺩﻓﺔ
ﻭﺍل Recovery Catalogﻓﻰ ﺍﻟﺤﻘﻴﻘﺔ ﺍل RMANﺘﻘﻭﻡ ﺒﻌﻤل ﻫﺫﺍ ﺍﻟﺘﺯﺍﻤﻥ ﺍﻟﻴﹰﺎ ﻤﺘﻰ ﺍﺤﺘﺎﺠﺔ ﺍﻟﻰ ﺫﻟﻙ ،
ﺍﻨﺕ ﺍﻴﻀﹰﺎ ﻗﺩ ﺘﻘﻭﻡ ﺒﺫﻟﻙ ﻴﺩﻭﻴﹰﺎ ﺒﻭﺍﺴﻁﺔ ﺍﻻﻤﺭ RESYNC CATALOG
145
;RMAN> RESYNC CATALOG
ﻋﻤﻭﻤﹰﺎ ﻗﺩ ﻨﺤﺘﺎﺝ ﺇﻟﻰ ﻫﺫﺍ ﺍﻹﺠﺭﺍﺀ ﻋﻨﺩ ﺇﻨﺸﺎﺀ ﺍﻭ ﺤﺫﻑ Tablespaceﺍﻭ Data Fileﺍﻭ ﻋﻨﺩ
ﺘﻐﻴﻴﺭ ﻤﻜﺎﻥ ﺍل.Database Files
ﻓﻰ ﺒﻌﺽ ﺍﻹﺤﻴﺎﻥ ﻴﺘﻡ ﻓﺘﺢ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺍﻟﻤﺴﺘﻬﺩﻓﺔ ﻓﻰ ﺍﻟﻭﻀﻊ RESTLOGSﻻ ﺸﻙ ﺃﻥ ﻓﻰ
ﻤﺜل ﻫﺫﻩ ﺍﻟﺤﺎﻟﺔ ﻻ ﻴﻜﻭﻥ ﺘﺯﺍﻤﻥ ﺒﻴﻥ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺍﻟﻤﺴﺘﻬﺩﻓﺔ ﻭﺍل Recovery Catalogﻟﺫﺍ ﻓﻰ ﻤﺜل ﻫﺫﻩ
ﺍﻟﺤﺎﻟﺔ ﻨﺴﺘﺨﺩﻡ ﺍﻻﻤﺭ .REST DATABASE
ﻋﻤﻭﻤﹰﺎ ﻫﺫﺍ ﻟﻴﺱ ﻜل ﺸﺊ ﻋﻥ ﺍل Recovery Catalogﻭﻟﻜﻥ ﻫﺫﺍ ﻤﺎ ﻴﻬﻤﻨﺎ ﺍﻻﻥ ﻭﺴﻨﻭﺍﺼل
ﺍﻟﻨﻘﺎﺵ ﻓﻰ ﻫﺫﺍ ﺍﻟﻤﻭﻀﻭﻉ ﻻﺤﻘﹰﺎ .ﻭﻟﻜﻥ ﻴﺠﺏ ﺃﻥ ﺘﺘﺫﻜﺭ ﺃﻨﻙ ﻗﺩ ﻻ ﺘﺤﺘﺎﺝ ﺍل Recovery Catalogﺇﻁﻼﻗﹰﺎ ،
ﻓﻘﺩ ﺘﺘﺼل ﺒﻘﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺍﻟﻤﺴﺘﻬﺩﻓﺔ ﻋﻥ ﻁﺭﻴﻕ ﺍل RMANﻭﻤﻥ ﺜﻡ ﺘﻨﺠﺯ ﻤﻬﺎﻤﻙ ﻟﻜﻥ ﺘﺫﻜﺭ ﺃﻥ ﻤﻥ
ﺍﻻﻓﻀل ﻟﻙ ﺃﻥ ﺘﺴﺘﺨﺩﻡ ﺍل.Recovery Catalog
146
:RMAN Backups
ﻭﻫﺫﺍ ﻫﻭ ﺒﻴﺕ ﺍﻟﻘﺼﻴﺩ ﻓﻜل ﻤﺎ ﺘﺤﺜﻨﺎ ﻋﻨﻪ ﺴﺎﺒﻘﹰﺎ ﻓﻰ ﻫﺫﺍ ﺍﻟﻔﺼل ﻤﺎ ﻫﻭ ﺇﻻ ﺘﻤﻬﻴﺩ ﻟﻬﺫﻩ ﺍﻟﻤﺭﺤﻠﺔ
ﻤﺭﺤﻠﺔ ﻋﻤل ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﻟﻘﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ،ﻭﺍﻟﺤﻘﻴﻘﺔ ﺃﻥ ﺍل RMANﺘﻭﻓﺭ ﻋﻤل ﻨﺴﺦ ﺇﺤﺘﻴﺎﻁﻰ ﻟﻜل
ﻤﻥ ﺍل)(Database & Tablespaces & Data Files & Control Files & Archive Log Files
ﻭﻓﻰ ﺍﻻﺼل ﻴﺘﻡ ﺘﺨﺯﻴﻥ ﻤﻠﻔﺎﺕ ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﻓﻰ ﺍل Flash Recovery Areaﻤﺎ ﻟﻡ ﻴﺘﻡ ﺘﺤﺩﻴﺩ ﻤﻜﺎﻥ
ﺘﺨﺯﻴﻥ ﺍﺨﺭ ﻟﻤﻔﺎﺕ ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﺍﺜﻨﺎﺀ ﻋﻤل ﺍﻟﻨﺴﺦ ﺒﻭﺍﺴﻁﺔ ﺍﻟﻤﺘﻐﻴﺭ Formatﻟﺘﺤﺩﻴﺩ ﺍﻟﻤﺴﺎﺭ ﻭﺇﺴﻡ ﻤﻠﻑ
ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ،ﻭﻟﻜﻥ ﺘﻔﻀل ﺸﺭﻜﺔ ﺍﻭﺭﻜل ﺍﺴﺘﺨﺩﺍﻡ ﺍﻟﻤﺴﺎﺤﺔ Flash Recovery Areaﻟﺘﺨﺯﻴﻥ ﻤﻠﻔﺎﺕ
ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﻭﺫﻟﻙ ﻷﻥ ﺍﺩﺍﺭﺘﻬﺎ ﺘﺘﻡ ﺒﻭﺍﺴﻁﺔ ﺍﻻﻭﺭﻜل ﻭﻴﺘﻡ ﺘﺤﺩﻴﺩ ﻤﺴﺎﺭ ﻫﺫﻩ ﺍﻟﻤﺴﺎﺤﺔ ﺒﻭﺍﺴﻁﺔ ﺍﻟﻤﺘﻐﻴﺭ
DB_RECOVERY_FILE_DESTﻭﻴﺘﻡ ﺘﺤﺩﻴﺩ ﻤﺴﺎﺤﺘﻬﺎ ﺒﻭﺍﺴﻁﺔ ﺍﻟﻤﺘﻐﻴﺭ
.DB_RECOVERY_FILE_DEST_SIZE
ﻭﺴﻨﺘﺤﺩﺙ ﻫﻨﺎ ﻋﻥ ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﺒﻭﺍﺴﻁﺔ ﺍل RMANﻭﻟﻜﻥ ﻴﺠﺏ ﺍﻟﺘﺫﻜﻴﺭ ﺃﻥ ﺍل RMANﻻ
ﺘﺩﻋﻡ ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﻟﻤﻠﻔﺎﺕ ﺍل Online Redo Log Filesﻭﺇﻨﻤﺎ ﺘﺩﻋﻡ ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﻟل Archive
.Log Filesﻜﻤﺎ ﻴﺠﺏ ﺍﻟﺘﺫﻜﻴﺭ ﺍﻴﻀﹰﺎ ﺃﻨﻪ ﺒﺈﻤﻜﺎﻨﻙ ﺇﺴﺘﺨﺩﺍﻡ ﺍل RMANﻟﻌﻤل ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﻟﻘﺎﻋﺩﺓ
ﺍﻟﺒﻴﺎﻨﺎﺕ ﺤﺘﻰ ﻭﻟﻭ ﻜﺎﻨﺕ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺘﻌﻤل ﻓﻰ ﺍﻟﻨﻤﻁ .NOARCHIVELOG
147
:Data Files Backup
ﺘﺴﺘﻁﻴﻊ ﻋﻥ ﻁﺭﻴﻕ ﺍل RMANﻋﻤل ﻨﺴﺦ ﺇﺤﺘﻴﺎﻁﻰ ﻟﻤﻠﻔﺎﺕ ﺍل Data Filesﺒﺸﺭﻁ ﺃﻥ ﺘﻜﻭﻥ
ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻓﻰ ﺍﻟﻭﻀﻊ ، Open or Mountﺍﻤﺎ ﺍل Recovery Catalogﻓﻴﺠﺏ ﺃﻥ ﺘﻜﻭﻥ ﻤﻔﺘﻭﺤﺔ ،
ﻭﻫﻨﺎﻙ ﻋﺩﺩ ﻤﻥ ﺍﻟﺨﻴﺎﺭﺍﺕ ﻟﻌﻤل ﻨﺴﺦ ﺇﺤﺘﻴﺎﻁﻰ ) (Backupﻟل:Data Files
ﻻﺤﻅ ﻤﻌﻰ ﻗﻤﺕ ﺒﻌﻤل ﻨﺴﺦ ﺇﺤﺘﻴﺎﻁﻰ ﻟﻜل ﻤﻥ ) Datafile(1&2ﻭﺍﻟﺭﻗﻡ 1ﻭ 2ﻫﻭ ﻋﺒﺎﺭﺓ ﻋﻥ ﺍل File
ﻻ ﻤﻥ ﻜﺘﺎﺒﺔ ﺍل Idﻟﻜﻥ ﺒﺎﻟﻁﺒﻊ ﻫﺫﺍ ﺍﺴﻬل ﻴﻤﻜﻨﻙ ﻤﻌﺭﻓﺔ
، Idﺒﺎﻟﻁﺒﻊ ﻴﻤﻜﻥ ﻜﺘﺎﺒﺔ ﺍﺴﻡ ﺍل Data Fileﺒﺩ ﹰ
ﺍل File Idﻋﻥ ﻁﺭﻴﻕ ﺍﻹﺴﺘﻌﻼﻡ ﺍﻻﺘﻰ
148
ﻜﻤﺎ ﻗﻤﻨﺎ ﺒﻌﻤل ﺘﺴﻤﻴﺔ ﻤﻨﻁﻘﻴﺔ ﻟﻬﺫﺍ ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﺒﻭﺍﺴﻁﺔ ﺍﻟﻤﺘﻐﻴﺭ TAGﻭﺴﻤﻴﻨﺎﻩ )FILE(1,2
،ﻜﻤﺎ ﻴﻤﻜﻨﻙ ﻤﻼﺤﻅﺔ ﺃﻨﻨﺎ ﻟﻡ ﻨﻘﻡ ﺒﺈﻨﺸﺎﺀ ﻗﻨﻭﺍﺕ ﻟﻠﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﻴﺩﻭﻴﹰﺎ Channelsﻭﺇﻨﻤﺎ ﻗﺎﻤﺕ
ﺍل RMANﺒﺈﺴﺘﺨﺩﺍﻡ ﺍﻟﺘﻬﻴﺌﺔ ﺍﻻﻟﻴﺔ .Configuration Setting
ﻋﻤﻭﻤﹰﺎ ﻴﻤﻜﻨﻨﺎ ﺍﻟﺘﺄﻜﺩ ﻤﻥ ﻋﻤﻠﻴﺔ ﻨﺠﺎﺡ ﻋﻤﻠﻴﺔ ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﺒﻭﺍﺴﻁﺔ ﺍﻻﻤﺭ LISTﺤﻴﺙ ﻴﻘﻭﻡ ﺒﻌﺭﺽ
ﺘﻔﺎﺼﻴل ﻋﻤﻠﻴﺔ ﺍﻟﻨﺴﺢ ﺍﻹﺤﺘﻴﺎﻁﻰ ،ﻓﺈﺫﺍ ﻜﺘﺒﻨﺎ LIST BACKUPSETﻴﻘﻭﻡ ﻫﺫﺍ ﺍﻻﻤﺭ ﺒﻌﺭﺽ ﺠﻤﻴﻊ
ﺘﻔﺎﺼﻴل ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﺍﻟﻤﺨﺯﻨﺔ ﻓﻰ ﺍل Recovery Catalogﻤﻥ ﺍﻟﻨﻭﻉ ، Backup Setﺃﻤﺎ ﺍﻻﻤﺭ
LIST COPYﻟﻌﺭﺽ ﺘﻔﺎﺼﻴل ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﻤﻥ ﺍﻟﻨﻭﻉ IMAGE COPYﻭﻏﻴﺭﻩ ﻤﻥ ﺍﻻﻭﺍﻤﺭ
ﺍﻟﺘﻰ ﺴﻨﺘﺤﺩﺙ ﻋﻨﻬﺎ ﻻﺤﻘﹰﺎ ﻤﺎ ﻴﻬﻤﻨﺎ ﺍﻻﻥ ﺍﻟﺘﺄﻜﺩ ﻤﻥ ﺍﻟﻨﺴﺦ ﺍﻻﺤﺘﻴﺎﻁﻰ ﺍﻟﺫﻯ ﻗﻤﻨﺎ ﺒﻪ ﺍﻻﻥ ﻭﻻﺤﻅ ﺍﻥ ﺍﺴﻤﻪ
ﺍﻟﻤﻨﻁﻘﻰ ") "FILE(1,2ﻓﻴﻤﻜﻥ ﻋﺭﺽ ﺘﻔﺎﺼﻴﻠﻪ ﺒﻭﺍﺴﻁﺔ ﺍﻻﻤﺭ LIST BACKUPSET TAG
”)“FILE(!,2
ﺍﻤﺎ ﺇﺫﺍ ﻟﻡ ﺘﻀﻊ ﺍﺴﻡ ﻤﻨﻁﻘﻰ ﻟﻠﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﻓﺎﻥ ﺍل RMANﺴﺘﻀﻊ ﻟﻪ ﺍﺴﻡ ﺇﺤﺘﻴﺎﻁﻰ ﺍﻟﻴﹰﺎ ،ﻜﻤﺎ ﻴﻤﻜﻨﻙ
ﻋﺭﺽ ﻤﻌﻠﻭﻤﺎﺕ ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﺍﻟﺴﺎﺒﻕ ﺒﻭﺍﺴﻁﺔ ﺍﻻﻤﺭ
LIST BACKUP OF DATAFILE 1,2
149
Data Files Backup as Image Copy -2
RMAN> RUN {
ALLOCATE CHANNEL D1 DEVICE TYPE DISK;
ALLOCATE CHANNEL D2 DEVICE TYPE DISK;
BACKUP AS COPY DATAFILE 3,4
(DATAFILE 3 CHANNEL D1)
(DATAFILE 4 CHANNEL D2)
; }
150
ﻗﻤﻨﺎ ﺒﻌﻤل ﻨﺴﺦ ﺇﺤﺘﻴﺎﻁﻰ ﻟل) Data Files(3,4ﻤﻥ ﺍﻟﻨﻭﻉ Image Copyﻭﻗﺩ ﻗﻤﻨﺎ ﺒﺈﻨﺸﺎﺀ ﻗﻨﺎﺘﻴﻥ
Channelsﻴﺩﻭﻴﹰﺎ ﻭﻗﻤﻨﺎ ﺒﺈﺭﺴﺎل ﻤﻠﻔﺎﺕ ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﺇﻟﻰ ﺍﻟﺩﻴﺴﻙ.
ﻴﻤﻜﻥ ﺍﻟﺘﺄﻜﺩ ﻤﻥ ﻨﺠﺎﺡ ﻋﻤﻠﻴﺔ ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﺒﻭﺍﺴﻁﺔ ﺍﻻﻤﺭ
LIST COPY OF DATAFILE 3,4
151
:Tablespaces Backup
{RMAN> RUN
ALLOCATE CHANNEL D1 DEVICE TYPE DISK
;MAXPIECESIZE 1G
BACKUP AS COMPRESSED BACKUPSET
;TABLESPACE USERS
}
ﻴﻤﻜﻥ ﺒﺎﻟﻁﺒﻊ ﻋﻤل ﻨﺴﺦ ﺇﺤﺘﻴﺎﻁﻰ ﻟل Tablespaceﻤﻥ ﺍﻟﻨﻭﻉ Image Copy
152
ﻴﻤﻜﻥ ﺍﻟﺘﺄﻜﺩ ﻤﻥ ﻨﺠﺎﺡ ﻋﻤﻠﻴﺔ ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﺍﻋﻼﻩ ﺒﻭﺍﺴﻁﺔ ﺍﻻﻤﺭ
LIST BACKUPSET OF TABLESPACE USERS
ﻟﻌﺭﺽ ﻤﻌﻠﻭﻤﺎﺕ ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﻤﻥ ﺍﻟﻨﻭﻉ Users Tablespace Backupset
LIST COPY OF TABLESPACE USERS
ﻟﻌﺭﺽ ﻤﻌﻠﻭﻤﺎﺕ ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﻤﻥ ﺍﻟﻨﻭﻉ Users Tablespace Image Copy
153
:Archived Redo Log Files Backup
RMAN> RUN{
ALLOCATE CHANNEL D1 DEVICE TYPE DISK;
ALLOCATE CHANNEL D2 DEVICE TYPE DISK;
ALLOCATE CHANNEL D3 DEVICE TYPE DISK;
BACKUP AS copy archivelog all DELETE ALL INPUT;
}
ﻗﻤﻨﺎ ﺒﻌﻤل ﻨﺴﺦ ﺇﺤﺘﻴﺎﻁﻰ ﺠﻤﻴﻊ ﻤﻠﻔﺎﺕ ﺍﻹﺭﺸﻴﻑ ﻭﻤﻥ ﺜﻡ ﻤﺴﺢ ﺍﻟﻤﻠﻔﺎﺕ ﺒﻌﺩ ﻨﺴﺨﻬﺎ ﻭﺫﻟﻙ ﻷﻨﻨﺎ ﻻ
ﻻﺤﻅ ﺃﻨﻨﺎ ﻗﻤﻨﺎ ﺒﻌﻤل ﻨﺴﺦ، ﻭﻤﺘﻰ ﻤﺎ ﺍﺤﺘﺠﻨﺎ ﻟﻬﺎ ﺴﻨﺠﺩﻫﺎ ﻓﻰ ﻤﻠﻔﺎﺕ ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ، ﻨﺤﺘﺎﺝ ﺍﻟﻴﻬﺎ ﺍﻻﻥ
ﺍﻨﺕ ﻴﻤﻜﻥ ﺍﻥ ﺘﻘﻭﻡ ﺒﻌﻤل ﻨﺴﺦ ﺇﺤﺘﻴﺎﻁﻰ ﻟﻤﻠﻔﺎﺕ ﺍﻻﺭﺸﻴﻑ ﺍﻟﺘﻰ ﺘﺤﺘﺎﺠﻬﺎ، ﺇﺤﺘﻴﺎﻁﻰ ﻟﻜل ﻤﻠﻔﺎﺕ ﺍﻻﺭﺸﻴﻑ
RMAN> RUN{
ALLOCATE CHANNEL D1 DEVICE TYPE DISK;
ALLOCATE CHANNEL D2 DEVICE TYPE DISK;
ALLOCATE CHANNEL D3 DEVICE TYPE DISK;
BACKUP AS copy archivelog until sequence 130;
}
154
ﻴﻤﻜﻨﻙ ﺍﻟﻘﻴﺎﻡ ﺒﻌﺭﺽ ﻤﻌﻠﻭﻤﺎﺕ ﻋﻥ ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﻟﻤﻠﻔﺎﺕ ﺍﻻﺭﺸﻴﻑ ﺒﻭﺍﺴﻁﺔ ﺍﻻﻤﺭ
LIST COPY OF ARCHIVELOG ALL
ﻟﻌﺭﺽ ﻤﻌﻠﻭﻤﺎﺕ ﻋﻥ ﺠﻤﻴﻊ ﻤﻠﻔﺎﺕ ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﻤﻥ ﺍﻟﻨﻭﻉ Image Copyﻟﻤﻠﻔﺎﺕ ﺍﻻﺭﺸﻴﻑ.
LIST BACKUP OF ARCHIVELOG ALL
ﻟﻌﺭﺽ ﻤﻌﻠﻭﻤﺎﺕ ﻋﻥ ﺠﻤﻴﻊ ﻤﻠﻔﺎﺕ ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﻤﻥ ﺍﻟﻨﻭﻉ Backupsetﻟﻤﻠﻔﺎﺕ ﺍﻻﺭﺸﻴﻑ.
ﻜﻤﺎ ﻴﻤﻜﻨﻙ ﺍﻟﻘﻴﺎﻡ ﺒﻌﺭﺽ ﻤﻌﻠﻭﻤﺎﺕ ﻋﻥ ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﻟﺒﻌﺽ ﻤﻠﻔﺎﺕ ﺍﻻﺭﺸﻴﻑ
155
:Control File Backup
-:Control Fileﻫﻨﺎﻙ ﻋﺩﺓ ﻁﺭﻕ ﻟﻌﻤل ﻨﺴﺦ ﺇﺤﺘﻴﺎﻁﻰ ﻟل
.CURRENT COTROL FILE ﻋﻥ ﻁﺭﻴﻕ ﺍﻻﻤﺭ-1
ﻭﺍﻴﻀﹰﺎ ﻴﻤﻜﻥ ﻀﻐﻁﻪ ﺒﻭﺍﺴﻁﺔBackupset ﻤﻥ ﺍﻟﻨﻭﻉControl Fileﺍﻴﻀﹰﺎ ﻴﻤﻜﻥ ﻋﻤل ﻨﺴﺦ ﺇﺤﺘﻴﺎﻁﻰ ﻟل
.Compressed Backupset ﺍﻻﻤﺭ
ﻓﻬﺫﺍ ﻴﻌﻨﻰ ﺃﻨﻪ ﻜﻠﻤﺎ ﻗﻤﻨﺎON ﺍﻟﻘﻴﻤﺔCONTROLFILE AUTOBACKUP ﻋﻨﺩﻤﺎ ﻴﺄﺨﺫ ﺍﻟﻤﺘﻐﻴﺭ
.Control Fileﺒﻌﻤﻠﻴﺔ ﻨﺴﺦ ﺇﺤﺘﻴﺎﻁﻰ ﻓﺈﻨﻪ ﺍﻟﻴﹰﺎ ﺴﻴﺘﻡ ﻋﻤل ﻨﺴﺦ ﺇﺤﺘﻴﺎﻁﻰ ﻟﻤﻠﻑ ﺍل
ﺒﻭﺍﺴﻁﺔ ﺍﻻﻤﺭControl fileﻜﻤﺎ ﻴﻤﻜﻥ ﻋﻤل ﺇﺴﺘﻌﻼﻡ ﻋﻥ ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﻟل
LIST BACKUP OF CONTROLFILE
156
:Database Backup
:Offline Backup -1
ﺘﺴﺘﻁﻴﻊ ﻋﻤل ﻨﺴﺦ ﺇﺤﺘﻴﺎﻁﻰ ﻟﻘﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻋﻥ ﻁﺭﻴﻕ ﺍل RMANﻓﻰ ﺍﻟﻭﻀﻊ MOUNT
ﻼ ﺇﺫﺍ ﻜﺎﻨﺕ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺘﻌﻤل ﻓﻰ ﺍﻟﻨﻤﻁ
ﻭﻫﻭ ﻤﺎ ﻴﺴﻤﻰ ﺒﺎل ، Offline Backupﻓﻤﺜ ﹰ
NOARCHIVELOGﻓﺤﻴﻨﻬﺎ ﻻﺒﺩ ﻤﻥ ﻋﻤل ﻨﺴﺦ ﺍﺤﺘﻴﺎﻁﻰ ﻟﻘﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺒﻌﺩ ﺇﻏﻼﻗﻬﺎ ) Offline
، (Backupﻭﺍﻴﻀﹰﺎ ﻻﺒﺩ ﻤﻥ ﺍﻹﺸﺎﺭﺓ ﺇﻟﻰ ﺃﻥ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻤﺎﺩﺍﻡ ﺃﻨﻬﺎ ﻓﻰ ﺍﻟﻨﻤﻁ NOARCHIVELOG
ﻓﻼﺒﺩ ﻤﻥ ﻋﻤل ﻨﺴﺦ ﺍﺤﺘﻴﺎﻁﻰ ﻟﺠﻤﻴﻊ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻭﻻﺒﺩ ﻤﻥ ﻋﻤل ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﺒﻌﺩ ﺇﻏﻼﻗﻬﺎ
).(Offline Backup
{ RMAN> RUN
;SHUTDOWN IMMEDIATE
;STARTUP MOUNT
;ALLOCATE CHANNEL D1 TYPE DISK
;ALLOCATE CHANNEL D2 TYPE DISK
BACKUP AS COMPRESSED BACKUPSET DATABASE
;FILESPERSET 2
;ALTER DATABASE OPEN
}
157
ﻫﻜﺫﺍ ﻗﻤﻨﺎ ﺒﻌﻤل ﻨﺴﺦ ﺇﺤﺘﻴﺎﻁﻰ ﻟﻘﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺒﻌﺩ ﺇﻏﻼﻗﻬﺎ ،ﻭﻴﺠﺏ ﺍﻟﺘﺫﻜﻴﺭ ﺒﺄﻥ ﻤﻠﻔﺎﺕ ﻗﺎﻋﺩﺓ
ﺍﻟﺒﻴﺎﻨﺎﺕ ﺴﻭﻑ ﻴﺘﻡ ﺍﺭﺴﺎﻟﻬﺎ ﺇﻟﻰ ﺍﻟﺩﻴﺴﻙ ﻤﻊ ﺍﻟﻌﻠﻡ ﺒﺄﻨﻙ ﺘﺴﺘﻁﻴﻊ ﺍﺭﺴﺎل ﺍﻟﻤﻠﻔﺎﺕ ﺇﻟﻰ ﺍلTape
.ALLOCATE CHANNEL T1 TYPE SBT
ﺒﺎﻟﻁﺒﻊ ﻋﻨﺩ ﻋﻤل ﻨﺴﺦ ﺇﺤﺘﻴﺎﻁﻰ ﻟﻘﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻓﻬﺫﺍ ﻴﻌﻨﻰ ﺒﺄﻨﻨﺎ ﻗﻤﻨﺎ ﺒﻌﻤل ﻨﺴﺦ ﺇﺤﺘﻴﺎﻁﻰ ﻟﺠﻤﻴﻊ ﺍل Data
Filesﺍﻭ ﺇﻥ ﺸﺌﺕ ﻓﻘل ﺠﻤﻴﻊ ﺍل Tablespacesﻤﺎ ﺩﺍﻡ ﺃﻨﻨﺎ ﻟﻡ ﻨﻘﻡ ﺒﺈﺴﺘﺜﻨﺎﺀ ﺒﻌﺽ ﺍل، Tablespaces
ﻭﻴﻤﻜﻨﻙ ﺇﺴﺘﺜﻨﺎﺀ ﺒﻌﺽ ﺍل Tablespacesﺒﻭﺍﺴﻁﺔ ﺍﻟﻤﺘﻐﻴﺭ
158
:Online Backup -2
ﻭﻫﻨﺎ ﻻﺒﺩ ﺃﻥ ﺘﻜﻭﻥ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻓﻰ، ﻭﻫﻭ ﻋﻤل ﻨﺴﺦ ﺇﺤﺘﻴﺎﻁﻰ ﻟﻘﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻭﻫﻰ ﻤﻔﺘﻭﺤﺔ
.ARCHIVELOG ﺍﻟﻭﻀﻊ
RMAN>RUN{
ALLOCATE CHANNEL D1 TYPE DISK;
ALLOCATE CHANNEL D2 TYPE DISK;
ALLOCATE CHANNEL D3 TYPE DISK;
BACKUP AS COMPRESSED BACKUPSET
DATABASE INCLUDE CURRENT CONTROLFILE PLUS
ARCHIVELOG;
}
159
ﻫﻜﺫﺍ ﻗﻤﻨﺎ ﺒﻌﻤل Online Full Backupﻟﻘﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻭﺫﻟﻙ ﺒﺈﺴﺘﺨﺩﺍﻡ ﺍﻟﺨﻴﺎﺭ Compressed
ﺍﻯ ﻗﻤﻨﺎ ﺒﻀﻐﻁ ﻤﻠﻔﺎﺕ ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﻭﻻﺤﻅ ﻤﻌﻰ ﺍﻨﻨﺎ ﺍﻀﻔﻨﺎ ﺍﻟﻰ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻤﻠﻔﺎﺕ ﺍﻻﺭﺸﻴﻑ ﻭﻤﻠﻑ
ﺍل ، Control Fileﻴﻤﻜﻨﻨﺎ ﺍﻟﺘﺄﻜﺩ ﻤﻥ ﻨﺠﺎﺡ ﻋﻤﻠﻴﺔ ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﺒﻭﺍﺴﻁﺔ ﺍﻻﻤﺭ.
:Incremental Backups
ﺫﻜﺭﺕ ﺴﺎﺒﻘﹰﺎ ﺃﻥ ﺍل RMANﺘﻭﻓﺭ ﺨﻴﺎﺭﺍﺕ ﺍﻟﻨﺴﺦ ﺍﻟﺘﻜﺎﻤﻠﻴﺔ ﻭﺍﻟﺘﺯﺍﻴﺩﻴﺔ ،ﺘﺴﺘﻁﻴﻊ ﺨﻼﻟﻬﺎ ﻋﻤل ﻨﺴﺦ
ﺇﺤﺘﻴﺎﻁﻰ ﻟﻠﻜﺘل ﺍﻟﺘﻰ ﺘﻡ ﺘﻐﻴﺭﻫﺎ ﻓﻘﻁ ﺨﻼل ﺍﺨﺭ ﺍﻨﺴﺦ ﺇﺤﺘﻴﺎﻁﻰ.
160
:Incremental Backup Level 0-1
Level 0ﻋﺒﺎﺭﺓ ﻋﻥ ﻨﺴﺦ ﺍﺤﺘﻴﺎﻁﻴﺔ ﺘﻜﺎﻤﻠﻴﺔ ﺘﺤﻭﻯ ﺠﻤﻴﻊ ﺍﻟﻜﺘل ﻭﺍﻟﻔﺭﻕ ﺒﻴﻨﻬﺎ ﻭﺍلFull Backup
ﻫﻭ ﺃﻥ ﻫﺫﻩ ﺍﻟﻨﺴﺦ ﺘﺴﺘﻁﻴﻊ ﺃﻥ ﺘﻜﻭﻥ ﺍﺴﺎﺱ ﻟﻠﻜﺘل ﺍﻟﺘﻜﺎﻤﻠﻴﺔ ﺍﻻﺨﺭﻯ ،ﺃﻤﺎ ﻤﻥ ﺤﻴﺙ ﺍﻟﺘﻁﺒﻴﻕ ﻓﺈﻥ ﺍﻟﻔﺭﻕ ﻓﻰ
ﺃﻥ ﺍل Full Backupﺘﺴﺘﻁﻴﻊ ﺇﻨﺠﺎﺯﻫﺎ ﻓﻘﻁ ﺒﻜﺘﺎﺒﺔ ﺍﻻﻤﺭ ، Backup Databaseﺃﻤﺎ ﺍﻟﻨﺴﺦ
ﺍل Incremental Level 0ﻓﻨﺤﺘﺎﺝ ﺇﻟﻰ ﺘﺤﺩﻴﺩ ﺫﻟﻙ ﺒﺎﻻﻤﺭ Backup Incremental Level 0
Database
{RMAN> RUN
;ALLOCATE CHANNEL D1 TYPE DISK
;ALLOCATE CHANNEL D2 TYPE DISK
BACKUP AS COMPRESSED BACKUPSET
;INCREMENTAL LEVEL 0 DATABASE
}
ﺍﻻﻥ ﻭﻀﻌﻨﺎ ﻨﺴﺨﺔ ﺘﻜﺎﻤﻠﻴﺔ ﺘﺼﻠﺢ ﻷﻥ ﺘﻜﻭﻥ ﺍﻻﺴﺎﺱ ﻟﻠﻨﺴﺦ ﺍﻟﺘﺯﺍﻴﺩﻴﺔ ﺍﻻﺨﺭﻯ ،ﻜﻤﺎ ﻴﻤﻜﻥ ﺍﻹﺴﺘﻌﻼﻡ ﻋﻥ ﻫﺫﻩ
ﺍﻟﻨﺴﺨﺔ ﺒﺎﻻﻤﺭ .LIST BACKUP OF DATABASE
161
:Cumulative Level 1 -2
ﺒﻤﻌﻨﻰ ﻋﻤل ﻨﺴﺨﺔ ﺇﺤﺘﻴﺎﻁﻴﺔ ﻟﻘﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺒﺤﻴﺙ ﻴﺘﻡ ﻋﻤل ﻨﺴﺦ ﺇﺤﺘﻴﺎﻁﻰ ﻓﻘﻁ ﻟﻠﻜﺘل ﺍﻟﺘﻰ ﺘﻡ
ﺘﻐﻴﻴﺭﻫﺎ ﺨﻼل ﺍﺨﺭ . Level 0 Incremental Backup
ﻻ ﺸﻙ ﺃﻥ ﻫﺫﻩ ﺍﻟﻌﻤﻠﻴﺔ ﺴﺘﻘﻠل ﻋﺩﺩ ﺍﻟﻜﺘل ﺍﻟﺘﻰ ﺴﻨﻘﻭﻡ ﺒﻌﻤل ﻨﺴﺦ ﺇﺤﺘﻴﺎﻁﻰ ﻟﻬﺎ ﻭﻫﻭ ﺍﻤﺭ ﻓﻰ ﻏﺎﻴﺔ
ﺍﻟﺭﻭﻋﺔ ﺇﺫ ﻟﻴﺱ ﻤﻥ ﺍﻟﻤﺼﻠﺤﺔ ﻋﻤل ﻨﺴﺦ ﺇﺤﺘﻴﺎﻁﻰ ﻟﺠﻤﻴﻊ ﻜﺘل ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻴﻭﻤﻴﹰﺎ ﻓﻤﻥ ﺍﻻﻓﻀل ﻭﻀﻊ
ﻨﺴﺦ ﺘﻜﺎﻤﻠﻴﺔ ﻭﻤﻥ ﺜﻡ ﺍﻟﻘﻴﺎﻡ ﺒﻌﻤل ﻨﺴﺦ ﺇﺤﺘﻴﺎﻁﻴﺔ ﺘﺯﺍﻴﺩﻴﺔ ﻟﻨﺴﺦ ﺍﻟﻜﺘل ﺍﻟﺘﻰ ﺘﺘﻐﻴﺭ ﺨﻼل ﺍﺨﺭ ﻨﺴﺦ ﺇﺤﺘﻴﺎﻁﻰ
ﻤﻥ ﺍﻟﻨﻭﻉ ، Level 0ﻟﻜﻥ ﺍﻟﻡ ﺘﻼﺤﻅ ﻤﻌﻰ ﺃﻨﻪ ﻤﺎ ﺯﺍﻟﺕ ﻟﺩﻴﻨﺎ ﻤﺸﻜﻠﺔ ﻓﻰ ﺍﻟﺯﻤﻥ ﺇﺫ ﺍﻥ ﺍل RMANﺤﺘﻰ
ﺘﻌﺭﻑ ﺍﻟﻜﺘل ) (Blocksﺍﻟﺘﻰ ﺘﻐﻴﺭ ﻤﻨﺫ ﺍﺨﺭ ﻨﺴﺦ ﺇﺤﺘﻴﺎﻁﻰ ﻤﻥ ﺍﻟﻨﻭﻉ Level 0ﻓﺈﻥ ﺫﻟﻙ ﻴﺘﻁﻠﺏ ﺍﻟﻤﺭﻭﺭ
ﻋﻠﻰ ﺠﻤﻴﻊ ﺍﻟﻜﺘل ؛ ﻟﺫﺍ ﻟﺠﺄﺕ ﺸﺭﻜﺔ ﺍﻭﺭﻜل ﻟﺤل ﻫﺫﻩ ﺍﻟﻤﺸﻜﻠﺔ ﺒﻭﺍﺴﻁﺔ ﺇﻨﺸﺎﺀ ﻤﻠﻑ ﻴﺴﻤﻰ Change
Tracking Fileﻴﺤﻭﻯ ﺍﻟﻌﻨﻭﺍﻨﻴﻥ ﺍﻟﻔﻴﺯﻴﺎﺌﻴﺔ ﻟﻠﻜﺘل ﺍﻟﺘﻰ ﺘﻐﻴﺭﺕ ﻤﻨﺫ ﺍﺨﺭ ﻨﺴﺦ ﺍﺤﺘﻴﺎﻁﻰ.
ﻭﻫﺫﺍ ﻤﺎ ﻴﺴﻤﻰ ﺒﺎل ، Block Change Trackingﻓﻌﻨﺩﻤﺎ ﻴﺘﻡ ﺘﻬﻴﺌﺔ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻓﻰ ﻫﺫﺍ ﺍﻟﻨﻤﻁ ﻴﺘﻡ
ﺇﻨﺸﺎﺀ Background Processﻴﺴﻤﻰ ) Change Tracking Writer (CTWRﻴﻘﻭﻡ ﺒﻜﺘﺎﺒﺔ ﻋﻨﺎﻭﻴﻥ
ﺍﻟﻜﺘل ﺍﻟﺘﻰ ﺘﻡ ﺘﻐﻴﻴﺭﻫﺎ ﻓﻰ ﻤﻠﻑ ﻴﺴﻤﻰ Change Tracking Fileﻴﺘﻡ ﺘﺤﺩﻴﺩﻩ ﺒﻭﺍﺴﻁﺔ ﺍﻟﻤﺘﻐﻴﺭ
DB_CREATE_FILE_DESTﺍﻭ ﻋﻥ ﻁﺭﻴﻕ ﺘﺤﺩﻴﺩ ﻫﺫﺍ ﺍﻟﻤﻠﻑ ﻴﺩﻭﻴﹰﺎ ﻋﻨﺩ ﺘﻬﻴﺌﺔ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻓﻰ
ﻫﺫﺍ ﺍﻟﻨﻤﻁ.
ﺍﻻﻥ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺘﻌﻤل ﻓﻰ ﺍﻟﻨﻤﻁ Block Change Trackingﺒﺎﻟﻁﺒﻊ ﻴﻤﻜﻥ ﺇﻟﻐﺎﺀ ﻫﺫﺍ ﺍﻟﻨﻤﻁ ﺒﻭﺍﺴﻁﺔ
ﺍﻻﻤﺭ
ALTER DATABASE DISABLE BLOCK CHANGE TRACKING
162
RMAN> BACKUP INCREMENTAL LEVEL 1 CUMULATIVE
;DATABASE
ﻫﻜﺫﺍ ﻗﻤﻨﺎ ﺒﻌﻤل ﻨﺴﺦ ﺘﺯﺍﻴﺩﻴﺔ ﻤﻥ ﺍﻟﻨﻭﻉ ، Cumulativeﺒﺎﻟﻁﺒﻊ ﻻ ﺘﺴﺘﻁﻴﻊ ﺍﻟﻘﻴﺎﻡ ﺒﻬﺫﻩ ﺍﻟﻨﺴﺨﺔ ﺇﺫﺍ
ﻟﻡ ﻴﻜﻥ ﻟﺩﻴﻙ ﻨﺴﺨﺔ ﺇﺤﺘﻴﺎﻁﻴﺔ ﻤﻥ ﺍﻟﻨﻭﻉ .Level 0
ﺒﺎﻟﻁﺒﻊ ﺍﻟﻨﺴﺨﺔ ﺍﻟﺘﺯﺍﻴﺩﻴﺔ ﺍﻟﺘﻰ ﻗﻤﻨﺕ ﺒﻌﻤﻠﻬﺎ ﺘﺤﻭﻯ ﻓﻘﻁ ﺍﻟﻜﺘل ﺍﻟﺘﻰ ﺘﻡ ﺘﻐﻴﺭﻫﺎ ﻤﻨﺫﺍ ﺍﺨﺭ ﻨﺴﺨﺔ
ﺍﺤﺘﻴﺎﻁﻴﺔ ﻤﻥ ﺍﻟﻨﻭﻉ ﺍل Level 0ﻭﻴﻤﻜﻥ ﺍﻹﺴﺘﻌﻼﻡ ﻋﻨﻬﺎ ﺍﻴﻀﹰﺎ ﺒﻭﺍﺴﻁﺔ ﺍﻻﻤﺭ
LIST BACKUP OF DATABASE
163
:Differential Level 1 -2
ﻭﻫﻭ ﻋﻤل ﻨﺴﺨﺔ ﺇﺤﺘﻴﺎﻁﻴﺔ ﺘﺯﺍﻴﺩﻴﺔ ﻟﻘﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺒﺤﻴﺙ ﺘﺤﻭﻯ ﻓﻘﻁ ﺍﻟﻜﺘل ﺍﻟﺘﻰ ﺘﻐﻴﺭﺕ ﻤﻨﺫ ﺍﺨﺭ
ﻨﺴﺦ ﺍﺤﺘﻴﺎﻁﻰ ﺴﻭﺍﺀ ﻜﺎﻥ ﺫﻟﻙ ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ) ، (Level 0 or Level 1ﻻﺤﻅ ﺍﻟﻔﺭﻕ ﺒﻴﻥ ﻫﺫﺍ ﺍﻟﻨﻭﻉ
ﻭﺍﻟﺫﻯ ﻗﺒﻠﻪ Cumulativeﺍﻟﺫﻯ ﻴﻘﻭﻡ ﺒﻌﻤل ﻨﺴﺦ ﺍﻟﻜﺘل ﺍﻟﺘﻰ ﺘﻐﻴﺭ ﻤﻨﺫ ﺍﺨﺭ ﻨﺴﺦ ﺇﺤﺘﻴﺎﻁﻰ ﻤﻥ ﺍﻟﻨﻭﻉ
Level 0ﻓﻘﻁ ،ﻜﻤﺎ ﻴﺠﺏ ﺍﻹﺸﺎﺭﺓ ﺇﻟﻰ ﺃﻥ ﻫﺫﺍ ﺍﻟﻨﻭﻉ ﻫﻭ ﺍﻻﺼل ﻋﻨﺩ ﻋﻤل ﻨﺴﺦ ﺇﺤﺘﻴﺎﻁﻰ ﻤﻥ ﺍﻟﻨﻭﻉ
Level 1ﻟﺫﺍ ﻻ ﻨﺤﺘﺎﺝ ﺇﻟﻰ ﻜﺘﺎﺒﺔ ﻜﻠﻤﺔ Differentialﻋﻨﺩ ﻋﻤل ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ.
ﻋﻤﻭﻤﹰﺎ ﺃﻨﺕ ﻴﻤﻜﻨﻙ ﻜﺘﺎﺒﺔ ﺍﻻﻭﺍﻤﺭ ﻋﻠﻰ ﻤﺤﺭﺭ ﺍل RMANﻤﺒﺎﺸﺭﺓ ﻜﻤﺎ ﻴﻤﻜﻨﻙ ﻜﺫﻟﻙ ﻜﺘﺎﺒﺔ ﺫﻟﻙ ﻓﻰ ﻤﻠﻑ
FILE.RCVﻭﻤﻥ ﺜﻡ ﺘﻨﻔﻴﺫﻩ RMAN>@C:\FILE.RCV
164
اﻻﻣﺮ :LIST
ﺍﺴﺘﺨﺩﻤﻨﺎ ﺍﻻﻤﺭ LISTﻜﺜﻴﺭﹰﺍ ﺍﺜﻨﺎﺀ ﺍﻟﺤﺩﻴﺙ ﻋﻥ ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﺇﺫﺍ ﺇﻥ ﻫﺫﺍ ﺍﻻﻤﺭ ﻴﻘﻭﻡ ﺒﻌﻤل
ﺇﺴﺘﻌﻼﻡ ﻋﻥ ﻋﻤﻠﻴﺎﺕ ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﺒﻜل ﺍﻨﻭﺍﻋﻬﺎ:
ﻟﻌﺭﺽ ﻤﻠﻔﺎﺕ ﺍﻻﺭﺸﻴﻑ ﺍﻟﺘﻰ ﻴﺘﻡ ﺘﺨﺯﻴﻨﻬﺎ ﻓﻰ ﺍل Flash Recovery :LIST ARCHIVELOGG ALL
Area
ﻫﺫﺍ ﺒﺎﻟﻁﺒﻊ ﻟﻴﺱ ﻜل ﺸﺊ ﻋﻥ ﺍﻻﻤﺭ LISTﻭﻟﻜﻥ ﻋﻤﻭﻤﹰﺎ ﻫﺫﺍ ﺍﻻﻤﺭ ﻴﻘﻭﻡ ﺒﻌﺭﺽ ﻤﻌﻠﻭﻤﺎﺕ ﻋﻥ
ﻋﻤﻠﻴﺎﺕ ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ،ﻭﺍﻨﺕ ﺘﺴﺘﻁﻴﻊ ﺃﻥ ﺘﺤﺩﺩ ﻤﺎ ﺘﺭﻴﺩ ﺍﻥ ﺘﺼل ﺍﻟﻴﻪ ﻤﻥ ﻤﻌﻭﻤﺎﺕ ﻭﻤﻥ ﺜﻡ ﺘﻘﻭﻡ
ﺒﺼﻴﺎﻏﺔ ﺍﻻﻤﺭ ﺒﻨﺎﺀ ﻋﻠﻰ ﺍﻻﻤﺜﻠﺔ ﺍﻟﺴﺎﺒﻘﺔ
165
اﻻﻣﺮ :REPORT
ﻫﺫﺍ ﺍﻻﻤﺭ ﻴﺴﺎﻋﺩﻙ ﻓﻰ ﺘﺤﻠﻴل ﺍﻟﻤﻌﻠﻭﻤﺎﺕ ﺍﻟﺘﻰ ﻋﻨﺩﻙ ﻓﻰ ﺍل. RMAN Repository
:REPORT SCHEMAﻟﻌﺭﺽ ﻫﻴﻜﻠﺔ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺍﻟﻤﺴﺘﻬﺩﻓﺔ ،ﻗﺩ ﺘﺤﺘﺎﺝ ﻟﻬﺫﺍ ﺍﻻﻤﺭ ﻗﺒل ﻋﻤﻠﻴﺔ ﺍﻟﻨﺴﺦ
ﺍﻹﺤﺘﻴﺎﻁﻰ ﻟﻌﺭﺽ ﻫﻴﻜﻠﺔ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ
:REPORT OBSOLETEﻟﻌﺭﺽ ﻤﻠﻔﺎﺕ ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﺍﻟﻤﻠﻐﻴﺔ ﺍﻭ ﺍﻟﺘﻰ ﺍﻨﺘﻬﺕ ﻓﺘﺭﺓ ﺍﻹﺤﺘﻔﺎﻅ ﺒﻬﺎ ،
ﺒﺎﻟﻁﺒﻊ ﺴﻭﻑ ﻴﺘﻡ ﺍﻟﺘﺄﻜﺩ ﻤﻥ ﺍﻟﻤﺘﻐﻴﺭ RETENTION POLICYﻭﻤﻥ ﺜﻡ ﻴﺘﻡ ﻋﺭﺽ ﺍﻟﻤﻌﻠﻭﻤﺎﺕ ﺒﻨﺎﺀ
ﻋﻠﻰ ﻗﻴﻤﺔ ﺍﻟﻤﺘﻐﻴﺭ.
:REPORT OBSOLETE REDUNDANCY 2ﻫﺫﺍ ﺍﻻﻤﺭ ﻴﻘﻭﻡ ﺒﺘﺠﺎﻫل ﻗﻴﻤﺔ ﺍﻟﺘﻬﻴﺌﺔ ﺍﻻﻟﻴﺔ ﻟﻠﻤﺘﻐﻴﺭ
RETENTION POLICYﻭﻴﻘﻭﻡ ﺒﻌﺭﺽ ﻤﻠﻔﺎﺕ ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﺍﻟﺘﻰ ﻤﺭ ﻋﻠﻴﻬﺎ ﺍﻜﺜﺭ ﻤﻥ ﻴﻭﻤﻴﻥ
ﻟﻌﺭﺽ ﻤﻠﻔﺎﺕ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺍﻟﺘﻰ ﺘﺤﺘﺎﺝ ﺇﻟﻰ ﻨﺴﺦ ﺇﺤﺘﻴﺎﻁﻰ ﻭﺫﻟﻙ ﺤﺴﺏ :REPORT NEED BACKUP
ﻗﻴﻤﺔ ﺍﻟﻤﺘﻐﻴﺭ ، RETENTION POLICYﻓﻠﻭ ﻜﺎﻥ ﻫﺫﺍ ﺍﻟﻤﺘﻐﻴﺭ ﻴﺄﺨﺫ ﺍﻟﻘﻴﻤﺔ REDUNDANCY 2
ﻓﻬﺫﺍ ﻴﻌﻨﻰ ﻋﺭﺽ ﻤﻠﻔﺎﺕ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺍﻟﺘﻰ ﻟﺩﻴﻬﺎ ﺍﻗل ﻤﻥ 2ﻨﺴﺨﺔ ﺇﺤﺘﻴﺎﻁﻴﺔ
:REPORT NEED BACKUP REDUNDANCY 2ﻫﺫﺍ ﺍﻻﻤﺭ ﻟﺘﺠﺎﻫل ﻗﻴﻤﺔ ﺍﻟﺘﻬﻴﺌﺔ ﺍﻻﻟﻴﺔ ﻟﻠﻤﺘﻐﻴﺭ
RETENTION POLICYﻭﻴﻘﻭﻡ ﺒﻌﺭﺽ ﻤﻠﻔﺎﺕ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺍﻟﺘﻰ ﻟﺩﻴﻬﺎ ﺍﻗل ﻤﻥ 2ﻨﺴﺨﺔ ﺇﺤﺘﻴﺎﻁﻴﺔ
166
اﻻﻣﺮ :DELETE
ﻫﺫﺍ ﺍﻻﻤﺭ ﻴﻭﻗﻡ ﺒﺤﺫﻑ ﻤﻠﻔﺎﺕ ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﻤﻥ ﺍلRMAN REPOSITORY
ﻭﺍﻟﻜﺎﺘﻠﻭﺝ ﻜﻤﺎ ﻴﻘﻭﻡ ﺒﺤﺫﻓﻬﺎ ﺍﻴﻀﹰﺎ ﻓﻴﺯﻴﺎﺌﻴﹰﺎ ،ﻟﺫﺍ ﻜﺎﻥ ﻤﻥ ﺍﻟﺨﻁﺄ ﺤﺫﻑ ﻤﻠﻔﺎﺕ ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﻓﻴﺯﻴﺎﺌﻴﹰﺎ ﻋﻥ
ﻁﺭﻴﻕ ﻨﻅﺎﻡ ﺍﻟﺘﺸﻐﻴل ﻭﺫﻟﻙ ﻷﻥ ﻫﺫﻩ ﺍﻟﻤﻠﻔﺎﺕ ﺴﺘﻅل ﻤﻭﺠﻭﺩﺓ ﻓﻰ ﺍل.REPOSITORY
:DELETE OBSOLETEﻟﺤﺫﻑ ﺍﻟﻤﻠﻔﺎﺕ ﺍﻟﺘﻰ ﺍﻨﺘﻬﺕ ﻓﺘﺭﺓ ﺍﻹﺤﺘﻔﺎﻅ ﺒﻬﺎ ﻭﺫﻟﻙ ﺤﺴﺏ ﺍل RETENTION
POLICY
:DELETE COPY OF DATAFILE 1ﻟﺤﺫﻑ ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻴﺔ ﻟل Data File 1ﻤﻥ ﺍﻟﻨﻭﻉ Image
.Copy
167
اﻻﻣﺮ :CROSSCHECK
ﻤﺎﺫﺍ ﻟﻭ ﻗﻤﺕ ﺒﻌﻤل ﺤﺫﻑ ﻟﻤﻠﻔﺎﺕ ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﻤﺒﺎﺸﺭﺓ ﻋﻥ ﻁﺭﻴﻕ ﻨﻅﺎﻡ ﺍﻟﺘﺸﻐﻴل ﻻ ﺸﻙ ﺃﻥ
ﻫﺫﻩ ﺍﻟﻨﺴﺦ ﺴﺘﻅل ﻤﻭﺠﻭﺩﺓ ﻓﻰ ﺍل ، Repositoryﻭﻴﻤﻜﻥ ﺤل ﻫﺫﻩ ﺍﻟﻤﺸﻜﻠﺔ ﺒﻭﺍﺴﻁﺔ ﺍﻻﻤﺭ
CROSSCHECKﺍﻟﺫﻯ ﻴﻘﻭﻡ ﺒﻌﻤل ﺍﺨﺘﺒﺎﺭ ﻟﺠﻤﻴﻊ ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻴﺔ ﺍﻟﻤﻭﺠﻭﺩﺓ ﻓﻰ ﺍلRepository
ﻭﻴﺘﺄﻜﺩ ﻤﻥ ﻭﺠﻭﺩﻫﺎ ﻓﻴﺯﻴﺎﺌﻴﹰﺎ ،ﺍﻤﺎ ﺍﻟﻤﻠﻔﺎﺕ ﺍﻟﺘﻰ ﻟﻥ ﻴﺠﺩﻫﺎ ﻓﻴﺯﻴﺎﺌﻴﹰﺎ ﻓﻴﻘﻭﻡ ﺒﻭﻀﻌﻬﺎ ﻓﻰ ﻗﺎﺌﻤﺔ ﺍﻟﻤﻨﺘﻬﻴﺎﺕ
، EXPIREDﺤﺘﻰ ﻨﺴﺘﻁﻴﻊ ﺤﺫﻓﻬﺎ ﻓﻴﻤﺎ ﺒﻌﺩ ﺒﻭﺍﺴﻁﺔ ﺍﻻﻤﺭ DELETE
EXPIRED BACKUPSETﺍﻭ DELETE EXPIRED COPYﻭﻗﺒل ﺫﻟﻙ ﺃﻨﺕ ﺘﺴﺘﻁﻴﻊ
ﺍﻹﺴﺘﻌﻼﻡ ﻋﻥ ﻫﺫﻩ ﺍﻟﻘﺎﺌﻤﺔ ﺒﻭﺍﺴﻁﺔ ﺍﻻﻤﺭ .LIST EXPIRED BACKUPSET
ﻟﻨﻔﺘﺭﺽ ﺍﻻﻥ ﺃﻨﻙ ﻗﻤﺕ ﺒﺤﺫﻑ ﺍﺤﺩ ﻤﻠﻔﺎﺕ ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﻤﻥ ﺍﻟﻨﻭﻉ Backupsetﻋﻥ
ﻁﺭﻴﻕ ﻨﻅﺎﻡ ﺍﻟﺘﺸﻐﻴل ،ﻭﻨﺭﻴﺩ ﺃﻥ ﺘﺤﺫﻑ ﺫﻟﻙ ﺍﻟﻤﻠﻑ ﻤﻥ ﺍلREPOSITORY
168
LIST EXPIRED ﻋﺭﺽ ﻗﺎﺌﻤﺔ ﺍﻟﻤﻨﺘﻬﻴﺎﺕ-2
169
:CHANGE…..UNAVAILABLE اﻻﻣﺮ
ﺘﺠﻌل ﻤﻥ ﺍﻟﻤﺘﻌﺫﺭ ﻓﻴﺯﻴﺎﺌﻴﹰﺎ ﻤﺸﺎﻫﺩﺓ ﺒﻌﺽHardwareﻓﻰ ﺒﻌﺽ ﺍﻻﺤﻴﺎﻥ ﺘﺤﺩﺙ ﻤﺸﻜﻠﺔ ﻓﻰ ﺍل
ﻓﻴﻘﻭﻡ ﻫﺫﻩ ﺍﻻﻤﺭ ﺒﻌﻤل ﺇﺸﺎﺭﺓ ﺍﻟﻰ ﺘﺠﺎﻫل ﻫﺫﺍ ﺍﻟﻤﻠﻑ ﺍﺜﻨﺎﺀ ﻋﻤل ﺍﻹﺴﺘﺭﺠﺎﻉ، ﻤﻠﻔﺎﺕ ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ
(RESTORE OR RECOVERY)
ﻴﻤﻜﻥ ﺒﺎﻟﻁﺒﻊ ﺒﻌﺩ ﻤﻌﺎﻟﺠﺔ ﺍﻟﻌﻁل ﻭﺍﺘﺎﺤﺔ ﺍﻟﻤﻠﻑ ﺘﻌﺩﻴل ﺍﻟﺤﺎﻟﺔ ﺒﻭﺍﺴﻁﺔ ﺍﻟﻤﺘﻐﻴﺭ
CHANGE ….AVAILABLE
170
اﻻﻣﺮ :CATALOG
ﻓﻰ ﺒﻌﺽ ﺍﻻﺤﻴﺎﻥ ﺘﻘﻭﻡ ﺒﻌﻤل ﻨﺴﺦ ﺇﺤﺘﻴﺎﻁﻰ ﻋﻥ ﻁﺭﻴﻕ ﻨﻅﺎﻡ ﺍﻟﺘﺸﻐﻴل
User-Managed Backupsﺒﺎﻟﻁﺒﻊ ﻤﺜل ﻫﺫﺍ ﺍﻟﻨﻭﻉ ﻤﻥ ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﻻ ﻴﺘﻡ ﺘﺴﺠﻴﻠﻪ ﻓﻰ
ﺍل Repositoryﻭﻟﻜﻥ ﻴﻤﻜﻥ ﺘﺴﺠﻴﻠﻪ ﻴﺩﻭﻴﹰﺎ ﻋﻥ ﻁﺭﻴﻕ ﺍﻻﻤﺭ CATALOGﺤﺘﻰ ﺘﺴﺘﻁﻴﻊ ﺍﻟﺘﻌﺎﻤل ﻤﻌﻪ
ﻋﻥ ﻁﺭﻴﻕ ﺍل ، RMANﻭﻨﻭﻉ ﺍﻟﻤﻠﻔﺎﺕ ﺍﻟﺘﻰ ﻴﺴﺘﻁﻴﻊ ﻫﺫﺍ ﺍﻻﻤﺭ ﺍﻟﺘﻌﺎﻤل ﻤﻌﻬﺎ ﻫﻰ:
Operating System Datafile Copy -1
Archive Log File Copy -2
Control File Copy -3
171
اﻻﻣﺮ :CHANGE….UNCATALOG
ﺒﺎﻟﻁﺒﻊ ﻴﻤﻜﻥ ﺇﻟﻐﺎﺀ ﺘﺴﺠﻴل ﻤﻠﻔﺎﺕ ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﻤﻥ ﺍل REPOSITORYﺒﻭﺍﺴﻁﺔ ﻫﺫﺍ ﺍﻻﻤﺭ
CHANGE….UNCATALOG
ﺒﺎﻟﻁﺒﻊ ﻫﺫﺍ ﺍﻻﻤﺭ ﻴﻘﻭﻡ ﺒﺈﻟﻐﺎﺀ ﻤﻠﻔﺎﺕ ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﻤﻥ ﺍل REPOSITORYﻭﻟﻜﻥ ﻴﻅل ﺍﻟﻤﻠﻑ ﻤﻭﺠﻭﺩ
ﻓﻴﺯﻴﺎﺌﻴﹰﺎ.
172
:Complete Recovery
ﻋﻤﻠﻴﺔ ﺤﺩﻭﺙ ﻓﺸل ﻓﻰ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻫﻰ ﻋﻤﻠﻴﺔ ﻭﺍﺭﺩﺓ ﻟﺫﺍ ﻭﺠﺏ ﻋﻠﻰ ﻤﺩﻴﺭ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻭﻀﻊ
ﺍﻟﺘﺭﺘﻴﺒﺎﺕ ﺍﻟﻼﺯﻤﺔ ﺤﺘﻰ ﻻ ﻴﻔﻘﺩ ﺠﺯﺀ ﻤﻥ ﻗﺎﻋﺩﺓ ﺒﻴﺎﻨﺎﺘﻪ ،ﻭﻟﻘﺩ ﺘﺤﺩﺜﻨﺎ ﻓﻰ ﺍﻟﻔﺼل ﺍﻟﺴﺎﺒﻕ ﻋﻥ ﺍل Complete
Reoveryﻭﻫﻭ ﺇﺭﺠﺎﻉ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺇﻟﻰ ﺍﻟﻰ ﻤﺎ ﻗﺒل ﺤﺩﻭﺙ ﺍﻟﻔﺸل ﺩﻭﻥ ﺃﻥ ﻨﻔﻘﺩ ﺠﺯﺀ ﻤﻥ ﺍﻟﺒﻴﺎﻨﺎﺕ .
{RMAN> RUN
;ALLOCATE CHANNEL D1 TYPE DISK
;RESTORE DATAFILE 4
;RECOVER DATAFILE 4
}
173
SET ﺍﺜﻨﺎﺀ ﻋﻤﻠﻴﺔ ﺍﻹﺴﺘﺭﺠﺎﻉ ﻭﺫﻟﻙ ﺒﺈﺴﺘﺨﺩﺍﻡ ﺍﻻﻤﺭData Fileﻴﻤﻜﻥ ﻜﺫﻟﻙ ﺇﻋﺎﺩﺓ ﺘﺴﻤﻴﺔ ﺍل
ﻟﺘﻌﺩﻴل ﻫﺫﺍ ﺍﻟﺘﻐﻴﻴﺭ ﻓﻰSWITCH ﻭﺍﻻﻤﺭData File ﻟﺘﻐﻴﻴﺭ ﺍﺴﻡ ﺍﻭ ﻤﻜﺎﻥ ﺍلNEWNAME
.Conreol Fileﺍل
RMAN> RUN{
ALLOCATE CHANNEL D1 TYPE DISK;
SET NEWNAME FOR DATAFILE 4 TO
'C:\oracle\product\10.1.0\oradata\orcl\USERS.DB
F';
RESTORE DATAFILE 4;
SWITCH DATAFILE 4;
RECOVER DATAFILE 4;
}
174
:Loss of a SYSTEM Data File -2
ﻭﺒﺎﻟﻁﺒﻊ ﻻ، (System or Undo Tablespace) ﺘﻨﺘﻤﻰ ﺇﻟﻰData Files ﻭﻨﻘﺼﺩ ﺒﻪ ﻫﻨﺎ ﺍﻯ
ﺩﻭﻥ ﺇﻏﻼﻕ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻭﺫﻟﻙ ﻻﻥ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻻSystem Data Fileﻨﺴﺘﻁﻴﻊ ﻋﻤل ﺇﺴﺘﺭﺠﺎﻉ ﻟل
(System or Undo Tablespace) ﻴﻨﺘﻤﻰ ﺇﻟﻰData File ﺘﻌﻤل ﺇﺫﺍ ﺤﺩﺜﺕ ﻤﺸﻜﻠﺔ ﻓﻰ
RMAN> RUN{
ALLOCATE CHANNEL D1 TYPE DISK;
SHUTDOWN ABORT;
STARTUP MOUNT;
RESTORE DATAFILE 2;
RECOVER DATAFILE 2;
SQL 'ALTER DATABASE OPEN';
}
ﺍﺜﻨﺎﺀ ﻋﻤﻠﻴﺔ ﺍﻹﺴﺘﺭﺠﺎﻉTablespace ﺍﻟﺘﺎﺒﻌﺔ ﻟلData Filesﻭﻴﻤﻜﻥ ﻫﻨﺎ ﺍﻴﻀﹰﺎ ﺇﻋﺎﺩﺓ ﺘﺴﻤﻴﺔ ﻤﻠﻔﺎﺕ ﺍل
.SWITCH ﻭﺍﻻﻤﺭSET NEWNAME ﺒﻭﺍﺴﻁﺔ ﺍﻻﻤﺭ
175
:Tablespace Recovery
System or Undo ﻤﻥ ﺃﻨﻪ ﺇﺫﺍ ﻓﻘﺩﻨﺎ ﺍلData Filesﻭﻴﻤﻜﻥ ﺍﻥ ﻨﻘﻭل ﻫﻨﺎ ﻤﺎ ﻗﻠﻨﺎﻩ ﻓﻰ ﻤﻭﻀﻭﻉ ﺍل
.MOUNT ﻻﺒﺩ ﻤﻥ ﺍﻟﻘﻴﺎﻡ ﺒﻌﻤﻠﻴﺔ ﺍﻹﺴﺘﺭﺠﺎﻉ ﻓﻰ ﺍﻟﻭﻀﻊTablespace
ﻓﻴﻤﻜﻥ ﺃﻥ ﻨﻘﻭﻡ ﺒﻌﻤﻠﻴﺔ ﺍﻹﺴﺘﺭﺠﺎﻉ ﺩﻭﻥ ﺇﻏﻼﻕ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕTablespaceﺍﻤﺎ ﻏﻴﺭﻫﻤﺎ ﻤﻥ ﺍل
.Offline ﻓﻰ ﺍﻟﻭﻀﻊTablespaceﻭﻟﻜﻥ ﺒﻌﺩ ﻭﻀﻊ ﺍل
RMAN> RUN{
ALLOCATE CHANNEL D1 TYPE DISK;
SQL 'ALTER TABLESPACE USERS OFFLINE';
RESTORE TABLESPACE USERS;
RECOVER TABLESPACE USERS;
SQL 'ALTER TABLESPACE USERS ONLINE';
}
176
:Database Recovery
ﻴﻤﻜﻥ ﻋﻥ ﻁﺭﻴﻕ ﺍل RMANﻋﻤل ﺇﺴﺘﺭﺠﺎﻉ ﻟﻘﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ،ﻭﺍﻟﻴﻙ ﺍﻟﺨﻁﻭﺍﺕ:
177
-3ﻋﻤل RECOVERYﻟﻘﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ.
ﻻﺤﻅ ﻤﻌﻰ ﺍﺜﻨﺎﺀ ﻋﻤﻠﻴﺔ ﺍل RESTOREﻭﻋﻤﻠﻴﺔ ﺍل RECOVERYﺘﻡ ﺘﺠﺎﻫل ﺍل DATA
FILE 6ﻭﺫﻟﻙ ﻻﻨﻪ ﻓﻰ ﺍﻟﻭﻀﻊ .OFFLINE
178
:Incomplete Recovery
ﻓﻰ ﺍﻻﺼل ﻓﺈﻥ ﻤﺩﻴﺭ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻴﺴﻌﻰ ﺠﺎﻫﺩﹰﺍ ﻓﻰ ﺤﺎل ﺤﺩﻭﺙ ﻤﺸﻜﻠﺔ ﻓﻰ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ
ﻹﺭﺠﺎﻉ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺇﻟﻰ ﻤﺎ ﻗﺒل ﺤﺩﻭﺙ ﺍﻟﻔﺸل ﻭﺩﻭﻥ ﺃﻥ ﻴﻔﻘﺩ ﺠﺯﺀ ﻤﻥ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻭﻫﻭ ﻤﺎ ﻴﺴﻤﻰ
ﺒﺎل ، Complete Recoveryﻟﻜﻥ ﻓﻰ ﺒﻌﺽ ﺍﻹﺤﻴﺎﻥ ﻴﻜﻭﻥ ﻤﻥ ﺍﻟﻤﺘﻌﺫﺭ ﺇﺭﺠﺎﻉ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺩﻭﻥ ﻓﻘﺩ
ﺠﺯﺀ ﻤﻥ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻭﺫﻟﻙ ﻻﺴﺒﺎﺏ ﻗﺩ ﻴﻜﻭﻥ ﻤﻨﻬﺎ ﻋﺩﻡ ﺘﻭﻓﺭ ﻤﻠﻔﺎﺕ ﺍﻻﺭﺸﻴﻑ ﺍﻟﺘﻰ ﻨﺤﺘﺎﺠﻬﺎ ﻓﻰ ﻋﻤﻠﻴﺔ
ﺍل Recoveryﺍﻭ ﻟﻔﻘﺩﺍﻥ ﻤﻠﻑ ﺍل Online Redo Logﺍﻟﺫﻯ ﻟﻡ ﺘﺘﻡ ﺍﺭﺸﻔﺘﻪ ﺍﻭ ﺍﺤﻴﺎﻨﹰﺎ ﻟﻔﻘﺩﺍﻥ ﺠﻤﻴﻊ ﻤﻠﻔﺎﺕ
ﺍل ، Control Filesﻭﻫﺫﺍ ﻤﺎ ﻴﺴﻤﻰ ﺒﺎل.Incomplete Recovery
ﻭﻴﻤﻜﻥ ﺇﻨﺠﺎﺯ ﻋﻤﻠﻴﺔ ﺍل Incomplete Recoveryﺒﻭﺍﺴﻁﺔ ﺍل RMANﻜﻤﺎ ﺍﻨﺠﺯﻨﺎﻫﺎ ﻤﻥ ﻗﺒل
ﺒﻭﺍﺴﻁﺔ ، User-Managed Backupsﻭﻴﻤﻜﻥ ﺍﻟﻘﻭل ﺒﺄﻥ ﻋﻤﻠﻴﺔ ﺍﻹﺴﺘﺭﺠﺎﻉ ﺒﻭﺍﺴﻁﺔ ﺍل RMANﺍﺴﻬل
ﺒﻜﺜﻴﺭ ﻤﻥ ﺍل.User-Managed Backups
179
:UNTIL TIME
ﻹﺭﺠﺎﻉ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺍﻟﻰ ﻭﻗﺕ ﻤﻌﻴﻥRedo Logﻫﺫﺍ ﺍﻟﺨﻴﺎﺭ ﻤﺘﺎﺡ ﻟﺘﻁﺒﻴﻕ ﻤﻠﻔﺎﺕ ﺍﻹﺭﺸﻴﻑ ﻭﺍل
ﻭﻫﺫﺍ ﺍﻟﺨﻴﺎﺭ ﻴﺴﺘﺨﺩﻡ ﻋﺎﺩﺓ ﻓﻰ ﺤﺎﻟﺔ ﺤﺩﻭﺙ ﺨﻁﺄ ﻤﻥ ﺍﻟﻤﺴﺘﺨﺩﻤﻴﻥ ﻓﻨﺤﺘﺎﺝ ﻹﺭﺠﺎﻉ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺇﻟﻰ ﻤﺎ،
.ﻗﺒل ﺤﺩﻭﺙ ﺍﻟﺨﻁﺄ
RMAN> RUN{
ALLOCATE CHANNEL D1 TYPE DISK;
ALLOCATE CHANNEL D2 TYPE DISK;
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
SQL "ALTER SESSION SET NLS_DATE_FORMAT=''DD-MM-
YYYY HH24:MI:SS''";
SET UNTIL TIME "27-01-2009 11:00:00";
RESTORE DATABASE;
RECOVER DATABASE;
}
ﺒﻌﺩ ﻓﺘﺢ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻓﻰ ﺍﻟﻭﻀﻊFULL BACKUP ﻴﺠﺏ ﺍﻟﺘﻨﺒﻴﻪ ﺇﻟﻰ ﻀﺭﻭﺭﺓ ﻭﻀﻊ
.RESETLOGS
180
:UNTIL SEQUENCE
ﻭﻟﻜﻥ ﺍﻜﺘﺸﻔﺕ ﺃﻥ، ﻓﻰ ﺒﻌﺽ ﺍﻻﺤﻴﺎﻥ ﻗﺩ ﺘﺤﺘﺎﺝ ﻟﻌﻤل ﺇﺴﺘﺭﺠﺎﻉ ﻟﻘﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺒﺴﺒﺏ ﻤﺸﻜﻠﺔ ﻤﺎ
Archive Log File ﻭﻟﻨﻔﺘﺭﺽ ﺃﻨﻙ ﻗﺩ ﻓﻘﺩﺕ، ﻗﺩ ﻓﻘﺩﺕArchive Log File ﺒﻌﺽ ﻤﻠﻔﺎﺕ ﺍﻹﺭﺸﻴﻑ
ﺘﻁﺒﻴﻕ ﻤﻠﻔﺎﺕ ﺍﻻﺭﺸﻴﻑ ﻓﻘﻁRecovery ﻓﻔﻰ ﻤﺜل ﻫﺫﻩ ﺍﻟﺤﺎﻟﺔ ﻨﺴﺘﻁﻴﻊ ﺍﺜﻨﺎﺀ ﻋﻤل ﺍل، Sequence 155
Sequence 15 ﺤﺘﻰ
RMAN> RUN{
ALLOCATE CHANNEL D1 TYPE DISK;
ALLOCATE CHANNEL D2 TYPE DISK;
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
SET UNTIL SEQUENCE 15 THREAD 1;
RESTORE DATABASE ;
RECOVER DATABASE;
ALTER DATABASE OPEN RESETLOGS;
}
ﻭﻻ ﻴﺘﻡ ﺘﻀﻤﺒﻥSequence 14 ﻴﺠﺏ ﺍﻟﺘﻨﺒﻴﻪ ﺇﻟﻰ ﺍﻨﻪ ﺴﻭﻑ ﻴﺘﻡ ﺘﻁﺒﻴﻕ ﻤﻠﻔﺎﺕ ﺍﻻﺭﺸﻴﻑ ﺤﺘﻰ
.Sequence 15 ﻤﻠﻑ ﺍﻻﺭﺸﻴﻑ
181
:Threadﺩﺍﺌﻤﹰﺎ ﻴﺄﺨﺫ ﺍﻟﻘﻴﻤﺔ 1ﻤﺎﺩﺍﻡ ﺃﻨﻨﺎ ﻨﻌﻤل ﻓﻰ ﺒﻴﺌﺔ Single Instanceﻭﻟﻜﻥ ﻋﻨﺩﻤﺎ ﻴﻜﻭﻥ ﻟﺩﻯ ﻋﺩﺩ
ﻤﻥ ﺍل Instancesﻓﺈﻥ ﻜل Instanceﺘﻜﻭﻥ ﻟﺩﻴﻬﺎ ﺭﻗﻡ Threadﺨﺎﺹ ﺒﻬﺎ ،ﻟﻜﻥ ﻋﻤﻭﻤﹰﺎ ﺤﺘﻰ ﻭﺍﻨﺎ ﺍﻋﻤل
ﻋﻠﻰ ﺒﻴﺌﺔ Single Instanceﻻﺒﺩ ﻤﻥ ﻜﺘﺎﺒﺔ Thread 1ﻋﻨﺩ ﻋﻤل Recover until Sequence
ﺍﻴﻀﹰﺎ ﺍﺫﻜﺭﻙ ﺒﻀﺭﻭﺭﺓ ﻋﻤل Backupﺒﻌﺩ ﻓﺘﺢ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻓﻰ ﺍﻟﻭﻀﻊ RESETLOGS
182
:UNTIL SCN
ﻭﺇﻥ ﻜﺎﻥ ﻤﻥSystem Change Number(SCN) ﺨﻴﺎﺭ ﺍﻹﺴﺘﺭﺠﺎﻉ ﺇﻟﻰRMANﺘﻭﻓﺭ ﺍل
ﻋﻨﺩ ﺤﺩﻭﺙSCNﻏﻴﺭ ﺍﻟﻤﻌﺘﺎﺩ ﺍﺴﺘﺨﺩﺍﻡ ﻫﺫﺍ ﺍﻟﻨﻭﻉ ﻋﻨﺩ ﺍﻹﺴﺘﺭﺠﺎﻉ ﻷﻨﻪ ﻓﻰ ﺍﻟﻌﺎﺩﺓ ﺃﻨﺕ ﻻ ﺘﺩﺭﻯ ﻤﺎﻫﻭ ﺍل
.ﺍﻟﻤﺸﻜﻠﺔ
RMAN> RUN{
ALLOCATE CHANNEL D1 TYPE DISK;
ALLOCATE CHANNEL D2 TYPE DISK;
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
SET UNTIL SCN 2621578;
RESTORE DATABASE;
RECOVER DATABASE;
ALTER DATABASE OPEN RESETLOGS;
}
183
:RESTORE CONTROL FILE
ﻟﻌﻤل RESTORE CONTROLFILEﻴﺠﺏ ﺃﻥ ﺘﻜﻭﻥ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻓﻰ ﺍﻟﻭﻀﻊ
.NOMOUNT
ﻟﺫﺍ ﺇﺫﺍ ﻓﻘﺩﻨﺎ ﺠﻤﻴﻊ ﻤﻠﻔﺎﺕ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺒﻤﺎ ﻓﻰ ﺫﻟﻙ ﻤﻠﻔﺎﺕ ﺍل CONTROL FILEﻓﺈﻥ ﺍﻟﺨﻁﻭﺓ
ﺍﻻﻭﻟﻰ ﻨﻘﻭﻡ ﺒﻌﻤل RESTORE CONTROLFILEﻓﻰ ﺍﻟﻭﻀﻊ NOMOUNTﻭﻤﻥ ﺜﻡ ﻨﻘﻭﻡ ﺒﻌﻤل
RESTORE AND RECOVER DATABASEﺒﻌﺩﻤﺎ ﻨﻔﺘﺢ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻓﻰ ﺍﻟﻭﻀﻊ
.MOUNT
ﻟﺫﺍ ﺍﻨﺼﺤﻙ ﻗﺒل ﺍﻥ ﺘﻘﻭﻡ ﺒﻌﻤل ﻨﺴﺦ ﺇﺤﺘﻴﺎﻁﻰ ﻟﻘﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺃﻥ ﺘﻘﻭﻡ ﺒﺘﻬﻴﺌﺔ ﺍل CONTROLFILE
AUTOBACKUPﻭﺫﻟﻙ ﻜﺎﻻﺘﻰ
CONFIGURE CONTROLFILE AUTOBACKUP ON
184
:RESTORE SPFILE
185
:RECOVERY CATALOG
ﺘﺤﺩﺜﻨﺎ ﻓﻰ ﺒﺩﺍﻴﺔ ﻫﺫﺍ ﺍﻟﻔﺼل ﻋﻥ ﺸﺊ ﻤﻥ ﺍل Recovery Catalogﻭﻫﻰ ﻋﺒﺎﺭﺓ ﻋﻥ ﻗﺎﻋﺩﺓ ﺒﻴﺎﻨﺎﺕ
ﻤﻨﻔﺼﻠﺔ ﻴﺘﻡ ﻓﻴﻬﺎ ﺘﺨﺯﻴﻥ ﻤﻌﻠﻭﻤﺎﺕ ﻭﻫﻴﻜﻠﺔ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺍﻟﻤﺴﺘﻬﺩﻓﺔ ﺒﺎﻹﻀﺎﻓﺔ ﻋﻥ ﻤﻌﻠﻭﻤﺎﺕ ﻋﻥ ﺍﻟﻨﺴﺦ
ﺍﻹﺤﺘﻴﺎﻁﻴﺔ ﺒﻨﻭﻋﻴﻬﺎ ) (Backupset & Image Copyﻭﺍﻴﻀﹰﺎ ﻴﺤﻔﻅ ﻓﻴﻬﺎ ﺍﻟﺘﻬﻴﺌﺔ ﺍﻻﻟﻴﺔ ﻟل، RMAN
ﻭﺫﻜﺭﻨﺎ ﺍﻴﻀﹰﺎ ﺃﻨﻪ ﻴﻤﻜﻥ ﺇﺩﺍﺭﺓ ﻤﺠﻤﻭﻋﺔ ﻤﻥ ﻗﻭﺍﻋﺩ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺍﻟﻤﺴﺘﻬﺩﻓﺔ ﻋﻥ ﻁﺭﻴﻕ Recovery Catalog
ﻭﺍﺤﺩﺓ ،ﻤﻤﺎ ﻴﺴﻬل ﺇﺩﺍﺭﺓ ﻋﻤﻠﻴﺔ ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﻭﺍﻹﺴﺘﺭﺠﺎﻉ.
ﻭﻤﺎ ﻟﻡ ﻨﺫﻜﺭﻩ ﺃﻨﻪ ﻴﻤﻜﻥ ﺍﻹﺴﺘﻔﺎﺩﺓ ﻤﻥ ﺍل Recovery Catalogﻜﻤﺨﺯﻥ ﻟﺘﺨﺯﻴﻥ ﻤﺠﻤﻭﻋﺔ ﻤﻥ
ﺍل Scriptsﺍﻟﺘﻰ ﻴﻤﻜﻥ ﺘﻨﻔﻴﺫﻫﺎ ﻓﻴﻤﺎ ﺒﻌﺩ ﻋﻠﻰ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺍﻟﻤﺴﺘﻬﺩﻓﺔ.
ﻭﺍل Scrtiptsﻓﻰ ﺍﻟﺤﻘﻴﻘﺔ ﻫﻰ ﻤﺠﻤﻭﻋﺔ ﻤﻥ ﺍﻻﻭﺍﻤﺭ ﺍﻟﺘﻰ ﺘﻨﺠﺯ ﻤﻬﺎﻡ ﻤﻌﻴﻨﺔ ﻴﺘﻡ ﺍﻋﺩﺍﺩﻫﺎ ﻭﺘﺠﻬﻴﺯﻫﺎ
ﺒﺤﻴﺙ ﻴﺘﻡ ﺘﻨﻔﻴﺫﻫﺎ ﻓﻴﻤﺎ ﺒﻌﺩ ﻋﻥ ﺍﻟﺤﻭﺠﺔ ﺇﻟﻰ ﺫﻟﻙ
ﻭﻟﻨﻔﺘﺭﺽ ﺍﻻﻥ ﺍﻨﻨﺎ ﺘﺭﻴﺩ ﺘﺠﻬﻴﺯ Scriptﺘﺴﻤﻰ TESTﻤﻬﻤﺘﻪ ﺍﻟﻘﻴﺎﻡ ﺒﻌﻤل ﺍﺴﺘﻌﺭﺍﺽ ﻟﻬﻴﻜﻠﺔ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ
ﺍﻟﻤﺴﺘﻬﺩﻓﺔ ،ﻭﻻ ﺸﻙ ﺃﻥ ﺍﻻﻤﺭ ﺍﻟﺫﻯ ﻴﻘﻭﻡ ﺒﺈﺴﺘﻌﺭﺍﺽ ﻫﺫﻩ ﺍﻟﻬﻴﻜﻠﺔ ﻫﻭ .REPORT SCHEMA
:CREATE SCRIPT
186
:PRINT SCRIPT
:EXECUTE SCRIPT
187
:REPLACE SCRIPT
:DELETE SCRIPT
188
:Backup of Recovery Catalog
ﻴﺠﺏ ﻋﻠﻰ ﻤﺩﻴﺭ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺍﻟﻤﺤﺎﻓﻅﺔ ﻋﻠﻰ ﺍل Recovery Catalogﻜﺠﺯﺀ ﻤﻥ ﻋﻤﻠﻪ ،
ﻭﺫﻟﻙ ﻷﻫﻤﻴﺔ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺍﻟﺘﻰ ﺘﺤﺘﻭﻴﻬﺎ ﻭﺍﻟﺘﻰ ﺫﻜﺭﻨﺎﻫﺎ ﺴﺎﺒﻘﹰﺎ ،ﻟﺫﺍ ﻜﺎﻥ ﻋﻠﻰ ﻤﺩﻴﺭ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺍﻟﻘﻴﺎﻡ ﺒﻌﻤل
ﻨﺴﺦ ﺇﺤﺘﻴﺎﻁﻰ ﻟل Recovery Catalogﻭﺫﻟﻙ ﺒﺄﺤﺩ ﺍﻟﻁﺭﻕ ﺍﻻﺘﻴﺔ:
-1ﻋﻤل ﻨﺴﺦ ﺇﺤﺘﻴﺎﻁﻰ ﻟﺠﻤﻴﻊ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺍﻟﺘﻰ ﺘﺤﻭﻯ ﺍل.Recovery Catalog
-2ﻋﻤل ﻨﺴﺦ ﺇﺤﺘﻴﺎﻁﻰ ﻟل Tablespaceﺍﻟﺫﻯ ﻴﺤﻭﻯ ﺍل.Recovery Catalog
-3ﻋﻤل ﻨﺴﺦ ﺇﺤﺘﻴﺎﻁﻰ ﻟل Schemaﺍﻟﺘﻰ ﺘﺤﻭﻯ ﺍل.Recovery Catalog
ﺒﺎﻟﻁﺒﻊ ﺇﺫﺍ ﺤﺩﺜﺕ ﻤﺸﻜﻠﺔ ﻓﻰ ﺍل Recovery Catalogﻨﺴﺘﻁﻴﻊ ﻋﻤل ﺇﺴﺘﺭﺠﺎﻉ ﻟﻬﺎ ﻤﻥ ﻤﻠﻔﺎﺕ
ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ،ﻭﻫﺫﺍ ﺍﻻﻤﺭ ﻴﻌﺘﻤﺩ ﻋﻠﻰ ﻨﻭﻉ ﺍﻟﻨﺴﺦ ﺍﻹﺤﺘﻴﺎﻁﻰ ﻭﻜﺫﻟﻙ ﻋﻠﻰ ﻨﻭﻉ ﺍﻟﻤﺸﻜﻠﺔ ﺍﻟﺘﻰ ﺤﺩﺜﺕ.
189
ALTER
SYSTEM
SET
DB_REC
190