Oracle DBA

SQL> select log_mode from v$database;

LOG_MODE
------------
NOARCHIVELOG

1.5 BT) Nézzük meg, hogy használunk-e spfile -t / Check if server is using spfile

Először nézzük meg, hogy milyen módban van az adatbázisunk. / First let's check which mode our database is in.

[oracle@localhost ~]$ sqlplus / as sysdba

SQL*Plus: Release 11.2.0.2.0 Production on Fri Oct 28 15:06:43 2011

Copyright (c) 1982, 2010, Oracle.  All rights reserved.


Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> select log_mode from v$database;

LOG_MODE
------------
NOARCHIVELOG

 OK, állítsuk le, majd mount módban indítsuk el, és tegyük ARCHIVELOG módba, majd nyissuk meg. / Okay, let's shut it down, then start it in mount mode and then change it to ARCHIVELOG mode then open it.

SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup mount
ORACLE instance started.

Total System Global Area  456146944 bytes
Fixed Size                  1344840 bytes
Variable Size             377490104 bytes
Database Buffers           71303168 bytes
Redo Buffers                6008832 bytes
Database mounted.
SQL> alter database archivelog;
SQL> alter database open;

Database altered

Nézzük meg, sikerült-e. / Let's check if it succeeded.

SQL> select log_mode from v$database;

LOG_MODE
------------
ARCHIVELOG
Megnézhetjük archive log list paranccsal is. / We can also check with archive log list command.

SQL> archive log list
Database log mode              Archive Mode
Automatic archival             Enabled
Archive destination            USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence     384
Next log sequence to archive   386
Current log sequence           386


 

Van egy select, ami sehogy nem akart leftuni, egy tizenmilliós táblán szalad végig, plusz néhány kisebb lookup táblából vesz még adatokat. Tettem indexeket a join mezőkre, de az sem segített. Hívjuk segítségül a tuning advisort!

There is a select that never happened to finish running. It scans through a 10M record table, and uses some other lookup tables to fetch additional data. I have created indexes on the join fields, but they didn't help. Let's call the tuning advisor.

DECLARE
 ret_val VARCHAR2(4000);
 SqlStr  CLOB := 'create TABLE bt_tesztusp2 AS (
SELECT ... <select statement goes here>  )';

BEGIN
  ret_val := dbms_sqltune.create_tuning_task(SqlStr);
  dbms_output.put_line(ret_val);
END;

Megvan az tuning task / we have the tuning task:
TASK_25827

Futtassuk le / let's run it:

SQL> exec dbms_sqltune.execute_tuning_task('TASK_25827');

PL/SQL procedure successfully completed
Miután lefutott, megnézhetjük az eredményét, ami egy CLOB-ban látható / After it has finished running, we can check the results coming in a CLOB:

SELECT dbms_sqltune.report_tuning_task('TASK_25827') FROM dual;


GENERAL INFORMATION SECTION
-------------------------------------------------------------------------------
Tuning Task Name                  : TASK_25827
Tuning Task Owner                 : BAGOT
Scope                             : COMPREHENSIVE
Time Limit(seconds)               : 1800
Completion Status                 : COMPLETED
Started at                        : 09/02/2011 11:40:13
Completed at                      : 09/02/2011 12:08:02
Number of SQL Profile Findings    : 1

-------------------------------------------------------------------------------
Schema Name: BAGOT
SQL ID     : bgv2s20aqq8b2
SQL Text   : create TABLE bt_tesztusp2 AS (
             SELECT <my select statement>
               )

-------------------------------------------------------------------------------
FINDINGS SECTION (1 finding)
-------------------------------------------------------------------------------

1- SQL Profile Finding (see explain plans section below)
--------------------------------------------------------
  A potentially better execution plan was found for this statement.

  Recommendation (estimated benefit: 98,51%)
  ------------------------------------------
  - Consider accepting the recommended SQL profile.
    execute dbms_sqltune.accept_sql_profile(task_name => 'TASK_25827',
            replace => TRUE);

-------------------------------------------------------------------------------
EXPLAIN PLANS SECTION
-------------------------------------------------------------------------------

1- Original With Adjusted Cost
------------------------------
Plan hash value: 2282809337

---------------------------------------------------------------------------------------------------------------
| Id  | Operation                           | Name            | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------------------------------
|   0 | CREATE TABLE STATEMENT              |                 | 96528 |    38M|       |   790K  (1)| 01:11:30 |
|   1 |  LOAD AS SELECT                     | BT_TESZTUSP2    |       |       |       |            |          |
|   2 |   TABLE ACCESS BY INDEX ROWID       | L_1INST_MUSP001 |     1 |    28 |       |     2   (0)| 00:00:01 |
|   3 |    NESTED LOOPS                     |                 | 96528 |    38M|       |   790K  (1)| 01:11:29 |
|*  4 |     HASH JOIN                       |                 | 73151 |    27M|    21M|   668K  (1)| 01:00:27 |
|   5 |      TABLE ACCESS BY INDEX ROWID    | L_1INST_MEPF00  |     1 |    75 |       |     2   (0)| 00:00:01 |
|   6 |       NESTED LOOPS                  |                 | 73541 |    20M|       |   668K  (1)| 01:00:25 |
|   7 |        NESTED LOOPS                 |                 | 73367 |    15M|       |   594K  (1)| 00:53:46 |
|   8 |         NESTED LOOPS                |                 |   133K|    18M|       |   460K  (1)| 00:41:42 |
|*  9 |          TABLE ACCESS BY INDEX ROWID| L_1INST_PCPF00  |   153K|    13M|       |    52   (2)| 00:00:01 |
|* 10 |           INDEX RANGE SCAN          | PCPF00_IX1      |  1386 |       |       |     4   (0)| 00:00:01 |
|  11 |          TABLE ACCESS BY INDEX ROWID| L_1INST_SOPF00  |     1 |    53 |       |     3   (0)| 00:00:01 |
|* 12 |           INDEX RANGE SCAN          | SOPF00_IX1      |     1 |       |       |     2   (0)| 00:00:01 |
|  13 |         TABLE ACCESS BY INDEX ROWID | L_1INST_SVPF00  |     1 |    81 |       |     2   (0)| 00:00:01 |
|* 14 |          INDEX RANGE SCAN           | SVPF00_IX1      |     1 |       |       |     1   (0)| 00:00:01 |
|* 15 |        INDEX RANGE SCAN             | MEPF00_IX1      |     1 |       |       |     1   (0)| 00:00:01 |
|* 16 |      TABLE ACCESS FULL              | L_1INST_MUSP00  | 15643 |  1405K|       |     7  (43)| 00:00:01 |
|* 17 |     INDEX RANGE SCAN                | MUSP001_IX1     |     1 |       |       |     1   (0)| 00:00:01 |
---------------------------------------------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
 
   4 - access <masked>
   9 - filter <masked>
  10 - access <masked>
  12 - access <masked>
  14 - access <masked>
  15 - access <masked>
  16 - filter <masked>
  17 - access <masked>

