Reklama: Szkolenia BHP za 59 zł na pracownika! Obniż koszty firmy!

Stwórz profil

Musisz wpisać swoje imię
Musisz wpisać swoje nazwisko
Musisz wpisać poprawny e-mail
Musisz wpisać hasło (min. 8 znaków)
Musisz zaakceptować regulamin

Optymalizacja 11g pod jeden typ prostych zapytań [?]

Paweł Grzegorz KwiatkowskiSenior Consultant,
Capgemini

Temat: Optymalizacja 11g pod jeden typ prostych zapytań [?]

Pomysł nieco odmienny, być może nie mający sensu, ale jak masz czas i chęci możesz się pobawić ;-)

Jak rozumiem, "itemów", jest 100, a każda transakcja to podzbiór itemów.

Czyli:
T1 = (itemX, itemY)
T2 = (itemA, itemB, itemC)
...

Nie wiem jaka logika kryje się za danym query, ale może warto rozważyć zmianę struktury tabeli na:

(TID, I1, ..., I100) - 101 kolumn
TID - unikalny numer transakcji
Ix = 1 gdy item należy do transakcji, null gdy nie należy

Do tego indeksy bitmapowe na każdą kolumnę.

Zapytania pewnie wtedy miałbyś ładnie pod użycie indeksów:
select ... where I1=1 or I50=1 or I70=1;
18.12.2009, 01:30
Link | Cytuj

Zacheusz SiedleckiProgramista Java

Temat: Optymalizacja 11g pod jeden typ prostych zapytań [?]

To co opisałeś to jest alternatywna pozioma reprezentacja. Jak najbardziej ma sens. Szczerze mówiąc intuicyjnie wydawało mi się, że będzie wolniejsza ale rzeczywiście mogę się mylić. Dzięki za pomysł - sprawdzę go :]
EDIT: aa jest 'mały' problem - wartości itemów nie mogę założyć, musiałbym je na przykład zapisywać w innej tabeli i jakoś łączyć z numerem kolumny.Zacheusz Siedlecki edytował(a) ten post dnia 18.12.09 o godzinie 03:12
18.12.2009, 03:11
Link | Cytuj

konto usunięte

Temat: Optymalizacja 11g pod jeden typ prostych zapytań [?]

Zacheusz Siedlecki:
);[/code] Na razie działa znacznie wolniej od poprzednich

Być może będzie działać szybciej jeśli do każdego z podzapytan dodasz AND ROWNUM=1, optymalizator czasami wybiera wtedy dużo lepsze plany.



select count(*) from (



  select distinct(tid) from party0.transactions_g2 outer



  where exists (select tid from party0.transactions_g2 where item = :1 and tid = outer.tid and rownum=1) 



  and exists (select tid from party0.transactions_g2 where item = :2 and tid = outer.tid and rownum=1) 



  and exists (select tid from party0.transactions_g2 where item = :3 and tid = outer.tid and rownum=1)



  and exists (select tid from party0.transactions_g2 where item = :4 and tid = outer.tid and rownum=1)



);
Krzysztof Pułapa edytował(a) ten post dnia 18.12.09 o godzinie 08:44
18.12.2009, 08:42
Link | Cytuj

Zacheusz SiedleckiProgramista Java

Temat: Optymalizacja 11g pod jeden typ prostych zapytań [?]

Rzeczywiście zmienia plan, ale akurat w tym przypadku jest on odrobinę wolniejszy. Dzięki temu jednak zauważył, że można przepisać na MV z group by (DDL widoku w poprzednich postach) tak:
  CREATE MATERIALIZED VIEW "PARTY0"."MVIEW_TRANSACTIONS_G2_GROUP_BY" ("TID", "ITEM", "C")

  AS SELECT 

    TID, 

    ITEM, 

    COUNT(*) AS c 

FROM 

    TRANSACTIONS_G2 

GROUP BY 

    TID, 

    ITEM;

SELECT COUNT(*) FROM

  (SELECT

    /*+ REWRITE (PARTY0.MVIEW_TRANSACTIONS_G2_GROUP_BY) */

    DISTINCT(tid)

  FROM party0.transactions_g2 OUTER

  WHERE EXISTS (SELECT tid FROM party0.transactions_g2 WHERE item = :1 AND tid    = outer.tid AND rownum =1)

  AND EXISTS (SELECT tid FROM party0.transactions_g2 WHERE item = :2 AND tid    = outer.tid AND rownum =1)

  AND EXISTS (SELECT tid FROM party0.transactions_g2 WHERE item = :3 AND tid    = outer.tid AND rownum =1)

  AND EXISTS (SELECT tid FROM party0.transactions_g2 WHERE item = :4 AND tid    = outer.tid AND rownum =1)

  );
