DB_FILE_MULTIBLOCK_READ_COUNT parameter

by Vazha Mantua 8. July 2011 16:54

DB_FILE_MULTIBLOCK_READ_COUNT
is one of the parameters you can use to minimize I/O during table scans.
It specifies the maximum number of blocks read in one I/O operation during a sequential scan.
The total number of I/Os needed to perform a full table scan depends on such factors as the size of the table, the multiblock read count,
and whether parallel execution is being utilized for the operation.


Let see example:

Set db_file_multiblock_read_count=1

1. alter system set db_file_multiblock_read_count=1
2. alter system flush buffer_cache

And now we watch sql_plan for following statment "select /*+ full(a) */count(*) from TABLE_1 a"


SQL> explain plan for
select /*+ full(a) */count(*) from TABLE_1 a
;

Explained

SQL> select * from table (dbms_xplan.display);

PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------
Plan hash value: 635235748
--------------------------------------------------------------------------
| Id | Operation | Name | Rows | Cost (%CPU)| Time |
--------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 21893 (2)| 00:05:22 |
| 1 | SORT AGGREGATE | | 1 | | |
| 2 | TABLE ACCESS FULL| TABLE_1 | 8567K| 21893 (2)| 00:05:22 |
--------------------------------------------------------------------------

 

Time of execution statement is 387 second

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


Now change db_file_multiblock_read_count

1.alter system set db_file_multiblock_read_count=64
2. Run statement for collecting new system statistics:
begin
dbms_stats.gather_system_stats();
end;

alter system flush buffer_cache


SQL> explain plan for
2 select /*+ full(a) */count(*) from TABLE_1 a;

Explained

SQL> select * from table (dbms_xplan.display);

PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------
Plan hash value: 635235748
--------------------------------------------------------------------------
| Id | Operation | Name | Rows | Cost (%CPU)| Time |
--------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 23709 (3)| 00:03:57 |
| 1 | SORT AGGREGATE | | 1 | | |
| 2 | TABLE ACCESS FULL| TABLE_1 | 8567K| 23709 (3)| 00:03:57 |
--------------------------------------------------------------------------


Time of execution statement is 69 second


Result told that in our case increasing of db_file_multiblock_read_count decrease runtime of statement but increase cost

The value of db_file_multiblock_read_count can have a significant impact on the overall database performance and it is not easy for the administrator to determine its most appropriate value.

Oracle Database 10g Release 2 automatically selects the appropriate value for this parameter depending on the operating system optimal I/O size and the size of the buffer cache.

Before 10g R2, DBA's used the db_file_multiblock_read_count initialization parameter to tell Oracle how many block to retrieve in the single I/O operation.

Before Oracle10g R2, the permitted values for db_file_multiblock_read_count were platform-dependent. The most common settings ranged from 4 to 64 blocks per single multi-block I/O execution.

Tags:

MCP-Club Tbilisi, Facebook Page

by Arman Obosyan 29. June 2011 07:42

MCP-Club Tbilisi Facebook Page

Tags:

Oracle Database 10g: Real Application Clusters Administrator Certified Expert

by Vazha Mantua 28. June 2011 12:32

Good Day All,

 

During last 2-3 weeks I was training for exam 1Z0-048, and today I have successfully passed it.

 

I used ebook  :

Oracle® Database
Oracle Clusterware and Oracle Real Application Clusters
Administration and Deployment Guide
10g Release 2 (10.2)
B14197-15

 

and tests for test4actual.com

 

Result of exam is that I  become Oracle Database 10g: Real Application Clusters Administrator Certified Expert.

 

If you have any question about exam 1z0-048, don’t hesitate, please email me.

Tags:

no_unnest hint, useful hint for subqueries!

by Vazha Mantua 25. May 2011 12:20

Good Day,

Today we discuss about optimize SQL statements with subqueries . In SQL Plan subquery maybe nested or unnested.

Subqueries are nested when they appear in the WHERE clause of the parent statement. When Oracle Database evaluates a statement with a nested subquery, it must evaluate the subquery portion multiple times and may overlook some efficient access paths or joins.

