{"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\/da\/blog\/administrirovanie\/po-sledam-highload-siberia-2019-8-zadach-po-oracle","title":{"rendered":"I k\u00f8lvandet p\u00e5 Highload++ Siberia 2019 - 8 opgaver om Oracle","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Hej!<\/p>\n<p>Den 24-25 juni fandt konferencen Highload++ Siberia 2019 sted i Novosibirsk. Vores team var ogs\u00e5 der. <noindex><a rel=\"nofollow\" href=\"https:\/\/www.highload.ru\/siberia\/2019\/abstracts\/5211\">pr\u00e6sentationen<\/a><\/noindex> \u00abOracle Container Databases (CDB\/PDB) og deres praktiske anvendelse til softwareudvikling\u00bb, vi vil dele den skriftlige version lidt senere. Det var fantastisk, tak. <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/users\/olegbunin\/\" class=\"user_link\">olegbunin<\/a><\/noindex> for organiseringen, og til alle der kom. <\/p>\n<p><img decoding=\"async\" alt=\"I k\u00f8lvandet p\u00e5 Highload++ Siberia 2019 - 8 opgaver om Oracle\" src=\"\/wp-content\/uploads\/2019\/07\/27f4707d4bb5968eaaa5c4748ff467cd.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nI dette indl\u00e6g vil vi gerne dele de opgaver, som vi havde p\u00e5 vores stand, s\u00e5 du kan teste din viden om Oracle. Under indl\u00e6gget - 8 opgaver, svarmuligheder og forklaring.<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h3>Hvad er den maksimale v\u00e6rdi for sekvensen, vi ser som resultat af k\u00f8rsel af det f\u00f8lgende 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>Ingen, der vil opst\u00e5 en fejl.<\/li>\n<\/ul>\n<p>\n<b class=\"spoiler_title\">Svar<\/b>If\u00f8lge Oracle-dokumentationen (citeret fra 8.1.6):<br \/>\nInden for en enkelt SQL-s\u00e6tning vil Oracle kun \u00f8ge sekvensen \u00e9n gang pr. r\u00e6kke. Hvis en s\u00e6tning indeholder mere end \u00e9n reference til NEXTVAL for en sekvens, \u00f8ger Oracle sekvensen \u00e9n gang og returnerer den samme v\u00e6rdi for alle forekomster af NEXTVAL. Hvis en s\u00e6tning indeholder referencer til b\u00e5de CURRVAL og NEXTVAL, \u00f8ger Oracle sekvensen og returnerer den samme v\u00e6rdi for b\u00e5de CURRVAL og NEXTVAL, uanset deres r\u00e6kkef\u00f8lge i s\u00e6tningen.<\/p>\n<p>Derfor <b>vil den maksimale v\u00e6rdi svare til antallet af r\u00e6kker, alts\u00e5 5.<\/b>.<\/p>\n<h3>Hvor mange r\u00e6kker vil der v\u00e6re i tabellen som resultat af k\u00f8rsel af det f\u00f8lgende 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\">Svar<\/b>If\u00f8lge Oracle-dokumentationen (citeret fra 11.2):<\/p>\n<p>F\u00f8r enhver SQL-erkl\u00e6ring udf\u00f8res, markerer Oracle en implicit gemmepunkt (ikke tilg\u00e6ngeligt for dig). Hvis erkl\u00e6ringen mislykkes, rulles den automatisk tilbage, og en g\u00e6ldende fejlkode returneres til SQLCODE i SQLCA. For eksempel, hvis en INSERT-erkl\u00e6ring for\u00e5rsager en fejl ved at fors\u00f8ge at inds\u00e6tte en duplikeret v\u00e6rdi i et unikt indeks, rulles erkl\u00e6ringen tilbage.<\/p>\n<p>Kaldet til den lagrede procedure fra klienten betragtes ogs\u00e5 og behandles som en single statement. Derfor afsluttes det f\u00f8rste kald til proceduren tilfredsstillende og inds\u00e6tter tre r\u00e6kker; det andet kald til proceduren afsluttes med en fejl og ruller den fjerde r\u00e6kke tilbage, som den n\u00e5ede at inds\u00e6tte; det tredje kald mislykkes med en fejl, <b>og der er tre r\u00e6kker i tabellen.<\/b>.<\/p>\n<h3>Hvor mange r\u00e6kker vil der v\u00e6re i tabellen som resultat af k\u00f8rsel af det f\u00f8lgende 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;Ups!&#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>If\u00f8lge Oracle-dokumentationen (citeret fra 11.2):<\/p>\n<p>En checkbegr\u00e6nsning giver dig mulighed for at angive en betingelse, som hver r\u00e6kke i tabellen skal opfylde. For at opfylde begr\u00e6nsningen skal hver r\u00e6kke i tabellen g\u00f8re betingelsen enten SAND eller ukendt (p\u00e5 grund af en null). N\u00e5r Oracle evaluerer en checkbegr\u00e6nsningsbetingelse for en bestemt r\u00e6kke, henviser eventuelle kolonnenavne i betingelsen til kolonnev\u00e6rdierne i den r\u00e6kke.<\/p>\n<p>Dermed vil null-v\u00e6rdien best\u00e5 kontrollen, og den anonyme blok vil blive udf\u00f8rt med succes, indtil der pr\u00f8ves at inds\u00e6tte v\u00e6rdien 3. Efter dette vil blokken for fejlh\u00e5ndtering neutralisere undtagelsen, der ikke vil f\u00f8re til noget rollback, og <b>der vil forblive fire r\u00e6kker i tabellen<\/b> med v\u00e6rdierne 1, null, 2 og igen null.<\/p>\n<h3>Hvilke v\u00e6rdi-par vil optage samme plads i blokken?<\/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 og X<\/li>\n<li>B og Y<\/li>\n<li>C og K<\/li>\n<li>C og Z<\/li>\n<li>K og Z<\/li>\n<li>I og J<\/li>\n<li>J og X<\/li>\n<li>Alle de n\u00e6vnte<\/li>\n<\/ul>\n<p>\n<b class=\"spoiler_title\">Svar<\/b>Lad os se p\u00e5 uddrag fra dokumentationen (12.1.0.2) om lagring af forskellige datatyper i Oracle.<\/p>\n<p><b>CHAR Datatype<\/b><br \/>\nCHAR-datatypen angiver en fast l\u00e6ngde tegnstreng i database tegns\u00e6ttet. Du specificerer database tegns\u00e6ttet, n\u00e5r du opretter din database. Oracle sikrer, at alle v\u00e6rdier, der opbevares i en CHAR-kolonne, har den l\u00e6ngde, som er angivet af st\u00f8rrelsen i det valgte l\u00e6ngdesemantik. Hvis du inds\u00e6tter en v\u00e6rdi, der er kortere end kolonnens l\u00e6ngde, s\u00e5 vil Oracle tilf\u00f8je mellemrum til v\u00e6rdien for at n\u00e5 kolonnens l\u00e6ngde.<\/p>\n<p><b>VARCHAR2 Datatype<\/b><br \/>\nVARCHAR2-datatypen angiver en variabel l\u00e6ngde tegnstreng i database tegns\u00e6ttet. Du specificerer database tegns\u00e6ttet, n\u00e5r du opretter din database. Oracle opbevarer en tegnv\u00e6rdi i en VARCHAR2-kolonne n\u00f8jagtigt som du specificerer den, uden nogen mellemrumspadning, forudsat at v\u00e6rdien ikke overstiger kolonnens l\u00e6ngde.<\/p>\n<p><b>NUMBER Datatype<\/b><br \/>\nNUMBER-datatypen opbevarer nul s\u00e5vel som positive og negative faste tal med absolutte v\u00e6rdier fra 1.0 x 10-130 til men ikke inklusive 1.0 x 10126. Hvis du angiver et aritmetisk udtryk, hvis v\u00e6rdi har en absolut v\u00e6rdi st\u00f8rre end eller lig med 1.0 x 10126, returnerer Oracle en fejl. Hver NUMBER v\u00e6rdi kr\u00e6ver fra 1 til 22 byte. Tag dette i betragtning, kan kolonnens st\u00f8rrelse i byte for et givet numerisk datav\u00e6rdi NUMBER(p), hvor p er pr\u00e6cisionen af en given v\u00e6rdi, beregnes ved hj\u00e6lp af f\u00f8lgende formel: <i>ROUND((length(p)+s)\/2))+1<\/i> hvor s er lig med nul, hvis tallet er positivt, og s er lig med 1, hvis tallet er negativt.<\/p>\n<p>Desuden lad os tage et uddrag fra dokumentationen om opbevaring af null-v\u00e6rdier.<\/p>\n<p>En null er frav\u00e6ret af en v\u00e6rdi i en kolonne. Nuller indikerer manglende, ukendt eller ikke-anvendelige data. Nuller opbevares i databasen, hvis de falder mellem kolonner med datav\u00e6rdier. I disse tilf\u00e6lde kr\u00e6ver de 1 byte til at opbevare l\u00e6ngden af kolonnen (nul). Efterf\u00f8lgende nuller i en r\u00e6kke kr\u00e6ver ingen opbevaring, fordi en ny r\u00e6kkeheader signalerer, at de resterende kolonner i den forrige r\u00e6kke er null. For eksempel, hvis de sidste tre kolonner i en tabel er null, s\u00e5 opbevares der ingen data for disse kolonner.<\/p>\n<p>Baseret p\u00e5 disse data opbygger vi vores r\u00e6sonnering. Antager, at databasen bruger kodningen AL32UTF8. I denne kodning vil russiske bogstaver optage 2 byte.<\/p>\n<p>1) A og X, v\u00e6rdien af feltet a &#8216;Y&#8217; optager 1 byte, v\u00e6rdien af feltet x \u2018\u0414\u2019 \u2013 2 bytes<br \/>\n2) B og Y, \u2018Vasya\u2019 i b vil blive udvidet med mellemrum op til 10 tegn og vil tage 14 byte, \u2018Vasya\u2019 i d \u2013 vil tage 8 byte.<br \/>\n3) C og K. Begge felter har v\u00e6rdien NULL, efter dem er der meningsfulde felter, derfor tager de hver 1 byte.<br \/>\n4) C og Z. Begge felter har v\u00e6rdien NULL, men felt Z \u2013 er det sidste i tabellen, derfor optager det ikke plads (0 byte). Felt C tager 1 byte.<br \/>\n5) K og Z. Ligner den foreg\u00e5ende situation. V\u00e6rdien i felt K tager 1 byte, i Z \u2013 0.<br \/>\n6) I og J. If\u00f8lge dokumentationen vil begge v\u00e6rdier tage 2 byte. L\u00e6ngden beregnes efter formlen fra dokumentationen: round((1 + 0) \/ 2) + 1 = 1 + 1 = 2.<br \/>\n7) J og X. V\u00e6rdien i felt J vil tage 2 byte, v\u00e6rdien i felt X vil tage 2 byte.<\/p>\n<p><b>I alt, de korrekte muligheder: C og K, I og J, J og X.<\/b><\/p>\n<p><\/p>\n<h3>Hvad vil clustering factor omtrent v\u00e6re for indekset T_I?<\/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>Omkring dages<\/li>\n<li>Omkring hundrede<\/li>\n<li>Omkring tusinde<\/li>\n<li>Omkring titusinde<\/li>\n<\/ul>\n<p>\n<b class=\"spoiler_title\">Svar<\/b>If\u00f8lge dokumentationen fra Oracle (citeret fra 12.1):<\/p>\n<p>For et B-tr\u00e6 indeks m\u00e5ler indeks clustering factor den fysiske gruppering af r\u00e6kker i forhold til en indeksv\u00e6rdi.<\/p>\n<p>Indeks clustering factor hj\u00e6lper optimeringsprogrammet med at beslutte, om et indeks scan eller fuld tabel scan er mere effektivt for visse foresp\u00f8rgsler. En lav clustering factor indikerer et effektivt indeks scan.<\/p>\n<p>En clustering factor, der ligger t\u00e6t p\u00e5 antallet af blokke i en tabel, indikerer, at r\u00e6kkerne er fysisk ordnet i tabelblokke efter indeksn\u00f8glen. Hvis databasen udf\u00f8rer en fuld tabel scan, vil databasen typisk hente r\u00e6kkerne, som de er gemt p\u00e5 disk, sorteret efter indeksn\u00f8glen. En clustering factor, der ligger t\u00e6t p\u00e5 antallet af r\u00e6kker, indikerer, at r\u00e6kkerne er spredt tilf\u00e6ldigt over databasedelene i forhold til indeksn\u00f8glen. Hvis databasen udf\u00f8rer en fuld tabel scan, vil databasen ikke hente r\u00e6kker i nogen sorteret r\u00e6kkef\u00f8lge efter denne indeksn\u00f8gle.<\/p>\n<p>I dette tilf\u00e6lde er dataene perfekt sorteret, derfor vil clustering factor v\u00e6re lig med eller t\u00e6t p\u00e5 antallet af optagede blokke i tabellen. For en standard blokst\u00f8rrelse p\u00e5 8 kilobyte kan man forvente, at omkring tusinde smalle number v\u00e6rdier passer i \u00e9n blok, derfor vil antallet af blokke og som f\u00f8lge deraf clustering factor v\u00e6re <b>omkring dages<\/b>.<\/p>\n<h3>Ved hvilke v\u00e6rdier N vil f\u00f8lgende script blive udf\u00f8rt med succes i en almindelig database med standardindstillinger?<\/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>If\u00f8lge Oracle-dokumentationen (citeret fra 11.2):<\/p>\n<p>Logiske databasegr\u00e6nser<\/p>\n<p><strong>Emne<\/strong><br \/>\n<strong>Type af gr\u00e6nse<\/strong><br \/>\n<strong>Gr\u00e6nsev\u00e6rdi<\/strong><\/p>\n<p>Indekser<br \/>\nTotal st\u00f8rrelse af indext kolonne<br \/>\n75% af databaseblokst\u00f8rrelsen minus lidt overhead<\/p>\n<p>\nS\u00e5ledes m\u00e5 den samlede st\u00f8rrelse af de indekserede kolonner ikke overstige 6 KB. Det n\u00e6ste afh\u00e6nger af den valgte databasekodning. For AL32UTF8-kodningen kan et tegn maksimalt tage 4 byte, s\u00e5 i 6 kilobyte kan der i v\u00e6rste fald v\u00e6re omkring 1500 tegn. Derfor vil Oracle forbyde oprettelse af indeks ved N = 400 (n\u00e5r n\u00f8glens l\u00e6ngde i v\u00e6rste tilf\u00e6lde vil v\u00e6re 1600 tegn * 4 byte + l\u00e6ngden af rowid), mens <b>ved N = 200 (eller mindre)<\/b> vil oprettelsen af indeks fungere uden problemer.<\/p>\n<h3>INSERT-operatoren med hintet APPEND er beregnet til at indl\u00e6se data i direktivmode. Hvad vil der ske, hvis den anvendes p\u00e5 en tabel med en trigger?<\/h3>\n<p><\/p>\n<ul>\n<li>Data vil blive indl\u00e6st i direktivmode, og triggeren vil fungere som den skal.<\/li>\n<li>Data vil blive indl\u00e6st i direktivmode, men triggeren vil ikke blive udf\u00f8rt.<\/li>\n<li>Data vil blive indl\u00e6st i konventionel mode, og triggeren vil fungere som den skal.<\/li>\n<li>Data vil blive indl\u00e6st i konventionel mode, men triggeren vil ikke blive udf\u00f8rt.<\/li>\n<li>Data vil ikke blive indl\u00e6st, der vil opst\u00e5 en fejl.<\/li>\n<\/ul>\n<p>\n<b class=\"spoiler_title\">Svar<\/b>I princippet er dette sp\u00f8rgsm\u00e5l mere logisk. For at finde det korrekte svar vil jeg foresl\u00e5 f\u00f8lgende r\u00e6sonneringsmodel:<\/p>\n<ol>\n<li>Inds\u00e6ttelse i direktivmode udf\u00f8res ved direkte oprettelse af datablokke, uden om SQL-motoren, hvilket sikrer h\u00f8j hastighed. Derfor er det sv\u00e6rt at sikre, at triggeren bliver udf\u00f8rt, hvis det overhovedet er muligt, og det giver ikke mening, da det stadig vil bremse inds\u00e6ttelsen betydeligt.<\/li>\n<li>Manglende udf\u00f8relse af triggeren vil medf\u00f8re, at tilstanden af databasen samlet set (andre tabeller) vil afh\u00e6nge af, hvilken mode der blev brugt til inds\u00e6ttelse af disse data. Dette vil \u00e5benlyst \u00f8del\u00e6gge dataintegriteten og kan ikke anvendes som en l\u00f8sning i produktion.<\/li>\n<li>Manglende evne til at udf\u00f8re den anmodede operation betragtes generelt som en fejl. Men her skal man huske p\u00e5, at APPEND er et hint, og den generelle logik for hints er, at de tages i betragtning, hvis det er muligt; hvis ikke, udf\u00f8res operationen uden at tage hintet i betragtning.<\/li>\n<\/ol>\n<p>\nS\u00e5ledes er det forventede svar - <b>data vil blive indl\u00e6st i normal (SQL) mode, og triggeren vil fungere.<\/b><\/p>\n<p>If\u00f8lge Oracle-dokumentationen (citeret fra 8.04):<\/p>\n<p>Overtr\u00e6delser af restriktionerne vil f\u00e5 erkl\u00e6ringen til at blive udf\u00f8rt synkront, ved at bruge den konventionelle inds\u00e6tningssti, uden advarsler eller fejlmeddelelser. En undtagelse er restriktionen om erkl\u00e6ringer, der f\u00e5r adgang til den samme tabel mere end \u00e9n gang i en transaktion, hvilket kan for\u00e5rsage fejlmeddelelser.<br \/>\nFor example, if there are triggers or referential integrity on the table, the APPEND hint will be ignored when attempting to use direct-load INSERT (serial or parallel), as well as the PARALLEL hint or clause, if present.<\/p>\n<h3>What will happen when executing the following 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>Successful execution<\/li>\n<li>Failure due to a syntax error<\/li>\n<li>Error related to the invalidity of the autonomous transaction<\/li>\n<li>Error related to exceeding the maximum call nesting<\/li>\n<li>Error related to foreign key violation<\/li>\n<li>Error related to locks<\/li>\n<\/ul>\n<p>\n<b class=\"spoiler_title\">Svar<\/b>The table and trigger are created correctly and this operation should not lead to problems. Autonomous transactions in triggers are also allowed, otherwise logging, for example, would be impossible.<\/p>\n<p>After inserting the first row, the successful trigger firing would lead to the insertion of the second row, which would again trigger the insertion of a third row, and so on until the statement fails due to exceeding the maximum nesting depth. However, there is another subtle point. At the moment the trigger is executed for the first inserted record, the commit has not yet been performed. Therefore, the trigger running in an autonomous transaction attempts to insert a row into the table that references a not yet committed record via a foreign key. This results in a wait (the autonomous transaction waits for the main to commit to determine if data can be inserted) and at the same time the main transaction waits for the autonomous to commit in order to continue its work after the trigger. <b>A deadlock occurs and as a result, the autonomous transaction is terminated due to locks<\/b>.<\/p>\n<p class=\"for_users_only_msg\">Kun registrerede brugere kan deltage i unders\u00f8gelsen. <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/auth\/login\/\">Log ind<\/a><\/noindex>, please.<\/p>\n<h2 class=\"default-block__polling-title\">Was it difficult?<\/h2>\n<ul class=\"content-list content-list_polling\">\n<li class=\"content-list__item content-list__item_polling\">\n<p>                    Like two fingers, I solved everything correctly right away.<\/p>\n<\/li>\n<li class=\"content-list__item content-list__item_polling\">\n<p>                    Not really, I made a couple of mistakes.<\/p>\n<\/li>\n<li class=\"content-list__item content-list__item_polling\">\n<p>                    I solved half correctly.<\/p>\n<\/li>\n<li class=\"content-list__item content-list__item_polling\">\n<p>                    I guessed the answer twice!<\/p>\n<\/li>\n<li class=\"content-list__item content-list__item_polling\">\n<p>                    I will write in the comments<\/p>\n<\/li>\n<\/ul>\n<p>    14 users voted. 10 users abstained.<br \/>\n<br \/>Kilde: <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\/da\/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=\"da_DK\" \/>\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\/da\/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\udd47Following Highload++ Siberia 2019 \u2014 8 tasks on Oracle | ProHoster","description":"Hello! The Highload++ Siberia 2019 conference took place in Novosibirsk on June 24-25.","canonical_url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/po-sledam-highload-siberia-2019-8-zadach-po-oracle","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"da_DK","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\/da\/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\/da\/wp-json\/wp\/v2\/posts\/36171","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/comments?post=36171"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/36171\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media\/27053"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media?parent=36171"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/categories?post=36171"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/tags?post=36171"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}