{"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\/nl\/blog\/administrirovanie\/po-sledam-highload-siberia-2019-8-zadach-po-oracle","title":{"rendered":"Naar aanleiding van Highload++ Siberi\u00eb 2019 - 8 taken over Oracle","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Hallo!<\/p>\n<p>Op 24-25 juni vond in Novosibirsk de conferentie Highload++ Siberia 2019 plaats. Onze mensen waren ook aanwezig. <noindex><a rel=\"nofollow\" href=\"https:\/\/www.highload.ru\/siberia\/2019\/abstracts\/5211\">presentatie<\/a><\/noindex> \u00abContainer databases van Oracle (CDB\/PDB) en hun praktische toepassing voor softwareontwikkeling\u00bb, we zullen de tekstversie iets later publiceren. Het was geweldig, bedankt. <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/users\/olegbunin\/\" class=\"user_link\">olegbunin<\/a><\/noindex> voor de organisatie, en ook voor iedereen die gekomen is. <\/p>\n<p><img decoding=\"async\" alt=\"Naar aanleiding van Highload++ Siberi\u00eb 2019 - 8 taken over Oracle\" src=\"\/wp-content\/uploads\/2019\/07\/27f4707d4bb5968eaaa5c4748ff467cd.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nIn deze post willen we graag de opdrachten delen die we bij onze stand hadden, zodat je je kennis van Oracle kunt testen. Onder de omslag \u2014 8 opdrachten, antwoordmogelijkheden en uitleg.<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h3>Wat is de maximale waarde van de sequence die we zullen zien na het uitvoeren van het volgende script?<\/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>Geen enkele, er zal een foutmelding zijn.<\/li>\n<\/ul>\n<p>\n<b class=\"spoiler_title\">Antwoord<\/b>Volgens de documentatie van Oracle (geciteerd uit 8.1.6):<br \/>\nBinnen een enkele SQL-instructie verhoogt Oracle de sequence slechts \u00e9\u00e9n keer per rij. Als een instructie meer dan \u00e9\u00e9n verwijzing naar NEXTVAL voor een sequence bevat, verhoogt Oracle de sequence \u00e9\u00e9n keer en retourneert dezelfde waarde voor alle vermeldingen van NEXTVAL. Als een instructie verwijzingen naar zowel CURRVAL als NEXTVAL bevat, verhoogt Oracle de sequence en retourneert dezelfde waarde voor zowel CURRVAL als NEXTVAL, ongeacht hun volgorde binnen de instructie.<\/p>\n<p>Dus, <b>de maximale waarde zal overeenkomen met het aantal rijen, dat wil zeggen 5.<\/b>.<\/p>\n<h3>Hoeveel rijen zullen er in de tabel zijn na het uitvoeren van het volgende script?<\/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\">Antwoord<\/b>Volgens de documentatie van Oracle (geciteerd uit 11.2):<\/p>\n<p>Voordat een SQL-instructie wordt uitgevoerd, markeert Oracle een impliciete savepoint (niet beschikbaar voor jou). Als de instructie mislukt, wordt deze automatisch teruggedraaid en retourneert Oracle de toepasselijke foutcode aan SQLCODE in de SQLCA. Bijvoorbeeld, als een INSERT-instructie een fout veroorzaakt door een duplicaatwaarde in een unieke index in te voegen, wordt de instructie teruggedraaid.<\/p>\n<p>Een aanroep van een opgeslagen procedure vanaf de client wordt ook behandeld als een enkele instructie. Dus de eerste aanroep van de opgeslagen procedure eindigt succesvol en voegt drie records in; de tweede aanroep van de opgeslagen procedure eindigt met een fout en draait het vierde record terug dat erin was toegevoegd; de derde aanroep eindigt met een fout, <b>en er blijven drie records in de tabel over.<\/b>.<\/p>\n<h3>Hoeveel rijen zullen er in de tabel zijn na het uitvoeren van het volgende script?<\/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\">Antwoord<\/b>Volgens de documentatie van Oracle (geciteerd uit 11.2):<\/p>\n<p>Een checkbeperking laat je een voorwaarde specificeren die elke rij in de tabel moet voldoen. Om aan de beperking te voldoen, moet elke rij in de tabel de voorwaarde ofwel WAAR of onbekend (door een null) maken. Wanneer Oracle een checkbeperkingsvoorwaarde voor een specifieke rij evalueert, verwijzen kolomnamen in de voorwaarde naar de kolomwaarden in die rij.<\/p>\n<p>Daarom zal de null-waarde de controle doorstaan, en het anonieme blok zal succesvol worden uitgevoerd tot het moment dat geprobeerd wordt de waarde 3 in te voegen. Daarna zal het foutafhandelingsblok de uitzondering opvangen, wordt er geen rollback uitgevoerd, en <b>zullen er vier rijen in de tabel blijven.<\/b> met de waarden 1, null, 2 en opnieuw null.<\/p>\n<h3>Welke paren waarden zullen dezelfde hoeveelheid ruimte in het blok innemen?<\/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', 'Vasya', 10, 10, 'D', 'Vasya');\n<\/code><\/pre>\n<p><\/p>\n<ul>\n<li>A en X<\/li>\n<li>B en Y<\/li>\n<li>C en K<\/li>\n<li>C en Z<\/li>\n<li>K en Z<\/li>\n<li>I en J<\/li>\n<li>J en X<\/li>\n<li>Alle bovenstaande<\/li>\n<\/ul>\n<p>\n<b class=\"spoiler_title\">Antwoord<\/b>Laten we enkele uittreksels uit de documentatie (12.1.0.2) over het opslaan van verschillende datatypes in Oracle weergeven.<\/p>\n<p><b>CHAR Gegevenstype<\/b><br \/>\nHet CHAR gegevenstype specificeert een karakterreeks met vaste lengte in de databasetekenset. Je specificeert de databasetekenset wanneer je je database maakt. Oracle zorgt ervoor dat alle waarden die in een CHAR-kolom zijn opgeslagen, de lengte hebben die is opgegeven door de grootte in de geselecteerde lengte-semantiek. Als je een waarde invoegt die korter is dan de kolomlengte, voegt Oracle zwarte spaties toe aan de waarde tot de kolomlengte.<\/p>\n<p><b>VARCHAR2 Gegevenstype<\/b><br \/>\nHet VARCHAR2 gegevenstype specificeert een karakterreeks met variabele lengte in de databasetekenset. Je specificeert de databasetekenset wanneer je je database maakt. Oracle slaat een tekenwaarde in een VARCHAR2-kolom precies op zoals je die opgeeft, zonder extra spaties, op voorwaarde dat de waarde de kolomlengte niet overschrijdt.<\/p>\n<p><b>NUMBER Gegevenstype<\/b><br \/>\nHet NUMBER gegevenstype slaat nul op, evenals positieve en negatieve vaste getallen met absolute waarden van 1.0 x 10-130 tot maar niet inclusief 1.0 x 10126. Als je een wiskundige uitdrukking opgeeft waarvan de waarde een absolute waarde heeft die groter is dan of gelijk is aan 1.0 x 10126, dan geeft Oracle een foutmelding. Elke NUMBER-waarde vereist tussen 1 en 22 bytes. Houd hier rekening mee: de kolomgrootte in bytes voor een bepaalde numerieke datavalue NUMBER(p), waarbij p de precisie van een gegeven waarde is, kan worden berekend met de volgende formule: <i>ROUND((length(p)+s)\/2))+1<\/i> waarbij s gelijk is aan nul als het getal positief is, en s gelijk is aan 1 als het getal negatief is.<\/p>\n<p>Bovendien, laten we een uittreksel uit de documentatie over het opslaan van Null-waarden bekijken.<\/p>\n<p>Een null is de afwezigheid van een waarde in een kolom. Nulls geven ontbrekende, onbekende of niet-toepasbare gegevens aan. Nulls worden in de database opgeslagen als ze vallen tussen kolommen met gegevenswaarden. In deze gevallen is 1 byte nodig om de lengte van de kolom op te slaan (nul). Achterlopende nulls in een rij vereisen geen opslag omdat een nieuwe rijheader aangeeft dat de resterende kolommen in de vorige rij null zijn. Bijvoorbeeld, als de laatste drie kolommen van een tabel null zijn, worden er geen gegevens opgeslagen voor deze kolommen.<\/p>\n<p>Op basis van deze gegevens bouwen we redeneringen op. We veronderstellen dat de DB gebruikmaakt van de codering AL32UTF8. In deze codering nemen Russische letters 2 bytes in beslag.<\/p>\n<p>1) A en X, de waarde van het veld a \u2018Y\u2019 neemt 1 byte in, de waarde van het veld x \u2018\u0414\u2019 \u2013 2 bytes<br \/>\n2) B en Y, \u2018Vasya\u2019 in b zal worden aangevuld met spaties tot 10 tekens en zal 14 bytes innemen, \u2018Vasya\u2019 in d \u2013 zal 8 bytes innemen.<br \/>\n3) C en K. Beide velden hebben de waarde NULL, er zijn significante velden na, dus nemen ze elk 1 byte in.<br \/>\n4) C en Z. Beide velden hebben de waarde NULL, maar veld Z is het laatste in de tabel, dus neemt geen ruimte in (0 bytes). Veld C neemt 1 byte in.<br \/>\n5) K en Z. Vergelijkbaar met de vorige geval. De waarde in veld K neemt 1 byte in, in Z \u2013 0.<br \/>\n6) I en J. Volgens de documentatie zullen beide waarden elk 2 bytes innemen. De lengte wordt berekend volgens de formule uit de documentatie: round((1 + 0)\/2) + 1 = 1 + 1 = 2.<br \/>\n7) J en X. De waarde in veld J neemt 2 bytes in, de waarde in veld X neemt 2 bytes in.<\/p>\n<p><b>Samenvattend, de juiste combinaties zijn: C en K, I en J, J en X.<\/b><\/p>\n<p><\/p>\n<h3>Wat zal ongeveer de clustering factor van de index T_I zijn?<\/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>Enkele tientallen<\/li>\n<li>Enkele honderden<\/li>\n<li>Enkele duizenden<\/li>\n<li>Enkele tienduizenden<\/li>\n<\/ul>\n<p>\n<b class=\"spoiler_title\">Antwoord<\/b>Volgens de Oracle-documentatie (geciteerd uit 12.1):<\/p>\n<p>Voor een B-tree index meet de index clustering factor de fysieke groepering van rijen in relatie tot een indexwaarde.<\/p>\n<p>De index clustering factor helpt de optimizer te beslissen of een indexscan of een volledige tabelscan effici\u00ebnter is voor bepaalde queries. Een lage clustering factor geeft aan dat een indexscan effici\u00ebnt is.<\/p>\n<p>Een clustering factor die dicht bij het aantal blokken in een tabel ligt, geeft aan dat de rijen fysiek zijn geordend in de tabelblokken volgens de index sleutel. Als de database een volledige tabelscan uitvoert, dan haalt de database de rijen op zoals ze op schijf zijn opgeslagen, gesorteerd op de index sleutel. Een clustering factor die dicht bij het aantal rijen ligt, geeft aan dat de rijen willekeurig verdeeld zijn over de databaseblokken in relatie tot de index sleutel. Als de database een volledige tabelscan uitvoert, zal de database rijen niet in een gesorteerde volgorde ophalen volgens deze index sleutel.<\/p>\n<p>In dit geval zijn de gegevens perfect gesorteerd, dus zal de clustering factor gelijk zijn aan of dicht bij het aantal bezette blokken in de tabel. Voor een standaard blokgrootte van 8 kilobyte kan worden verwacht dat er ongeveer duizend smalle numerieke waarden per blok passen, dus het aantal blokken, en als gevolg daarvan de clustering factor zal <b>enkele tientallen zijn.<\/b>.<\/p>\n<h3>Bij welke waarden van N zal het volgende script succesvol worden uitgevoerd in een normale database met standaardinstellingen?<\/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\">Antwoord<\/b>Volgens de documentatie van Oracle (geciteerd uit 11.2):<\/p>\n<p>Logische Database Limieten<\/p>\n<p><strong>Item<\/strong><br \/>\n<strong>Type Limiet<\/strong><br \/>\n<strong>Limiet Waarde<\/strong><\/p>\n<p>Indexen<br \/>\nTotale grootte van ge\u00efndexeerde kolom<br \/>\n75% van de databaseblokgrootte minus wat overhead<\/p>\n<p>\nHet totale formaat van de ge\u00efndexeerde kolommen mag niet meer dan 6 KB bedragen. Wat verder gebeurt, hangt af van de gekozen datacodering. Voor de codering AL32UTF8 kan \u00e9\u00e9n teken maximaal 4 bytes innemen, waardoor in het slechtste geval ongeveer 1500 tekens in 6 kilobyte passen. Om deze reden zal Oracle het cre\u00ebren van een index verbieden bij N = 400 (wanneer de sleutel in het slechtste geval 1600 tekens * 4 bytes + de lengte van rowid zal zijn), terwijl <b>bij N = 200 (en minder)<\/b> het cre\u00ebren van een index probleemloos zal verlopen.<\/p>\n<h3>De INSERT-opdracht met de hint APPEND is bedoeld voor het laden van gegevens in de directe modus. Wat gebeurt er als deze wordt toegepast op een tabel met een trigger?<\/h3>\n<p><\/p>\n<ul>\n<li>Gegevens worden in directe modus geladen, de trigger zal worden geactiveerd zoals het hoort.<\/li>\n<li>Gegevens worden in directe modus geladen, maar de trigger zal niet worden uitgevoerd.<\/li>\n<li>Gegevens worden in de conventionele modus geladen, de trigger zal worden geactiveerd zoals het hoort.<\/li>\n<li>Gegevens worden in de conventionele modus geladen, maar de trigger zal niet worden uitgevoerd.<\/li>\n<li>Gegevens worden niet geladen, er zal een fout worden vastgelegd.<\/li>\n<\/ul>\n<p>\n<b class=\"spoiler_title\">Antwoord<\/b>In principe is dit meer een vraag van logica. Voor het vinden van het juiste antwoord zou ik het volgende denkmodel voorstellen:<\/p>\n<ol>\n<li>Inserting in directe modus gebeurt door het direct genereren van een gegevensblok, om de SQL-engine heen, wat hoge snelheid biedt. Het is daardoor zeer moeilijk, indien \u00fcberhaupt mogelijk, om de trigger uit te voeren, en het heeft geen zin omdat het de insert alsnog aanzienlijk zou vertragen.<\/li>\n<li>Het niet uitvoeren van de trigger zou ertoe leiden dat, bij gelijke gegevens in de tabel, de staat van de database als geheel (andere tabellen) afhankelijk zou zijn van de specifieke modus waarin deze gegevens zijn ingevoegd. Dit zou duidelijk de dataconsistentie aantasten en kan niet worden toegepast als oplossing in productie.<\/li>\n<li>De onmogelijkheid om de gevraagde operatie uit te voeren, wordt in het algemeen opgevat als een fout. Maar hier moet men zich herinneren dat APPEND een hint is, en de algemene logica van hints is dat ze worden in overweging genomen als dat mogelijk is; als dit niet het geval is, wordt de operator uitgevoerd zonder rekening te houden met de hint.<\/li>\n<\/ol>\n<p>\nDus, het verwachte antwoord is: <b>gegevens worden geladen in de normale (SQL) modus, de trigger zal worden geactiveerd.<\/b><\/p>\n<p>Volgens de documentatie van Oracle (citaat uit 8.04):<\/p>\n<p>Overtredingen van de beperkingen zullen ervoor zorgen dat de verklaring sequentieel wordt uitgevoerd, met gebruik van het conventionele invoerpad, zonder waarschuwingen of foutmeldingen. Een uitzondering is de beperking op verklaringen die dezelfde tabel meer dan eens binnen een transactie benaderen, wat foutmeldingen kan veroorzaken.<br \/>\nBijvoorbeeld, als er triggers of referenti\u00eble integriteit op de tabel aanwezig zijn, dan zal de APPEND-hint worden genegeerd wanneer je probeert een directe INSERT (serieel of parallel) te gebruiken, net als de PARALLEL-hint of clausule, indien aanwezig.<\/p>\n<h3>Wat gebeurt er bij het uitvoeren van het volgende script?<\/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>Succesvolle uitvoering<\/li>\n<li>Fout door een syntaxisfout<\/li>\n<li>Fout gerelateerd aan de ongeldigheid van de autonome transactie<\/li>\n<li>Fout gerelateerd aan het overschrijden van de maximale diepte van aanroepen<\/li>\n<li>Fout gerelateerd aan de schending van de buitenlandse sleutel<\/li>\n<li>Fout gerelateerd aan vergrendelingen<\/li>\n<\/ul>\n<p>\n<b class=\"spoiler_title\">Antwoord<\/b>De tabel en trigger worden volledig correct aangemaakt en deze operatie zou geen problemen moeten veroorzaken. Autonome transacties in de trigger zijn ook toegestaan, anders zou het bijvoorbeeld onmogelijk zijn om te loggen.<\/p>\n<p>Na de invoer van de eerste rij zou de succesvolle activering van de trigger leiden tot de invoer van de tweede rij, waardoor de trigger opnieuw zou afgaan, de derde rij zou invoegen en ga zo maar door totdat de instructie zou falen vanwege het overschrijden van de maximale diepte van aanroepen. Er is echter nog een subtiele kwestie. Op het moment dat de trigger voor de eerste ingevoerde record wordt uitgevoerd, is de commit nog niet uitgevoerd. Daarom probeert de trigger, die in een autonome transactie werkt, een rij in de tabel in te voegen die een verwijzing heeft naar een nog niet gecommitteerde record via de buitenlandse sleutel. Dit leidt tot een afwachting (de autonome transactie wacht op de commit van de hoofdtransactie om te begrijpen of de gegevens kunnen worden ingevoegd) en tegelijkertijd wacht de hoofdtransactie op de commit van de autonome transactie om de werkzaamheden na de trigger voort te zetten. <b>Er ontstaat een deadlock en als gevolg daarvan wordt de autonome transactie be\u00ebindigd vanwege vergrendelingsproblemen.<\/b>.<\/p>\n<p class=\"for_users_only_msg\">Alleen geregistreerde gebruikers kunnen deelnemen aan de enqu\u00eate. <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/auth\/login\/\">Log in<\/a><\/noindex>, alstublieft.<\/p>\n<h2 class=\"default-block__polling-title\">Was het moeilijk?<\/h2>\n<ul class=\"content-list content-list_polling\">\n<li class=\"content-list__item content-list__item_polling\">\n<p>                    Als twee vingers, heb alles meteen goed opgelost.<\/p>\n<\/li>\n<li class=\"content-list__item content-list__item_polling\">\n<p>                    Niet echt, ik vergiste me in een paar vragen.<\/p>\n<\/li>\n<li class=\"content-list__item content-list__item_polling\">\n<p>                    Ik had de helft goed opgelost.<\/p>\n<\/li>\n<li class=\"content-list__item content-list__item_polling\">\n<p>                    Ik heb twee keer het juiste antwoord geraden!<\/p>\n<\/li>\n<li class=\"content-list__item content-list__item_polling\">\n<p>                    Ik zal in de reacties schrijven<\/p>\n<\/li>\n<\/ul>\n<p>    14 gebruikers stemden, 10 gebruikers onthielden zich.<br \/>\n<br \/>Bron: <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.3 - 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\/nl\/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.3\" \/>\n\t\t<meta property=\"og:locale\" content=\"nl_NL\" \/>\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\/nl\/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\udd47Op de voet van Highload++ Siberia 2019 \u2014 8 vragen over Oracle | ProHoster","description":"Hallo! Van 24-25 juni vond de Highload++ Siberia 2019-conferentie in Novosibirsk plaats.","canonical_url":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/po-sledam-highload-siberia-2019-8-zadach-po-oracle","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"nl_NL","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\/nl\/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\/nl\/wp-json\/wp\/v2\/posts\/36171","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/comments?post=36171"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts\/36171\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media\/27053"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media?parent=36171"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/categories?post=36171"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/tags?post=36171"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}