שימוש ב-RMAN כדי למחוק Archivelogs ישנים

/0 תגובות/ב- /מאת /זמן קריאה משוער: 1 דקה

כדי למחוק Archive logs ישנים בצורה אוטומטית ניתן להשתמש ב-RMAN גם אם לא מגבים דרכו.

הפעלת ה-RMAN:

rman target / cmdfile=delete_arc_rman.sql

הסקריפט שמוחק בפועל את הקבצים (delete_arc_rman.sql):

run {
crosscheck archivelog all;
delete noprompt archivelog until time 'sysdate - 7';
crosscheck archivelog all;
delete noprompt expired archivelog all;
}

שליפת רשימת מספרים בלתי מוגבלת בלי להשתמש בטבלה

/0 תגובות/ב- , /מאת /זמן קריאה משוער: 1 דקה

כדי לשלוף רשימה של מספרים (מ-1 עד אינסוף), ניתן להשתמש ב-dual בשביל זה:

select rownum from dual connect by level <= 1000;

כשה-level מוגבל על ידי המספר המקסימלי שאנחנו רוצים לקבל.


מפתח ראשי ואינדקסים

/0 תגובות/ב- /מאת /זמן קריאה משוער: 1 דקה

כנראה שאתם יודעים על זה אבל למקרה ולא.

כאשר מקימים primary key בצורה של :

alter table XXX add constraint XXX$PK primary key (X,Y) using index;

אורקל יקים  index כדי לאכוף את ה constraint. כאשר נרצה לנטרל את ה-Contraint ונעשה:

alter table DIM_DWENG_REJECT_REASON disable primary key

או

alter table DIM_DWENG_REJECT_REASON drop primary key

אורקל ימחק מייד גם  את האינדקס.

איך ניתן לעקוף את זה? אם קודם ניצור unique index על עמודות שהם Not Null:

create unique index XXX$PK on XXX (X, Y) nologging;

ורק אז נוסיף את ה-constraint:

alter table XXX add constraint XXX$PK primary key (X,Y) using index;

אורקל לא יעשה drop לאינדקס בצורה אוטומטית ונצטרך לעשות את זה ידנית.

רשימת ה-session-ים שה-QC הוא ב-INACTIVE אבל יש לו ילדים שעדיין תופסים Parallel

/1 תגובה/ב- , /מאת /זמן קריאה משוער: 1 דקה

תופעה מעניינת עם כלים שמחזירים row set בגודל מסויים ושמאפשרים לעשות fetching היא שאם השליפה המקורית הייתה מקבילית (parallel) הכלים נוטים שלא לשחרר את הפרוססים שהם השתמשו בהם בשביל השליפה ולתפוס אותם כל עוד לא נעשתה שליפה אחרת באותו חלון.

אז מה בעצם הבעיה? הבעיה היא שכאשר יש load גבוה על המערכת ויש צורך ב-Parallel servers, התוכנות האלה מחזיקות את המשאבים ושליפות אחרות מקבלות downgrade.

שני כלים שעושים את זה הם TOAD ו-PL/SQL Developer וניתן להשתמש בשליפה הבאה כדי לאתר מי הם הסשנים שנראים Inactive אבל בפועל הם תופסים משאבים (השליפה הזו נעטפה על ידי סקריפט CSH שגם מעיף את המשתמשים האלה כאשר הם מחזיקים את המשאבים יותר מדי זמן):

with curr_sessions as (
SELECT ROUND(BITAND(s.ownerid, 65535)) parent_session_sid,
       s.sid,
       s.status,
       s.sql_id,
       UPPER(s.program) program
  FROM v$session s, v$process p
 WHERE ((s.username IS NOT NULL) AND (NVL(s.osuser, 'x') &lt;&gt; 'SYSTEM') AND (s.TYPE &lt;&gt; 'BACKGROUND'))
   AND (p.addr(+) = s.paddr))
select distinct a.sid parent, b.sid child, a.status status_p, b.status status_c, a.program, a.sql_id
  from curr_sessions a
  join curr_sessions b on a.sid = b.parent_Session_sid
                      and a.status = 'INACTIVE'
                      and a.program in ('TOAD.EXE')