ale to też nie dało piorunujących rezultatów. Próbowałem również różnych indeksów w zmaterializowanym widoku przepisanym pod group by. Sprawdziłem różne kombinacje i mimo wszystko dalej najszybsze jest Twoje rozwiązanie z OIT które jest parokrotnie szybsze od pozostłych. To sprawiło, że baza zaczęła działać z w miarę dopuszczalną prędkością. Jeszcze nie sprawdziłem pomysłu z partycjonowaniem ale jeśli on też się okaże wolniejszy to zostanę przy OIT. Bardzo dziękuję za pomoc :]Zacheusz Siedlecki edytował(a) ten post dnia 18.12.09 o godzinie 12:01
18.12.2009, 11:47
Link | Cytuj

Rafał WardasPS Consultant

Temat: Optymalizacja 11g pod jeden typ prostych zapytań [?]

Doleję trochę oliwy do ognia ;)

W przerwie od magisterki pobawiłem się trochę danymi od Zacheusza... Ogólnie idea polega na wykorzystaniu typów tablicowych ( miałem złudną nadzieję, że uda się ominąć grupowanie ) ze skutkiem ~0.7 sec przy ~0.4 dzięki wskazówką Krzysztofa.

Wszystko stanie się jasne po przyjrzeniu się zrzutowi ekranu :


Obrazek


Początkowo chciałem wyciągnąć liczbę transakcji przy użyciu PL/SQL ale okazało się, że ( przynajmniej w moim wykonaniu ) nie jest to najszybsze i trwa powyżej sekundy. Nawet jak zachowa się kolejność parametrów wejściowych i bazuje na ograniczonej liczbie iteracji dzięki własności posortowanego zbioru to nie udało mi się uzyskać lepszego wyniku niż przy zwykłym ale trochę przekombinowanym zapytaniu. 



SELECT COUNT(*) FROM (

SELECT 

    case when ( 

    SELECT COUNT(*) FROM [b]table[/b](items) d where d.column_value in (70,2573,2430,2424))=4 then 1

    else 0 end as matched_group

 FROM 

   transactions_end

 WHERE ctr >= 4) x

 WHERE matched_group=1;


W dalszym ciągu jest problem grupowania (table(items)) i z tego co zauważyłem, to z poziomu SQL nie można się dostać do typu tablicowego i wykonywać na nim operacji porównywania zbiorów. Będę jeszcze próbował z NESTED TABLES dla zabawy ;) bo największym problemem jest tutaj COLLECTION ITERATOR. Ma ktoś pomysł jak odpytać typ tablicowy "items" w sekcji WHERE bez powyższych dziwactw ? ;)

R.
18.12.2009, 15:41
Link | Cytuj

Sebastian Kolskiprogramista/DBA

Temat: Optymalizacja 11g pod jeden typ prostych zapytań [?]

Sprawdź MULTISET INTERSECT, co prawda nigdy nie używałem ale to chyba powinno zadziałać.
<edit>
err to by zadziałało jakby w podzbiorach były tid a nie na itemy
</edit>

Oczywiście proste rozwiązanie widzi się na końcu. Pomyślałem sobie, że można to query zapisać jeszcze jako wielokrotne złączenie tej samej tabeli (1.tid = 2.tid = 3.tid = 4.tid and 1.item = :1 and 2.item = :2 ...), no ale po co jak można po prostu zrobić:


select tid from party0.transactons_g2 where item = :1

intersect

select tid from party0.transactons_g2 where item = :2

intersect

select tid from party0.transactons_g2 where item = :3

intersect

select tid from party0.transactons_g2 where item = :4

dodatkowo popartycjonować po itemie, założyć lokalne indeksy na tid i dodać hinty INDEX_FFS do podzapytań, jeśli optimizer nie użyje fast full scan'ów na indeksach. Efektem powinno być odczytanie 4 lokalnych indeksów na partycjach przy użyciu multi-block readów. Czy będzie to szybsze od IOT'a, pewnie zależy od wielu czynników, między innymi od gęstości danych w strukturach i wielkości multi-block readów etc.Sebastian Kolski edytował(a) ten post dnia 18.12.09 o godzinie 18:55
18.12.2009, 16:12
Link | Cytuj

