Pitanja u vezi Oracle Real Application Cluster?

Wednesday, 07.11.2007 – Dejan

Za 10-ak dana imam dvodnevni individualni “trening” u vezi Oracle Real Application Clustera, a što više znanja, trikova i “best practice” u vezi toga, pokušaće mi prenijeti gdin. Pierre Wagner, jedan od vodećih Oracle stručnjaka u Austriji. On je vođa “Expert Service” tima za Oracle u Austriji i jedan je od autora službene dokumentacije za “Oracle 11g Real Application Cluster  on Linux“.

Ja već imam neka pripremljena pitanja i par problema da mu postavim, a ukoliko i vi želite nešto da pitate u vezi Oracle RAC, ostavite ovdje komentar.


Recovery Oracle baze pomoću RMAN-a

Wednesday, 31.10.2007 – Dejan

U prethodnom tekstu sam pisao kako obaviti backup Oracle baze pomoću RMAN-a, u kojem sam pored ostalog naveo i da ću pokazati kako se vrši povratak (recovery) Oracle baze pomoću RMAN-a. Pošto je taj tekst ionako bio dug, odlučio sam ovaj dio objaviti kao nastavak.

Od mnogih mogućih situacija u kojima može doći do problema u radu baze, ja ću objasniti dva:
– Povratak izgubljenog/oštećenog SYSTEM tablespace
– Povratak obične datoteke ili tablespacea (NON-SYSTEM)

Pročitaj kompletan tekst »


Isti upit izražen na različite načine

Sunday, 28.10.2007 – Srdjan

Većina upita može da se napiše na različite načine.  C.J. Date je u online članku “Fifty Ways to Quote Your Query” prikazao listu od 52 načina da se iskaže jedan upit! Nije mi namera da se u ovome takmičim sa Date-om, već želim da prikažem nekoliko praktičnih i pravolinijskih metoda pomoću kojih se izvesna forma upita može zameniti adekvatnom (a efikasnijom) formom.

Prikazaću dve slične metode za transformaciju upita.

1. Prvom metodom se upit oblika … IN (SELECT …) pretvara u upit oblika … EXISTS (SELECT …), a naknadno se EXISTS zamenjuje sa INNER JOIN.

2. Drugom metodom se upit oblika … NOT IN (SELECT …) pretvara u upit oblika … NOT EXISTS (SELECT …), a naknadno se EXISTS zamenjuje sa LEFT OUTER JOIN

Cilj ovih transformacija je da se pronađe oblik upita koji najbolje odgovara SQL optimizatoru konkretnog SUBP-a (sistema za upravljanje bazama podataka), to jest da se koristi oblik upita koji se najbrže izvršava.

Struktura testnih tabela i testni podaci

Prvo ću dati strukturu i podatke, koji će mi pomoći u demonstraciji metoda transformacije upita. (Strukturu sam pozajmio iz jednog od mojih predhodnih postova.)

CREATE TABLE partneri ( 
  sifra_partnera INTEGER NOT NULL, 
  ime_partnera VARCHAR(50) NOT NULL, 
  CONSTRAINT pk_par 
    PRIMARY KEY (sifra_partnera) 
);    

CREATE TABLE adrese ( 
  sifra_partnera INTEGER NOT NULL, 
  opis_adrese VARCHAR(20) NOT NULL, 
  CONSTRAINT pk_tra 
    PRIMARY KEY (sifra_partnera, opis_adrese), 
  CONSTRAINT fk_tra_par 
    FOREIGN KEY (sifra_partnera) REFERENCES partneri 
    ON DELETE CASCADE ON UPDATE CASCADE );    

INSERT INTO partneri (sifra_partnera, ime_partnera) 
  VALUES (1, 'Mika str'); 
INSERT INTO partneri (sifra_partnera, ime_partnera) 
  VALUES (2, 'Pera doo'); 
INSERT INTO partneri (sifra_partnera, ime_partnera) 
  VALUES (3, 'MELANIJA'); 
INSERT INTO partneri (sifra_partnera, ime_partnera) 
  VALUES (4, 'Joca doo'); 
INSERT INTO partneri (sifra_partnera, ime_partnera) 
  VALUES (5, 'Doo ZIKA i SONS');    

INSERT INTO adrese (sifra_partnera, opis_adrese) 
  VALUES (1, 'prodavnica'); 
INSERT INTO adrese (sifra_partnera, opis_adrese) 
  VALUES (2, 'prodavnica br 1'); 