2- Using SQL Profile
--------------------
Plan hash value: 1624737859

----------------------------------------------------------------------------------------------------------
| Id  | Operation                      | Name            | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------------------------
|   0 | CREATE TABLE STATEMENT         |                 | 96528 |    38M|       | 11737  (14)| 00:01:04 |
|   1 |  LOAD AS SELECT                | BT_TESZTUSP2    |       |       |       |            |          |
|*  2 |   HASH JOIN                    |                 | 96528 |    38M|       | 11490  (14)| 00:01:03 |
|*  3 |    TABLE ACCESS FULL           | L_1INST_MUSP001 | 20648 |   564K|       |     5  (60)| 00:00:01 |
|*  4 |    HASH JOIN                   |                 | 73151 |    27M|       | 11482  (14)| 00:01:03 |
|   5 |     TABLE ACCESS BY INDEX ROWID| L_1INST_MEPF00  | 14825 |  1085K|       |     4   (0)| 00:00:01 |
|*  6 |      INDEX RANGE SCAN          | MEPF00_IX1      |    60 |       |       |     2   (0)| 00:00:01 |
|*  7 |     HASH JOIN                  |                 | 72978 |    21M|       | 11476  (14)| 00:01:03 |
|*  8 |      TABLE ACCESS FULL         | L_1INST_MUSP00  | 15643 |  1405K|       |     7  (43)| 00:00:01 |
|*  9 |      HASH JOIN                 |                 | 73367 |    15M|       | 11467  (14)| 00:01:03 |
|* 10 |       TABLE ACCESS FULL        | L_1INST_SVPF00  |  1937 |   153K|       |     2   (0)| 00:00:01 |
|* 11 |       HASH JOIN                |                 |   133K|    18M|    14M| 11462  (14)| 00:01:03 |
|* 12 |        TABLE ACCESS FULL       | L_1INST_PCPF00  |   153K|    13M|       |    50  (76)| 00:00:01 |
|* 13 |        TABLE ACCESS FULL       | L_1INST_SOPF00  |    10M|   534M|       |  2419  (45)| 00:00:14 |
----------------------------------------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
 
   2 - access <masked>
   3 - filter <masked>
   4 - access <masked>
   6 - access <masked>
   7 - access <masked>
   8 - filter <masked>
   9 - access <masked>
  10 - filter <masked>
  11 - access <masked>
  12 - filter <masked>
  13 - filter <masked>

-------------------------------------------------------------------------------

OK, fogadjuk el a javaslatot / Let's accept the recommendation:

SQL> execute dbms_sqltune.accept_sql_profile(task_name => 'TASK_25827', replace => TRUE);

PL/SQL procedure successfully completed

Az explain plan valóban frissült, a SELECT szövegének betűre egyeznie kell a tuning advisornak paraméterként megadottal, és végül 41 perc alatt lefutott. Ez az adott helyzetben már elfogadható / The explain plan really has been refreshed, the text of the SELECT statement has to be exactly the same as the one given to the tuning advisor as a parameter, and eventually it has completed in 41 minutes. This is acceptable in this situation.

Takarítsunk / let's do a clean-up:

SQL> exec dbms_sqltune.drop_tuning_task('TASK_25827');
 
PL/SQL procedure successfully completed

Az egyik használaton kívüli teszt szerverünket életre kellett lehelni. Igenám, csak közben elvették alóla a memóriát, összesen 2GB maradt.

---

We had to startup one of our test servers not being used. Meanwhile its memory has been reduced to only 2GB.

C:\Users\oracle>SET ORACLE_SID=TEST
C:\Users\oracle>SQLPLUS / AS SYSDBA

SQL*Plus: Release 10.2.0.4.0 - Production on Cs. J˙l. 28 08:21:32 2011
Copyright (c) 1982, 2007, Oracle.  All Rights Reserved.
Connected to an idle instance.

SQL> STARTUP
ORA-27102: out of memory
OSD-00026: additional error information
O/S-Error: (OS 1455) The paging file is too small for this operation to complete

Persze, hogy csak spfile létezett, pfile nem, kellett egyet gyártani, hogy el tudjon indulni.

---

Of course there was only an spfile, no pfile, so we had to create one in order to let oracle start up.

initTEST.ora
db_name='TEST'
sga_target=750M
pga_aggregate_target=250M
processes = 150
audit_file_dest='c:\oracle\product\10.2.0\admin\TEST\adump '
audit_trail ='db'
db_block_size=8192
db_domain='fibernetrt.fibernet.hu'
db_recovery_file_dest='c:\oracle\product\10.2.0\flash_recovery_area'
db_recovery_file_dest_size=2G
background_dump_dest='c:\oracle\product\10.2.0\admin\TEST\bdump'
dispatchers='(PROTOCOL=TCP) (SERVICE=TEST)'
open_cursors=300
remote_login_passwordfile='EXCLUSIVE'
undo_tablespace='UNDO_DATA'
# You may want to ensure that control files are created on separate physical
# devices
control_files = ("c:\oracle\product\10.2.0\oradata\test\CONTROL01.CTL","c:\oracle\product\10.2.0
\oradata\test\CONTROL02.CTL","c:\oracle\product\10.2.0\oradata\test\CONTROL03.CTL")
compatible ='10.2.0'

Próbáljuk ki!

---

Let's give it a try.

SQL> STARTUP PFILE='c:\oracle\product\10.2.0\db_1\database\initTEST.ORA'
ORACLE instance started.

Total System Global Area  788529152 bytes
Fixed Size                  2069000 bytes
Variable Size             201330168 bytes
Database Buffers          578813952 bytes
Redo Buffers                6316032 bytes
ORA-00201: control file version 10.2.0.3.0 incompatible with ORACLE version
10.2.0.0.0
ORA-00202: control file: 'C:\ORACLE\PRODUCT\10.2.0\ORADATA\TEST\CONTROL01.CTL'

Hoppá, az init.ora -ban cseréljük ki a compatible = '10.2.0' paramétert compatible = '10.2.0.3' -ra.

---

Oops, let's change compatible = '10.2.0' parameter to compatible = '10.2.0.3' in init.ora

SQL> shut abort
ORACLE instance shut down.
SQL> STARTUP PFILE='c:\oracle\product\10.2.0\db_1\database\initTEST.ORA'
ORACLE instance started.

Total System Global Area  788529152 bytes
Fixed Size                  2069000 bytes
Variable Size             201330168 bytes
Database Buffers          578813952 bytes
Redo Buffers                6316032 bytes
Database mounted.
Database opened.
SQL>

 Voila!

for i in `ps -ef|grep pmon|grep -v grep |awk '{print $9}'|cut -d"_" -f3`;do
   #itt valamit csinalhatsz / do your stuff here
   #$i a futo Oracle Instance-ok nevet tartalmazza
done
 

egy gyors wrapper script, amit hasznalok surun, ha valamely gepunkon az osszes adatbazissal tenni szeretnek valalmit.
a megoldashoz termeszetesen adott a szepen karbantartott oratab, (feltetel hogy az instance automatikus inditasa engedelyezve legyen az oratab-ban ---> az utolso mezo=Y)

pl:

DABC:/oracle/product/10.2.0:Y
DABC1:/oracle/product/10.2.0:Y
DABC2:/oracle/product/10.2.0:Y
DABC3:/oracle/product/10.2.0:Y
DABC4:/oracle/product/10.2.0:Y
valahogy igy

grep "^[^#]*Y$" /etc/oratab|while read line; do
  OSID=`echo $line|cut -d":" -f1`
  echo "\n" $OSID "\n" '#########' "\n";
  echo "Ide johet amit szeretnel csinalni, stb..."
done

Nos, oktober 1-tol a DWH DBA (Datawarehouse/gy.k. adattarhaz) csoport tagja vagyok. :)