konto usunięte

Temat: Optymalizacja 11g pod jeden typ prostych zapytań [?]

Sebastian Kolski:
Czy będzie to szybsze od IOT'a, pewnie zależy od wielu czynników, między innymi od gęstości danych w strukturach i wielkości multi-block readów

Ja się wprawdzie dawno bawiłem w optymalizację a teraz głównie dbam o to, żeby bazy w ogóle działały :) ale ...

Same IOT jako pomysł zostały wprowadzone dość dawno, a od tamtego czasu optymalizator jak i silnik odpowiedzialny za I/O uległy sporym przeobrażeniom. Już na samym początku tabele IOT miały w sobie "pewną siłę", jednak przy zachowaniu kilku, niestety dość ostrych warunków. Tutaj jest spełniony jeden z ciekawszych czyli wszystkie kolumny są kluczem PK no i na dodatek są dość niewielkie objętościowo. Dlatego jak zobaczyłem "to coś" to od razu w ciemno rzuciłem pomysł z IOT.

Jednak sama struktura danych jak i ich "filozofia" powoduje, że ciężko jest uzyskać bardziej znaczący zysk niż IOT. Na pewno byłoby to dużo bardziej zyskowne, gdyby w where brała udział kolumna o większej selektywności. A tak, to prawie na pewno przy dobrym zaprojektowaniu "zwykłej" tabeli oraz paru "mykom" z hintami jak i zmianami zapytań uda się zbliżyć do wyniku IOT. A IOT ma "masakryczną" wadę: wielokrotnie wyższy koszt insertów i update'ów niż zwykła tabela.

Jeśli zostawić tą strukturę to teraz dalszy wzrost można osiągnąć podchodząc do tematu nie od strony projektanta czy programisty, a bardziej od strony DBA.

Czyli ...

1. Jeśli jest mocna maszyna i storage (nie pojedyńczy dysk) to można spróbować skorzystać z wielowątkowości i skonfigurować w bazie i na tej tabeli parallel query.

2. Jeśli w/w da zysk, to można spróbować z wyższy mdb_multiblock_read_count jak i zwiększeniem db_block_size dla przestrzeni tabel związanej z tą tabelą. Przy "niskich pobraniach" może to być gorsze rozwiązanie, ale przy dużych porcjach czytanych rekordów może być z tego paruprocentowy zysk.

3. Jeśli jest dużo RAMu to można skonfigurować KEEP_BUFFER i wrzucić tą tabelę do niego.

4. Można spróbować pomysłu z TEMPORARY TABLE czyli w ogóle wszystko wrzucić do RAM - oczywiście jeśli tabela ta nie jest modyfikowana w trakcie pracy bazy. Ale z moich testów wynikało, że dla dużych tabel i odczytów z nich na poziomie około <40% ich objętości nie jest to specjalnie korzystne. TEMPORARY TABLE było dobre przy niedużym rozmiarze (kilka tys rekordów) i full scanie. Jednak trzeba było wtedy specjalnie dbać o to, żeby w złączeniach nie powstawał efekt "kaskady full scanów". Czyli full scan tabeli TEMPORARY nie powodował full scanów pozostałych tabel.

No to się rozpisałem ... jutro jak to przeczytam to sam siebie nie zrozumiem :)
18.12.2009, 18:36
Link | Cytuj

Zacheusz SiedleckiProgramista Java

Temat: Optymalizacja 11g pod jeden typ prostych zapytań [?]

Krzysztof Pułapa:
Jednak sama struktura danych jak i ich "filozofia" powoduje, że ciężko jest uzyskać bardziej znaczący zysk niż IOT. Na pewno byłoby to dużo bardziej zyskowne, gdyby w where brała udział kolumna o większej selektywności. A tak, to prawie na pewno przy dobrym zaprojektowaniu "zwykłej" tabeli oraz paru "mykom" z hintami jak i zmianami zapytań uda się zbliżyć do wyniku IOT. A IOT ma "masakryczną" wadę: wielokrotnie wyższy koszt insertów i update'ów niż zwykła tabela.
To jest system przeprowadzający wielostronne odkrywanie wiedzy (hurtownia danych). Ładowanie danych odbywa się osobno i jak najbardziej może być kosztowne jeśli ma przyspieszyć późniejsze działanie.
Jeśli zostawić tą strukturę to teraz dalszy wzrost można osiągnąć podchodząc do tematu nie od strony projektanta czy programisty, a bardziej od strony DBA.