INSERT INTO adrese (sifra_partnera, opis_adrese) 
  VALUES (2, 'prodavnica br 2'); 
INSERT INTO adrese (sifra_partnera, opis_adrese) 
  VALUES (2, 'Kafana kod Pere'); 
INSERT INTO adrese (sifra_partnera, opis_adrese) 
  VALUES (4, 'uprava'); 
INSERT INTO adrese (sifra_partnera, opis_adrese) 
  VALUES (4, 'skladiste'); 
INSERT INTO adrese (sifra_partnera, opis_adrese) 
  VALUES (4, 'prodavnica'); 
INSERT INTO adrese (sifra_partnera, opis_adrese) 
  VALUES (5, 'Kafana Sinovi');

Prva metoda – zamena upita oblika … IN (SELECT …)

Ovu metodu ću demonstrirati na upitu koji daje odgovor na pitanje: Treba prikazati partnere koji imaju barem dve adrese.

Jedan od upita koji daje odgovor na ovo pitanje je upit koji koristi IN izraz:

SELECT p.sifra_partnera, p.ime_partnera 
  FROM partneri AS p 
 WHERE p.sifra_partnera IN 
       (SELECT a.sifra_partnera 
          FROM adrese AS a 
         GROUP BY a.sifra_partnera 
        HAVING COUNT(a.sifra_partnera) > 1 
       ) 
 ORDER BY p.sifra_partnera

Kako od ovog upita napraviti ekvivalentan upit upotrebom izraza EXISTS? Ponoviću ponovo predhodan upit, ali ću bojom istaći ključne elemente upita koji učestvuju u transformaciji.

SELECT p.sifra_partnera, p.ime_partnera 
  FROM partneri AS p 
 WHERE p.sifra_partnera IN 
       (SELECT a.sifra_partnera
          FROM adrese AS a 
         GROUP BY a.sifra_partnera 
        HAVING COUNT(a.sifra_partnera) > 1 
       ) 
 ORDER BY p.sifra_partnera

Ekvivalentan upit je sledeći upit u kojem sam istakao šta se desilo sa ključnim elementima iz predhodnog upita. Treba primetiti da je p.sifra_partnera iz spoljašnjeg upita ušla u unutrašnji upit u sastavu WHERE klauzule.

SELECT p.sifra_partnera, p.ime_partnera 
  FROM partneri AS p  WHERE EXISTS 
       (SELECT a.sifra_partnera 
          FROM adrese AS a 
         WHERE p.sifra_partnera = a.sifra_partnera 
         GROUP BY a.sifra_partnera 
        HAVING COUNT(a.sifra_partnera) > 1 
       ) 
 ORDER BY p.sifra_partnera

Kako od ovog upita doći do upita koji koristi INNER JOIN? Isti ključni elementi i dalje učestvuju u transformaciji i dobija se donji upit. Treba primetiti da konstrukcija p.sifra_partnera = a.sifra_partnera izlazi iz unutrašnjeg upita i pojavljuje se kao uslov spajanja u spoljašnjem upitu.

SELECT p.sifra_partnera, p.ime_partnera 
  FROM partneri AS p 
       INNER JOIN 
       (SELECT a.sifra_partnera 
          FROM adrese AS a 
         GROUP BY a.sifra_partnera 
        HAVING COUNT(a.sifra_partnera) > 1 
       ) AS pa 
         ON p.sifra_partnera = pa.sifra_partnera 
 ORDER BY p.sifra_partnera

Ceo postupak, korak po korak, sam bolje demonstrirao pomoću Power Point prezentacije Isti upit 1.

Rezultat izvršavanja sva tri gornja upita je isti:

sifra_partnera   ime_partnera 
--------------   ------------ 
             2   Pera doo 
             4   Joca doo

Druga metoda – zamena upita oblika … NOT IN (SELECT …)

Ovu metodu ću demonstrirati na upitu koji daje odgovor na pitanje: Treba prikazati partnere koji nemaju adresu.

Jedan od upita koji daje odgovor na ovo pitanje je upit koji koristi IN izraz:

SELECT p.sifra_partnera, p.ime_partnera 
  FROM partneri AS p 
 WHERE p.sifra_partnera NOT IN 
       (SELECT a.sifra_partnera 
          FROM adrese AS a 
       ) 
 ORDER BY p.sifra_partnera

Kako od ovog upita napraviti ekvivalentan upit upotrebom izraza NOT EXISTS? Ponoviću ponovo predhodan upit, ali ću bojom istaći ključne elemente upita koji učestvuju u transformaciji.