order by 1

שליפות שעושות Downgrade

/0 תגובות/ב- , /מאת /זמן קריאה משוער: 1 דקה

לפעמים יש צורך למצוא מהן השליפות שעשו downgrade במערכת ולא קיבלו מספיק parallel processes. צריך להבחין בין שני מקרים: מקרה שהשליפות קיבלו חלק מהמשאבים ומקרה שבהם הן לא קיבלו בכלל משאבים ועכשיו הן עובדות ב-serial.

כדי למצוא מהן השליפות שקיבלו downgrade (אבל עדיין עובדות ב-Parallel) ניתן להשתמש בשליפה הבאה. השליפה מחזירה רק את ה-PX coordinator (כלומר ה-SID של ההורה) ולא את כל הפרוססים עצמם:

SELECT a.sid parent_sid,
       a.logon_time,
       a.program,
       a.osuser,
       a.username,
       a.sql_id,
       ps.req_degree,
       ps.got_degree
  FROM (SELECT s.sid,
               s.osuser,
               s.USERNAME,
               s.status,
               s.sql_id,
               s.logon_time,
               s.last_call_et,
               UPPER(s.program) program
          FROM v$session s
         WHERE ((s.username IS NOT NULL) AND (NVL(s.osuser, 'x') &lt;&gt; 'SYSTEM') AND
               (s.TYPE &lt;&gt; 'BACKGROUND'))) a
  JOIN (SELECT DISTINCT qcsid,
                        CASE
                            WHEN req_degree &gt; degree THEN
                             1
                            ELSE
                             0
                        END is_downgrade,
                        MAX(req_degree) req_degree,
                        MAX(degree) got_degree
          FROM v$px_session
         GROUP BY qcsid,
                  CASE
                      WHEN req_degree &gt; degree THEN
                       1
                      ELSE
                       0
                  END) ps ON a.sid = ps.qcsid
 WHERE ps.is_downgrade = 1

כדי לאתר את השליפות שלא קיבלו פרוססים בכלל (ובעצם עשו downgrade to serial) ניתן להשתמש בשליפה הבאה:

SELECT sess.sid parent_sid,
		 logon_time,
		 sess.program,
		 sess.osuser,
		 sess.username,
		 sql_id,
		 TRUNC (last_call_et / 60) dur_minutes
  FROM v$sesstat sesstat, v$sysstat sysstat, v$session sess
 WHERE	  sesstat.statistic# = sysstat.statistic#
		 AND sesstat.sid = sess.sid
		 AND name = 'Parallel operations downgraded to serial'
		 AND sesstat.VALUE &gt; 0
		 AND sess.status = 'ACTIVE'

n השליפות הארוכות ביותר של משתמש מתוך ה-AWR

/0 תגובות/ב- , , /מאת /זמן קריאה משוער: 1 דקה

איך מוציאים את 30‏ השליפות הארוכות ביותר של משתמש מסויים מתוך ה-AWR‏?

משתמשים בשליפה הבאה:

select sub.sql_id,
       txt.sql_text,
       parsing_schema_name,
       sub.seconds_since_date,
       sub.execs_since_date,
--       sub.gets_since_date,
       round(sub.seconds_since_date / sub.execs_since_date, 3) avg_query_time
  from ( -- sub to sort before rownum
        select sql_id,
                g.parsing_schema_name,
                round(sum(elapsed_time_delta) / 1000000) as seconds_since_date,
                sum(executions_delta) as execs_since_date,
                sum(buffer_gets_delta) as gets_since_date
          from dba_hist_snapshot natural
          join dba_hist_sqlstat g
         where begin_interval_time > to_date('2010-01-01', 'YYYY-MM-DD')
           and parsing_schema_name = '&user_name'
         group by sql_id, g.parsing_schema_name
         order by seconds_since_date desc) sub
  join dba_hist_sqltext txt on sub.sql_id = txt.sql_id
 where rownum < &n;