Lassunk egy egyszerunek tuno esetet es annak gyors megoldasat. UNIX-on (pl.:Solaris) amennyiben bejelentkezel sqlplus-bol igy:

sqlplus scott/tigerezesetben a ps -ef|grep sqlplus szepen kiirja a passwordot

oracle 28221  4364  0 09:23:15 pts/4    0:00 sqlplus scott/tigerezt nem szeretnenk, ugye. Foleg ha scriptelunk, meg egyebkent sem. Trukkos felhasznalok elonyt tudnak kovacsolni ebbol a kis gyengesegbol.
Ket gyors megoldasi lehetoseg (nem tul szep scriptben jelszot beegetni, de ha nincs mas megoldas...)

1) szkripten belul mukodik (interaktivan is csak nem tul kenyelmes):

echo tiger|sqlplus scott << EOF
.
.
.
EOF2) vagy igy

sqlplus /nolog << EOF
connect scott/tiger
.
.
.
EOFA fenn emlitett modozatokat hasznalva ps -ef|grep sqlplus nem jeleniti meg a jelszot a processz listaban:)

Termeszetesen vannak egyeb megoldasi lehetosegek is (pl.: OS autentikalt felhasznalo/OS authenticated user, tudjatok: ez az koznyelveben OPS$-kent ismert /init.ora: os_authent_prefix/)

Amennyiben felhasznalokat kell migralnod, objektum/rendszer privilegiumokkal, role-ok, tablater quota-k megorzesevel itt egy szkript amivel a klonozo sql-t generalhatjuk:

 set long 100000
declare
 begin
 DBMS_METADATA.SET_TRANSFORM_PARAM(
DBMS_METADATA.SESSION_TRANSFORM, 'SQLTERMINATOR',TRUE);
 declare
   no_grant      EXCEPTION;
   PRAGMA EXCEPTION_INIT (no_grant, -31608);
   CURSOR get_username
   IS
      SELECT username
        FROM all_users;
      
   file_handle   UTL_FILE.file_type;
   stmt          CLOB;
BEGIN
   file_handle := UTL_FILE.fopen ('DP07', 'cr_users.sql', 'w', 32767);

   FOR l_user IN get_username
   LOOP

-- USERS
    stmt:=DBMS_METADATA.get_ddl ('USER', l_user.username)||chr(10);
    begin
     stmt:=stmt||'---------------------------------------'||chr(10);
     stmt:=stmt||'-- SYSTEM_GRANT'||chr(10);
     stmt:=stmt||'---------------------------------------'||chr(10);
     stmt:=stmt||DBMS_METADATA.get_granted_ddl ('SYSTEM_GRANT', l_user.username)||chr(10);
     exception
      when no_grant then stmt := '-- no system grants'||chr(10);
    end;
    begin
     stmt:=stmt||'---------------------------------------'||chr(10);
     stmt:=stmt||'-- OBJECT_GRANT'||chr(10);
     stmt:=stmt||'---------------------------------------'||chr(10);
     stmt:=stmt||DBMS_METADATA.get_granted_ddl ('OBJECT_GRANT', l_user.username)||chr(10);
     exception
      when no_grant then stmt := '-- no object grants'||chr(10);
    end;
    begin
     stmt:=stmt||'---------------------------------------'||chr(10);
     stmt:=stmt||'-- ROLE_GRANT'||chr(10);
     stmt:=stmt||'---------------------------------------'||chr(10);
     stmt := stmt||DBMS_METADATA.GET_GRANTED_DDL('ROLE_GRANT', l_user.username)||chr(10);
     exception
      when no_grant then stmt := '-- no role grants'||chr(10);
    end;
    begin
     stmt:=stmt||'---------------------------------------'||chr(10);
     stmt:=stmt||'-- TABLESPACE_QUOTA'||chr(10);
     stmt:=stmt||'---------------------------------------'||chr(10);
     stmt:=stmt||DBMS_METADATA.GET_GRANTED_DDL(
'TABLESPACE_QUOTA',l_user.username)||chr(10);
     exception
      when no_grant then stmt := '-- no tablespace quota'||chr(10);
    end;
   begin
     stmt:=stmt||'---------------------------------------'||chr(10);
     stmt:=stmt||'-- DEFAULT_ROLE'||chr(10);
     stmt:=stmt||'---------------------------------------'||chr(10);
    stmt := stmt||DBMS_METADATA.GET_GRANTED_DDL('DEFAULT_ROLE', l_user.username)||chr(10);
    exception
     when no_grant then stmt := '-- no default role'||chr(10);
   end;

   UTL_FILE.put (file_handle, stmt);

 end loop;
 UTL_FILE.fclose (file_handle);
 END;