SELECT p.sifra_partnera, p.ime_partnera 
  FROM partneri AS p 
 WHERE p.sifra_partnera NOT IN 
       (SELECT a.sifra_partnera 
          FROM adrese AS a 
       ) 
 ORDER BY p.sifra_partnera

Ekvivalentan upit je sledeći upit u kojem sam istakao šta se desilo sa ključnim elementima iz predhodnog upita. Treba primetiti da je p.sifra_partnera iz spoljašnjeg upita ušla u unutrašnji upit u sastavu WHERE klauzule.

SELECT p.sifra_partnera, p.ime_partnera 
  FROM partneri AS p 
 WHERE NOT EXISTS 
       (SELECT a.sifra_partnera 
          FROM adrese AS a 
         WHERE p.sifra_partnera = a.sifra_partnera 
       ) 
 ORDER BY p.sifra_partnera

Kako od ovog upita doći do upita koji koristi LEFT OUTER JOIN? Isti ključni elementi i dalje učestvuju u transformaciji i dobija se donji upit. Treba primetiti da konstrukcija p.sifra_partnera = a.sifra_partnera izlazi iz unutrašnjeg upita i pojavljuje se kao uslov spajanja u spoljašnjem upitu. Takođe je bitno napomenuti kako je potrebno dodati WHERE klauzulu pa.sifra_partnera IS NULL.

SELECT p.sifra_partnera, p.ime_partnera 
  FROM partneri AS p 
       LEFT OUTER JOIN 
       (SELECT a.sifra_partnera 
          FROM adrese AS a 
       ) AS pa 
         ON p.sifra_partnera = pa.sifra_partnera 
 WHERE pa.sifra_partnera IS NULL 
 ORDER BY p.sifra_partnera

Slično kao i kod prethodne metode, i ovde sam ceo postupak demonstrirao pomoću Power Point prezentacije Isti upit 2.

Rezultat izvršavanja sva tri gornja upita je isti:

sifra_partnera   ime_partnera 
--------------   ------------ 
             3   MELANIJA

Zaključak

Koji od prikazanih upita daje rezultat najbrže? To se mora proveriti u zavisnosti od konkretnog SUBP-a, količine podataka, postojanja indeksa. Može se desiti da pojedini (stariji?) sistemi ni ne podržavaju sve prikazane verzije upita.

Moja iskustva sa PostgreSQL 8.1 i 8.2 sistemima pokazuju, da se najbolje ponašaju verzije upita koje koriste INNER JOIN i LEFT OUTER JOIN.


Oracle 11g za Windows

Wednesday, 24.10.2007 – Dejan

“Dugo” očekivana verzija 11g za Windows je postala dostupna.

Službena ovavijest i link za download

Sad ću da skinem i ovu verziju, pa da se malo poigram. 😀 Nadam se da će mi kućni “server” podnijeti ovu novu verziju…


Backup Oracle baze pomoću RMAN-a

Tuesday, 23.10.2007 – Dejan

Jedan od obaveznih zadataka svakog administratora Oracle baze je pravljenje sigurnosne kopije, odnosno backup Oracle baze. Ja ću vam u primjeru “korak po korak” objasniti kako se RMAN podešava i koristi za backup Oracle baze, a za detaljnije definicije šta je šta, pročitajte službenu Oracle dokumentaciju(Oracle® Database Backup and Recovery Advanced User’s Guide).

Za ovaj recept nam nisu potrebni ni limun, niti peršun, tako da možemo slobodno da ih bačimo.

Za backup Oracle baze pomoću RMAN-a trebaju nam ovi sastojci:
– 2 Oracle baze
– 1 RMAN
– 1 administrator Oracle baza
– 2 piva
– 1 film ili epizoda omiljene serije za ubijanje dosade dok traje backup

Pročitaj kompletan tekst »


DUAL vs. FAST DUAL (_fast_dual_enabled)

Wednesday, 17.10.2007 – Dejan

Ukoliko u izvornom kôdu često koristite DUAL tabelu, npr.  “SELECT sysdate FROM dual”, interne funkcije USER, USERENV, SYS_CONTEXT ili pseudokolone (ROWID, LEVEL i td.), onda pogledajte, da li je podešen parametar “_fast_dual_enabled” i da li je postavljen na “true”, jer u verziji 10g Oracle koristi poboljšani “access path” za operacije, koje uključuju DUAL tabelu i za svaku tu operaciju štedi 3 logička I/O upita.