Czyli ...

1. Jeśli jest mocna maszyna i storage (nie pojedyńczy dysk) to można spróbować skorzystać z wielowątkowości i skonfigurować w bazie i na tej tabeli parallel query.
Niestety sprzęt jest słabiutki. Komputer przeznaczony pod bazę to:
Intel Core 2 Quad 2.66GHz
2 GB RAM
pojedynczy dysk SATA2 7200rpm
(Innna sprawa, że w skład systemu wchodzą 4 takie bazy, ale nie mogą one być połączone.)

Tak więc Twoje uwagi jak najbardziej cenne niestety przy tej konfiguracji nie znajdą zastosowania. Niemniej jednak dziękuję za te informacje - niewątpliwie przydadzą się w przyszłości.

EDIT: Spróbuję jeszcze to partycjonowanie - wygląda z logicznego punktu widzenia jak pozioma reprezentacja.Zacheusz Siedlecki edytował(a) ten post dnia 19.12.09 o godzinie 09:13
19.12.2009, 09:06
Link | Cytuj

Mariusz MasewiczPrawie wszysko o
bazach danych Oracle
:-)

Temat: Optymalizacja 11g pod jeden typ prostych zapytań [?]

Zacheusz Siedlecki:
Niestety sprzęt jest słabiutki. Komputer przeznaczony pod bazę to:
Intel Core 2 Quad 2.66GHz
2 GB RAM
pojedynczy dysk SATA2 7200rpm

Czyli wg. Oracle masz 4 procki, troche malo pamieci i wolne I/O.
Przy optymalizacji poszedlbym jednak w strone zrownoleglania (zeby dobic procki) i oszczedzania I/O, czyli partycjonowanie, agregaty (MV), dane wstepnie posortowane i byc moze nawet skompresowane (Oraclowa kompresja w 10g jest "naiwna" wiec pozwala tylko zmniejszyc I/O bez dodatkowego zwiekszania kosztow typu procesor)
(Innna sprawa, że w skład systemu wchodzą 4 takie bazy, ale nie mogą one być połączone.)

Tego nie zrozumialem...
19.12.2009, 17:19
Link | Cytuj

konto usunięte

Temat: Optymalizacja 11g pod jeden typ prostych zapytań [?]

Mariusz Masewicz:
Tego nie zrozumialem...

4 instancje i nie może zawartych w nich danych wrzucić do jednej ?
19.12.2009, 19:13
Link | Cytuj

Zacheusz SiedleckiProgramista Java

Temat: Optymalizacja 11g pod jeden typ prostych zapytań [?]

Właśnie tak. 4 oddzielne bazy o takiej samej strukturze z innymi danymi. Chodzi o to, że to jest wielostronne bezpieczne odkrywanie wiedzy. Przeprowadzam data mining na całości danych (w tej konfiguracji należących do 4 różnych stron) przy czym strony na wzajem nie ujawniają sobie danych a jedynie poznają wynik całego procesu. Tak więc od strony bazy danych każdą należy rozpatrywać jako samodzielną.Zacheusz Siedlecki edytował(a) ten post dnia 20.12.09 o godzinie 03:29
20.12.2009, 03:28
Link | Cytuj

Jacek TomakaProgramista,
Intergraph Polska Sp
z o.o.

Temat: Optymalizacja 11g pod jeden typ prostych zapytań [?]

O ile dobrze rozumiem potrzebujesz wyciągnąć itemy, które biorą udział w określonej liczbie transakcji.
Czemu nie można zrobić tak, że stworzysz sobie od razu zmaterializowany widok, który będzie zawierał to co potrzebujesz, mianowicie:
create materialized view test_view as
select item, count(*) ilosc from tabelka;

Następnie założyć unikalny indeks na itemie, ilosc.

zapytanie wyglądałoby tak:
select item, count(*) from test_view where item in (:1,:2,:3,:4) and ilosc=:5

