osszeraktam egy logikai standby-t, ahol az volt az igeny, hogy nem kell failover/switchover-re hasznalni azt, csupan reporting/lekerdezo rendszer lesz. ez nemi konnyebseg.
egy tipp: ha hasznalhato logikai standby-t akarsz 10.2.0.3 alatt ne probalkozz, a 10.2.0.1 nagyon bugos, csak a fejfajas es sok gond lesz vele.
megint csak nem a klikkelegtos verziot (Oracle Grid Control/Database control) mutatom, mert az nem olyan erdekes.
az alabbi lepesek mind system felhasznaloval vannak vegrehajtva, hacsak mast nem tuntetek fel.
———————————————————————————————————————————
Ellenorizzuk hogy a ‘force logging’ opcio es az archivelog mod az elsodleges db-n (primary) be van-e kapcsolva:
select force_logging,log_mode from v$database;
ha nincs, engedelyezzuk az archivelog modot (log_archive_dest_N parametert allitsuk be elotte /spfile v. init.ora-ban/):
shutdown immediate
startup mount
alter database archivelog;
alter database open;
majd a 'force logging' opciot is:
alter database force logging;
jo tudni, hogy mely semak vannak alapbol kizarva a replikaciobol, ezt az alabbi sql-lel tudjuk megjeleniteni, hasznalva a DBA_LOGSTDBY_SKIP nezetet:select * from DBA_LOGSTDBY_SKIP;
select distinct owner table_name from dba_logstdby_unsupported;
a logical standby replikacio lelke, hogy elsodleges kulcsok letezzenek es az egyes sorok egyertelmuen azonosithatok legyenek. hogy mely tablak nem tartoznak ebbe a korbe igy derithetjuk ki:
SELECT * FROM DBA_LOGSTDBY_NOT_UNIQUE
WHERE (OWNER, TABLE_NAME) NOT IN
(SELECT DISTINCT OWNER, TABLE_NAME FROM DBA_LOGSTDBY_UNSUPPORTED) AND BAD_COLUMN = 'Y'
csekkeljuk az init parameter beallitasokat a forrason:
select inst_id,name, value from gv$parameter
where name in ('db_name','compatible','log_archive_format',
'log_archive_dest_1','log_archive_dest_2', 'log_archive_dest_3','instance_name','remote_login_password_file', 'db_unique_name','log_archive_dest_state_1',
'log_archive_dest_state_2', 'log_archive_dest_state_3',
'log_archive_max_processes', 'fal_server','fal_client')
az enyem igy nezett ki:
INST_ID |
NAME |
VALUE |
1 |
compatible |
10.2.0.1.0 |
1 |
log_archive_dest_1 |
LOCATION=/u01/odata/myprod/archives |
1 |
log_archive_dest_2 |
SERVICE=myprod2 OPTIONAL |
1 |
log_archive_dest_3 |
|
1 |
log_archive_dest_state_1 |
enable |
1 |
log_archive_dest_state_2 |
enable |
1 |
log_archive_dest_state_3 |
|
1 |
log_archive_max_processes |
5 |
1 |
log_archive_format |
arch_%r_%t_%s.arc |
1 |
fal_client |
|
1 |
fal_server |
|
1 |
instance_name |
myprod1 |
1 |
db_name |
myprod |
1 |
db_unique_name |
myprod |
2 |
compatible |
10.2.0.1.0 |
2 |
log_archive_dest_1 |
LOCATION=/u02/odata/myprod/archives |
2 |
log_archive_dest_2 |
SERVICE=myprod1 OPTIONAL |
2 |
log_archive_dest_3 |
|
2 |
log_archive_dest_state_1 |
enable |
2 |
log_archive_dest_state_2 |
enable |
2 |
log_archive_dest_state_3 |
|
2 |
log_archive_max_processes |
5 |
2 |
log_archive_format |
arch_%r_%t_%s.arc |
2 |
fal_client |
|
2 |
fal_server |
|
2 |
instance_name |
myprod2 |
2 |
db_name |
myprod |
2 |
db_unique_name |
myprod |
(A fenti tablazatbol latszik hogy ez valoban egy RAC setup es az is hogy cross-node archivalast is hasznaltunk.)
a kovetkezoket muveljuk:
* beallitjuk log_archive_dest_x-et hogy a jovobeli celra (target logical standby) DB-re mutasson
* log_archive_max_processes tuningoljuk
* a fal_server es a fal_client parametereket (FAL = Fetch Archive Log) beallitjuk:
alter system set log_archive_dest_3='service=myls' scope=both sid='*';
(Figyeljunk, ha single node installunk van a forrason, termeszetesen a 4. es 5. lepes kozul csak az egyik szukseges!)
alter system set log_archive_dest_state_3='DEFER' scope=both sid='*';
alter system set log_archive_max_processes=5 scope=both sid='*';
alter system set fal_server='myprod2' scope=both sid='myprod2';
alter system set fal_server='myprod1' scope=both sid='myprod1';
alter system set fal_client='myls' scope=both;
ha idaig megvagyunk, csinaljunk egy backupot (en rman-t javaslok) a forrasrol, pl:
backup compressed backupset database plus archivelog;
krealjunk egy standby controlfile-t:
alter database create standby controlfile as '/tmp/myls_stdby.ctl';
backupoljuk le az spfilet (rman-nal):
backup spfile;
masoljuk at a backup file-okat es a standby controlfile-t a cel gepunkre, ahol a logical standby-t szeretnenk felhuzni.
igazabol most kezdodik a moka, 2 fobb resze lesz:
1. Csinalunk egy physical standby-t
2. majd ezt konvertaljuk logikaiva.
Fizikai standby elkeszitese:
innentol a cel gepen dolgozunk, hacsak mast nem irok.
gyozodj meg rola, hogy a filerendszered es direktori strukturad ki van alakitva, es persze az Oracle binaris fel van telepitve.
altalaban szoktam csinalni egy env filet minden SID-nek, ami most igy nez ki a logical standby-unknak (az oracle felhasznalo home-jaba szoktam tenni oraenv_<STDBY_SID>.sh neven):
export ORACLE_BASE=/u01/app/oracle
export ORACLE_HOME=/u01/app/oracle/product/10.2.0/db_1
export ORACLE_SID=myls
export LD_LIBRARY_PATH=$ORACLE_HOME/lib
export PATH=$ORACLE_HOME/bin:$PATH:$HOME/bin
allitsuk be a shell kornyezetet:
. ./oraenv_myls.sh
keszitsunk egy password file-t. Nagyon fontos hogy a pwd-nek meg kell hogy egyezzen a forras oldalival:
cd $ORACLE_HOME/dbs
allitsuk vissza a szoveges parameterallomanyunkat a mentesbeli spfile-bol:
orapwd file=orapwmyls entries=5 password=<YOUR_SYS_PASSWORD>
rman target /
csinalj, egy a kovetkezohoz hasonlo init.ora-t, termeszetesen a sajat setupodnak megfeleloen. az enyemet csak peldakepp teszem ide.
startup nomount
restore spfile to pfile '/u01/app/oracle/product/10.2.0/db_1/dbs/initmyls.ora' from '/u01/odata/myprod/rman/bkp_myprod_3118276980_070404_90ieb29k_1';
shutdown;
mindenkepp allitsd be a kovetkezoket:
1. allitsd at az osszes utvonalat, hogy megfeleljen a cel gepen kialakitasra kerultnek (audit_file_dest, background_dump_dest, control_files, core_dump_dest, log_archive_dest_1, log_archive_format, user_dump_dest, stb...)
2. hagyd a db_name-t ugy ahogy van
3. allitsd at az instance_name-t (pl.:instance_name=myls)
4. vedd ki a nemkello archiver bealltasokat:
log_archive_dest_2 es log_archive_dest_3
log_archive_dest_state_2 es log_archive_dest_state_3
5. allitsd be db_unique_name='myls'
6. ha nem ugyanaz a konyvtarszerkezet, mint a forrason, akkor allitsd be a db_file_name_convert, log_file_name_convert parametereket
7. allitsd be standby_file_management=auto
8. allitsd be fal_server=myprod1, myprod2 (ez RAC forrasnal kell igy, ertelemszeruen single node forrasnal csak 1 db fog itt szerepelni)
9. allitsd be fal_client=myls
myls.__db_cache_size=973078528
a cel gepen konfiguralj es indits egy listenert.
myls.__java_pool_size=33554432
myls.__large_pool_size=16777216
myls.__shared_pool_size=956301312
myls.__streams_pool_size=16777216
*._kgl_large_heap_warning_threshold=0
*.archive_lag_target=0
*.audit_file_dest='/u01/app/oracle/admin/myprod/adump'
*.background_dump_dest='/u01/app/oracle/admin/myprod/bdump'
*.compatible='10.2.0.1.0'
*.control_files='/d03/odata/myprod/control01.ctl', \
'/d03/odata/myprod/control02.ctl', \
'/d03/odata/myprod/control03.ctl'
*.core_dump_dest='/u01/app/oracle/admin/myprod/cdump'
*.db_block_size=8192
*.db_domain=''
*.db_file_multiblock_read_count=16
*.db_files=400
*.db_name='myprod'
*.db_unique_name='myls'
*.dispatchers='(PROTOCOL=TCP) (SERVICE=myprodXDB)'
*.fal_client=myls
*.fal_server=myprod1,myprod2
*.fixed_date='NONE'
*.instance_name='myls'
*.job_queue_processes=10
*.log_archive_dest_1='location=/u01/odata/myprod/archives valid_for=(online_logfiles, all_roles) db_unique_name=myls'
*.log_archive_format='arch_%r_%t_%s.arc'
myls.log_archive_format='arch_%r_%t_%s.arc'
*.log_archive_max_processes=2
*.log_archive_min_succeed_dest=1
myls.log_archive_trace=0
*.nls_length_semantics='CHAR'
*.open_cursors=300
*.pga_aggregate_target=734003200
*.plsql_native_library_dir='/u01/app/oracle/product/10.2.0/db_1/plsql/lib'
*.processes=150
*.recyclebin='OFF'
*.remote_login_passwordfile='exclusive'
*.sga_max_size=2000000000
*.sga_target=2000000000
*.standby_file_management='auto'
*.undo_management='AUTO'
*.undo_retention=10800
*.undo_tablespace='UNDOTBS1'
*.user_dump_dest='/u01/app/oracle/admin/myprod/udump'
*.standby_archive_dest='/u01/odata/myprod/archives_standby'
ha ez kesz, mindket oldalon (forras, cel) konfigurald az sqlnet-et, hogy a db-k lassak majd egymast (pl.: tnsnames.ora-ba vedd fel a a megfelelo szervizneveket)
az adatbazis nomount allapotaban keszits egy spfile-t:
startup nomount;
a korabban atmasolt standby controlfile-t masold az init.ora-ban beallitott control_files poziciokra.
create spfile from pfile;
hozd a db-t mount allapotba:
alter database mount;
allitsd vissza az rman backupot. en voltam olyan szerencses, hogy ki tudtam harcolni azt, hogy a forrassal teljesen megegyezo konfigot kapjak ezert a konyvtarszerkezetet is tokeletesen megfeleltettem a forras node-eval. ha nalad nem ez a helyzet, akkor a visszatoltes kicsit korulmenyesebb (set newname, switch datafile...).
rman target /
lepj ki rman-bol majd sqlplus-bol tisztan allitsd le az instance-t:
crosscheck backupset;
crosscheck copy;
delete noprompt expired copy;
delete noprompt expired backupset;
catalog start with '/u01/odata/myprod/rman';
restore database;
recover database;
shutdown immediate
allitsd le es inditsd ujra a listenert (nem reload):
lsnrctl stop
inditsuk a fizikai standby-t (managed recovery):
lsnrctl start
startup nomount
a cel db-ben allitsuk be a log_archive_dest_2-t. mondjuk meg a rendszernek, hogy a forrasbol erkezo archive logok hova menjenek:
alter database mount standby database;
alter database recover managed standby database disconnect from session;
alter system set log_archive_dest_2='location=/u01/odata/myprod/archives_standby VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) db_unique_name=myls' scope=both;
a forras db-ben engedelyezzuk az archivalast a standby-ra:
alter system set log_archive_dest_state_3='ENABLE' scope=both sid='*';
alter system switch logfile;
ezutan nezegethetjuk hogyan halad az archivalas es recovery (mindket db-n futtassuk es hasonlitsuk ossze a kimeneteket):
SELECT sequence#, first_time, next_time
FROM v$archived_log
ORDER BY sequence# ;
SELECT MAX(sequence#)
FROM v$archived_log ;
a cel db-n ellenorizzuk, hogy minden hianyzo archive log applikalva lett-e (APPLIED=Y):
SELECT sequence#, applied
(RAC forras eseteben mindig lesz 1, ami NO statuszu, a thread-ek kozotti fuggoseg miatt, de ez rendben van)
FROM v$archived_log
ORDER BY sequence# ;
Logical Standby konverzio
allitsuk le az automatikus recovery-t a celon:
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
a forrason epitsuk fel a logminer szotarat
(javaslom, hogy mindezt egy csendes idoszakban tegyuk meg, figyeljuk milyen lock-ok vannak a rendszerben, megkockaztatnam, hogy a legjobb megoldas ujrainditas utan restricted modban elkovetni mindezt, habar nem szuksegszeru):
EXECUTE DBMS_LOGSTDBY.BUILD;
az ugynevezett 'Supplemental logging' automatikusan elesedik, ami szukseges a logminerkedeshez (ezen alapszik a logical standby mukodese)
elerkeztunk a varva vart pillanathoz, konvertaljunk logikaiva:
ALTER DATABASE RECOVER TO LOGICAL STANDBY myls;
krealjuk ujra a passwordfile-t (emlekezzunk vissza, a pwd-nek meg kell hogy egyezzen a forrasbelivel):
cd $ORACLE_HOME/dbs
tiszta shutdown utan mount:
mv orapwmyls orapwmyls.old
orapwd file=orapwmyls entries=5 password=<YOUR_SYS_PWD>
shutdown immediate
nezzuk meg hogy is van beallitva a log_archive_dest_1:
startup mount
show parameter log_archive_dest_1
valami hasonlot fogunk latni:
NAME TYPE VALUE
------------------------------------------------------------
log_archive_dest_1 string location=/u01/odata/myprod/arc
hives valid_for=(online_logfil
es, all_roles) db_unique_name=
myls
ami azt jelenti, hogy a sajat logikai standby-unk altal generalt redo logokat a log_archive_dest_1-be fogjuk tarolni. (fyi: nem is gondoltam arra, hogy noarchive modban menjen a logstdby, mert tablakon strukturalis valtoztatasokat terveztunk es ezert rman-nal kivantuk a logstdby-t menteni, online).
nyissuk meg az adatbazist resetloggal:
ALTER DATABASE OPEN RESETLOGS;
inditsuk az sql apply processeket:
ALTER DATABASE START LOGICAL STANDBY APPLY;
ezzel kesz a logical standby, nezegessuk az alert.log-ot szorgalmasan.
van meg mit allitgatni, azt a kovetkezo reszben irom le.
Ajánlott bejegyzések:
A bejegyzés trackback címe:
Kommentek:
A hozzászólások a vonatkozó jogszabályok értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a Felhasználási feltételekben és az adatvédelmi tájékoztatóban.
Béla 2007.08.08. 17:11:08
Futás közben, sp-ből indítva kéne mentést csinálnom az adatbázisról. Nemigen sikerül...
Annyit már sejtek, hogy ARCHIVELOG módban kéne indítanom az adatbázist, de már ez sem sikerül. Az "alter database archivelog" reklamál, hogy exclusive módban kéne lennem (a "shutdown immediate; startup mount exclusive;" elvileg hiba nélkül lefut).
Így itt el is akadok, és sehogy nem jutok tovább. Ha estelg tudnál segíteni, azért nagyon hálás lennék!
Köszi, Béla
darvat 2007.08.08. 17:21:54
esetleg rdbms verzio, es platform is johet.
udv!
Béla 2007.08.08. 20:38:33
shutdown immediate;
startup mount exclusive;
alter database archivelog; -- erre közöl egy ORA-01126-ot és nem is érdemes továbbmennem
bár igazság szerint még nem is világos, hogy hogyan fogok, bár valami ilyesmire gondoltam (by Google):
ALTER TABLESPACE tablespace BEGIN BACKUP;
! cp xyfFile1 /backupDir/
ALTER TABLESPACE tablespace END BACKUP;
Mindez MSSQL-ben pofon egyszerű volt, de ez nagyon nem megy nekem...
Köszönöm, Béla
Béla 2007.08.08. 20:42:35
a fenti szörnyűségeket pedig egyenlőre Toad-ban próbálom futtatni
darvat 2007.08.08. 22:02:59
cluster_database=false
parallel_server=false
log_archive_dest='c:\archivelogs' (vagy egy altalad definialt konyvtar, ahova az archivlogok mennek majd)
log_archive_format=arch%d_%s.arc (formatum mask)
log_archive_start=true (automatikus archivalas)
ha spfile-t hasznaltok init.ora helyett akkor:
alter system set cluster_database=false scope=spfile;
alter system set parallel_server=false scope=spfile;
alter system set log_archive_dest='c:\archivelogs' scope=spfile;
alter system set log_archive_format=arch%d_%s.arc scope=spfile;
alter system set log_archive_start=true scope=spfile;
ezutan dos promptbol:
sqlplus "/ as sysdba"
shutdown immediate
startup mount exclusive
alter database archivelog;
alter database open;
ha sikerult szolj, mondom hogyan lehet egyszeruen menteni.
udv
Béla 2007.08.09. 11:12:40
Béla 2007.08.09. 11:19:33
darvat 2007.08.09. 11:31:48
db mentes -> dos promptbol:
rman target /
run {
allocate channel d1 type disk maxpiecesize 2048m maxopenfiles 64;
backup incremental level 0 database
format='c:\backupdir\full_%d_s%s_p%p_t%t'
tag='FULL_BKP'
filesperset=8
PLUS ARCHIVELOG delete input
format='c:\backupdir\arch_%d_s%s_p%p_t%t'
tag='ARCH_BKP'
filesperset=32
;
backup current controlfile
format='c:\backupdir\ctrl_%d_s%s_p%p_t%t'
tag='CTRL_BKP'
;
release channel d1;
}
ebbol majd vissza is tudsz allni :)
Béla 2007.08.09. 11:42:04
darvat 2007.08.09. 11:47:14
mit szeretnel pontosan menteni? (az elejen azt irtad hogy adatbazist, ez alatt en az egesz db-t ertettem).
nos akkor:
az egesz adatbazist akarod menteni?
egy schema (felhasznalo) adatait?
egy tablater adatait?
bizonyos tablak adatait?
Béla 2007.08.09. 12:22:57
Lényegében csak az adatokra van szükségem, az alkalmazás egy adott állapotában (hogy hiba, vagy egyéb gáz esetén ide vissza lehessen állni, és újra indítani a futást). Ez sejtésem szerint a tablespace-t jelenti.
Béla 2007.08.09. 13:43:56
darvat 2007.08.09. 14:18:57
sajnos ennel joval bonyolultabb. mindig kell hogy legyen egy full db backup, amibol a visszaallitas utan kiindulsz.
ezert teljesen mas megoldast kellene keresni. azt javaslom tudd meg mely tablakat kell menteni, azt joval egyszerubben meg tudjuk oldani logikai backuppal (exp utility). itt arra kell figyelni, hogy visszaallitasnal adatkonzisztencia ne seruljon (magyarul minden olyan adatot menteni kell ami osszefuggesben vagy egymassal)
ha van 10-20 tabla amit menteni kellene, arra gyorsan ossze lehet dobni egy export scriptet.
mekkora db-rol beszelunk egyebkent? (select sum(bytes)/1024/1024/1024 from dba_segments;).
kerdesek: mikor dol el hogy vissza kell allni? 1-2 ora mulva? napok mulva?
visszaallasnal az egesz db-t vissza kellene allitani X idopontra, vagy csak erintett reszek?
darvat 2007.08.09. 14:19:58
Béla 2007.08.09. 15:03:01
Ora-ban nincs meg meret, mert ezutan kerul majd uzembe. MSS meretem van, az most 3,5GB, kb. egy ev futas utan. Adatforgalomban az ORA sem lesz tobb, mert a szervezet merete es adatforgalma is kisebb.
Az egesz mentesesdi egyebkent azert kell, hogy hiba eseten meg tudjuk orizni a konzisztenciat (nem "megbizhato" parnerrel kommunikalunk, batch szeruen). A mentendo tablak egyertelmuek, nagyjabol 20 db de ezekben van az adatok 95%-a. Pontosan tudom is, hogy melyek azok, mert anno en irtam meg mindent, MSSQL-ben. Ezt a 20 tablat kene tudni visszaallitani a mentesbol. Ebbol a szempontbol szerencse, hogy nem folyamatos a futas, tehet, ha vissza kell allni, akkor nincs adatvesztes, nincsenek beerkezo adatok a hiba es a visszaallas kozott. Egyszeruen el kell dobni a "hibas" adatokat es visszatenni a regit.
Az exp utility "insert into" script-eket gyart? Utannanezek, mert nem ismerem. Futhat ez sp-bol?
darvat 2007.08.09. 15:27:44
DROP TABLE xyz_bkp; (ez ugye az elso futasnal hibara fog futni de le kell kezelni)
CREATE TABLE xyz_bkp AS SELECT * FROM xyz;
ennyi. visszatolteni egyszeruen:
TRUNCATE TABLE xyz;
INSERT INTO xyz SELECT * FROM xyz_bkp;
amire visszatoltesnel figyelni kel:
- "referential integrity constraints", magyarul a tablakon, ha vannak, ki kell kapcsolani a foreign key constraint-eket
- triggereket, ha vannak, kikapcsolni.
Béla 2007.08.09. 15:40:43
De mindenkeppen koszi a turelmedet!
Udv, Bela
darvat 2007.08.09. 16:24:46
sqlplus user/pwd
host exp user/pwd file=c:\export\table_backup.dmp tables=table1,table2,table3,table4 consistent=y
ennyi...
visszatoltesnel:
truncate table table1;
truncate table table2;
.
.
.
constraint-ek, triggerek kikapcs,
imp user/pwd file=c:\export\table_backup.dmp tables=table1,table2,table3,table4 commit=y buffer=1000000
Béla 2007.08.09. 16:37:46
darvat 2007.08.09. 16:50:14
sebessegre vakon nem tudok okosat mondani. gyors diszk, izmos gep -> pikk-pakk.
alapvetoen 1 millio rekord nem tetel az oracle-nek, csak legyen alatta vas (mondjuk ez mindenre igaz).
Béla 2007.08.09. 16:56:19
Koszonom a nagy-nagy segitseget es a turelmedet, ez meg forintban is sokat erne, nemhogy chf-ben ;-)
Béla 2007.08.19. 09:38:45
Köszi, Béla
darvat 2007.08.19. 10:07:06
CREATE TABLE xyz_bkp TABLESPACE bkp_tbspc AS SELECT * FROM xyz;
ugyelj arra, hogy a bkp_tbspc tablateren legyen a muveletet vegzo felhasznalonak quotaja (dba felhasznaloval: alter user myuser quota unlimited on bkp_tbspc) vagy esetleg unlimited tablespace rendszer privilegiuma, de ez eleg eros (dba felhasznaloval: grant myuser unlimited tablespace).
udv!
Béla 2007.08.19. 20:44:16
Üdv, Béla
beze 2008.01.07. 14:50:58
Szuper a leírás, szerinted 9.2.0.8-al meg tudom csinálni? Ha jól tudom 9.2-ben jött a logikai standby hazsnálatba. Nekem most "fizikai" van, de egy un. éles-teszt adatbázist kell minden reggelre produkálnom. Ez sajna egyre lassabban megy :( Az adatbázis mérete 180gb, most exportálom a kérdéses sémát, valamint azokat a táblákat más sémákból amik kellenek, majd jól betöltöm...
A kérdés:
- A fizika mehet a logikai mellett?
- rman-al mentek, + tivoli tsm, ebből tudok rendesen máshova visszaállítani, és éleszteni egy db-t? ő lenne a teszt. Szerinted ez lehet elég gyors?
Előre is köszi a választ:
beze
darvat 2008.01.07. 19:42:17
- egy adabazis vagy fizikai vagy logikai stdby, ez egyszerre nem megy egy DB-n belul. (azt lehet viszont hogy egy forrasrol "etetni" egy fizikai-t es egy masik logikait vagy egy masik fizikait...)
- az rman mentesbol kellemes modon es viszolnylag egyszeruen tudsz egy masik adatbazist krealni. Hogy milyen gyorsan az attol fugg milyen gyors a backup subsystem (backup server, tape library, network). A megoldas RMAN DUPLICATE. Ha konkretumokra vagy kivancsi javaslom a dokumentacio olvasasat, vagy ha goldolod tudok adni egy-ket egyszerubb pelda szkriptet. Latatlanba ezt a megoldast javasolnam.
- amennyiben a "éles-teszt" DB-t csak lekerdezesekre hasznalnak akkor ugye a fizikait meg tudod nyitni read-onlyban es mehet a moka. ha modositani is akarnak benne akkor ez termeszetesen kilove.
- godolkodtal mar Transportable Tablespace megoldason? RMAN-nal is mehet. Ha info kell errol, szolj, vagy tahiti.oracle.com ;)
beze 2008.01.07. 20:48:08
Az rman tetszik, rákeresek, ha példa scriptet küldesz, megköszönöm. Backup szerver gyors, fibren keresztül.
A Transportable Tablespacenek mi lenne a lényege? (közben már olvasok...)
Köszi:
beze
darvat 2008.01.08. 11:07:58
1.) target DB init.ora-ban figyelj db_file_name_convert, log_file_name_convert beallitasokra, ha nem ugyanazon path-ra szeretned tenni mint amin a source van
2.) target DB: startup nomount
3.) target host-on: rman target system/manager@SOURCE_DB catalog cataloguser/catalogpwd@RMAN_CATALOG_DB auxiliary system/manager@TARGET_DB
4.) rman-ban: duplicate target database to TARGET_DB pfile='/itt/a/parameterfile/init.ora';
persze mindezt lehet szkriptelni, tobb csatornan huzni, stb de kb ez a lenyeg.
Transportable Tablespace: ha jo a db desing a kulonbozo schemak kulon tbspc-ben vannak. Ekkor hasznalhato a TTS (Transportable Tablespaces). Nagyon leegyszerusitve ez azt jelenti, hogy kis elomunka utan a Source DB-bol at copyzod/ftpzed... a megfelelo tablaterhez tartozo adatfileokat a target host-ra es ott, ujra kis mahinacio utan beilleszted a DB-be. Ez is jol szkriptelheto, vannak elonyei/hatranyai, mint mindennek.
beze 2008.01.10. 16:50:58
Valami nem sikerült, lehet nem jól csináltam, mert az rman azt dobja:
RMAN> run {
2> DUPLICATE TARGET DATABASE TO IIERDUP;
3> }
Starting Duplicate Db at 08-JAN-10
allocated channel: ORA_AUX_DISK_1
channel ORA_AUX_DISK_1: sid=8 devtype=DISK
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of Duplicate Db command at 01/10/2008 17:01:34
RMAN-05501: aborting duplication of target database
RMAN-05001: auxiliary filename /app/oracle/oradata/IIER/iier_data5_6.dbf conflicts with a file used by the target database
RMAN-05001: auxiliary filename /app/oracle/oradata/IIER/IIER_ARCHIVE_2008B1.dbf conflicts with a file used by the target database
.......
Kell nekem csatornát foglalni?
A mentéskor így teszek: allocate channel c1 type 'sbt_tape' parms 'ENV=(TDPO_OPTFILE=/opt/tivoli/tsm/client/oracle/bin64/tdpo.opt)';
Csak ezen a szerveren nincs tivoli.
Köszi:
beze
beze 2008.01.10. 16:55:46
Lehet nekem a "nofilenamecheck" paramáter megfelelő lenne?
Csak az a kérdés nem rontom-e el az éles adatbázist, mert ha ez megtörténne szerintem nekem levágnák a.... meg a fülemet is. :D
A parancsom:
rman TARGET sys/******@IIER CATALOG rman/rman@wflow AUXILIARY SYS/***
Az IIER sid-es az éles.
Köszi:
beze
darvat 2008.01.16. 08:39:19
most volt erkezesem megnezni a kommentjeidet, sorry.
Valaszok:
igen, kell csatornat foglalnod, en igy szoktam szkriptbol pl.:
run {
allocate auxiliary channel c1 type sbt_tape;
allocate auxiliary channel c2 type sbt_tape;
allocate auxiliary channel c3 type sbt_tape;
allocate auxiliary channel c4 type sbt_tape;
set until scn 5734724643454;
send 'NB_ORA_POLICY=O_SYR_uh, NB_ORA_SCHED=O_SYR_uh_user,NB_ORA_CLIENT=zus15h-3001-bkp.csintra.net,NB_ORA_SERV=bkpuh12en1.csintra.net';
duplicate target database to DZHCBOIX
pfile='/app/oracle/admin/DZHCBOIX/pfile/initDZHCBOIX.ora';
}
azt hiszem igy mar joval vilagosabb.
Masik fontos dolog, hogy ha duplicate-et akarsz csinalni a teszt gepre, termeszetesen a teszt gepnek is latnia kell a szalagokat amin az rman mentesek vannak a prod-rol.
Ha a parancsod:
rman TARGET sys/******@IIER CATALOG rman/rman@wflow AUXILIARY SYS/***
ugye ezt a TARGET (teszt) hoszt-on adod ki (mivel az AUXILIARY DBhez a teszt gepen kell hogy csatlakozzon).
Probald meg a nofilenamecheck-et, mukodnie kell, vagy amennyiben az IIERDUP esetleg mas dir strukturaba kerul mint az eles akkor az IIERDUP init-orajaba: db_file_name_convert es log_file_name_convert bellaitasa javasolt.
alby 2008.04.22. 20:19:45
A cel az lenne, hogy a leheto legegyszerubben hozzak letre egy szimpla adatbazishoz egy fizikai standby-t, (esetleg felparameterezve failover/switchover-re), mindezt a 10g EE alatt, ket gepen.
Eddig probalkoztam mar az OEM feleulettel es probalkoztam (mindenfele egyeb leiras alapjan) konzolon is... Ha van lelkierod, kerlek segits.
Elore is koszonom!
alby 2008.04.30. 09:58:31
Abban tudnál további útmutatást adni, hogy amennyiben a primary és a standby adatbázisok működnek, hogyan lehet életet lehelni a data guard brokerbe? (Leginkább a failover részletei érdekelnének.)
Előre is köszönöm!
darvat 2008.04.30. 10:19:49
elolvasasat a DG broker setuphoz.