Dokaz:

SQL> select sysdate from dual;

Execution Plan 
--------------------------------------------------------- 

0    SELECT STATEMENT Optimizer=ALL_ROWS (Cost=2 Card=1) 
1  0  FAST DUAL (Cost=2 Card=1) 

Statistics 

--------------------------------------------------------- 
0 consistent gets 

SQL> alter session set "_fast_dual_enabled"=false; 

SQL> select sysdate from dual; 

Execution Plan 

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

0    SELECT STATEMENT Optimizer=ALL_ROWS (Cost=2 Card=1)

1  0  TABLE ACCESS (FULL) OF 'DUAL' (TABLE) (Cost=2 Card=1) 

Statistics 

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

3 consistent gets

Postavite taj parametar na TRUE i uživajte.


Spajanje podataka po zajednickom atributu

Tuesday, 16.10.2007 – Srdjan

Miša, jedan moj kolega s posla, je juče naišao na problem prilikom pravljenja nekog izveštaja. Za potrebe tog izveštaja mora da prikupi podatke iz četiri različita izvora, a onda da ih objedini u jedinstven izveštaj.

Miša je napravio strukturu od četiri tabele, i u svaku od tabela je importovao podatke iz po jednog izvora. Svi prikupljeni podaci se odnose na odnose sa poslovnim partnerima (bilo da se radi o kupcima ili dobavljačima). Ono što je zajedničko svim podacima je da svi izvori koriste zajednički način ‘šifriranja’ partnera.

Pošto nemaju svi izvori odnose sa svim partnerima, ni jedan izvor nema kompletnu listu partnera. Problem je nastao kako se od četiri nepotpune liste partnera može napraviti jedna jedinstvena lista. Po dobijanju jedinstvene liste partnera ostaje rutinski posao spajanja tabela.

Miša mi se obratio za pomoć baš za kreiranje ove jedinstvene liste partnera, jer je problem dodatno komplikovala činjenica da su različiti izvori davali različita imena partnerima.

Da bih ilustrovao problem, daću sledeću strukturu tabela:

CREATE TABLE podaci_prodaje ( 
  sifra_partnera INTEGER NOT NULL PRIMARY KEY, 
  ime_partnera VARCHAR(50) NOT NULL, 
  broj_faktura INTEGER NOT NULL, 
  prodajna_vrednost NUMERIC(12, 2) NOT NULL);         

CREATE TABLE podaci_nabavke ( 
  sifra_partnera INTEGER NOT NULL PRIMARY KEY, 
  ime_partnera VARCHAR(50) NOT NULL, 
  datum_poslednje_nabavke DATE NOT NULL, 
  nabavna_vrednost NUMERIC(12, 2) NOT NULL);              

CREATE TABLE podaci_marketinga ( 
  sifra_partnera INTEGER NOT NULL PRIMARY KEY, 
  ime_partnera VARCHAR(50) NOT NULL, 
  broj_promocija INTEGER NOT NULL);

Ovu strukturu ću popuniti test podacima:

INSERT INTO podaci_prodaje (sifra_partnera, ime_partnera, broj_faktura, prodajna_vrednost) 
  VALUES (1, 'Mika str', 2, 15000.00); 
INSERT INTO podaci_prodaje (sifra_partnera, ime_partnera, broj_faktura, prodajna_vrednost) 
  VALUES (2, 'Pera doo', 5, 46500.00); 
INSERT INTO podaci_prodaje (sifra_partnera, ime_partnera, broj_faktura, prodajna_vrednost) 
  VALUES (4, 'Joca doo', 4, 75000.00);         

INSERT INTO podaci_nabavke (sifra_partnera, ime_partnera, datum_poslednje_nabavke, nabavna_vrednost) 
  VALUES (4, 'D.O.O. JOCA', '2007-03-01', 22000.00); 
INSERT INTO podaci_nabavke (sifra_partnera, ime_partnera, datum_poslednje_nabavke, nabavna_vrednost) 
  VALUES (5, 'Doo ZIKA i SONS', '2007-05-15', 15000.00);          

INSERT INTO podaci_marketinga (sifra_partnera, ime_partnera, broj_promocija) 
  VALUES (1, 'MIKA', 1); 
INSERT INTO podaci_marketinga (sifra_partnera, ime_partnera, broj_promocija) 
  VALUES (3, 'MELANIJA', 2); 