Tak czy inaczej nie ma znaczenia, w zapytaniu będzie in (inlist iterator) czy temporary table (nested loop join), głównym kosztem zapytania będzie n strzałów przez unikalny indeks.

Jeśli zamiast MV zrobisz IOT to zysk będzie raczej w miejscu na dysku (bo nie będzie redundancji kolumn item, ilosc - w mv i w indeksie), natomiast w wydajnosci nie będzie.

Podstawowa różnica w wydajności będzie się brała stąd, że zliczanie odbędzie się raz, na początku, a nie za każdym zapytaniem.

Ale może czegoś nie rozumiem ;>
20.12.2009, 13:45
Link | Cytuj

Zacheusz SiedleckiProgramista Java

Temat: Optymalizacja 11g pod jeden typ prostych zapytań [?]

Jacek Tomaka:
Ale może czegoś nie rozumiem ;>
No nie rozumiesz :) Ale pewnie dlatego, że nie wyjaśniłem dokładnie znaczenia tego zapytania.
TID - identyfikator zbioru
ITEM - element zbioru
Zapytanie zlicza ilość zbiorów (TID) które zawierają zbiór podany do zapytania. Ten agregat który podałeś IMHO nie ma się nijak do zapytania.
Jeśli chodzi o agregat z ilością to niestety liczba możliwych zbiorów k elemtntowych ze zbioru n elementów jest n!/(k!*(n-k)!)
W tej konfiguracji teraz mam 100 różnych elementów a transakcja zawiera maksymalnie 30 z nich no ale mogę założyć że będę testował podzbiory maksymalnie 10 elementowe. Tak więc liczba zagregowanych wierszy to by była suma wyników takiego wyrażenia dla k od 1 do 10 i n = 100 czyli baardzo dużo. Mam nadzieję, że nigdzie się tu nie pomyliłem ;)Zacheusz Siedlecki edytował(a) ten post dnia 20.12.09 o godzinie 17:59
20.12.2009, 17:51
Link | Cytuj

konto usunięte

Temat: Optymalizacja 11g pod jeden typ prostych zapytań [?]

Zacheusz Siedlecki:
TID - identyfikator zbioru
ITEM - element zbioru

No, to macie prosto i przejrzyście wytłumaczone ... :)
20.12.2009, 18:40
Link | Cytuj

Mariusz MasewiczPrawie wszysko o
bazach danych Oracle
:-)

Temat: Optymalizacja 11g pod jeden typ prostych zapytań [?]

Zacheusz Siedlecki:
Jacek Tomaka:
Ale może czegoś nie rozumiem ;>
No nie rozumiesz :) Ale pewnie dlatego, że nie wyjaśniłem dokładnie znaczenia tego zapytania.
TID - identyfikator zbioru
ITEM - element zbioru
Zapytanie zlicza ilość zbiorów (TID) które zawierają zbiór podany do zapytania. Ten agregat który podałeś IMHO nie ma się nijak do zapytania.

tu masz racje - ma sie nijak. Ale ja sie bede upieral przy swoje MV (z poprzendiej strony tego ciekawego watku)
Jeśli chodzi o agregat z ilością to niestety liczba możliwych zbiorów k elemtntowych ze zbioru n elementów jest n!/(k!*(n-k)!)
W tej konfiguracji teraz mam 100 różnych elementów a transakcja zawiera maksymalnie 30 z nich no ale mogę założyć że będę testował podzbiory maksymalnie 10 elementowe. Tak więc liczba
[...]

Cos mi swita, ze efektywne indeksowanie zbiorow to juz od dluzszego czasu uskuteczniaja moi koledzy - napisz do mnie na priv, to dam ci namiary na nich (a oni z kolei na liste swoich publikacji - lektura w sam raz na dlugie, zimowe wieczory..)
23.12.2009, 00:56
Link | Cytuj

Mariusz MasewiczPrawie wszysko o
bazach danych Oracle
:-)

Temat: Optymalizacja 11g pod jeden typ prostych zapytań [?]

Krzysztof Pułapa:
Mariusz Masewicz:
Tego nie zrozumialem...

4 instancje i nie może zawartych w nich danych wrzucić do jednej ?

4 bazy moglo oznaczac od: 4 tabelki o takiej samej strukturze
poprzez: 4 bazy na tej samej maszynie
do: 4 identyczne maszyny rozniace sie tylko zawartoscia tabelek w bazach