DBMS_METADATA.SET_TRANSFORM_PARAM(
DBMS_METADATA.SESSION_TRANSFORM,
'SQLTERMINATOR',FALSE);
end;

/ 

Egz kollega a szomszedos DBA csoportbol megkeresett azzal, hogy a fonoke keri tole, hogy szerezze be az informaciokat az osszes oracle csoporttol, mennyi adatot mentunk el (szalagra, diszkre) rman-nal. Most csak a full backup-ok erdekeltek.

Nos nalunk az rman katalogus adatbazis ugy van felsetup-olva hogy minden kliens adatbazisnak van egy schemaja, ami tartalmazza a katalogust. Magyarul, nem 1 nagy katalogust hasznalunk hanem 250 kicsit.

irtam egy szkirptet, ami a 10g katalogusokra mukodik. amit csinal:

az elmult 30 napban a legutolso sikeres full backup (ha volt) eseteben kiirja mennyi volt az elmentett adatmennyiseg.

SELECT device_type, 
       round(SUM (output_bytes) / 1024 / 1024) MB
FROM &1.rc_backup_set_details
WHERE (session_key, session_recid) =
 (SELECT session_key,
         session_recid 
  FROM 
   (SELECT rbsd.session_key,
           rbsd.session_recid, 
           TRUNC (rbsd.start_time) 
    FROM &1.rc_backup_set_details rbsd,
         &1.rc_rman_backup_job_details rbjd
    WHERE rbsd.session_key = rbjd.session_key
      AND rbsd.session_recid = rbjd.session_recid 
      AND rbjd.status = 'COMPLETED'
      AND rbsd.completion_time > SYSDATE - 30
      AND rbsd.backup_type = 'D'
      AND rbsd.incremental_level = 0 
    ORDER BY 3 DESC)
   WHERE ROWNUM = 1)
     AND backup_type = 'D'
     AND incremental_level=0
group by device_type;

Eme szkript kore lehet irni egy egyszeru wrappert es mindjart latjuk is mennyi az annyi az osszes 10-es adatbazisra.

ez csunya, csak 18 even felulieknek :)

egy kollega 9i-rol 10.2.0.4-re upgradelt egy UAT adatbazist solaris-on.
az upgrade sikeresnek bizonyult.

kis ido elteltevel hivasokat kezdett kapni a fejlesztoktol/teszteloktol, hogy valami nem mukodik tokeletesen, a kovetkezo hibauzeneteket kapjak:

ERROR at line 1:
ORA-04068: existing state of packages has been discarded
ORA-04065: not executed, altered or dropped stored procedure "PUBLIC.DBMS_LOB"
ORA-06508: PL/SQL: could not find program unit being called: "PUBLIC.DBMS_LOB"
ORA-06512: at "XXXXX.YYYYY_ZZZ_BL_PKG", line 354
ORA-06512: at "SSSSS.WWWWW_PPPPP_BL_PKG", line 354
ORA-06512: at line 4

Nehany probalkozas utan szolt hogy menjek segiteni, mert elakadt.

ORA-4068-nal altalaban egy recompile segit a dolgon, de mivel itt a DBMS_LOB-ra panaszkodott a rendszer kicsit gyanakodni kezdtem.

Vegigneztem az upgrade logot, dba_registry, minden jonak tunt.
Invalid objektumok nincsenek. Furcsa!!
Hat akkor hajra:

alter system flush shared_pool;
alter package dbms_lob compile;
alter package dbms_lob compile body;
@?/rdbms/admin/utlrp

ezek utan fejlesztok mar hivtak is hogy megjavult a rendszer. Na, milyen ugyesek voltunk. szevasztok, hazamentem.

Masnap reggel azzal fogadtak, hogy nehany oraig mukodott a rendszer azota azonban ismet a fenti hibauzeneteket kapjak. (a kollega korabban ujra lefuttatta a catalog, catproc duot, de nem segitett).

Ismetlem, nincsenek invalid objektumok!

Ekkor mar mindketten erosen raztuk a fejunket es bug-ot szimatoltunk. Ebben az esetben csak egy shared pool flush-t eresztettem el, mert nem lattam ertelmet ujraforditani az egyebkent is valid objektumokat. Ujra megjavult a rendszer. A kollega ekkor mar oriasi lendulettel nyitotta a SR-t a metalinken.

Idokozben bogarasztam kicsit oracle-eknel es nicsak mit talaltam:

Doc ID: 778842.1
Subject: Possible causes for ORA-4068 and ORA-4065 in 10gR2
Bug 6136074 ORA-4068 ORA-4065 ORA-06508 ERRORS SIGNALED FOR VALID OBJECTSez eleg kozel van ahhoz amit mi kaptunk :P

tovabb olvasva egy szuper "data dictionary consistency check" anyagot talaltam, legfuttattam es majdnem sirva fakadtam:

.
.
Problem: SOURCE$ for OBJ# not in OBJ$ - Bug:3532977 ?
SOURCE$ has 68 rows for 1 OBJ# values not in OBJ$
.
.
Problem: Dependency$ p_timestamp mismatch for VALID objects
.
.
Warning: Synonym LAST_DDL_TIME!=CREATED - May hit Bug:2371453
.
.
Found 78 potential problems and 396 warnings
Contact Oracle Support with the output
to check if the above needs attention or not az output ment a metalinkre az SR-ba, eredmeny meg nincs, de szerintem tuti adatszotar (data dictionary) korrupcio.

Ha valakit erdekelnek az adatszotar csekker szkriptek ("hcheck.sql" script to check for known problems in Oracle8i,Oracle9i, Oracle10g and Oracle 11g):
METALINK SCRIPT DOC ID 136697.1

vagy uzenet nekem.
 

A redo logok valtasa igencsak draga operacio. Miert? Tobbek kozott ilyenkor checkpoint (is) tortenik.

(DBWR, LGWR, valszeg az ARCH processek kemenyen dolgoznak)

Az egyik legaltalanosabb problema a redo logok tul kis merete, amely nagy dml terheles alatt a rendszert durvan lassithatja, mivel ha pl.: egy percen belul 1-2 logvaltas tortenik az minimum ugyanennyi checkpointot is jelent. A checkpoint pedig mindig eroforras igenyes muvelet.

ket szkriptet mutatok most be amivel a multbeli logvaltasokat (log switch -eket) elemezhetjuk:

az elso szkriptet ugy irtam meg es parametereztem, hogy csak hetkoznapokat monitorozzon ejfel es reggel 8 kozott (termeszetesen megvaltoztathatod :) ):

 