INSERT INTO podaci_marketinga (sifra_partnera, ime_partnera, broj_promocija) 
  VALUES (4, 'JOCA', 5);

Napomena: Spomenuo sam da je Miša napravio četiri tabele, a ja ovde radim sa tri tabele jer to ne utiče na princip rešavanja problema.

Zahtev je da se od datih podataka napravi izveštaj sa sledećim kolonama: ime partnera, broj faktura, prodajna vrednost, datum poslednje nabavke, nabavna vrednost i kolona sa brojem promocija. Takođe, svi podaci o jednom partneru se moraju pojaviti u jednom redu.

U testnim podacima treba uočiti da ni jedna od službi (prodaje, nabavke, marketinga) nema u svojim podacima sve partnere. Druga stvar koju treba uočiti je neznatna razlika u imenovanju partnera u pojedinim službama. Tako služba prodaje partnera sa šifrom 1 imenuje ‘Mika str’, dok tog istog partnera marketing imenuje ‘MIKA’.

Ova činjenica o imenovanju partnera komplikuje stvari jer se objedinjena lista partnera nemože dobiti prostim spajanjem (UNION) podataka raznih službi.

SELECT sifra_partnera, ime_partnera FROM podaci_prodaje 
 UNION ALL 
SELECT sifra_partnera, ime_partnera FROM podaci_nabavke 
 UNION ALL 
SELECT sifra_partnera, ime_partnera FROM podaci_marketinga;

Prikazan upit ne spaja podatke o partnerima na ispravan način jer duplira partnere koji su različito imenovani od strane različitih službi. Ovde nebi pomogla ni upotreba čistog UNION umesto UNION ALL.

Treba nam suptilniji način za spajanje podataka o partnerima i to se postiže pomoću sledećeg pogleda:

CREATE VIEW partneri (sifra_partnera, ime_partnera) 
AS 
SELECT s.sifra_partnera, 
       CASE WHEN p.ime_partnera IS NOT NULL THEN p.ime_partnera 
            WHEN n.ime_partnera IS NOT NULL THEN n.ime_partnera 
            WHEN m.ime_partnera IS NOT NULL THEN m.ime_partnera 
       END 
  FROM (SELECT sifra_partnera FROM podaci_prodaje 
         UNION 
        SELECT sifra_partnera FROM podaci_nabavke 
         UNION 
        SELECT sifra_partnera FROM podaci_marketinga 
       ) AS s 
       LEFT OUTER JOIN 
       podaci_prodaje AS p 
         ON s.sifra_partnera = p.sifra_partnera 
       LEFT OUTER JOIN 
       podaci_nabavke AS n 
         ON s.sifra_partnera = n.sifra_partnera 
       LEFT OUTER JOIN 
       podaci_marketinga AS m 
         ON s.sifra_partnera = m.sifra_partnera;

U gornjem pogledu je prvo upotrebljen čist UNION za dobijanje svih (unikatnih) šifara, a onda su te šifre spojene sa odgovarajućim imenima partnera. Prost SELECT nad ovim pogledom vraća kompletnu listu jedinstvenih partnera:

sifra_partnera  ime_partnera 
--------------  --------------- 
             1  Mika str 
             2  Pera doo 
             3  MELANIJA 
             4  Joca doo 
             5  Doo ZIKA i SONS

Sada kada imamo jedinstvenu listu partnera uopšte nije teško doći do sledećeg upita:

SELECT s.ime_partnera, 
       p.broj_faktura, p.prodajna_vrednost, 
       n.datum_poslednje_nabavke, n.nabavna_vrednost, 
       m.broj_promocija 
  FROM partneri AS s 
       LEFT OUTER JOIN 
       podaci_prodaje AS p 
         ON s.sifra_partnera = p.sifra_partnera 
       LEFT OUTER JOIN 
       podaci_nabavke AS n 
         ON s.sifra_partnera = n.sifra_partnera 
       LEFT OUTER JOIN 
       podaci_marketinga AS m 
         ON s.sifra_partnera = m.sifra_partnera;

Ovaj upit nam daje traženi rezultat:

ime_partnera     broj_faktura  prodajna_vrednost  datum_poslednje_nabavke  nabavna_vrednost  broj_promocija 
---------------  ------------  -----------------  -----------------------  ----------------  -------------- 
Mika str                    2           15000.00                                                          1 
Pera doo                    5           46500.00 
MELANIJA                                                                                                  2 
Joca doo                    4           75000.00               2007-03-01          22000.00               5 
Doo ZIKA i SONS                                                2007-05-15          15000.00