Subquery unnesting unnests and merges the body of the subquery into the body of the statement that contains it, allowing the optimizer to consider them together when evaluating access paths and joins. The optimizer can unnest most subqueries, with some exceptions. Those exceptions include hierarchical subqueries and subqueries that contain a ROWNUM pseudocolumn, one of the set operators, a nested aggregate function, or a correlated reference to a query block that is not the immediate outer query block of the subquery.

Assuming no restrictions exist, the optimizer automatically unnests some (but not all) of the following nested subqueries:

  • Uncorrelated IN subqueries

  • IN and EXISTS correlated subqueries, as long as they do not contain aggregate functions or a GROUP BY clause

You can enable extended subquery unnesting by instructing the optimizer to unnest additional types of subqueries:

  • You can unnest an uncorrelated NOT IN subquery by specifying the HASH_AJ or MERGE_AJ hint in the subquery.

  • You can unnest other subqueries by specifying the UNNEST hint in the subquery.

 

 

Know talk about example how can we improve performance with no_unnest hint.

 

SELECT /*+ index(v1.table1 table1_IX1) */
v1.col1,
v1.col2,
v1.col3,
v1.col4,
v1.col5
FROM VIEW1 v1
WHERE (v1.code = :B1 And v1.ID = Nvl(null, v1.ID) And
v1.ID In
(Select
v2.sid
From VIEW2 v2
Where ('N' = 'N' And v2.Key1 = Nvl(null, Key1) And
NVL(null, Active_Flag) = Active_Flag And
NVL(null, Inform_Flag) = Inform_Flag)
Or ('Y' = 'Y' and :b2 = KEY1 and Active_Flag = 'Y')) )

sql_plan of this statement is :

 

PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes
--------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 244
| 1 | HASH JOIN SEMI | | 1 | 244
| 2 | NESTED LOOPS OUTER | | 1 | 231
| 3 | TABLE ACCESS BY INDEX ROWID | TABLE1 | 1 | 110
| 4 | INDEX RANGE SCAN | TABLE1_IX1 | 2 |
| 5 | TABLE ACCESS BY INDEX ROWID | TABLE2 | 1 | 121
| 6 | INDEX UNIQUE SCAN | TABLE2_PK | 1 |
| 7 | VIEW | VW_NSO_1 | 2 | 26
| 8 | CONCATENATION | | |
| 9 | TABLE ACCESS BY INDEX ROWID | TABLE3 | 1 | 21
| 10 | NESTED LOOPS | | 1 | 49
| 11 | NESTED LOOPS | | 1 | 28
| 12 | TABLE ACCESS BY INDEX ROWID| TABLE4 | 1 | 18
| 13 | INDEX UNIQUE SCAN | TABLE4_PK | 1 |
| 14 | TABLE ACCESS BY INDEX ROWID| TABLE5 | 1 | 10
| 15 | INDEX RANGE SCAN | TABLE5_PK | 1 |
| 16 | INDEX RANGE SCAN | TABLE1_IX1 | 1 |
| 17 | TABLE ACCESS BY INDEX ROWID | TABLE5 | 1 | 10
| 18 | NESTED LOOPS | | 1 | 49
| 19 | NESTED LOOPS | | 1 | 39
| 20 | TABLE ACCESS FULL | TABLE3 | 4559 | 95739
| 21 | TABLE ACCESS BY INDEX ROWID| TABLE4 | 1 | 18
| 22 | INDEX UNIQUE SCAN | TABLE4_PK | 1 |
| 23 | INDEX RANGE SCAN | TABLE5_PK | 1 |
--------------------------------------------------------------------------------

Know Write no_unnest hint in subquery:

 

