{"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\/it\/blog\/administrirovanie\/po-sledam-highload-siberia-2019-8-zadach-po-oracle","title":{"rendered":"Sulle orme di Highload++ Siberia 2019 \u2014 8 compiti su Oracle","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Ciao!<\/p>\n<p>Il 24-25 giugno si \u00e8 tenuta a Novosibirsk la conferenza Highload++ Siberia 2019. Anche il nostro team era presente. <noindex><a rel=\"nofollow\" href=\"https:\/\/www.highload.ru\/siberia\/2019\/abstracts\/5211\">relazione<\/a><\/noindex> \u00abBasi container Oracle (CDB\/PDB) e il loro utilizzo pratico nello sviluppo di software\u00bb, pubblicheremo la versione testuale un po' pi\u00f9 tardi. \u00c8 stato fantastico, grazie <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/users\/olegbunin\/\" class=\"user_link\">olegbunin<\/a><\/noindex> per l'organizzazione e a tutti coloro che sono venuti. <\/p>\n<p><img decoding=\"async\" alt=\"Sulle orme di Highload++ Siberia 2019 \u2014 8 compiti su Oracle\" src=\"\/wp-content\/uploads\/2019\/07\/27f4707d4bb5968eaaa5c4748ff467cd.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nIn questo post desideriamo condividere con voi le attivit\u00e0 che avevamo al nostro stand, affinch\u00e9 possiate mettere alla prova le vostre conoscenze su Oracle. Di seguito trovate 8 attivit\u00e0, le opzioni di risposta e spiegazioni.<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h3>Qual \u00e8 il valore massimo della sequenza che vedremo come risultato dell'esecuzione del seguente 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>Nessuno, ci sar\u00e0 un errore<\/li>\n<\/ul>\n<p>\n<b class=\"spoiler_title\">Risposta<\/b>Secondo la documentazione di Oracle (citato da 8.1.6):<br \/>\nAll'interno di una singola istruzione SQL, Oracle incrementa la sequenza solo una volta per riga. Se un'istruzione contiene pi\u00f9 di un riferimento a NEXTVAL per una sequenza, Oracle incrementa la sequenza una volta e restituisce lo stesso valore per tutte le occorrenze di NEXTVAL. Se un'istruzione contiene riferimenti sia a CURRVAL che a NEXTVAL, Oracle incrementa la sequenza e restituisce lo stesso valore per CURRVAL e NEXTVAL indipendentemente dal loro ordine nell'istruzione.<\/p>\n<p>Pertanto, <b>il valore massimo corrisponder\u00e0 al numero di righe, ovvero 5.<\/b>.<\/p>\n<h3>Quante righe ci saranno nella tabella a seguito dell'esecuzione del seguente 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\">Risposta<\/b>Secondo la documentazione Oracle (riportata da 11.2):<\/p>\n<p>Prima di eseguire qualsiasi dichiarazione SQL, Oracle segna un salvataggio implicito (non disponibile per te). Quindi, se la dichiarazione fallisce, Oracle la annulla automaticamente e restituisce il codice di errore applicabile a SQLCODE in SQLCA. Ad esempio, se un'istruzione INSERT provoca un errore cercando di inserire un valore duplicato in un indice unico, l'istruzione viene annullata.<\/p>\n<p>La chiamata alla stored procedure dal client \u00e8 anche considerata e trattata come un'istruzione singola. Pertanto, la prima chiamata alla stored procedure si conclude con successo, inserendo tre record; la seconda chiamata alla stored procedure termina con un errore e annulla il quarto record, che \u00e8 stato inserito; la terza chiamata termina con un errore, <b>e nella tabella ci sono tre record<\/b>.<\/p>\n<h3>Quante righe ci saranno nella tabella a seguito dell'esecuzione del seguente 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\">Risposta<\/b>Secondo la documentazione Oracle (riportata da 11.2):<\/p>\n<p>Una restrizione di controllo consente di specificare una condizione che ogni riga nella tabella deve soddisfare. Per soddisfare la restrizione, ogni riga nella tabella deve rendere la condizione vera o sconosciuta (a causa di un valore nullo). Quando Oracle valuta una condizione di restrizione di controllo per una riga particolare, i nomi delle colonne nella condizione si riferiscono ai valori delle colonne in quella riga.<\/p>\n<p>In questo modo, il valore nullo passer\u00e0 il controllo e il blocco anonimo verr\u00e0 eseguito correttamente fino al momento in cui si tenter\u00e0 di inserire il valore 3. Dopo di ci\u00f2, il blocco di gestione degli errori interverr\u00e0 per annullare l'eccezione, senza alcun rollback, e <b>quattro righe rimarranno nella tabella<\/b> con i valori 1, null, 2 e nuovamente null.<\/p>\n<h3>Quali coppie di valori occuperanno spazi identici nel blocco?<\/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 e X<\/li>\n<li>B e Y<\/li>\n<li>C e K<\/li>\n<li>C e Z<\/li>\n<li>K e Z<\/li>\n<li>I e J<\/li>\n<li>J e X<\/li>\n<li>Tutti i suddetti<\/li>\n<\/ul>\n<p>\n<b class=\"spoiler_title\">Risposta<\/b>Riportiamo estratti dalla documentazione (12.1.0.2) riguardante l'archiviazione di diversi tipi di dati in Oracle.<\/p>\n<p><b>Tipo di dati CHAR<\/b><br \/>\nIl tipo di dati CHAR specifica una stringa di caratteri a lunghezza fissa nel set di caratteri del database. Devi specificare il set di caratteri del database quando crei il tuo database. Oracle garantisce che tutti i valori memorizzati in una colonna CHAR abbiano la lunghezza specificata dalla dimensione nella semantica di lunghezza selezionata. Se inserisci un valore pi\u00f9 corto della lunghezza della colonna, Oracle riempir\u00e0 il valore con spazi fino alla lunghezza della colonna.<\/p>\n<p><b>Tipo di dati VARCHAR2<\/b><br \/>\nIl tipo di dati VARCHAR2 specifica una stringa di caratteri a lunghezza variabile nel set di caratteri del database. Si specifica il set di caratteri del database quando si crea il database. Oracle memorizza un valore di carattere in una colonna VARCHAR2 esattamente come lo si specifica, senza alcun riempimento con spazi vuoti, a condizione che il valore non superi la lunghezza della colonna.<\/p>\n<p><b>Tipo di dati NUMBER<\/b><br \/>\nIl tipo di dati NUMBER memorizza zero insieme a numeri fissi positivi e negativi con valori assoluti da 1.0 x 10-130 a, ma non incluso, 1.0 x 10^126. Se si specifica un'espressione aritmetica il cui valore ha un valore assoluto maggiore o uguale a 1.0 x 10^126, Oracle restituisce un errore. Ogni valore NUMBER richiede da 1 a 22 byte. Tenendo conto di questo, la dimensione della colonna in byte per un valore numerico particolare NUMBER(p), dove p \u00e8 la precisione di un valore dato, pu\u00f2 essere calcolata utilizzando la seguente formula: <i>ROUND((lunghezza(p)+s)\/2))+1<\/i> dove s \u00e8 uguale a zero se il numero \u00e8 positivo e s \u00e8 uguale a 1 se il numero \u00e8 negativo.<\/p>\n<p>Inoltre, prendiamo un estratto dalla documentazione riguardante la memorizzazione dei valori Null.<\/p>\n<p>Un null \u00e8 l'assenza di un valore in una colonna. I null indicano dati mancanti, sconosciuti o non applicabili. I null vengono memorizzati nel database se si trovano tra colonne con valori di dati. In questi casi, richiedono 1 byte per memorizzare la lunghezza della colonna (zero). I null finali in una riga non richiedono spazio di memorizzazione perch\u00e9 un nuovo intestazione di riga segnala che le colonne rimanenti nella riga precedente sono null. Ad esempio, se le ultime tre colonne di una tabella sono null, non vengono memorizzati dati per queste colonne.<\/p>\n<p>Sulla base di questi dati, costruiamo le deduzioni. Supponiamo che nel database venga utilizzata la codifica AL32UTF8. In questa codifica, le lettere russe occuperanno 2 byte.<\/p>\n<p>1) A e X, il valore del campo a 'Y' occupa 1 byte, il valore del campo x '\u0414' occupa 2 byte<br \/>\n2) B e Y, '\u0412\u0430\u0441\u044f' nel b verr\u00e0 completato con spazi fino a 10 caratteri e occuper\u00e0 14 byte, '\u0412\u0430\u0441\u044f' nel d \u2013 occuper\u00e0 8 byte.<br \/>\n3) C e K. Entrambi i campi hanno valore NULL, dopo di essi ci sono campi significativi, quindi occupano ciascuno 1 byte.<br \/>\n4) C e Z. Entrambi i campi hanno valore NULL, ma il campo Z \u00e8 l'ultimo nella tabella, quindi non occupa spazio (0 byte). Il campo C occupa 1 byte.<br \/>\n5) K e Z. Analogamente al caso precedente. Il valore nel campo K occupa 1 byte, in Z \u2013 0.<br \/>\n6) I e J. Secondo la documentazione, entrambi i valori occuperanno 2 byte. La lunghezza \u00e8 calcolata secondo la formula prelevata dalla documentazione: round( (1 + 0)\/2) +1 = 1 + 1 = 2.<br \/>\n7) J e X. Il valore nel campo J occuper\u00e0 2 byte, il valore nel campo X occuper\u00e0 2 byte.<\/p>\n<p><b>In totale, le opzioni corrette sono: C e K, I e J, J e X.<\/b><\/p>\n<p><\/p>\n<h3>Quale sar\u00e0 approssimativamente il clustering factor dell'indice 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>Dell'ordine di decine<\/li>\n<li>Dell'ordine di centinaia<\/li>\n<li>Dell'ordine di migliaia<\/li>\n<li>Dell'ordine di decine di migliaia<\/li>\n<\/ul>\n<p>\n<b class=\"spoiler_title\">Risposta<\/b>Secondo la documentazione Oracle (citato da 12.1):<\/p>\n<p>Per un indice B-tree, il fattore di clustering dell'indice misura il raggruppamento fisico delle righe in relazione a un valore dell'indice.<\/p>\n<p>Il fattore di clustering dell'indice aiuta l'ottimizzatore a decidere se \u00e8 pi\u00f9 efficiente eseguire uno scan dell'indice o uno scan completo della tabella per determinate query. Un fattore di clustering basso indica uno scan dell'indice efficiente.<\/p>\n<p>Un fattore di clustering vicino al numero di blocchi in una tabella indica che le righe sono fisicamente ordinate nei blocchi della tabella in base alla chiave dell'indice. Se il database esegue uno scan completo della tabella, tende a recuperare le righe come sono memorizzate su disco, ordinate dalla chiave dell'indice. Un fattore di clustering vicino al numero di righe indica che le righe sono sparse casualmente tra i blocchi del database in relazione alla chiave dell'indice. Se il database esegue uno scan completo della tabella, non recupererebbe le righe in nessun ordine ordinato per questa chiave dell'indice.<\/p>\n<p>In questo caso, i dati sono perfettamente ordinati, quindi il fattore di clustering sar\u00e0 uguale o vicino al numero di blocchi occupati nella tabella. Per una dimensione standard del blocco di 8 kilobyte, ci si pu\u00f2 aspettare che in un blocco possano entrare circa mille valori numerici ristretti, quindi il numero di blocchi, e di conseguenza il fattore di clustering sar\u00e0 <b>di decine<\/b>.<\/p>\n<h3>Quali valori di N consentiranno l'esecuzione del seguente script in un normale database con impostazioni standard?<\/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\">Risposta<\/b>Secondo la documentazione Oracle (riportata da 11.2):<\/p>\n<p>Limiti Logici del Database<\/p>\n<p><strong>Voce<\/strong><br \/>\n<strong>Tipo di Limite<\/strong><br \/>\n<strong>Valore Limite<\/strong><\/p>\n<p>Indici<br \/>\nDimensione totale della colonna indicizzata<br \/>\n75% della dimensione del blocco del database meno un certo sovraccarico<\/p>\n<p>\nPertanto, la dimensione totale delle colonne indicizzate non deve superare i 6 KB. Il resto dipende dalla codifica scelta per il database. Per la codifica AL32UTF8, un carattere pu\u00f2 occupare al massimo 4 byte, quindi in 6 kilobyte, nel caso peggiore, ci stanno circa 1500 caratteri. Di conseguenza, Oracle impedir\u00e0 la creazione dell'indice quando N = 400 (quando la lunghezza della chiave nel caso peggiore sar\u00e0 1600 caratteri * 4 byte + lunghezza del rowid), mentre <b>quando N = 200 (e meno)<\/b> la creazione dell'indice funzioner\u00e0 senza problemi.<\/p>\n<h3>L'operatore INSERT con hint APPEND \u00e8 progettato per caricare dati in modalit\u00e0 diretta. Cosa succede se viene applicato a una tabella con un trigger attivo?<\/h3>\n<p><\/p>\n<ul>\n<li>I dati verranno caricati in modalit\u00e0 diretta, il trigger verr\u00e0 attivato come previsto<\/li>\n<li>I dati verranno caricati in modalit\u00e0 diretta, ma il trigger non verr\u00e0 eseguito<\/li>\n<li>I dati verranno caricati in modalit\u00e0 convenzionale, il trigger verr\u00e0 attivato come previsto<\/li>\n<li>I dati verranno caricati in modalit\u00e0 convenzionale, ma il trigger non verr\u00e0 eseguito<\/li>\n<li>I dati non verranno caricati, verr\u00e0 registrato un errore<\/li>\n<\/ul>\n<p>\n<b class=\"spoiler_title\">Risposta<\/b>In linea di principio, questa \u00e8 pi\u00f9 una questione di logica. Per trovare la risposta corretta, suggerirei il seguente modello di ragionamento:<\/p>\n<ol>\n<li>L'inserimento in modalit\u00e0 diretta avviene tramite la generazione diretta di un blocco di dati, bypassando il motore SQL, il che garantisce un'alta velocit\u00e0. Pertanto, \u00e8 molto difficile garantire l'esecuzione di un trigger, se non impossibile, e non ha senso, poich\u00e9 rallenterebbe drasticamente l'inserimento.<\/li>\n<li>L'eventuale mancato funzionamento del trigger porter\u00e0 a una situazione in cui, con dati identici nella tabella, lo stato complessivo del database (di altre tabelle) dipender\u00e0 da quale modalit\u00e0 \u00e8 stata utilizzata per l'inserimento di questi dati. Questo distrugger\u00e0 evidentemente l'integrit\u00e0 dei dati e non pu\u00f2 essere applicato come soluzione in produzione.<\/li>\n<li>L'impossibilit\u00e0 di eseguire l'operazione richiesta viene generalmente interpretata come un errore. Ma qui \u00e8 opportuno ricordare che APPEND \u00e8 un hint, e la logica generale degli hint consiste nel fatto che vengono presi in considerazione se possibile; in caso contrario, l'operatore viene eseguito senza considerare l'hint.<\/li>\n<\/ol>\n<p>\nPertanto, la risposta attesa \u00e8 <b>i dati saranno caricati in modalit\u00e0 normale (SQL), il trigger si attiver\u00e0.<\/b><\/p>\n<p>Secondo la documentazione Oracle (citata dalla versione 8.04):<\/p>\n<p>Le violazioni delle restrizioni comporteranno l'esecuzione della dichiarazione in modo seriale, utilizzando il percorso di inserimento convenzionale, senza avvisi o messaggi di errore. Un'eccezione \u00e8 rappresentata dalla restrizione su dichiarazioni che accedono alla stessa tabella pi\u00f9 di una volta in una transazione, il che pu\u00f2 provocare messaggi di errore.<br \/>\nAd esempio, se sono presenti trigger o integrit\u00e0 referenziale sulla tabella, allora l'indicazione APPEND verr\u00e0 ignorata quando si tenta di utilizzare INSERT a caricamento diretto (seriale o parallelo), cos\u00ec come l'indicazione o clausola PARALLEL, se presente.<\/p>\n<h3>Cosa succede quando esegui il seguente 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>Esecuzione riuscita<\/li>\n<li>Fallimento a causa di un errore di sintassi<\/li>\n<li>Errore relativo all'invalidit\u00e0 della transazione autonoma<\/li>\n<li>Errore relativo al superamento della massima profondit\u00e0 di chiamate<\/li>\n<li>Errore relativo alla violazione della chiave esterna<\/li>\n<li>Errore relativo ai lock<\/li>\n<\/ul>\n<p>\n<b class=\"spoiler_title\">Risposta<\/b>La tabella e il trigger sono creati correttamente e questa operazione non dovrebbe causare problemi. Le transazioni autonome nel trigger sono anche consentite, altrimenti non sarebbe possibile, ad esempio, il logging.<\/p>\n<p>Dopo l'inserimento della prima riga, l'attivazione del trigger avrebbe comportato l'inserimento della seconda riga, il che avrebbe riattivato il trigger, inserito la terza riga e cos\u00ec via, fino a quando lo statement non sarebbe fallito a causa del superamento del numero massimo di chiamate annidate. Tuttavia, c'\u00e8 un altro aspetto sottile. Al momento dell'esecuzione del trigger per la prima riga inserita, il commit non \u00e8 ancora stato eseguito. Pertanto, il trigger, che opera in una transazione autonoma, tenta di inserire una riga nella tabella che fa riferimento a un record non ancora impegnato da un vincolo esterno. Questo provoca un'attesa (la transazione autonoma aspetta il commit principale per capire se i dati possono essere inseriti) e contemporaneamente la transazione principale aspetta il commit della transazione autonoma per continuare a operare dopo il trigger. <b>Si verifica un deadlock e, di conseguenza, la transazione autonoma viene interrotta a causa di blocchi.<\/b>.<\/p>\n<p class=\"for_users_only_msg\">Solo gli utenti registrati possono partecipare al sondaggio. <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/auth\/login\/\">Accedi<\/a><\/noindex>, per favore.<\/p>\n<h2 class=\"default-block__polling-title\">\u00c8 stato difficile?<\/h2>\n<ul class=\"content-list content-list_polling\">\n<li class=\"content-list__item content-list__item_polling\">\n<p>                    Come bere un bicchier d'acqua, ho risolto tutto subito.<\/p>\n<\/li>\n<li class=\"content-list__item content-list__item_polling\">\n<p>                    Non molto, ho sbagliato un paio di domande.<\/p>\n<\/li>\n<li class=\"content-list__item content-list__item_polling\">\n<p>                    Ho risolto met\u00e0 correttamente.<\/p>\n<\/li>\n<li class=\"content-list__item content-list__item_polling\">\n<p>                    Ho indovinato due volte la risposta!<\/p>\n<\/li>\n<li class=\"content-list__item content-list__item_polling\">\n<p>                    Scriver\u00f2 nei commenti.<\/p>\n<\/li>\n<\/ul>\n<p>    Hanno votato 14 utenti. 10 utenti si sono astenuti.<br \/>\n<br \/>Fonte: <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 4.9.10 - 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. \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\" \/>\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\/it\/blog\/administrirovanie\/po-sledam-highload-siberia-2019-8-zadach-po-oracle\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 4.9.10\" \/>\n\t\t<meta property=\"og:locale\" content=\"it_IT\" \/>\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. \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\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/it\/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\udd47Sulle tracce di Highload++ Siberia 2019 \u2014 8 sfide su Oracle | ProHoster","description":"Ciao! Il 24-25 giugno si \u00e8 svolta a Novosibirsk la conferenza Highload++ Siberia 2019. Anche i nostri ragazzi erano l\u00ec con la presentazione \"Database containerizzati Oracle (CDB\/PDB) e il loro utilizzo pratico per lo sviluppo software\", pubblicheremo la versione testuale un po' pi\u00f9 tardi. \u00c8 stato fantastico, grazie a olegbunin per l'organizzazione, e a tutti coloro che sono intervenuti. In questo post vorremmo condividere con voi le sfide che","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/po-sledam-highload-siberia-2019-8-zadach-po-oracle","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","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. \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","og:url":"https:\/\/prohoster.info\/it\/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"},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/36171","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=36171"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/36171\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/27053"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=36171"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=36171"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=36171"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}