Njemački znakovi u nazivima kolona + impdp u UTF8 bazu = problem

Thursday, 27.09.2007 – Dejan

Džabe ja govorim ljudima da izbjegavaju njemačke ili bilo koje druge “specijalne” znakove u nazivima kolona, jer nema efekta sve dok ne iskrsne neki problem.

A kad iskrsne neki “ozbiljniji” problem, onda se i ja ko fol naljutim, pa im ozbiljnijim tonom dam do znanja da moraju ispraviti svoje greške.

Slična situacija se desila i juče. Exportujem bazu sa expdp, pokrenem import sa DataPump-om (impdp) u novu UTF8 bazu, kadli nakon nekoliko sati iskrsnu slijedeća greška:

Wed Sep 26 12:01:07 2007 Errors in file c:\oracle\product\10.2.0\admin\espaLive\bdump\espaLive_dw01_5360.trc:
ORA-07445: exception encountered: core dump [ACCESS_VIOLATION] [kpodpals+8916]
[PC:0x298CBA4] [ADDR:0x0] [UNABLE_TO_READ] []
 

a u trace datoteci pronađem ovo:

ksedmp: internal or fatal error 
ORA-07445: exception encountered: core dump [ACCESS_VIOLATION] [kpodpals+8916] 
 [PC:0x298CBA4] [ADDR:0x0] [UNABLE_TO_READ] [] 
----- PL/SQL Call Stack ----- 
  object      line  object 
  handle    number  name 
000007FF89AB6488        54  package body SYS.KUPD$DATA_INT 
000007FF89AF62F8      1324  package body SYS.KUPD$DATA 
000007FF89AFC3C8     10716  package body SYS.KUPW$WORKER 
000007FF89AFC3C8      3687  package body SYS.KUPW$WORKER 
000007FF89AFC3C8      6896  package body SYS.KUPW$WORKER 
000007FF89AFC3C8      1259  package body SYS.KUPW$WORKER 
000007FF89AD9440         2  anonymous block 
----- Call Stack Trace -----

Nakon pretrage na MetaLinku nađoh da je riječ o bug-u (Bug: 5576865), koji se pojavljuje, kada se u pojedinim tabelama nalaze kolone sa njemačkim znakovima (‘Ö’,’Ä’,’Ü’,’ß’), a koji je ispravljen u verziji 11g. Super.

Dakle, pošto od upgrade-a na 11g još dugo neće biti ništa, ne preostaje nam ništa drugo, nego prepraviti nazive kolona.


Oracle u Hrvatskoj obučava studente da dođu lakše do posla

Thursday, 20.09.2007 – Dejan

U zadnjem newsletteru od Oraclea sam vidio jednu veoma zanimljivu vijest pod naslovom “Oracle helps young people to find employment opportunities“, a u tekstu sam pronašao veoma optimističan potez zastupništva Oraclea u Hrvatskoj.

Naime, zbog nedostatka dovoljno stručnih administratora Oracle baza podataka na hrvatskom tržištu, Oracle Hrvatska je odlučio da u saradnji sa Fakultetom elektrotehnike i računarstva održi besplatan kurs  “Oracle Database Administrator 10g“, sa ciljem da se popuni spomenuta rupa u manjku kvalifikovanih Oracle DBA.

Prenijeću citat gospodina Marina Tadića, predstavnika Oracle Hrvatska:
Everyone benefits from this initiative. Students receive free, vocational training that can help them to find a job more easily when they graduate, and they can also connect with potential employers who may also be interested in investing in their further education. Employers have an opportunity to find new employees with the combination of skills they are looking for.

Palac gore!


Isplativost sertifikata

Tuesday, 11.09.2007 – Dejan

Tu i tamo me znaju pitati, da li se isplati polagati ispite za pojedine sertifikate. Moj odgovor je – samo ukoliko te papire mozete potvrditi stvarnim znanjem.

Sertifikat bez znanja je u vecini slucajeva bezvrijedan. Ukoliko imate iole prakticnog znanja i iskustva, sertifikat vam moze pomoci pri zaposljavanju ili pri dobijanju povisice, a meni je sertifikat pomogao u oba slucaja – i pri dobijanju prvog PRAVOG posla, i sad nedavno pri dobijanju povisice (nekoliko stotina EUR vise). Znaci, meni se isplatio.

U svakom slucaju ne mozete biti na gubitku. 🙂