- Karácsonyfaként világíthat a Thermaltake új CPU-hűtője
- Az USA vizsgálja a RISC-V kínai terjedésének kockázatát
- Kicsit extrémre sikerült a Hyte belépője a készre szerelt vízhűtések világába
- Egészen nagy teljesítményspektrumon fedné le a mobil piacot az AMD
- Kihívás a középkategóriában: teszten a Radeon RX 7600 XT
- VR topik (Oculus Rift, stb.)
- Gaming notebook topik
- Apple notebookok
- NVIDIA GeForce RTX 3080 / 3090 / Ti (GA102)
- Az USA vizsgálja a RISC-V kínai terjedésének kockázatát
- Logitech Z906
- Vezetékes FEJhallgatók
- Milyen egeret válasszak?
- Kormányok / autós szimulátorok topicja
- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
Hirdetés
-
Samsung Univerzum: Így ismerhető meg a Galaxy AI bármilyen telefonon
ma A Try Galaxy webalkalmazás kontrollált környezetben mutatja meg, mit tud a One UI 6.1-es rendszer és a mesterséges intelligencia.
-
Már tudjuk, hogy mikor jön az idei Xbox Games Showcase
gp A showt egy külön Direct előadás követi, ami szinte biztosan az idei Call of Duty lelepelzése lesz.
-
Súlyos adatvédelmi botrányba kerülhet a ChatGPT az EU-ban
it Egyre nagyobb probléma az AI hallucinálása – most az osztrák adatvédelmi hatóság veheti elő a ChatGPT miatt az OpenAI-t, alapvetően a GDPR megsértése miatt.
Új hozzászólás Aktív témák
-
Relisys
senior tag
Nem tudom, de egy példa rá:
Van egy date típusú mező (sysdate, sysdate-1, sysdate, sysdate-4....) , meg van egy number ahol az eladások száma van. És ha egy nap többször kerül feljegyzésre az eladások száma akkor ha azokat összeszámolom és group by-al csoportosítom a napokat, akkor ugyanazon napokat külön veszi. Gondolom azért mert nem másodperc pontossággal lettek a rekordok felvéve. Van erre valami megoldás?
-
bpx
őstag
unusable állapotban nincs indexkarbantartás
van egy táblád, rajta index(ekk)el
be akarsz tölteni a táblába 20 millió sort
alapértelmezett esetben betöltéskor minden új sor hozzáadásánál frissíteni kell az indexet
ennél gyorsabb az indexet újraépíteni, amikor már bent van a táblában minden adatbetöltés előtt index unusable
sorok betöltése gyorsan, indexhez nem kell nyúlni
végén index rebuildhttp://docs.oracle.com/cd/E11882_01/server.112/e25494/indexes002.htm#CIHJIDJG
[ Szerkesztve ]
-
bpx
őstag
-
bpx
őstag
Ez így azért nem jó, mert nem az update-ben van a where, ezért a table1 összes sorát update-eli, és azoknál a soroknál, amelyek table1-ben és table2-ben az erv_vege egyezik az erv_vege értéke null lesz, mivel az allekérdezés ott nem eredményt.
Ha már update, akkor pl. így:
update table1 o
set o.erv_vege = (select c.erv_vege from table2 c where o.id = c.id)
where o.erv_vege != (select c.erv_vege from table2 c where o.id = c.id);Ezzel az a gond, hogy nem optimális, feleslegesen dolgozik. Az Oracle nem engedi az update table1, table2, ... szintaktikát, ilyesmire a merge használható. Az eredeti merge azért nem jó ugye, mert az onban levő oszlopot szeretnéd update-elni, de ettől még lehet ezt merge használatával, ami jobb, mint a fenti update:
merge into table1 o
using table2 c
on (o.id = c.id)
when matched then
update set o.erv_vege = c.erv_vege
where o.erv_vege != c.erv_vege; -
lakisoft
veterán
1. megoldás:
SQL> select trunc(months_between(sysdate,dob)/12) year,
2 trunc(mod(months_between(sysdate,dob),12)) month,
3 trunc(sysdate-add_months(dob,trunc(months_between(sysdate,dob)/12)*12+trunc(mod(months_between(sysdate,dob),12)))) day
4 from (Select to_date('15122000','DDMMYYYY') dob from dual);
YEAR MONTH DAY
---------- ---------- ----------
9 5 26
SQL>2. megoldás:
SELECT TRUNC(
MONTHS_BETWEEN(
SYSDATE,
CASE TO_CHAR(birthdate,'MMDD')
WHEN '0229' -- born on February 29
THEN CASE TO_CHAR(TRUNC(SYSDATE,'YYYY') + 59,'MMDD')
WHEN '0229'-- current year is leap year
THEN birthdate
ELSE birthdate - 1 -- if person was born on February 29 and current year is not a leap year
END -- we will consider person was born on February 28
ELSE birthdate
END
) / 12
) age
FROM tbl3. megoldás:
SELECT FLOOR((SYSDATE - (ADD_MONTHS(SYSDATE,-22)+1))/365) YEARS,
MOD( (SYSDATE - (ADD_MONTHS(SYSDATE,-22)+1)),365) DAYS
FROM DUAL4. megoldás:
select
trunc((to_number(to_char(sysdate,'yyyymmdd'))
-to_number(to_char(date '2002-12-07','yyyymmdd'))
)/10000) as "age of this thread"
from dual; -
bpx
őstag
Ez ilyen tipikus adattárházas dolog, van egy tény táblád, amihez tartozik N dimenzió. A dimenziók szerint 2^N-féleképpen lehet csoportosítani, és ebből szükség van mondjuk azokra a részösszegekre, ahol a GROUP BY az alábbi oszlopok szerint történne (és akkor itt most a hasamra ütök, legyen 6 dimenzió):
N1, N2
N3, N4, N6
N1, N4, N5
N2, N6Egyik lehetőség, hogy ezt a 4 különböző esetet külön összegyűjtöd és a UNION-nal összerakod, pl.
select n1, n2, null, null, null, null, sum(value) from tabla group by n1, n2 union all
select null, null, n3, n4, null, n6, sum(value) from tabla group by n3, n4, n6 union all
select n1, null, null, n4, n5, null, sum(value) from tabla group by n1, n4, n5 union all
select null, n2, null, null, null, n6, sum(value) from tabla group by n2, n6;Ez eléggé gány meg lassú, ehelyett lehet azt írni, hogy a GROUP BY-t csak bizonyos oszlopcsoportok alapján képezett csoportokra kérem:
select n1, n2, n3, n4, n5, n6, sum(value) from tabla
group by grouping sets ((n1, n2), (n3, n4, n6), (n1, n4, n5), (n2, n6));[ Szerkesztve ]
-
sutszi
veterán
Gyorsan ránéztem...látszik egy raklapnyi... Pontosan melyiket nem látod?
Mondja, Mr. Babbage, ha rossz adatokat ad meg a gépnek, akkor is jó válasz fog kijönni belőle?" Képtelen vagyok felfogni azt az értelmi zavart, ami valakit egy ilyen kérdés feltevésére késztethet. - by Charles Babbage
-
sutszi
veterán
Még nem próbáltam. Mielőtt nekiugrok bármivel is küzdeni, gondoltam előbb kérdezek... hátha van valami kevésbé problémás megoldás.
Mondja, Mr. Babbage, ha rossz adatokat ad meg a gépnek, akkor is jó válasz fog kijönni belőle?" Képtelen vagyok felfogni azt az értelmi zavart, ami valakit egy ilyen kérdés feltevésére késztethet. - by Charles Babbage
-
sutszi
veterán
Ilyen távoli DB-s mókát még nem csináltam, mostanában kellet userek között synomym-os objektummegosztást csinálnom. Szóval ott GRANT is kellett a tulajdonos user részéről, hogy az aki a synonym-et létrehozza, hozzá is tudjon férni. Gondolom távoli DB-nél is kell GRANT?!
[ Szerkesztve ]
Mondja, Mr. Babbage, ha rossz adatokat ad meg a gépnek, akkor is jó válasz fog kijönni belőle?" Képtelen vagyok felfogni azt az értelmi zavart, ami valakit egy ilyen kérdés feltevésére késztethet. - by Charles Babbage
-
bpx
őstag
Ok, leegyszerűsítettem, hogy csak a lényeg legyen benne, a table function a baja.
drop type t_tab;
drop type t_row;
create type t_row as object (id number, description varchar2(50));
create type t_tab is table of t_row;
create or replace function f1 (p_rows in number) return t_tab as
l_tab t_tab := t_tab();
begin
for i in 1 .. p_rows loop
l_tab.extend;
l_tab(l_tab.last) := t_row(i, 'Description for ' || i);
end loop;
return l_tab;
end;
/
select * from table(f1(3));
ID DESCRIPTION
---------- --------------------------------------------------
1 Description for 1
2 Description for 2
3 Description for 3
create database link qaz connect to bp identified by bp using 'qaz';
desc t1@qaz
Name Null? Type
----- -------- -------
ID NUMBERVan tehát egy T1 táblám egy távoli adatbázisban. Na most hiába próbálsz akármit insertelni, a table function miatt rögtön hibát dob (a szinonímát kihagytam, mert az most nem lényeg), tehát pl. 1 darab 1-es számot szeretnék insertelni, már az sem megy:
SQL> insert into t1@qaz select 1 from dual where 1 in (select id from table(f1(1)));
insert into t1@qaz select 1 from dual where 1 in (select id from table(f1(1)))
*
ERROR at line 1:
ORA-22804: remote operations not permitted on object tables or user-defined type columnsLátszik, a beszúrt érték egy sima szám lenne, de az utasításban van egy table function, az adatbázis ezt ellenőrzi és rögtön hibát dob rá. Kerülő megoldás lehet a temp táblás módszer, amit írtál, vagy simán egy soronkénti insert PL/SQL-ből, de ha sok sort gyűjt össze a lekérdezésed, akkor azt nem kellene soronként csinálni (a távoli objektumokra nem megy a bulk insert).
SQL>
begin
for c in (select 1 as id from dual where 1 in (select id from table(f1(1))))
loop
insert into t1@qaz values (c.id);
end loop;
commit;
end;
8 /
PL/SQL procedure successfully completed.
SQL> select * from t1@qaz;
ID
----------
1[ Szerkesztve ]
-
adalbert1
veterán
-
bpx
őstag
Én nem tudok olyan hivatalos terminológiáról, ami azt mondaná, hogy a tábla ilyenkor inkonzisztens. A constraint az, ami nem engedné azt az adatot, így a constraint az, ami nem teljes értékű. Ilyen esetben csak az új adatoknál kényszerít a constraint, ezért az adatbázis nem használhat olyan optimalizációt, amit egy engedélyezett, validált constrainttel használhat.
Tehát ha pl. a gyerek táblában nézed egy EXISTS-tel, hogy ki az, akinek van szülője, ez nyilván hülyeség, mert mindenkinek van definíció szerint. Egy ENABLED VALIDATED constrainttel az adatbázis meg sem nézi a szülő táblát. Ha viszont neked ENABLED NOT VALIDATED constrainted van, akkor hiába van szülő-gyerek viszony, bizony minden egyes gyerekhez meg kell nézni a szülő táblában, hogy létezik-e.
-
rum-cajsz
őstag
persze, ha a loop-on belül indítasz egy új begin end alrészt, ott belül elkapod a hibát és ott eldöntheted vele, hogy mi történjen. Ha ki akarsz lépni a kurzorból, arról is külön kell gondoskodnod, pl. az exit paranccsal.
=Kilroy was here============================ooO=*(_)*=Ooo=======
-
bpx
őstag
Ennél konkrétabb kell. A módszer működik:
set serveroutput on
begin
for c in (select level - 2 as i from dual connect by level <= 3) loop
begin
dbms_output.put_line('i = ' || c.i || ', 1/i = ' || 1/c.i);
exception when others then dbms_output.put_line('i = ' || c.i || ', 1/i error: ' || sqlerrm);
end;
end loop;
end;
/
i = -1, 1/i = -1
i = 0, 1/i error: ORA-01476: divisor is equal to zero
i = 1, 1/i = 1
PL/SQL procedure successfully completed. -
bpx
őstag
"To invoke this procedure you must be owner of the table, or you need the ANALYZE ANY privilege."
Vagy marad a wrapper procedure + execute grantolva user1-nek rá.
Új hozzászólás Aktív témák
- KERÉKPÁR / BRINGA / ALKATRÉSZ beárazás
- Call of Duty: Modern Warfare III (2023)
- VR topik (Oculus Rift, stb.)
- Poco X6 Pro - ötös alá
- Kerékpárosok, bringások ide!
- Szevam: Érzelmi magabiztosság/biztonság - miért megyünk sokan külföldre valójában?
- Alkalmazásbemutató: Keep
- Gaming notebook topik
- Súlyos adatvédelmi botrányba kerülhet a ChatGPT az EU-ban
- Debrecen és környéke adok-veszek-beszélgetek
- További aktív témák...