{"id":36171,"date":"2019-10-31T22:09:58","date_gmt":"2019-10-31T19:09:58","guid":{"rendered":"https:\/\/prohoster.info\/blog\/po-sledam-highload-siberia-2019-8-zadach-po-oracle\/"},"modified":"2019-10-31T22:09:58","modified_gmt":"2019-10-31T19:09:58","slug":"po-sledam-highload-siberia-2019-8-zadach-po-oracle","status":"publish","type":"post","link":"https:\/\/prohoster.info\/sv\/blog\/administrirovanie\/po-sledam-highload-siberia-2019-8-zadach-po-oracle","title":{"rendered":"I sp\u00e5ren av Highload++ Siberia 2019 \u2013 8 uppgifter om Oracle","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Hej!<\/p>\n<p>Den 24-25 juni anordnades konferensen Highload++ Siberia 2019 i Novosibirsk. V\u00e5rt team var ocks\u00e5 d\u00e4r. <noindex><a rel=\"nofollow\" href=\"https:\/\/www.highload.ru\/siberia\/2019\/abstracts\/5211\">med en presentation<\/a><\/noindex> \u00bbContainerdatabaser Oracle (CDB\/PDB) och deras praktiska anv\u00e4ndning f\u00f6r programutveckling\u00ab, vi kommer att l\u00e4gga ut en textversion lite senare. Det var fantastiskt, tack. <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/users\/olegbunin\/\" class=\"user_link\">olegbunin<\/a><\/noindex> f\u00f6r arrangemanget, samt alla som kom. <\/p>\n<p><img decoding=\"async\" alt=\"I sp\u00e5ren av Highload++ Siberia 2019 \u2013 8 uppgifter om Oracle\" src=\"\/wp-content\/uploads\/2019\/07\/27f4707d4bb5968eaaa5c4748ff467cd.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nI det h\u00e4r inl\u00e4gget vill vi dela med oss av de uppgifter som fanns p\u00e5 v\u00e5r monter, s\u00e5 att ni kan testa era kunskaper i Oracle. Nedan f\u00f6ljer 8 uppgifter, svarsalternativ och f\u00f6rklaringar.<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h3>Vilket \u00e4r det h\u00f6gsta v\u00e4rdet av sekvensen vi kommer att se som resultat av att k\u00f6ra f\u00f6ljande skript?<\/h3>\n<p><\/p>\n<pre><code class=\"sql\">create sequence s start with 1;\n \nselect s.currval, s.nextval, s.currval, s.nextval, s.currval\nfrom dual\nconnect by level &lt;= 5;\n<\/code><\/pre>\n<p><\/p>\n<ul>\n<li>1<\/li>\n<li>5<\/li>\n<li>10<\/li>\n<li>25<\/li>\n<li>Inget, det blir ett fel.<\/li>\n<\/ul>\n<p>\n<b class=\"spoiler_title\">Svar<\/b>Enligt Oracle-dokumentationen (citerad fr\u00e5n 8.1.6):<br \/>\nInom en enda SQL-sats kommer Oracle att \u00f6ka sekvensen endast en g\u00e5ng per rad. Om en sats inneh\u00e5ller mer \u00e4n en referens till NEXTVAL f\u00f6r en sekvens, \u00f6kar Oracle sekvensen en g\u00e5ng och returnerar samma v\u00e4rde f\u00f6r alla f\u00f6rekomster av NEXTVAL. Om en sats inneh\u00e5ller referenser till b\u00e5de CURRVAL och NEXTVAL, \u00f6kar Oracle sekvensen och returnerar samma v\u00e4rde f\u00f6r b\u00e5de CURRVAL och NEXTVAL oavsett deras ordning inom satsen.<\/p>\n<p>D\u00e4rf\u00f6r <b>kommer det h\u00f6gsta v\u00e4rdet att motsvara antalet rader, det vill s\u00e4ga 5.<\/b>.<\/p>\n<h3>Hur m\u00e5nga rader kommer att finnas i tabellen som resultat av att k\u00f6ra f\u00f6ljande skript?<\/h3>\n<p><\/p>\n<pre><code class=\"sql\">create table t(i integer check (i &lt; 5));\n \ncreate procedure p(p_from integer, p_to integer) as\nbegin\n    for i in p_from .. p_to loop\n        insert into t values (i);\n    end loop;\nend;\n\/\n \nexec p(1, 3);\nexec p(4, 6);\nexec p(7, 9);<\/code><\/pre>\n<p><\/p>\n<ul>\n<li>0<\/li>\n<li>3<\/li>\n<li>4<\/li>\n<li>5<\/li>\n<li>6<\/li>\n<li>9<\/li>\n<\/ul>\n<p>\n<b class=\"spoiler_title\">Svar<\/b>Enligt Oracle-dokumentationen (citerad fr\u00e5n 11.2):<\/p>\n<p>Innan n\u00e5gon SQL-sats k\u00f6rs markerar Oracle en implicit savepoint (inte tillg\u00e4nglig f\u00f6r dig). Om satsen misslyckas backar Oracle automatiskt tillbaka och returnerar den aktuella felkoden till SQLCODE i SQLCA. Till exempel, om en INSERT-sats orsakar ett fel genom att f\u00f6rs\u00f6ka s\u00e4tta in ett dubblettv\u00e4rde i ett unikt index, backas satsen tillbaka.<\/p>\n<p>Anropet f\u00f6r lagrad procedur fr\u00e5n klienten betraktas ocks\u00e5 och behandlas som en enda sats. S\u00e5ledes avslutas det f\u00f6rsta anropet f\u00f6r den lagrade proceduren framg\u00e5ngsrikt och s\u00e4tter in tre poster; det andra anropet f\u00f6r den lagrade proceduren avslutas med ett fel och backar den fj\u00e4rde posten som den har lyckats s\u00e4tta in; det tredje anropet avslutas med ett fel, <b>och i tabellen finns tre poster.<\/b>.<\/p>\n<h3>Hur m\u00e5nga rader kommer att finnas i tabellen som resultat av att k\u00f6ra f\u00f6ljande skript?<\/h3>\n<p><\/p>\n<pre><code class=\"sql\">create table t(i integer, constraint i_ch check (i &lt; 3));\n \nbegin\n    insert into t values (1);\n    insert into t values (null);\n    insert into t values (2);\n    insert into t values (null);\n    insert into t values (3);\n    insert into t values (null);\n    insert into t values (4);\n    insert into t values (null);\n    insert into t values (5);\nexception\n    when others then\n        dbms_output.put_line(&#039;Oops!&#039;);\nend;\n\/<\/code><\/pre>\n<p><\/p>\n<ul>\n<li>1<\/li>\n<li>2<\/li>\n<li>3<\/li>\n<li>4<\/li>\n<li>5<\/li>\n<li>6<\/li>\n<li>7<\/li>\n<\/ul>\n<p>\n<b class=\"spoiler_title\">Svar<\/b>Enligt Oracle-dokumentationen (citerad fr\u00e5n 11.2):<\/p>\n<p>En kontrollbegr\u00e4nsning l\u00e5ter dig specificera ett villkor som varje rad i tabellen m\u00e5ste uppfylla. F\u00f6r att uppfylla begr\u00e4nsningen m\u00e5ste varje rad i tabellen g\u00f6ra villkoret antingen SANT eller ok\u00e4nt (p\u00e5 grund av null). N\u00e4r Oracle utv\u00e4rderar ett villkor f\u00f6r en kontrollbegr\u00e4nsning f\u00f6r en specifik rad, refererar alla kolumnnamn i villkoret till kolumnv\u00e4rdena i den raden.<\/p>\n<p>S\u00e5ledes kommer v\u00e4rdet null att passera kontrollen, och det anonyma blocket kommer att k\u00f6ras fram till f\u00f6rs\u00f6ket att inf\u00f6ra v\u00e4rdet 3. D\u00e4refter kommer felhanteringsblocket att f\u00e5nga undantaget, det kommer inte att bli n\u00e5gon tillbakag\u00e5ng och <b>fyra rader kommer att f\u00f6rbli i tabellen<\/b> med v\u00e4rdena 1, null, 2 och \u00e5terigen null.<\/p>\n<h3>Vilka v\u00e4rdepar kommer att ta upp samma m\u00e4ngd utrymme i blocket?<\/h3>\n<p><\/p>\n<pre><code class=\"sql\">create table t (\n    a char(1 char),\n    b char(10 char),\n    c char(100 char),\n    i number(4),\n    j number(14),\n    k number(24),\n    x varchar2(1 char),\n    y varchar2(10 char),\n    z varchar2(100 char));\n \ninsert into t (a, b, i, j, x, y)\n    values ('Y', 'Vanya', 10, 10, 'D', 'Vanya');\n<\/code><\/pre>\n<p><\/p>\n<ul>\n<li>A och X<\/li>\n<li>B och Y<\/li>\n<li>C och K<\/li>\n<li>C och Z<\/li>\n<li>K och Z<\/li>\n<li>I och J<\/li>\n<li>J och X<\/li>\n<li>Alla angivna<\/li>\n<\/ul>\n<p>\n<b class=\"spoiler_title\">Svar<\/b>L\u00e5t oss ge utdrag fr\u00e5n dokumentationen (12.1.0.2) om lagring av olika datatyper i Oracle.<\/p>\n<p><b>CHAR Datatyp<\/b><br \/>\nCHAR-datatypen specificerar en teckenstr\u00e4ng med fast l\u00e4ngd i databasens teckenkodning. Du specificerar databasens teckenkodning n\u00e4r du skapar din databas. Oracle s\u00e4kerst\u00e4ller att alla v\u00e4rden som lagras i en CHAR-kolumn har den l\u00e4ngd som anges av storleken i den valda l\u00e4ngdsemantiken. Om du infogar ett v\u00e4rde som \u00e4r kortare \u00e4n kolumnens l\u00e4ngd, d\u00e5 fyller Oracle upp v\u00e4rdet med mellanslag till kolumnens l\u00e4ngd.<\/p>\n<p><b>VARCHAR2 Datatyp<\/b><br \/>\nVARCHAR2-datatypen specificerar en teckenstr\u00e4ng med variabel l\u00e4ngd i databasens teckenkodning. Du specificerar databasens teckenkodning n\u00e4r du skapar din databas. Oracle lagrar ett teckenv\u00e4rde i en VARCHAR2-kolumn exakt som du anger det, utan n\u00e5got mellanslagsfyllande, f\u00f6rutsatt att v\u00e4rdet inte \u00f6verskrider kolumnens l\u00e4ngd.<\/p>\n<p><b>NUMBER Datatyp<\/b><br \/>\nNUMBER-datatypen lagrar noll samt positiva och negativa fasta tal med absoluta v\u00e4rden fr\u00e5n 1.0 x 10-130 till men inte inklusive 1.0 x 10126. Om du anger ett aritmetiskt uttryck vars v\u00e4rde har ett absolut v\u00e4rde st\u00f6rre \u00e4n eller lika med 1.0 x 10126, d\u00e5 returnerar Oracle ett fel. Varje NUMBER-v\u00e4rde kr\u00e4ver fr\u00e5n 1 till 22 byte. Med detta i \u00e5tanke kan kolumnens storlek i byte f\u00f6r ett specifikt numeriskt datav\u00e4rde NUMBER(p), d\u00e4r p \u00e4r precisionen f\u00f6r ett givet v\u00e4rde, ber\u00e4knas med f\u00f6ljande formel: <i>ROUND((length(p)+s)\/2))+1<\/i> d\u00e4r s \u00e4r lika med noll om talet \u00e4r positivt, och s \u00e4r lika med 1 om talet \u00e4r negativt.<\/p>\n<p>Dessutom ska vi ta en utdrag ur dokumentationen om lagring av Null-v\u00e4rden.<\/p>\n<p>Ett null-v\u00e4rde \u00e4r avsaknaden av ett v\u00e4rde i en kolumn. Null-v\u00e4rden indikerar saknad, ok\u00e4nt eller ovidkommande data. Null-v\u00e4rden lagras i databasen om de ligger mellan kolumner med datav\u00e4rden. I dessa fall kr\u00e4ver de 1 byte f\u00f6r att lagra l\u00e4ngden p\u00e5 kolumnen (noll). Efterf\u00f6ljande null-v\u00e4rden i en rad kr\u00e4ver ingen lagring eftersom en ny radhuvud signalerar att de \u00e5terst\u00e5ende kolumnerna i den f\u00f6reg\u00e5ende raden \u00e4r null. Till exempel, om de tre sista kolumnerna i en tabell \u00e4r null, lagras ingen data f\u00f6r dessa kolumner.<\/p>\n<p>Baserat p\u00e5 dessa data bygger vi resonemang. Vi antar att databasen anv\u00e4nder kodningen AL32UTF8. I denna kodning kommer ryska bokst\u00e4ver att ta upp 2 byte.<\/p>\n<p>1) A \u0438 X, \u0437\u043d\u0430\u0447\u0435\u043d\u0438\u0435 \u043f\u043e\u043b\u044f a &#8216;Y&#8217; \u0437\u0430\u043d\u0438\u043c\u0430\u0435\u0442 1 \u0431\u0430\u0439\u0442, \u0437\u043d\u0430\u0447\u0435\u043d\u0438\u0435 \u043f\u043e\u043b\u044f x \u2018\u0414\u2019 \u2013 2 \u0431\u0430\u0439\u0442\u0430<br \/>\n2) B och Y, 'Vasya' i b kommer att fyllas ut med mellanslag upp till 10 tecken och ta 14 byte, 'Vasya' i d \u2013 kommer att ta 8 byte.<br \/>\n3) C och K. B\u00e5da f\u00e4lten har v\u00e4rdet NULL, efter dem finns betydelsefulla f\u00e4lt, s\u00e5 de tar upp 1 byte vardera.<br \/>\n4) C och Z. B\u00e5da f\u00e4lten har v\u00e4rdet NULL, men f\u00e4ltet Z \u00e4r det sista i tabellen, s\u00e5 det tar ingen plats (0 byte). F\u00e4lt C tar upp 1 byte.<br \/>\n5) K och Z. P\u00e5 samma s\u00e4tt som f\u00f6reg\u00e5ende fall. V\u00e4rdet i f\u00e4lt K tar upp 1 byte, i Z \u2013 0.<br \/>\n6) I och J. Enligt dokumentationen kommer b\u00e5da v\u00e4rdena att ta upp 2 byte. L\u00e4ngden ber\u00e4knas med formeln fr\u00e5n dokumentationen: round((1 + 0) \/ 2) + 1 = 1 + 1 = 2.<br \/>\n7) J och X. V\u00e4rdet i f\u00e4lt J tar upp 2 byte, v\u00e4rdet i f\u00e4lt X tar upp 2 byte.<\/p>\n<p><b>Sammanlagt, korrekta alternativ: C och K, I och J, J och X.<\/b><\/p>\n<p><\/p>\n<h3>Vad kommer clustering-faktorn f\u00f6r indexet T_I att vara ungef\u00e4r?<\/h3>\n<p><\/p>\n<pre><code class=\"sql\">create table t (i integer);\n \ninsert into t select rownum from dual connect by level &lt;= 10000;\n \ncreate index t_i on t(i);\n<\/code><\/pre>\n<p><\/p>\n<ul>\n<li>Cirka tiotal<\/li>\n<li>Cirka hundratal<\/li>\n<li>Cirka tusental<\/li>\n<li>Cirka tiotusental<\/li>\n<\/ul>\n<p>\n<b class=\"spoiler_title\">Svar<\/b>Enligt Oracle-dokumentationen (citeras fr\u00e5n 12.1):<\/p>\n<p>F\u00f6r ett B-tr\u00e4d index m\u00e4ter indexets clustering-faktor den fysiska grupperingen av rader i f\u00f6rh\u00e5llande till ett indexv\u00e4rde.<\/p>\n<p>Indexets clustering-faktor hj\u00e4lper optimeraren att avg\u00f6ra om en indexscanning eller en full tabellscanning \u00e4r mer effektiv f\u00f6r vissa fr\u00e5gor. En l\u00e5g clustering-faktor indikerar en effektiv indexscanning.<\/p>\n<p>En clustering-faktor som ligger n\u00e4ra antalet block i en tabell indikerar att raderna \u00e4r fysiskt ordnade i tabellblocken efter indexnyckeln. Om databasen g\u00f6r en full tabellscanning tenderar databasen att h\u00e4mta raderna i den ordning de lagras p\u00e5 disk sorterade efter indexnyckeln. En clustering-faktor som ligger n\u00e4ra antalet rader indikerar att raderna \u00e4r slumpm\u00e4ssigt spridda \u00f6ver databaskluster i f\u00f6rh\u00e5llande till indexnyckeln. Om databasen g\u00f6r en full tabellscanning h\u00e4mtar databasen inte rader i n\u00e5gon sorterad ordning efter denna indexnyckel.<\/p>\n<p>I detta fall \u00e4r data perfekt sorterade, s\u00e5 clustering-faktorn kommer att vara lika med eller n\u00e4ra antalet upptagna block i tabellen. F\u00f6r en standard blockstorlek p\u00e5 8 kilobyte kan man f\u00f6rv\u00e4nta sig att ett block rymmer cirka tusen smala nummerv\u00e4rden, s\u00e5 antalet block, och d\u00e4rmed clustering-faktorn, kommer att vara <b>cirka tiotal<\/b>.<\/p>\n<h3>Vid vilka v\u00e4rden av N kommer f\u00f6ljande skript att k\u00f6ras framg\u00e5ngsrikt i en vanlig databas med standardinst\u00e4llningar?<\/h3>\n<p><\/p>\n<pre><code class=\"sql\">create table t (\n    a varchar2(N char),\n    b varchar2(N char),\n    c varchar2(N char),\n    d varchar2(N char));\n \ncreate index t_i on t (a, b, c, d);\n<\/code><\/pre>\n<p><\/p>\n<ul>\n<li>100<\/li>\n<li>200<\/li>\n<li>400<\/li>\n<li>800<\/li>\n<li>1600<\/li>\n<li>3200<\/li>\n<li>6400<\/li>\n<\/ul>\n<p>\n<b class=\"spoiler_title\">Svar<\/b>Enligt Oracle-dokumentationen (citerad fr\u00e5n 11.2):<\/p>\n<p>Logiska datab gr\u00e4nser<\/p>\n<p><strong>Objekt<\/strong><br \/>\n<strong>Typ av begr\u00e4nsning<\/strong><br \/>\n<strong>Begr\u00e4nsningsv\u00e4rde<\/strong><\/p>\n<p>Index<br \/>\nTotal storlek av indexerat kolumn<br \/>\n75% av databasklusterstorleken minus viss overhead<\/p>\n<p>\nS\u00e5ledes f\u00e5r den totala storleken p\u00e5 de indexerade kolumnerna inte \u00f6verstiga 6 KB. Vad som h\u00e4nder d\u00e4rfter beror p\u00e5 den valda databaskodningen. F\u00f6r kodningen AL32UTF8 kan en symbol ta upp till 4 byte, vilket inneb\u00e4r att cirka 1500 symboler kan f\u00e5 plats i 6 kilobyte i det v\u00e4rsta fallet. D\u00e4rf\u00f6r kommer Oracle att f\u00f6rbjuda skapandet av ett index vid N = 400 (n\u00e4r nyckell\u00e4ngden i v\u00e4rsta fall kommer att vara 1600 symboler * 4 byte + l\u00e4ngden av rowid), medan <b>vid N = 200 (och mindre)<\/b> kan skapandet av indexet utf\u00f6ras utan problem.<\/p>\n<h3>INSERT-operat\u00f6ren med APPEND-hint \u00e4r avsedd f\u00f6r att ladda data i direktl\u00e4ge. Vad h\u00e4nder om den till\u00e4mpas p\u00e5 en tabell som har en trigger?<\/h3>\n<p><\/p>\n<ul>\n<li>Data kommer att laddas i direktl\u00e4ge, triggern aktiveras som den ska<\/li>\n<li>Data kommer att laddas i direktl\u00e4ge, men triggern kommer inte att utf\u00f6ras<\/li>\n<li>Data kommer att laddas i konventionellt l\u00e4ge, triggern aktiveras som den ska<\/li>\n<li>Data kommer att laddas i konventionellt l\u00e4ge, men triggern kommer inte att utf\u00f6ras<\/li>\n<li>Data kommer inte att laddas, ett fel kommer att registreras<\/li>\n<\/ul>\n<p>\n<b class=\"spoiler_title\">Svar<\/b>Rent tekniskt \u00e4r detta fr\u00e5ga om logik. F\u00f6r att hitta r\u00e4tt svar skulle jag f\u00f6resl\u00e5 f\u00f6ljande resonemangsmodell:<\/p>\n<ol>\n<li>Infogning i direktl\u00e4ge utf\u00f6rs genom att direkt bilda datablokkar, utan att g\u00e5 genom SQL-motorn, vilket m\u00f6jligg\u00f6r h\u00f6g hastighet. D\u00e4rf\u00f6r \u00e4r det mycket sv\u00e5rt att s\u00e4kerst\u00e4lla att triggern utf\u00f6rs, om det ens \u00e4r m\u00f6jligt, och det finns ingen mening med det, eftersom det \u00e4nd\u00e5 kraftigt skulle bromsa infogningen.<\/li>\n<li>Att triggern inte utf\u00f6rs kommer att leda till att tillst\u00e5ndet hos databasen som helhet (andra tabeller) kommer att bero p\u00e5 vilket l\u00e4ge dessa data har infogats. Detta skulle uppenbart underminera dataintegriteten och kan inte till\u00e4mpas som en l\u00f6sning i produktion.<\/li>\n<li>Of\u00f6rm\u00e5gan att utf\u00f6ra den beg\u00e4rda operationen betraktas generellt som ett fel. Men h\u00e4r b\u00f6r vi komma ih\u00e5g att APPEND \u00e4r en hint, och den allm\u00e4nna logiken med hints \u00e4r att de beaktas om det \u00e4r m\u00f6jligt; om inte, s\u00e5 utf\u00f6rs operat\u00f6ren utan att ta h\u00e4nsyn till hint.<\/li>\n<\/ol>\n<p>\nS\u00e5ledes \u00e4r det f\u00f6rv\u00e4ntade svaret - <b>data kommer att laddas i normalt (SQL) l\u00e4ge, triggern aktiveras.<\/b><\/p>\n<p>Enligt Oracle-dokumentationen (citerat fr\u00e5n 8.04):<\/p>\n<p>\u00d6vertr\u00e4delser av restriktionerna kommer att leda till att satsen k\u00f6rs sekventiellt, med den konventionella ins\u00e4ttningsv\u00e4gen, utan varningar eller felmeddelanden. Ett undantag \u00e4r restriktionen mot satser som kommer \u00e5t samma tabell mer \u00e4n en g\u00e5ng i en transaktion, vilket kan orsaka felmeddelanden.<br \/>\nTill exempel, om det finns triggar eller referentiell integritet p\u00e5 tabellen, kommer APPEND-hintet att ignoreras n\u00e4r du f\u00f6rs\u00f6ker anv\u00e4nda direktladdning INSERT (seriel eller parallell), liksom PARALLEL-hintet eller klausulen, om det finns n\u00e5got.<\/p>\n<h3>Vad h\u00e4nder n\u00e4r f\u00f6ljande skript k\u00f6rs?<\/h3>\n<p><\/p>\n<pre><code class=\"sql\">create table t(i integer not null primary key, j integer references t);\n \ncreate trigger t_a_i after insert on t for each row\ndeclare\n    pragma autonomous_transaction;\nbegin\n    insert into t values (:new.i + 1, :new.i);\n    commit;\nend;\n\/\n \ninsert into t values (1, null);\n<\/code><\/pre>\n<p><\/p>\n<ul>\n<li>Framg\u00e5ngsrik k\u00f6rning<\/li>\n<li>Misslyckande p\u00e5 grund av syntaxfel<\/li>\n<li>Fel relaterat till otill\u00e5ten autonom transaktion<\/li>\n<li>Fel relaterat till \u00f6verskridande av maximal anropsniv\u00e5<\/li>\n<li>Fel relaterat till en brytning av en utl\u00e4ndsk nyckel<\/li>\n<li>Fel relaterat till l\u00e5sningar<\/li>\n<\/ul>\n<p>\n<b class=\"spoiler_title\">Svar<\/b>Tabellen och triggarna skapas helt korrekt och denna operation b\u00f6r inte orsaka problem. Autonoma transaktioner i triggar \u00e4r ocks\u00e5 till\u00e5tna, annars skulle det vara om\u00f6jligt, till exempel loggning.<\/p>\n<p>Efter att den f\u00f6rsta raden infogats skulle den framg\u00e5ngsrika triggen leda till en andra infogning, vilket skulle orsaka att triggen k\u00f6rdes igen, infoga en tredje rad och s\u00e5 vidare tills kommandot misslyckade p\u00e5 grund av \u00f6verskridande av maximal anropsniv\u00e5. Emellertid intr\u00e4ffar en annan subtil punkt. Vid k\u00f6rning av triggen f\u00f6r den f\u00f6rsta infogade posten har commit \u00e4nnu inte utf\u00f6rts. D\u00e4rf\u00f6r f\u00f6rs\u00f6ker triggen, som arbetar i en autonom transaktion, att infoga en rad i tabellen som refererar till en \u00e4nnu icke-committad post. Detta leder till v\u00e4ntan (den autonoma transaktionen v\u00e4ntar p\u00e5 commit av huvudet f\u00f6r att f\u00f6rst\u00e5 om data kan infogas) och samtidigt v\u00e4ntar den huvudsakliga transaktionen p\u00e5 commit av den autonoma f\u00f6r att forts\u00e4tta arbetet efter triggen. <b>Det uppst\u00e5r en deadlock och som en f\u00f6ljd av detta avbryts den autonoma transaktionen p\u00e5 grund av l\u00e5sningar<\/b>.<\/p>\n<p class=\"for_users_only_msg\">Endast registrerade anv\u00e4ndare kan delta i omr\u00f6stningen. <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/auth\/login\/\">Logga in<\/a><\/noindex>, tack.<\/p>\n<h2 class=\"default-block__polling-title\">Var det sv\u00e5rt?<\/h2>\n<ul class=\"content-list content-list_polling\">\n<li class=\"content-list__item content-list__item_polling\">\n<p>                    Som tv\u00e5 fingrar, l\u00f6ste allt r\u00e4tt med en g\u00e5ng.<\/p>\n<\/li>\n<li class=\"content-list__item content-list__item_polling\">\n<p>                    Inte s\u00e4rskilt, jag gjorde fel p\u00e5 ett par fr\u00e5gor.<\/p>\n<\/li>\n<li class=\"content-list__item content-list__item_polling\">\n<p>                    Jag l\u00f6ste h\u00e4lften r\u00e4tt.<\/p>\n<\/li>\n<li class=\"content-list__item content-list__item_polling\">\n<p>                    Jag gissade svaret tv\u00e5 g\u00e5nger!<\/p>\n<\/li>\n<li class=\"content-list__item content-list__item_polling\">\n<p>                    Jag skriver i kommentarerna<\/p>\n<\/li>\n<\/ul>\n<p>    14 anv\u00e4ndare r\u00f6stade. 10 anv\u00e4ndare avstod.<br \/>\n<br \/>K\u00e4lla: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/sportmaster_lab\/blog\/459680\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041f\u0440\u0438\u0432\u0435\u0442! 24-25 \u0438\u044e\u043d\u044f \u0432 \u041d\u043e\u0432\u043e\u0441\u0438\u0431\u0438\u0440\u0441\u043a\u0435 \u043f\u0440\u043e\u0448\u043b\u0430 \u043a\u043e\u043d\u0444\u0435\u0440\u0435\u043d\u0446\u0438\u044f Highload++ Siberia 2019. \u041d\u0430\u0448\u0438 \u0440\u0435\u0431\u044f\u0442\u0430 \u0442\u043e\u0436\u0435 \u0442\u0430\u043c \u0431\u044b\u043b\u0438 \u0434\u043e\u043a\u043b\u0430\u0434\u043e\u043c \u00ab\u041a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440\u043d\u044b\u0435 \u0431\u0430\u0437\u044b Oracle (CDB\/PDB) \u0438 \u0438\u0445 \u043f\u0440\u0430\u043a\u0442\u0438\u0447\u0435\u0441\u043a\u043e\u0435 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u043d\u0438\u0435 \u0434\u043b\u044f \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u043a\u0438 \u041f\u041e\u00bb, \u043c\u044b \u0432\u044b\u043b\u043e\u0436\u0438\u043c \u0442\u0435\u043a\u0441\u0442\u043e\u0432\u0443\u044e \u0432\u0435\u0440\u0441\u0438\u044e \u043d\u0435\u043c\u043d\u043e\u0433\u043e \u043f\u043e\u0437\u0436\u0435. \u0411\u044b\u043b\u043e \u043a\u0440\u0443\u0442\u043e, \u0441\u043f\u0430\u0441\u0438\u0431\u043e olegbunin \u0437\u0430 \u043e\u0440\u0433\u0430\u043d\u0438\u0437\u0430\u0446\u0438\u044e, \u0430 \u0442\u0430\u043a\u0436\u0435 \u0432\u0441\u0435\u043c, \u043a\u0442\u043e \u043f\u0440\u0438\u0448\u0451\u043b. \u0412 \u044d\u0442\u043e\u043c \u043f\u043e\u0441\u0442\u0435 \u043c\u044b \u0445\u043e\u0442\u0435\u043b\u0438 \u0431\u044b \u043f\u043e\u0434\u0435\u043b\u0438\u0442\u044c\u0441\u044f \u0441 \u0432\u0430\u043c\u0438 \u0437\u0430\u0434\u0430\u0447\u0430\u043c\u0438, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":27053,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-36171","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.4 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u041f\u0440\u0438\u0432\u0435\u0442! 24-25 \u0438\u044e\u043d\u044f \u0432 \u041d\u043e\u0432\u043e\u0441\u0438\u0431\u0438\u0440\u0441\u043a\u0435 \u043f\u0440\u043e\u0448\u043b\u0430 \u043a\u043e\u043d\u0444\u0435\u0440\u0435\u043d\u0446\u0438\u044f Highload++ Siberia 2019.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/sv\/blog\/administrirovanie\/po-sledam-highload-siberia-2019-8-zadach-po-oracle\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.4\" \/>\n\t\t<meta property=\"og:locale\" content=\"sv_SE\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u041f\u043e \u0441\u043b\u0435\u0434\u0430\u043c Highload++ Siberia 2019 \u2014 8 \u0437\u0430\u0434\u0430\u0447 \u043f\u043e Oracle | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u041f\u0440\u0438\u0432\u0435\u0442! 24-25 \u0438\u044e\u043d\u044f \u0432 \u041d\u043e\u0432\u043e\u0441\u0438\u0431\u0438\u0440\u0441\u043a\u0435 \u043f\u0440\u043e\u0448\u043b\u0430 \u043a\u043e\u043d\u0444\u0435\u0440\u0435\u043d\u0446\u0438\u044f Highload++ Siberia 2019.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/sv\/blog\/administrirovanie\/po-sledam-highload-siberia-2019-8-zadach-po-oracle\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T19:09:58+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T19:09:58+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Efter Highload++ Siberia 2019 - 8 uppgifter om Oracle | ProHoster","description":"Hej! Den 24-25 juni h\u00f6lls konferensen Highload++ Siberia 2019 i Novosibirsk.","canonical_url":"https:\/\/prohoster.info\/sv\/blog\/administrirovanie\/po-sledam-highload-siberia-2019-8-zadach-po-oracle","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"sv_SE","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041f\u043e \u0441\u043b\u0435\u0434\u0430\u043c Highload++ Siberia 2019 \u2014 8 \u0437\u0430\u0434\u0430\u0447 \u043f\u043e Oracle | ProHoster","og:description":"\u041f\u0440\u0438\u0432\u0435\u0442! 24-25 \u0438\u044e\u043d\u044f \u0432 \u041d\u043e\u0432\u043e\u0441\u0438\u0431\u0438\u0440\u0441\u043a\u0435 \u043f\u0440\u043e\u0448\u043b\u0430 \u043a\u043e\u043d\u0444\u0435\u0440\u0435\u043d\u0446\u0438\u044f Highload++ Siberia 2019.","og:url":"https:\/\/prohoster.info\/sv\/blog\/administrirovanie\/po-sledam-highload-siberia-2019-8-zadach-po-oracle","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:09:58+00:00","article:modified_time":"2019-10-31T19:09:58+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"36171","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-22 02:18:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 01:49:43","updated":"2026-01-22 02:18:19","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/posts\/36171","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/comments?post=36171"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/posts\/36171\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/media\/27053"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/media?parent=36171"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/categories?post=36171"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/tags?post=36171"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}