пропозиції роботи
Wypowiedzi
-
a może regexp_substr :D
-
konflikt to jak w 2 bazach ktos zmienił te same dane ;).
Jako ze bazy nie wiedzą o swoim istnieniu ;) obie zmiany się powiodą. -
Pytanie czy obie bazy maja być aktywne. Bo jak tak to pojawi się dodatkowy problem z rozwiązywaniem konfliktów. Pozatym cięzko bedzie zapewnić realtime.
-
SELECT *
FROM dba_procedures
where procedure_name = :1;
:1 - nazwa procedury z pakietu -
Tu jest opis funkcji sprawdzającej. Jednak implementacja tego w triggerze :) niesie za sobą obniżenie wydajności. Wszystko zależy od tego jak ma być wykorzystywana tabela.
http://download.oracle.com/docs/cd/E11882_01/server.11... -
Jak zna się zasadę działania. to nie ma wielkiego znaczenia w jaki sposób sie korzysta z funkcjonalności.
Oczywiście pozostają przyzwyczajenia . Wiec najlepiej się uczyć z poziomu dokumentacji a potem używać najwygodniejszej metody do obsługi. -
albo tu
SELECT *
FROM DICT; -
user_tab_columns
-
heh ;) w dokumentacji jest dlaczego.
When you enable table compression by specifying either COMPRESS or COMPRESS BASIC, you enable basic table compression. Oracle Database attempts to compress data during direct-path INSERT operations when it is productive to do so. The original import utility (imp) does not support direct-path INSERT, and therefore cannot import data in a compressed format.
Tables with COMPRESS or COMPRESS BASIC use a PCTFREE value of 0 to maximize compression, unless you explicitly set a value for PCTFREE in the physical_attributes_clause.
In earlier releases, this type of compression was called DSS table compression and was enabled using COMPRESS FOR DIRECT_LOAD OPERATIONS. This syntax has been deprecated. -
mogłem dodać hinta :)
-
no nie do końca.
1 sql skonczył sie w Elapsed: 00:00:29.15
2 sql skonczył sie w Elapsed: 00:00:06.71
Mimo że według costu 1 sql byl dużo niższy.
Kwestia ustawienia.
create table kbi_cost_test nologging
as
select rownum as id,a.*
from dba_objects a
join (select rownum
from dual
connect by level <= 100) on 1=1;
alter table kbi_cost_test add constraint pk_kbi_cost_test primary key (id);
begin
dbms_stats.gather_table_stats(user,
'KBI_COST_TEST',
degree => 4,
estimate_percent=>50,
cascade=> true,
no_invalidate=>false);
end;
/
alter session set optimizer_index_cost_adj = 5;
explain plan for
select distinct OBJECT_NAME
from kbi_cost_test
where id > 10000;
select *
from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 2459475618
-------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 15974 | 374K| 2833 (9)| 00:00:34 |
| 1 | HASH UNIQUE | | 15974 | 374K| 2833 (9)| 00:00:34 |
| 2 | TABLE ACCESS BY INDEX ROWID| KBI_COST_TEST | 3029K| 69M| 2607 (1)| 00:00:32 |
|* 3 | INDEX RANGE SCAN | PK_KBI_COST_TEST | 3029K| | 323 (1)| 00:00:04 |
-------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
3 - access("ID">10000)
alter session set optimizer_index_cost_adj = 20;
explain plan for
select distinct OBJECT_NAME
from kbi_cost_test
where id > 10000;
select *
from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 1659472491
------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 15974 | 374K| 8209 (4)| 00:01:39 |
| 1 | HASH UNIQUE | | 15974 | 374K| 8209 (4)| 00:01:39 |
|* 2 | TABLE ACCESS FULL| KBI_COST_TEST | 3029K| 69M| 7983 (2)| 00:01:36 |
------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
2 - filter("ID">10000)
-
a czy niższy koszt ma gwarantować któtszy czas wykonania ?
-
OPTIMIZER_INDEX_CACHING - oznacza ile % ma optimizer sie spodziewać w cache. Tak naprawdę zmienia to tylko explain plan.
-
Paweł Grzegorz Kwiatkowski:
Pomijając plany zapytania (bo można wymusić taki czy inny), to dlaczego hash join jest wolniejszy, skoro jest tak dobrze z zasobami? :) Coś ciekawego musi się dziać w trakcie budowania hashy.
Na początek najlepiej porównać czas wykonania bez parallel.
Dopiero potem zacząć analizować jak parallel wpływa na wykonania.
Wykonanie hash_join i nl w paralel zmienia bardzo wiele. -
Grzegorz Drzymała:
Krzysztof Bielecki:
Grzegorz Drzymała:
Niekoniecznie o takie rozwiązanie mi chodziło :)
Przyjmujemy, że tabele dla poszczególnych stanowisk już istnieją.
Chodzi jedynie o efektywne przerzucenie danych.
Zapytanie SQL.
Insert all powinien pomoc.
Bardziej mi chodziło o INSERT FIRST WHEN - nie sprawdzasz wtedy niepotrzebnie warunków, ale generalnie ok - multitable insert.
Twoja kolej :)Grzegorz Drzymała edytował(a) ten post dnia 10.02.11 o godzinie 10:45
Racja ;) -
Podeslij cały plan wykonania w parallelu bo tam troche rzeczy brakuje koszty to nie wszystko :)
-
Grzegorz Drzymała:
Niekoniecznie o takie rozwiązanie mi chodziło :)
Przyjmujemy, że tabele dla poszczególnych stanowisk już istnieją.
Chodzi jedynie o efektywne przerzucenie danych.
Zapytanie SQL.
Insert all powinien pomoc. -
zapewne ln_licznik jest problemem :)
-
A dokładniej opisz do czego chcesz używać bulkow ?:)
Bo są szybsze rzeczy niżupdate bulkiem. -
to może pomoże :D
select q'!gfdffddddd'dssdsdd !'
from dual;
Dołącz do GoldenLine
Oferty pracy
Sprawdź aktualne oferty pracy
Aplikuj w łatwy sposób
Aplikuj jednym kliknięciem