SELECT TRUNC (a.first_time), COUNT (*)
FROM
(SELECT b.first_time
FROM v$log_history b
WHERE TO_CHAR (b.first_time, 'Dy') IN ('Mon', 'Tue', 'Wed', 'Thu', 'Fri')) a
WHERE TO_NUMBER (TO_CHAR (a.first_time, 'HH24')) BETWEEN 0 AND 8 GROUP BY TRUNC (a.first_time)
ORDER BY 1 DESC

A masodik szkript hasonlo, viszont ez napon beluli eloszlast mutat, perces bontasban (intraday distribution): SELECT to_char(a.first_time,'YYYY/Mon/DD-HH24-MI') HOUR_OF_DAY,
COUNT (*)
FROM (SELECT b.first_time FROM v$log_history b) a where
trunc(a.first_time)=to_date('290109','DDMMYY')
GROUP BY to_char(a.first_time,'YYYY/Mon/DD-HH24-MI')
ORDER BY 2 desc Mindez szep es jo, mostmar tudjuk hogy orankent mikor van csucs redo log "gyartasban", akkor allitsuk be a meretet rendesen.

Az tapasztalatom az, hogy 5-15 perces logvaltas optimalis, persze minden a kornyezettol fugg.
Ha surun valtunk logot, belassul a rendszer, ha ritkan akkor instance crash eseten hosszabb a recovery (vagy tobb adatot vesztunk...). Mindenki dontse el mi a fontos(abb).

Nezzunk egy peldat, intraday distribution-ra (a 2. szkript kimenete): 2009/Jan/29-07-03 3
2009/Jan/29-07-09 3
2009/Jan/29-07-02 3
2009/Jan/29-07-04 2
2009/Jan/29-08-59 2
2009/Jan/29-20-10 2
2009/Jan/29-07-14 2
.
.
.

A fenti lista azt mutatja, hogy Jan 29-en reggel 7 ora utan volt a "peak period" logvaltas szempontjabol, 3 logvaltas/perc!! ... az sok.

Akkor most szamoljunk:

select distinct(bytes/1024/1024) REDO_MB from v$log;Ha itt nem 1 sort kaptal vissza eredmenykent, akkor ejnye-bejnye es javaslom gondolkozz el rajta miert nincsenek a redo logjaid egyforma meretre allitva :) Szoval a lenyeg, hogy igy megkaptuk a redo logok meretet MB-ban.

Ha a fenti peldat veszem alapul (csucsidoben 3 logvaltas) es az 5 perces logvaltasi intervallumot szeretnem elerni a csucsidoszakban akkor:

---

3 * 5 * [aktualis redo log meret MB] = uj redo log merete MB-ban

---

 

Pl.: az aktualis redo logok merete 50 MB akkor a kepletbe valo behelyettesites utan 3*5*50 = 750MB

Ez a gyalogos modszer. Ha lustak vagyunk vagy nem bizunk magunkban vegyuk igenybe a super-dooper Oracle advisory segitseget, lasd alabb ...

A fenti technika hatranya, hogy ha a DB DML terhelese nem egyenletes (az esetek nagy tobbsegeben ez igy van) akkor sajnos mivel a csucsra mereteztunk, lesznek idoszakok amikor a redo logok merete nem optimalis (peldany crash eseten sok adatot veszithetunk, vagy az instance recovery sokaing tart).

Hasznaljuk a fast_start_mttr_target parametert, amennyiben az instance osszeomlas utani ujraidulas kivant idotartamat szeretnenk meghatarozni.

... amennyibe a fast_start_mttr_target parametert nem 0 ertekre allitjuk, akkor igenybe vehetjuk az Oracle advisort is az optimalis redo log meret meghatarozasara:

 select optimal_logfile_size from v$instance_recovery; Ezzel azert csinjan banjunk, mert jobb felni mint ... szoval mindig ellenorizzuk terheles alatt hogyan muzsikal a DBnk.

Kellemes meretezes!

Kerestem egy olyan megoldast ami egy adott felhasznalo teljes koru auditalasat teszi lehetove.

Termeszetesen az audit_trail init parameter korrekt beallitasa mindig szukseges, erre most nem ternek ki, reszletek itt >>>>>>>>>>>

Az evidens megoldas a :

 audit all by uglyuser by access;

 audit all privileges by uglyuser by access;

lenne de ez sajnos igencsak keveske. Mi tobbet szeretnenk tudni!

A dokumentacio szerint az "audit all" csak egy adott reszhalmazt audital, tehat a kovetkezoket meg meg kell tennunk:

audit
 alter sequence,
 alter table,
 comment table,
 delete table,
 execute procedure,
 grant directory,
 grant procedure,
 grant sequence,
 grant table,
 grant type,
 insert table,
 lock table,
 select sequence,
 select table,
 update table
by uglyuser by access;

De ez nekunk meg mindig keves mert nem latjuk azokat a konkret sql-eket, amelyeket az uglyuser futtatott, pedig mi nagyon szigoru DB adminok vagyunk es mindenrol tudni akarunk! :)

Ehhez krealjunk egy FGA policy-t:

begin
 DBMS_FGA.ADD_POLICY(
 object_schema => 'PAYROLL',
 object_name=>'SALARIES',
 policy_name   => 'salary_fga',
 audit_condition => 'user='||'''UGLYUSER''',
 statement_types => 'insert,update,delete,select');
end;

Mit is fog a fenti policy tenni? Amennyiben kedves baratunk - UGLYUSER - a payroll.salaries tablat manipulalja (barmilyen dml-lel) az audit rekord(oka)t fog generalni, amelyek szepen lathatok a DBA_FGA_AUDIT_TRAIL nezetben. (illetve a dba_common_audit_trail -ben is).

Latjuk a vegrehajtott SQL-eket, es a bind parameterek is helyettesitve vannak ! Szuper!

Azonban mi szeretnenk meg tobb tablat auditalni! Ekkor egyszeruen csak egy masik objektum nevvel egy uj policyt adunk a rendszerhez:

begin
 DBMS_FGA.ADD_POLICY(
 object_schema => 'PAYROLL',
 object_name=>'BONUSES',
 policy_name   => 'payroll_fga',
 audit_condition => 'user='||'''UGLYUSER''',
 statement_types => 'insert,update,delete,select');
end;

A rendszerben talalhato FGA policy-k listazhatok a DBA_AUDIT_POLICIES nezetbol.

Inaktivalni FGA policy-t egy objektumon a kovetkezokepp lehetseges:

begin
 DBMS_FGA.DISABLE_POLICY(
 object_schema => 'PAYROLL',
 object_name=>'BONUSES',
 policy_name   => 'payroll_fga');