SELECT /*+ index(v1.table1 table1_IX1) */
v1.col1,
v1.col2,
v1.col3,
v1.col4,
v1.col5
FROM VIEW1 v1
WHERE (v1.code = :B1 And v1.ID = Nvl(null, v1.ID) And
v1.ID In
(Select /*+ no_unnest */
v2.sid
From VIEW2 v2
Where ('N' = 'N' And v2.Key1 = Nvl(null, Key1) And
NVL(null, Active_Flag) = Active_Flag And
NVL(null, Inform_Flag) = Inform_Flag)
Or ('Y' = 'Y' and :b2 = KEY1 and Active_Flag = 'Y')) )

Cost of this plan was 9192

 

 

Let’s see new SQL PLAN

PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes |
--------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 231 |
| 1 | FILTER | | | |
| 2 | NESTED LOOPS OUTER | | 1 | 231 |
| 3 | TABLE ACCESS BY INDEX ROWID | TABLE1 | 1 | 110 |
| 4 | INDEX RANGE SCAN | TABLE1_IX1 | 2 | |
| 5 | TABLE ACCESS BY INDEX ROWID | TABLE2 | 1 | 121 |
| 6 | INDEX UNIQUE SCAN | TABLE2_PK | 1 | |
| 7 | TABLE ACCESS BY INDEX ROWID | TABLE5 | 1 | 10 |
| 8 | NESTED LOOPS | | 1 | 49 |
| 9 | NESTED LOOPS | | 1 | 39 |
| 10 | TABLE ACCESS BY INDEX ROWID| TABLE3 | 3 | 63 |
| 11 | INDEX RANGE SCAN | TABLE3_IX1 | 3 | |
| 12 | TABLE ACCESS BY INDEX ROWID| TABLE4 | 1 | 18 |
| 13 | INDEX UNIQUE SCAN | TABLE4_PK | 1 | |
| 14 | INDEX RANGE SCAN | TABLE5_PK | 1 | |

 

Cost of this plan was 16, it’s 574 times less!!!

Tags:

Another Solution for latch library cache, Troubleshooting this event

by Vazha Mantua 3. May 2011 16:36

Early we discuss about latch library lock and we have got some solutions for avoid this problem for Database.

 

Now discuss troubleshoot scenario for latch library cache event:

 

First of all we should find latch address of problem statement:

select p1text,p1raw from v$session_wait a
where a.EVENT='latch: library cache'

where value of p1text must be “address” and p1raw latch address for problem latch.

Now we have got latch address , we should find latch number.

 

select a.CHILD# from v$latch_children a
where a.ADDR=p1raw

 

 

We know child number of possible bottleneck.

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

Let’s prove that we can’t find exact SQL statement if we know only a latch address.

We should get structure of v$latch_children view with this statement:

 

select * from v$fixed_view_definition a
where a.VIEW_NAME='GV$LATCH_CHILDREN'

Result of this statement tell us that view v$latch_children is based on x$ksllt object.

 

Now find which of data dictionary object created by x$ksllt with this statement

 

select * from v$fixed_view_definition a
where upper(a.VIEW_DEFINITION) like '%X$KSLLT%'
or upper(a.VIEW_DEFINITION) like '%GV$LATCH%'

Result of this Select are :

GV$LATCH
GV$LATCH_CHILDREN
GV$LATCH_PARENT
V$LATCH
V$LATCHHOLDER
V$LATCHNAME
V$LATCH_CHILDREN
V$LATCH_MISSES
V$LATCH_PARENT

 

in these views the are no sql statements.

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

 

What we can do for find possible problematic SQL statement , if we only know number of child latch.

 

All SQL statements are served by number of latches given by parameter _kgl_latch_count, which means total number of latches in system , maximum value of this parameter is 66.

 

Return back to our case.

 

For find possible problematic statement we should run this statements:

 

select * from v$sqlarea a
where a.CHILD_LATCH=child#
order by a.EXECUTIONS desc

 

Problematic sql statements must be statements with maximum number of exection.

 

Also there is very interesting view named v$db_object_cache.

with this view and these SQL statements we can find cause of latch library cache

 

 

1.

select * from v$db_object_cache a
where a.CHILD_LATCH=child#
order by a.EXECUTIONS

2.