Do tego mozna doliczyc Microsoftowe tlumaczenie baza na cos co przypomina nasz tablespace. BTW uwielbiam jak admini od M$SQLServera opowiadaja jak to maja duzo pracy tworzac nowe bazy danych, zwlaszcza, ze mi czasami i przez pol roku zdarza sie nie tworzyc zadnej nowej bazy...
23.12.2009, 01:00
Link | Cytuj

Rafał WardasPS Consultant

Temat: Optymalizacja 11g pod jeden typ prostych zapytań [?]

Sebastian Kolski:
Sprawdź MULTISET INTERSECT, co prawda nigdy nie używałem ale to chyba powinno zadziałać.
<edit>
err to by zadziałało jakby w podzbiorach były tid a nie na itemy
</edit>

Oczywiście proste rozwiązanie widzi się na końcu. Pomyślałem sobie, że można to query zapisać jeszcze jako wielokrotne złączenie tej samej tabeli (1.tid = 2.tid = 3.tid = 4.tid and 1.item = :1 and 2.item = :2 ...), no ale po co jak można po prostu zrobić:


select tid from party0.transactons_g2 where item = :1

intersect

select tid from party0.transactons_g2 where item = :2

intersect

select tid from party0.transactons_g2 where item = :3

intersect

select tid from party0.transactons_g2 where item = :4
Znalazłem chwilę by odpisać ;).. w końcu wigilia.
Pocięcie tego w drugą stronę jest o wiele bardziej logiczne ;) mój błąd. Ustawiłem partycje HASH dla 100 elementów, założyłem lokalne indeksy i z tego co Zacheusz mówił to było to szybsze przy małej ilości danych i założeniu, że nie czyści się cache. Przy zrównolegleniu lub zwiększeniu ilości danych wydajność spadała ;)

dodatkowo popartycjonować po itemie, założyć lokalne indeksy na tid i dodać hinty INDEX_FFS do podzapytań, jeśli optimizer nie użyje fast full scan'ów na indeksach. Efektem powinno być odczytanie 4 lokalnych indeksów na partycjach przy użyciu multi-block readów. Czy będzie to szybsze od IOT'a, pewnie zależy od wielu czynników, między innymi od gęstości danych w strukturach i wielkości multi-block readów etc.
Nie wiem czy czegoś nie popsułem przy tworzeniu tego ;) Testy przeprowadzaliśmy bez zmiany multi-block w sesji (w zamian za to na IOT) W każdym bądź razie spróbujemy jeszcze raz do tego podejść.

Mariusz Masewicz:
....

Do tego mozna doliczyc Microsoftowe tlumaczenie baza na cos co przypomina nasz tablespace.
Może to i brzmi dumnie ale koło prawdy nawet nie leży.

R.Rafał Wardas edytował(a) ten post dnia 24.12.09 o godzinie 15:31
24.12.2009, 15:24
Link | Cytuj

Mariusz MasewiczPrawie wszysko o
bazach danych Oracle
:-)

Temat: Optymalizacja 11g pod jeden typ prostych zapytań [?]

Rafał Wardas:
Do tego mozna doliczyc Microsoftowe tlumaczenie baza na cos co przypomina nasz tablespace.
Może to i brzmi dumnie ale koło prawdy nawet nie leży.

A jak wyglada powiazanie "filegrupy" z "databejzem" u microsofta? Bo od tego to juz maly krok do:
http://msdn.microsoft.com/en-us/library/ms152551.aspx - A tablespace is a unit of database storage that is roughly equivalent to a file group in Microsoft SQL Server

A tu sam M$ przyrownuje zachowanie przestrzeni tabel do jednej ze swoich baz danych...
http://msdn.microsoft.com/en-us/library/ms345124%28SQL... - the undo tablespace behavior is similar to that of SQL Server 2005 tempdb

No i moj ulubieniec (do sciagniecia z M$):
SQLServer2008forOracle.docx

Dalej nie chce mi sie googlac, ale podobnych stwierdzen jest wiecej w dokumentacji M$Mariusz Masewicz edytował(a) ten post dnia 29.12.09 o godzinie 22:36
29.12.2009, 21:57
Link | Cytuj

Rafał WardasPS Consultant