end;

Ha mar nem kell, igy dobjuk el:

begin
 DBMS_FGA.DROP_POLICY(
 object_schema => 'PAYROLL',
 object_name=>'BONUSES',
 policy_name   => 'payroll_fga');
end

Az Oracle szoftver altal nyujtott fine graded auditing mindennel sokkal tobb mindent tud, itt csupan azt szerettem volna bemutatni, hogyan tudjuk 1 adott felhasznalo tevekenyseget rendkivuli reszletesseggel nyomonkovetni. Nem esett szo magarol az "audit" parancs altal generalt audit rekordokrol, az egy masikbejegyzes temaja lehet.

library cache pin wait, miert??

es mi az ami blokkol? 

az eredeti innen valo: http://www.freelists.org/archives/oracle-l/02-2007/msg00288.html

hasznos szkript:

 

 

 

 

 

select decode(lob.kglobtyp, 0, 'NEXT OBJECT', 1, 'INDEX', 2, 'TABLE', 3, 'CLUSTER',

                      4, 'VIEW', 5, 'SYNONYM', 6, 'SEQUENCE',

                      7, 'PROCEDURE', 8, 'FUNCTION', 9, 'PACKAGE',

                      11, 'PACKAGE BODY', 12, 'TRIGGER',

                      13, 'TYPE', 14, 'TYPE BODY',

                      19, 'TABLE PARTITION', 20, 'INDEX PARTITION', 21, 'LOB',

                      22, 'LIBRARY', 23, 'DIRECTORY', 24, 'QUEUE',

                      28, 'JAVA SOURCE', 29, 'JAVA CLASS', 30, 'JAVA RESOURCE',

                      32, 'INDEXTYPE', 33, 'OPERATOR',

                      34, 'TABLE SUBPARTITION', 35, 'INDEX SUBPARTITION',

                      40, 'LOB PARTITION', 41, 'LOB SUBPARTITION',

                      42, 'MATERIALIZED VIEW',

                      43, 'DIMENSION',

                      44, 'CONTEXT', 46, 'RULE SET', 47, 'RESOURCE PLAN',

                      48, 'CONSUMER GROUP',

                      51, 'SUBSCRIPTION', 52, 'LOCATION',

                      55, 'XML SCHEMA', 56, 'JAVA DATA',

                      57, 'SECURITY PROFILE', 59, 'RULE',

                      62, 'EVALUATION CONTEXT',

                     'UNDEFINED') object_type,

       lob.KGLNAOBJ object_name,

       pn.KGLPNMOD lock_mode_held,

       pn.KGLPNREQ lock_mode_requested,

       ses.sid,

       ses.serial#,

       ses.username

  FROM

       x$kglpn pn,

       v$session ses,

       x$kglob lob,

       v$session_wait vsw

  WHERE

   pn.KGLPNUSE = ses.saddr and

   pn.KGLPNHDL = lob.KGLHDADR

   and lob.kglhdadr = vsw.p1raw

   and vsw.event = 'library cache pin'

order by lock_mode_held desc;

"Who has %ANY% system privilege? Directly granted or through a role"

akar direktben, akar role-on keresztul (Oracle 10g-ben tesztelve, rendszer felhasznalok kizarva):

SELECT drs.grantee USERNAME, 'ROLE: '||granted_role SOURCE
           FROM dba_role_privs drs
 

          WHERE drs.granted_role IN (SELECT DISTINCT grantee
                                                FROM dba_sys_privs
                                               WHERE PRIVILEGE LIKE '%ANY%')
            AND drs.grantee
                NOT IN
                   ('SYS',
                    'SYSTEM',
                    'DBSNMP',
                    'OUTLN',
                    'SCHEDULER_ADMIN',
                    'OEM_MONITOR',
                    'JAVADEBUGPRIV',
                    'IMP_FULL_DATABASE',
                    'EXP_FULL_DATABASE',
                    'EXFSYS',         
                    'AQ_ADMINISTRATOR_ROLE'
                   )
            AND EXISTS (
                   SELECT 1
                     FROM dba_users du
                    WHERE drs.grantee = du.username
                      AND du.account_status = 'OPEN')
UNION ALL
SELECT dsp.grantee USERNAME, 'PRIVILEGE: '||privilege SOURCE
           FROM dba_sys_privs dsp
          WHERE dsp.PRIVILEGE LIKE '%ANY%'
            AND dsp.grantee NOT IN
                   ('SYS',
                    'SYSTEM',
                    'DBSNMP',
                    'OUTLN',
                    'SCHEDULER_ADMIN',
                    'OEM_MONITOR',
                    'JAVADEBUGPRIV',
                    'IMP_FULL_DATABASE',
                    'EXP_FULL_DATABASE',
                    'EXFSYS',
                    'AQ_ADMINISTRATOR_ROLE'
                   )
            AND EXISTS (
                   SELECT 1
                     FROM dba_users du
                    WHERE dsp.grantee = du.username
                      AND du.account_status = 'OPEN')
       ORDER BY 1,2;

 

"Let the users kill their own oracle sessions"  -  tesztelve Oracle 10g-ben

mivel egyre tobb ilyen jellegu kerest kapok mostanaban (please, kill this or that session...)

ugy dontottem megadom a lehetoseget a kollegaknak, hogy sajat maguk lojek ki a "nemkivanatos" munkameneteket.

ez nem trivialis, mivel alter system rendszerjogosultsag szuksegeltetik, azt meg ugye nem osztjuk szire-szora :)

Fontos kiemelni, hogy csak a sajat felhasznalo altal folyamatban levo munkameneteket kepesek a kollegak kiloni (magyarul, ha user scott futtat egy monster lekerdezest, akkor pl.: sqlplus-ba be kell lepjen scott es csak igy tudja kiloni a masik sessiont, ahol a lekerdezese fut).

Telepitese: egy poweruser schema-jaba (<POWERUSER>) az alabbi pkg-t installaljuk.

a kovetkezo jogosultsagot szuksegesek az installalo (<POWERUSER>) schemanak (direktben grantolva, role-on keresztul nem mukodik):

grant select on sys.v_$session to <POWERUSER>;

grant alter system to <POWERUSER>;

majd johet a pkg krealasa.

Telepites utan (<POWERUSER> felhasznalokent):

grant execute on <POWERUSER>.cs_util to public;
create public synonym cs_util for <POWERUSER>.cs_util;

Tovabba:

- SYS% session-t nem lehet kiloni