select * from v$db_object_cache a
where a.CHILD_LATCH=child#
order by a.lock

3.

select * from v$db_object_cache a
where a.CHILD_LATCH=child#
order by a.pins

if you can’t find cause of latch library cache you can restart database and SQL statements will give new order of latch child number, and you can compare statements with new problematic latch child number.

Tags: ,

Cisco Club Georgia Blog

by Besarion GIorgadze 2. May 2011 20:03

მოგესალმებით მინდა გაცნობთ ახალი და სასიამოვნო ამბავი. შეიქმნა Cisco Club Georgia-ს ბლოგ, ერთ-ერთი პირველი ქართიულენოვანი ტექნიკური blog-ი ge-ზონაში.  შევეცდებით თვენთვის სასიამოვნო გახდეს ბლოგზე სტუმრობა. კლუბის სახელიდან გამომდინარე რთული მისახვედრი არ არის რაზე იქნება ბლოგი :) ჩვენი ძირითადმი მიმართულებები იქნება: Networking-ი, Security-ი, VOIP.  აქ განვიხილავთ და მოგიყვებით, ტექნოლოგიებზე, სერტიფიცირებაზე, მოწყობილობებზე და ზოგადად სიხალეებზე, ასევე გავკეთებთ სხვადასხვა სახის ტუტორიალებს და configuration guide-ებს . მაქსიმალურად შევეცდებით ჩვენი გამოცდილება გაგიზიაროთ.

 

ბლოგის მისამართი: blog.ciscoclub.ge

Facebook-ის მისამართი: fb.com/CiscoClub


თქვენ თუ გექნებათ სურვილი გამოცდილების გაზიარების მოგვწერეთ და თქვენი სახელით დავდებთ ჩვენს ბლოგზე. ასევე სიამოვნებით მოვისმენთ თქვენ აზრს  და შენიშვნებს ბლოგის შესახებ. რაღათქმაუნდა შეძლებისდაგვარად გავითვალისწინე��თ.

Tags:

სასიხარულო სიახლე! - VMUG-TBL #001

by David Ramishvili 14. April 2011 12:55

image

მოგესალმებით!

მოხარული ვართ გაცნობოთ სასიამოვნო სიახლის შესახებ, ჩამოყალიბდა VMware User Group - Tbilisi (www.vmug.ge). რიგით პირველი შეხვედრის თარიღი და ადგილი უკვე შერჩეულია და მომხსენებლები მზად არიან საინტერესო თემებით წარდგნენ თქვენს წინაშე.

მომხსენებლები:
ივან სკუდინი (კომპანია EMC)

ანტონ ჟბანკოვი (კომპანია EMC - vSpecialist)
ბლოგი:
http://blog.vadmin.ru

სანდრო გალდავა, თემა - “vCenter Server Heartbeat” (კომპანია Delta Systems -Senior Systems Engineer)
ბლოგი:
www.vforv.me

იური სემენიხინი, თემა - “vCenter Site Recovery Manager 4 Technical Overview” (კომპანია UGT -Senior Systems Architect)
ბლოგი:
www.vmlab.ge

აგენდა:
11:00-11:30 რეგისტრაცია
11:30-11:45 მისალმება/გაცნობა
11:45-13:00 პირველი მომხსენებელი
13:00-13:30 ყავა/ჩაი
13:30-14:45 მეორე მომხსენებელი
14:45-15:15 ლანჩი
15:15-16:30 მესამე მომხსენებელი
16:30-16:45 ყავა/ჩაი
16:45-18:00 მეოთხე მომხსენებელი

ჩატარების თარიღი და ადგილი:
22 აპრილი, პარასკევი
სასტუმრო “ვერე პალასი”, ქუჩიშვილის ქ.22-24, თბილისი, საქართველო.
იხილეთ რუკა

ახლა დარჩა მხოლოდ დაუთმოთ 2 წუთი, შეავსოთ სააპლიკაციო ფორმა და გამოაგზავნოთ თქვენი დასტური შეხვედრაზე დასასწრებად.

