Re: Ness ir Vytas:)'ui :) [Vytas :) @ 2009-06-12 14:33:08]

Tema: Re: Ness ir Vytas:)'ui :)
Autorius: Vytas :)
Data: 2009-06-12 14:33:08
Dėkui dėkui, alų prisiminsiu, į privatą brūkštelsiu prie progos :)

> 1) keistas dalykas
> "WARNING: db_recovery_file_dest is same as db_create_online_log_dest_1" - cia blogai ar galima gyvent?

Prisegu paaiškiną iš Oracle metalinko apie parametrus atsakingus už redo 
logų vietą:

The initialization parameters that determine where online redolog files are
created are DB_CREATE_ONLINE_LOG_DEST_n, DB_RECOVERY_FILE_DEST and
DB_CREATE_FILE_DEST.


Order of Precedence for Online Redo Log Creation
====================================================

o  If DB_CREATE_ONLINE_LOG_DEST_n is specified, an online redolog file 
member is
    created in each directory up to MAXLOGMEMBERS for the database. No 
online
    redologs are created in the Flash Recovery Area  .

o  If the DB_CREATE_FILE_DEST and DB_RECOVERY_FILE_DEST parameters are 
specified,
    and if the DB_CREATE_ONLINE_LOG_DEST_n parameter is not specified, 
an online
    redolog file member is created in both DB_CREATE_FILE_DEST and
    DB_RECOVERY_FILE_DEST up to MAXLOGMEMBERS. The file in 
DB_CREATE_FILE_DEST is
    the first member.

o  If DB_RECOVERY_FILE_DEST is specified and DB_CREATE_FILE_DEST or
    DB_CREATE_ONLINE_LOG_DEST_n are not specified, an online redolog 
file member is
    created in DB_RECOVERY_FILE_DEST.

o  If DB_CREATE_ONLINE_LOG_DEST_n, DB_CREATE_FILE_DEST, or
    DB_RECOVERY_FILE_DEST are all not specified, an online redo log file is
    created in an operating system' specific default location (eq 
$ORACLE_HOME/dbs).
    The file is not created as an Oracle Manager File (OMF).


Tad realiai db_create_online_log_dest_1 parametro reikšmę gali mest 
lauk. Aš asmeniškai siūlyčiau serverio architektūrą pasiplanuoti kad 
būtų bent taip: C: - sisteminis, D: - softas, E: - DB failai, F: - Flash 
Recovery Area su visais jai priklausančiais failais. Kol vyksta tokie 
čiudai, taip pat siūlau bent laikinai nedubliuoti REDO logų (laikyti 
kiekvienoje grupėje po 1 logą).

> 2) 
> Errors in file d:\oracle\admin\sid\bdump\v8_lgwr_2068.trc:
> 
> ORA-00313: open failed for members of log group 1 of thread 1
> 

Čia, mano manymu, paseka to, kad log writeris (db procesas) nesugeba 
rašyti į redo logą. Apie tai jau diskutuota - matomai logas aktyvus ir 
negali jo per naują panaudoti. Sprendimus irgi aptarėm - nuimti kvotas 
nuo log_archive_dest_2 parametro, iškelti į kitą vietą, sukurti per 
naują ir t.t. Beje, referencas apie log_archive_dest_n: 
http://download.oracle.com/docs/cd/B14117_01/server.101/b10755/initparams101.htm#sthref425
Šiaip gal paprastumo dėlei irgi siūlyčiau nenaudoti log_archive_dest_n 
parametrų, o vietoje jų palikti vieną log_archive_dest su normaliu keliu 
į normalų folderį.


> 3)Fri Jun 12 10:51:55 2009
> 
> ALTER SYSTEM SET log_archive_dest_1='LOCATION=e:\oracle\log\' SCOPE=BOTH;
> 
> Fri Jun 12 10:54:03 2009
> 
> Errors in file e:\udump\sid_ora_3252.trc:
> 
> ORA-07445: exception encountered: core dump [ACCESS_VIOLATION] [___intel_new_memcpy+67] [PC:0x27BE5E3] [ADDR:0x101BAA9D] [UNABLE_TO_READ] []

Kaip jau rašiau, pabandyk naudoti log_archive_dest parametrą vietoje tų 
su skaičiais:
http://download.oracle.com/docs/cd/B14117_01/server.101/b10755/initparams100.htm


> 4) ALTER DATABASE CLEAR UNARCHIVED LOGFILE GROUP 4
> Fri Jun 12 11:37:34 2009
> ORA-1624 signalled during: ALTER DATABASE CLEAR UNARCHIVED LOGFILE GROUP 4...
> Fri Jun 12 11:41:42 2009
> Errors in file e:\udump\sid_ora_2624.trc:
> ORA-07445: exception encountered: core dump [ACCESS_VIOLATION] [___intel_new_memcpy+67] [PC:0x27BE5E3] [ADDR:0xF541E53] [UNABLE_TO_READ] []
> 

Iš metalinko:
- Clear the logfile having the problem:

   Syntax:

       alter database clear <unarchived> logfile group <integer>;
       alter database clear <unarchived> logfile '<filename>';

   eg: alter database clear logfile group 1;
       alter database clear unarchived logfile group 1;

- An online redo log file with status=CURRENT or status=ACTIVE in v$log 
may not be cleared and
the error ORA-1624 will be produced.

- Please note that 'alter database clear logfile' should be used 
cautiously. If no archived log was produced, then
a complete recovery will not be possible. Perform a backup immediately 
after completing this command.


Sėkmės ir darbingo savaitgalio :)


P.S. Dar galėtum dėl viso pikto sugeneruoti ir pfile ir prisegti, 
pažiūrėtume gal dar kokių minčių kils.
CREATE PFILE='C:\pfile.txt' FROM SPFILE;