- mivel nalunk a prod adatbazisok neve PZH.... ezert a P% instance-okon nem lehet hasznalni a pkg-t (kis elovigyazatossag)

 CREATE OR REPLACE PACKAGE CS_UTIL AS

  PROCEDURE KillSid(in_sid IN NUMBER, in_serial in number);

END CS_UTIL;
/
CREATE OR REPLACE PACKAGE BODY cs_util
AS
   PROCEDURE killsid (in_sid IN NUMBER, in_serial IN NUMBER)
   AS
      suser      VARCHAR2 (30);
      killuser   VARCHAR2 (30);
   BEGIN
      SELECT SYS_CONTEXT ('USERENV', 'SESSION_USER')
        INTO suser
        FROM DUAL;

      SELECT username
        INTO killuser
        FROM SYS.v_$session
       WHERE SID = in_sid AND serial# = in_serial;

      IF killuser <> suser
      THEN
         raise_application_error
                (-20001,
                 'SID owner and user executing this procedure does not match'
                );
      ELSIF SUBSTR (SYS_CONTEXT ('USERENV', 'INSTANCE_NAME'), 1, 1) = 'P'
      THEN
         raise_application_error
                 (-20003,
                  'Killing sessions are not allowed on production instances.'
                 );
      ELSIF suser LIKE 'SYS%'
      THEN
         raise_application_error (-20004,
                                  'Killing SYS% processes are not allowed.'
                                 );
      ELSE
         EXECUTE IMMEDIATE    'alter system kill session '''
                           || in_sid
                           || ','
                           || in_serial
                           || '''';
      END IF;
   EXCEPTION
      WHEN NO_DATA_FOUND
      THEN
         raise_application_error (-20002,
                                     'SID: '
                                  || in_sid
                                  || ', serial: '
                                  || in_serial
                                  || ' does not exist.'
                                 );
   END;
END;
/

 

Aug 11-en sikeresen teljesitettem az OCP 11g vizsgat (igy mostmar megvan a 9i, 10g es 11g is :)

ha valakit erdekel anyag hozza, email-ezzen vagy kukk ide: http://11gbooks.blogspot.com/

hasznos lehet nyomozashoz, mi tortenik a datapump jobjaink futasa kozben <Metalink note:286496.1>

Hasznaljuk a TRACE parametert:

expdp system/manager DIRECTORY=my_dir DUMPFILE=expdp_s.dmp \ 
LOGFILE=expdp_s.log TABLES=scott.emp TRACE=480300

*******************************************************************

A TRACE parameter erteke a trace melysegetol/milyensegetol fugg, amely magyarazatat a kovetkezo tablazatban talalhatjuk meg:


-- Summary of Data Pump trace levels:
-- ==================================

  Trace   DM   DW  ORA  Lines
  level  trc  trc  trc     in
  (hex) file file file  trace   Trace what
------- ---- ---- ---- ------ ----------------------------------
  10300    x    x    x  SHDW:  Shadow process (API)(expdp/impdp)
  20300    x    x    x  KUPV:  Fixed table
  40300    x    x    x  'div'  Process services
  80300    x            KUPM:  Master Control Process (MCP)(DM)
 100300    x    x       KUPF:  File Manager
 200300    x    x    x  KUPC:  Queue services
 400300         x       KUPW:  Worker process(es)         (DW)
 800300         x       KUPD:  Data Package
1000300         x       META:  Metadata Package
--- +
1FF0300    x    x    x  'all'  all components    (full tracing)

a kovetkezo datapump import elhasal:

impdp
USERID=dbamon
NETWORK_LINK=pzhpcit1
JOB_NAME=pzhpcit4
TABLES=pcit_prod.sec_pl_detail
CONTENT=data_only
logfile=sec_pl_detail2.log
PARALLEL=4
STATUS=120



Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - 64bit Production
With the Partitioning and Data Mining options
ORA-39001: invalid argument value
ORA-39200: Link name "pzhpcit1" is invalid.
ORA-12154: TNS:could not resolve the connect identifier
specified

Megoldas:

az adatbazislinket a kovetkezokeppen kell megkrealni:

CREATE DATABASE LINK linkname
CONNECT TO user IDENTIFIED BY password
USING '(description=(address=(protocol=TCP)
(host=xxx.xxx.x.xx)(port=1521))(connect_data=(sid=sidname)))';

...es minden mukodik szuperul

Viszonlyag ritkan kell ezt vegrehajtanom, de akkor mindig eltoltok vele 20 percet mire megtalalom, ezrt most leirom, hatha masoknak is megsporol nehany ertekes percet.

Szoval, ha egy host-on manualisan kell listenert felvenned a monitorozanado targetek koze igy lehet:

1) valasszuk ki a megfelelo host-ot
2) ha megvan, akkor klikklejunk a host altal menedzselt "Target" linkre
3) a target-ek kozul valasszuk az "Agent"-et es klikkeljunk a nevere
4) a "Monitored targets" szekcioban megtalaljuk az "Add" gombot es mellette a legordulo menubol kivalszathatjuk a hon ahitott "Listener"-t (es termeszetesen mas komponenseket is).

Nekem nem volt mindez nyilvanvalo, ha van mas lehetoseg is (az automatikus discovery-n kivul) es valaki megirja, akkor azt megkoszonom.

lob indexet nem lehet csak "ugy" ujraepiteni, mint ahogy azt a normalis dba gondolja :)
normal b*tree indexet ugye egy gyors mozdulattal: alter index .... rebuild tablespace ....; paranccsal ujra tudunk epiteni egy masik tablaterben, igy megoldott a szegmens mozgatasa.
mi a helyzet a lob index-szel?

tegyuk fel hogy meg akarjuk keresni az osszes lob szegmenst (index, data) amely egy megadott tablaterben van, mert azokat at szeretnenk tenni egy masikba.
Hasznaljuk a kovetkezo sqlt:

select owner, table_name, column_name, segment_name, index_name from dba_lobs
where owner='&YOUROWNER' and tablespace_name='&YOURTBSPC';szuper, mostmar latjuk mit szeretnenk atrakni. no de hogyan? A lob szegmenst es az indexet egyutt tudjuk csak mozgatni:

alter table &YOUROWNER.&YOURTABLE
move tablespace &NEWDATATBSPC
lob (&LOB_COLUMN)
store as &LOBSEGMENTNAME (tablespace &NEWLOBTBSPC);


Amennyiben autoexetensible file-okat hasznalunk az kicsit megneheziti a tablaterben levo szabad hely meghatarozasat.

Ha feltetelezzuk, hogy a tablateret alkoto file-ok - amelyek autoextensible-k - valojaban megnohetnek a beallitott MAXSIZE-ig (ugye senki nem hagyja UNLIMITED-en :P) mert van eleg hely a filerendszerben akkor a kovetkezo sql-lel megtudhatjuk mennyi is a valojaban hasznalhato hely a tablaterunkben:

select 'NON AUTOEXTENSIBLE FILES: '||nvl(sum(bytes)/1024/1024,0)||' MB'
from dba_free_space
where file_id in
    (select distinct file_id
     from dba_data_files
     where autoextensible='NO' and tablespace_name='&YOURTBSPCNAME')
union
select 'AUTOEXTENSIBLE FILES: '||nvl(sum(maxbytes-user_bytes)/1024/1024, 0)||' MB'  from dba_data_files
where tablespace_name='&&YOURTBSPCNAME' and autoextensible='YES';

RMAN bug:
miutan egy temp tablater tempfile-jait at kell rakjam egy masik filerendszerbe a kovetkezot megoldast valasztottam:
alter tablespace temp_1 drop tempfile '/data/oracle/u03/PZHHTET1/temp1_1.dbf';
alter tablespace temp_1 add tempfile '/data/oracle/u03/PZHHTET1/temp1_1.dbf' size 512m autoextend off;
ezutan rman backup probaltam futtatni ami megbukott a kovetkezo hibaval:
RMAN-03002: failure of allocate command at .....
RMAN-03014: implicit resync of recovery catalog failed
RMAN-03009: failure of full resync command on default channel at.....
ORA-00001: unique constraint (XXXXXX.DF_U2) violated
metalinken megtalaltam a bugot, 11g-ben javitva.
megoldas: 'disable constraint' a katalogus db-ben es 'resync catalog'.

nem szeretnem ha linux blogga valtoznank, de ez erdekes lehet, ma talaltam ra:

ha pl.: egy konyvtarbol tobb file-t szeretnenk mozgatni egy masikba, bizonyos kondiciok mellett (modjuk egy hetnel regebben modositottak es a nevuk *.log) az megoldhato igy:

find /logdir -name "*log" -mtime +7 -maxdepth 0 | xargs -i mv {} /logdir/archive

Oracle 10gR2 - az alert.log kezd megtelni ilyen uzenetekkel:
Memory Notification: Library Cache Object loaded into SGA
Heap size 2254K exceeds notification threshold (2048K)Mindenekelott: ez nem fatalis problema, csupan fgyelmeztetes (mint ahogy irja is: "notification"), azonban 1-2 dologra erdemes odafigyelni.

mi is ez? egy process tul sok idot tolt azzal, hogy az SGA-ban hogy szabad memoria "slot"-ot talaljon maganak, mivel az lehet hogy tulzottan fragmentalt.
ha tul gyakran fordul elo az emlitett uzenet, az ORA-4031 (unable to allocate 8621 bytes of shared memory ... utalatos dolog) bekovetkezesere utalhat (nem feltetlenul, de megeshet). Erdemes odafigyelni erre.
sajnos 10.2.0.1-ben tul alacsonyra allitottak az uzenetkuldesi kuszoberteket: 2M.
10.2.0.2-ben mar felemeltek 50M-ra a threshold-ot, ha ezen verzioban is surun mejelenik a fenti figyelmeztetes az alert.log-ban, akkor erdemes a fejleszto brigaddal egyeztetni, egy kis tuningolas vegett...

El lehet nyomni az uzeneteket, ha nem kivanjuk latni az alert.log-ban (igazabol feljebb lehet venni a kuszoberteket 10.2.0.1-ben):

ha pl 16M-ra szeretnenk allitani akkor -> 16384 * 1024 = 16777216

sqlplus / as  sysdba
SQL> alter system set "_kgl_large_heap_warning_threshold"=16777216 scope=spfile;
SQL> shutdown immediate
SQL> startup
SQL> show parameter _kgl_large_heap_warning_threshold
NAME                                            TYPE     VALUE
------------------------------------ ----------- ------------------------------
_kgl_large_heap_warning_threshold     integer  16777216

ha init.ora-t hasznalunk akkor ertelemszeruen abban kell beallitani:

_kgl_large_heap_warning_threshold=16777216

majd db bounce.

happy DBAing!

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.

RHEL 3 es Oracle RDBMS 10.2.0.1-et hasznaltam 2 node-os RAC setuppal a forrason.
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;

keressuk ki melyek azok a tablak, amelyekben a logical standby altal nem tamogatott adattipusok leteznek:

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='*';
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;(Figyeljunk, ha single node installunk van a forrason, termeszetesen a 4. es 5. lepes kozul csak az egyik szukseges!)

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.shkeszitsunk egy password file-t. Nagyon fontos hogy a pwd-nek meg kell hogy egyezzen a forras oldalival:
cd $ORACLE_HOME/dbs
orapwd file=orapwmyls entries=5 password=<YOUR_SYS_PASSWORD>allitsuk vissza a szoveges parameterallomanyunkat a mentesbeli spfile-bol:
rman target /
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;csinalj, egy a kovetkezohoz hasonlo init.ora-t, termeszetesen a sajat setupodnak megfeleloen. az enyemet csak peldakepp teszem ide.

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
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'a cel gepen konfiguralj es indits egy listenert.

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;
create spfile from pfile;a korabban atmasolt standby controlfile-t masold az init.ora-ban beallitott control_files poziciokra.

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 /
crosscheck backupset;
crosscheck copy;
delete noprompt expired copy; 
delete noprompt expired backupset;
catalog start with '/u01/odata/myprod/rman';
restore database;
recover database;lepj ki rman-bol majd sqlplus-bol tisztan allitsd le az instance-t:
shutdown immediateallitsd le es inditsd ujra a listenert (nem reload):
lsnrctl stop
lsnrctl start
inditsuk a fizikai standby-t (managed recovery):
startup nomount
alter database mount standby database;
alter database recover managed standby database disconnect from session;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 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
FROM v$archived_log
ORDER BY sequence# ;(RAC forras eseteben mindig lesz 1, ami NO statuszu, a thread-ek kozotti fuggoseg miatt, de ez rendben van)

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
mv orapwmyls orapwmyls.old
orapwd file=orapwmyls entries=5 password=<YOUR_SYS_PWD>tiszta shutdown utan mount:
shutdown immediate
startup mountnezzuk meg hogy is van beallitva a log_archive_dest_1:
show parameter log_archive_dest_1valami 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.