Temat: Optymalizacja 11g pod jeden typ prostych zapytań [?]

Mariusz Masewicz:
...moment ;) dopiero z nart wróciłem... .
A jak wyglada powiazanie "filegrupy" z "databejzem" u microsofta? Bo od tego to juz maly krok do:
http://msdn.microsoft.com/en-us/library/ms152551.aspx - A tablespace is a unit of database storage that is roughly equivalent to a file group in Microsoft SQL Server

A tu sam M$ przyrownuje zachowanie przestrzeni tabel do jednej ze swoich baz danych...
http://msdn.microsoft.com/en-us/library/ms345124%28SQL... - the undo tablespace behavior is similar to that of SQL Server 2005 tempdb
Podpisuję się pod tym ;) ale..
Do tego mozna doliczyc Microsoftowe tlumaczenie baza na cos co przypomina nasz tablespace. , w którym pewnie coś innego miałeś na myśli się z tym nie pokrywa ;)

No i moj ulubieniec (do sciagniecia z M$):
SQLServer2008forOracle.docx
Ja M$ lubię tylko za AS i IS... ale od dawna go na oczy nie widziałem ;) może się coś zmieniło.

Co do samej koncepcji.. hmm.. chyba MS logiczniej to ujął. W sumie to nie tylko MS a raczej większość producentów. Osobiście bardziej do mnie przemawia Instancja->baza.Rafał Wardas edytował(a) ten post dnia 30.12.09 o godzinie 19:35
30.12.2009, 19:31
Link | Cytuj

Mariusz MasewiczPrawie wszysko o
bazach danych Oracle
:-)

Temat: Optymalizacja 11g pod jeden typ prostych zapytań [?]

Rafał Wardas:
Do tego mozna doliczyc Microsoftowe tlumaczenie baza na cos co przypomina nasz tablespace. , w którym pewnie coś innego miałeś na myśli się z tym nie pokrywa ;)

Dokladnie to:
- tablespace/baza to pewien zbior plikow na dysku, ze wzgledow wydajnosciowych pewnie nawet na kilku dyskach
- obiekt (tabela/indeks) jest przypisany do tablespaca/bazy
- parametry skladownia, uprawnienia uzytkownikow definuijemy na poziomoe tablespaca/bazy (no w oracle z tych uprawien to tylko quoty)
- rozne tablespace/bazy swietnie nadaja sie do podzialu obiektow w zaleznosci od planowanego ich zastoswania...
- no i M$ sam przyznaje, ze w wielu miejscach te termininy sa sobie mniej wiecej rownowazne

COMMIT - na moj ogranczony Oraclowy umysl takie tlumaczenie mi wystarcza
Co do samej koncepcji.. hmm.. chyba MS logiczniej to ujął. W sumie to nie tylko MS a raczej większość producentów. Osobiście bardziej do mnie przemawia Instancja->baza.

Od zarania dziejow naukowcy twierdzili, ze baza danych to dane. Cos tam wspominali o jakiejs wspolnej dziedzinie tematycznej laczacej te dane i wogole. Fajnie bylo jak byl jakis efektywny mechanizm zarzadzania tymi danymi (o indeksach nie wspominajac). Przykladem bazy danych sa tabliczki sumeryjskie ze spisem ówczesnej ludnosci, czy stosowane przed wynalezieniem telefonow komorkowych takie smieszne kalendarzyki w ktore wpisywano adresy znajomych - te kalendarzyki milay nawet indeks na kluczu glownym :-) A jak juz baze udalo sie zapisac na dysku komputra i do tego dorobiono program do zarzadzania baza danych - to juz wogole naukowcy osiagneli szczyt rozkoszy (i zaczeli kombinowac nad modelem relacyjnym - milosciwie nam panujacym do dzisiaj).
Tak wiec Oracle w swojej terminologii slusznie nazywa bazą danych dane zapisane na dysku,

Przy okazji - pamietaj, ze SQl Server nie jest produktem M$ tylko Sybase'a ktory podczas rozwiazywania krotkiego malzenstwa obu tych korporacji zostal przywlaszczony przez M$ - Ale to juz osobna historia i pewnie obecnie kodu zrodlowego po przodkach niewiele znajdzie sie w SQlServer 2008.
30.12.2009, 23:32
Link | Cytuj
Odpowiedz

« | »


Wyślij zaproszenie do

Anuluj