საინტერესო იქნება, ამიტომ გელით ყველას. VMware User Group-ზე შევხვდებით!

Tags:

Concatenation and filter option in SQL PLAN

by Vazha Mantua 8. April 2011 20:38
Hello All,
For example we have this statement:
select count(*) from customers
where acc_nbr = nvl(:v,acc_nbr)
Execution Plan
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=CHOOSE (Cost=137 Card=1 Bytes=7)
   1    0   SORT (AGGREGATE)
   2    1     CONCATENATION
   3    2       FILTER
   4    3         INDEX (FAST FULL SCAN) OF 'CUST_PK' (UNIQUE) (Cost
   5    2       FILTER
   6    5         INDEX (UNIQUE SCAN) OF 'CUST_PK' (UNIQUE) (Cost=2
In execution plan we see 2 filters and then concatenation. Reason of this is nvl comand, Oracle CBO rule . We have 2 possible scenario bind variable :v is null or is not null.
but for RBO rule change sql plan and filters and concatenation is not appear in SQL PLAN
Many examples say that in this case that CBO is better than RBO(Rule hint), but sometimes RBU rule is better.
How can we avoid 2 filters in concatenation,simple we have 2 solutions:
select /*+ rule */ count(*) from customers where acc_nbr = nvl(:v,acc_nbr)
or
select /*+ no_expand*/ count(*) from customers where acc_nbr = nvl(:v,acc_nbr).
Let describe hint no_expand:
The NO_EXPAND hint prevents the cost-based optimizer from considering OR-expansion for queries having OR conditions or IN-lists in the WHERE clause. Usually, the optimizer considers using OR expansion and uses this method if it decides that the cost is lower than not using it.

Tags: , ,

Dual Internet with IP SLA and PBR

by besarion giorgadze 21. March 2011 14:40
დღეს-დღეობით როცა ინტენეტი თითქმის ყველა ორგანიზააციისთვის არის საარსებო წყარო , თავისთავად ჩნდება მოთხვონილება ინტერნეტის მაღალი საიმედოობის. ამის გადასაწყვეთად ქსელის დონეზე არსებობს რამდენიმე ნორმალური გადაწყვეტილება (რაც ჩემთვის არის ცნობილი). ამ პოსტში მინდა დავწერო როგორ შეიძლება ორ პროვაიდერთან IP SLA-ით და Policy Based Routing-ით ინტერნეტის მაღალი საიმედოობის უზრუნველყოფბა და ასევე დატვირთვის გადანაწილება (Load Sharing) . ამისთვის გავაკეთე შემდეგი LAB-ი.


Tasks:

Host1-იდან მომვალი ტრაფიკი Edge-მა უნდა გაიაროს ISP1-ის გავლით, მხოლოდ იმ შემთხვევაში თუ ISP1 გაითიშება ISP2-ის გავლით.
Host2-იდან მომავალი ტრაფიკი Edge-მა უნდა გაიაროს ISP2-ის გავლით, მხოლოდ იმ შემთხვევაში თუ ISP2 გაითიშება ISP1-ის გავლით.

იმაზე არ ვისაუბრებ თუ როგორ არის დაკონფიგურირებული როუტინგი უბრალოდ იმას გეტყვით რომ მაქსიმალურად შევეცადე რეალური 2 პროვაიდერის სცენარი გამეკეთებინა მარტივად. ISP1 ვერ ხედავს 192.168.3.0/24 და 192.168.5.0/24, შესაბამისად ISP2 ვერ ხედავს 192.168.2.0/24 და ასევე 192.168.4.0/24-ს.

პირველ რიგში Edge-ზე უნდა დავაკონფიგურიროთ NAT-ი, იქედან გამომდინარე, რომ INSIDE ინტერფეისი ერთი გვაქვს და OUTSIDE ინტერფეისი ორი გვაქვს, მე პირადად ვარჩევ რომ NAT-ი გავაკეთო route-map-ის დახმარებით.

NAT-ის კონფიგურაცია დავიწყოთ იმით რომ განვსაზღვროთ inside და outside ინტერფეისები.

interface FastEthernet1/0

ip address 192.168.1.1 255.255.255.0

ip nat inside

interface Serial0/0

ip address 192.168.2.2 255.255.255.0


ამის
შემდეგ დავწეროთ შემდეგი Route-map- NAT-ისთვის და NAT წესებითუ Source- დაემთხვა host-ების IP მისამართებს  და გამავლი Interface- დაემთხვა serial0/0 მაშინ შესრულდეს NAT და გადაითარგმნოს serial0/0-ის IP მისამართში, მხოლოდ თუ Srource- დაემთხვა host-ების IP მისამართებს და გამავალი Interface-ის დაემთხვა  serial0/1 ამ შემთხვევაშიც შესრულდეს NAT- მაგრამ გავიდეს serial0/1 ის IP მისამართით.

ip access-list standard NAT

 permit 192.168.1.0 0.0.0.255


route-map NAT-ISP1 permit 10

 match ip address NAT

 match interface Serial0/0


route-map NAT-ISP2 permit 10

 match ip address NAT

 match interface Serial0/1


ip nat inside source route-map NAT-ISP1 interface Serial0/0 overload

ip nat inside source route-map NAT-ISP2 interface Serial0/1 overload

 ეხლა კიდევ გადავიდეთ ყველაზე საინტერესო დეტალების კონფიგურაციაზე. მოკლედ გავაკეთოთ შემდგეი policy- თუ souce- იქნება Host1- მაშინ ინტერნეტისკენ მიმავალი ტრაფიკი წავიდეს ISP1-ის გავლით, მხოლოდ თუ Source-იქნება Host2 მაშინ ტრაფიკის წავიდეს ISP2-ის გავლით. მაგრამ თუ ISP1- გაითიშა (ჩვენს შემთხვევაში ვთქვათ ISP1 LO 1.1.1.1 მისამართი Edge-იდან მიუწვდომელი გახდა) მაშინ Host1-ის ტრაფიკი გავიდეს ISP2-ით და როცა კავშირი აღდგება მაშინ პირველად მგომარეობაში დაბრუნდეს ანუ HOST1-მა ისევ დაიწყოს სიარული ISP1-ით. შესაბამისად Host2-თვისაც იგივე გავაკეთოთ ანუ თუ ISP2 გაითიშა (ჩვენს შემთხვეაში ვთქვათ რომ Edge-იდან ISP2 LO 2.2.2.2 მიუწვდომადი გახდა) მაშინ Host2-მა დაიწყოს სიარული ISP2-ის გავლით.

 

 ეს ყველაფერი რომ გავაკეთოთ და ავამუშაოთ პირველ რიგში უნდა შევქმნათ SLA monitor- რომლიც გარკვეულ პერიოდში გაპინგავს პროვაიდერების მისამრთებს ჩვენს მეთხვევაში ISP1-ის მხარეს გაპინფავს 1.1.1.1 და ISP2-ის მხარეს 2.2.2.2-. რეალურ სიტუაციში ესეთი მისამართი შერჩევა ცოტა არ იყოს რთულია და ამიტომ ჩემი აზრით ჯობია პროვიდერს ვკითხოთ თუ რომელი IP ვპინგოთ.  თუ ვერ გაიპინგა ამის შესახებაც შეგვატყობინებს. ამის მერე უნდა გავაკეთოთ track object-ები სადაც მივაბავთ უკვე არსებულ SLA monitor-ებს და მოგვცემს საშუალებას მივაბათ track object-ები ზემოთ ხსნებებულ policy Route-. უი რაც მთავარი კინაღამ გამომრჩა edge-ზე უნდა გავწეროთ სტატიკური მარშუტები 1.1.1.1-ისკენ და 2.2.2.2-სკენ. SLA monitor 11 ამოწმებს კავშირს ISP1-თან და SLA monitor 22 ამოწმებს კავშირს ISP2-თან. შესაბამის ნომრებით მიბმულია Track object-ებთან


ip route 1.1.1.1 255.255.255.255 192.168.2.1

ip route 2.2.2.2 255.255.255.255 192.168.3.1


ip sla monitor 11

 type echo protocol ipIcmpEcho 1.1.1.1 source-ipaddr 192.168.2.2

 frequency 5

ip sla monitor schedule 11 life forever start-time now


ip sla monitor 22

 type echo protocol ipIcmpEcho 2.2.2.2 source-ipaddr 192.168.3.2

ip sla monitor schedule 22 life forever start-time now


track 11 rtr 11 reachability

track 22 rtr 22 reachability
შევამოწმოთ რაც გავაკეთეთ ხომ მუშაობას.

edge#ping 1.1.1.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/34/100 ms


edge#ping 2.2.2.2

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 12/68/148 ms


edge#show ip sla monitor statistics 11

Round trip time (RTT)   Index 11

        Latest RTT: 48 ms

Latest operation start time: *18:30:04.425 UTC Sat Mar 2 2002

Latest operation return code: OK

Number of successes: 358

Number of failures: 0

Operation time to live: Forever

 

edge#show ip sla monitor statistics 22

Round trip time (RTT)   Index 22

        Latest RTT: 52 ms

Latest operation start time: *18:30:14.429 UTC Sat Mar 2 2002

Latest operation return code: OK

Number of successes: 30

Number of failures: 0

Operation time to live: Forever

 

edge#show track 11

Track 11

  Response Time Reporter 11 reachability

  Reachability is Up

    2 changes, last change 1d18h

  Latest operation return code: OK

  Latest RTT (millisecs) 120

  Tracked by:

    ROUTE-MAP 0

 

edge#show track 22

Track 22

  Response Time Reporter 22 reachability

  Reachability is Up

    2 changes, last change 1d18h

  Latest operation return code: OK

  Latest RTT (millisecs) 52

  Tracked by:

    ROUTE-MAP 0

ყველაფერი წესრიგშია ეხლა გადავიდეთ route-map-ის კონფიგურაციაზე და შესაბამისად შემოწმებაზე. ასევე დაგვჭირდება Access-list-ები რომლიც მოგვცემს საშუალებს განვასხვავოთ HOST1 და HOST2-. Route-map- რომ გამოვიყენოთ PBR-ისთვის (policy Based Routing) უნდა დავადოთ შემომავალ ინტერფეისზე. ჩვენს შემთხვევაში Fa1/0-ზე

ოღოდ გასათავლისწინებელია ის ფაქთი რომ როუტერის მიერ გენერირებული ტრაფიკმა რომ შეხედოს Route-map- გლობალური კონფიგურაციის რეჟიმში უნდა დავამატოთ ბრძანება ip local policy route-map <route-map NAME>


route-map PBR permit 10

 description Host 1 Policy

 match ip address HOST1

 set ip next-hop verify-availability 192.168.2.1 10 track 11

 set ip next-hop verify-availability 192.168.3.1 20 track 22

 

route-map PBR permit 20

 description Host 2 policy

 match ip address HOST2

 set ip next-hop verify-availability 192.168.3.1 10 track 22

 set ip next-hop verify-availability 192.168.2.1 20 track 11

 

interface FastEthernet1/0
ip address 192.168.1.1 255.255.255.0
ip nat inside
ip virtual-reassembly
 ip policy route-map PBR
duplex auto
speed auto

edge#show route-map PBR
route-map PBR, permit, sequence 10
  Match clauses:
    ip address (access-lists): HOST1
  Set clauses:
    ip next-hop verify-availability 192.168.2.1 10 track 11  [up]
    ip next-hop verify-availability 192.168.3.1 20 track 22  [up]
  Policy routing matches: 34 packets, 3876 bytes
route-map PBR, permit, sequence 20
  Match clauses:
    ip address (access-lists): HOST2
  Set clauses:
   ip next-hop verify-availability 192.168.3.1 10 track 22  [up]
    ip next-hop verify-availability 192.168.2.1 20 track 11  [up]
  Policy routing matches: 0 packets, 0 bytes

ყველაფრის კონფიგურაციას მოვრჩით და შეიძლება უკვე შემოწმებაზე გადავიდეთ. Host1-იდან გავპინგოთ 10.10.10.10 და შევამოწმოთ traceroute- როგორ დადის Host1-ი ინტერნეტში და ასევე Host2-იდანაც იგივე უნდა გავაკეთოთ.

host1#ping 1.1.1.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 28/52/108 ms

host1#traceroute 10.10.10.1

Type escape sequence to abort.

Tracing the route to 10.10.10.10

  1 192.168.1.1 68 msec 92 msec 40 msec

  2 192.168.2.1 128 msec 80 msec 16 msec

  3 192.168.4.1 80 msec *  96 msec

 

host2#ping 10.10.10.10

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.10.10, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 32/83/136 ms
host2#traceroute 10.10.10.10

Type escape sequence to abort.
Tracing the route to 10.10.10.10

  1 192.168.1.1 60 msec 72 msec 16 msec
  2 192.168.3.1 52 msec 96 msec 32 msec
  3 192.168.5.1 60 msec *  136 msec

ვხედავთ რომ ტრაფიკი როგორც ზემოთ გვაქვს აღწერილი ისე დადის ანუ Host1 დადის ISP1-ის გავლით და Host2- დადის ISP2-ის გავლით. მოდით ეხლა გავთიშავ ISP1-ის s0/0 და თუ მოხდება Host1-ის გადართვა ISP2-ზე.


edge#show route-map PBR

route-map PBR, permit, sequence 10

  Match clauses:

    ip address (access-lists): HOST1

  Set clauses:

    ip next-hop verify-availability 192.168.2.1 10 track 11  [down]

    ip next-hop verify-availability 192.168.3.1 20 track 22  [up]

  Policy routing matches: 45 packets, 4806 bytes

route-map PBR, permit, sequence 20

  Match clauses:

    ip address (access-lists): HOST2

  Set clauses:

    ip next-hop verify-availability 192.168.3.1 10 track 22  [up]

    ip next-hop verify-availability 192.168.2.1 20 track 11  [down]

  Policy routing matches: 10 packets, 816 bytes

 

 

host1#traceroute 10.10.10.10

Type escape sequence to abort.

Tracing the route to 10.10.10.10

  1 192.168.1.1 120 msec 48 msec 40 msec

  2 192.168.3.1 64 msec 64 msec 48 msec

  3 192.168.5.1 176 msec *  112 msec

Route-map-ში ჩანს რომ SLA monitor- 11 არის Down-ში და traceroute- რომ გავუშვით Host1-იდან გავიდა ISP2-ის გავლით. ანუ როგორც ჩვენ გვინდოდა და წინასწარ როგროც იყო განსაზღვრული ისე მოხდა.


config and Dynamips Files

Tags: , , ,

Tags:

ORA-10567: Redo is inconsistent with data block (file# 25, block# 7652)

by Vazha Mantua 9. March 2011 10:57

Good morning all,

 

On of our standby database stop apply process with error ORA-10567: Redo is inconsistent with data block (file# 25, block# 7652).

 

ORA-10567: Redo is inconsistent with data block (file# 25, block# 7652)

ORA-10564: tablespace USER_DATA

ORA-01110: data file 124: ‘/u01/oradata/ORAST/USER_DATA_01.DBF’

ORA-10561: block type ‘TRANSACTION MANAGED INDEX BLOCK’, data object# 7652

 

Cause

The Redo when shipped across network or somewhere along the way had some issues which caused the inconsistency, hence not able to syncup with the standby datafiles.

 

Solution

On primary database

1.ALTER tablespace USER_DATA begin backup;

2.copy USER_DATA01.dbf datafile from primary DB to standby DB

On primary database

3.ALTER tablespace USER_DATA end backup;

on standby database start recovery

4. recover managed standby database using current logfile disconnect;

 

Remark: Does not do this operation when production database has pick load, begin backup can decrease DB performance

Tags: ,