Why Use Parallel Processing?

Подписаться 140 тыс.

Просмотров 24 тыс.

50% 1

This video compares the use of parallel and serial processing for the same SQL query. Copyright © 2012 Oracle and/or its affiliates. Oracle® is a registered trademark of Oracle and/or its affiliates. All rights reserved. Oracle disclaims any warranties or representations as to the accuracy or completeness of this recording, demonstration, and/or written materials (the "Materials"). The Materials are provided "as is" without any warranty of any kind, either express or implied, including without limitation warranties of merchantability, fitness for a particular purpose, and non-infringement.

Наука

Опубликовано:

25 май 2011

Ссылка:

Скачать:

Готовим ссылку...

Добавить в:

Мой плейлист

Посмотреть позже

Комментарии : 11

@mwdunn531 3 года назад

Just to correct one statement made in the video....the query did NOT run on 8 different machines. The query is split up depending on the degrees of parallelism (DOP), in this case "8", and completed by 8 parallel worker processes on the SAME machine. If you are CPU bound, this will not be very helpful in solving query performance issues. Optimal for compute platforms with ample CPU.

@jamiet8921 8 лет назад

can you create a tutorial on how to setup a parallel database

@anshuanand90 10 лет назад

thanks

@nasimchaklader126 8 лет назад

can u explain how really works?

@SatyendraSingh-ul5iq 3 года назад

May i know y u shutdown the database also want to know that r u working on linux ?

@blsraja 6 лет назад

Will it work on oracle standard edition 12c?

@GKizer 5 лет назад

I have just recently seen it implemented on a huge query that would take 18 minutes, and brought it to under 19 seconds in 12c.

@joseabeldelafuentearriaga5993 2 года назад

is there some rigth way to know the number of paralell process?, I means, in you explample you used 8.

@laeeqahmed1980 11 лет назад

Also I/O, the biggest issue.

@GaryL3803 12 лет назад

The vast improvement is indeed greatly exaggerated by this test. This is PROBABLY due to the effect of the 1st query running using a SAN that cached the I/O for the table on the 1st run. The second execution is reading out of the SAN cache. Probaly would have been faster if executed serially the second time.