Oracle mechanics

05.06.2016

Посказка BITMAP_TREE

Filed under: CBO,hints,Oracle — Игорь Усольцев @ 17:52
Tags:

Определение, приведённое ранее:

Usage: BITMAP_TREE([<@Block>] <Table> AND(<Index1>[ <Index2> ...]))
    or BITMAP_TREE([<@Block>] <Table> AND((<Index1 columns>)[ (<Index2 columns>) ...]))
Description: Instructs the optimizer to convert ROWIDs to bitmap, then performance bitmap operations

оказалось неполным, и в этом, как обычно, помогла проблема с планом критичного запроса типа:

SELECT *
  FROM dual
 WHERE EXISTS (SELECT *
          FROM (SELECT DISTINCT t_lines_1.*
                  FROM t_lines t_lines_1
                  JOIN t_lines
                    ON t_lines.group_lines_id = t_lines_1.id
                 WHERE t_lines.group_lines_id IS NOT NULL
                   AND t_lines_1.group_lines_id IS NULL
                   AND t_lines.service_id IN (:service_id_1, :service_id_2, :service_id_3, :service_id_4)                     -- [1]
                   AND (t_lines.person_id = :person_id_1 OR t_lines.client_id = :client_id_1 AND t_lines.person_id IS NULL))) -- [2]

, который, как обычно неожиданно, из 2-х планов выбрал худший (PHV 2429571734 — второй по счёту в нижеприведённом сравнении) — с использование комбинации двух BITMAP ROWIDS индексных пребразований, соответствующих 2-м вхождениям/использованиям оператора OR в запросе — в строках [1] и [2] (more…)

Реклама

03.06.2016

Синтаксическая ошибка в запросе, приводящая к бесконечному parsing-у

Filed under: CBO,Oracle — Игорь Усольцев @ 00:16
Tags:

Наблюдали с коллегами запрос, часами не выходящий из фазы Hard Parse:

SQL> @ash_sqlmon2 81vm5p8sr91zr
 
LAST_PLSQL                SQL_ID        PLAN_HASH_VALUE   ID PLAN_OPERATION                    COST ASH_ROWS WAIT_PROFILE
------------------------- ------------- --------------- ---- --------------------------------- ---- -------- --------------------------------------------------------------------
Hard Parse                81vm5p8sr91zr               0    0 sql_plan_hash_value = 0                   32514 ON CPU(32514)
Main Query w/o saved plan 81vm5p8sr91zr               0                                                      
SQL Summary                                           0    0 ASH fixed 0 execs from 1 sessions         32514  ash rows were fixed from 01.06.2016 03:26:52 to 01.06.2016 12:29:00

— и так не сформировавшему за 8 часов плана выполнения!

Оказалось, что поведение запроса поменялось после незначительных изменений в тексте запроса (что ожидаемо и неудивительно), запрос «плотно висел» ON CPU, oradebug dump errorstack 3 стабильно указывал: (more…)

25.03.2016

12c: Automatic Dynamic Statistics в присутствии SPM Baseline

Восстановление default значения optimizer_dynamic_sampling = 2, последовавшее после обновления на 12c выявило краткосрочную проблему:

Top 5 Foreground Events by Total Wait Time
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                                           Total Wait       Wait   % DB Wait    
Event                                Waits Time (sec)    Avg(ms)   time Class   
------------------------------ ----------- ---------- ---------- ------ -----------
DB CPU                                          53.2K              55.8         
db file sequential read          1,998,398      15.5K       7.74   16.2 User I/O
cursor: pin S wait on X             29,094      11.5K     396.15   12.1 Concurrency -- тут
db file parallel read               72,823       3284      45.09    3.4 User I/O
db file scattered read             164,408       2134      12.98    2.2 User I/O

локализованную одним запросом:

12.1.0.2.@ SQL> @ash_sql_wait_tree "event = 'cursor: pin S wait on X'"
 
LVL BLOCKING_TREE  EVENT                    WAIT_CLASS   WAITS_COUNT EXECS_COUNT AVG_WA SESS_COUNT BLOCK_SID  MIN_STIME                   MAX_STIME                   SQL_ID        SQL_PLAN_HASH_VALUE SQL_TEXT
--- -------------- ------------------------ ------------ ----------- ----------- ------ ---------- ---------- --------------------------- --------------------------- ------------- ------------------- -----------------------------------------------
  1 (USER)         cursor: pin S wait on X  Concurrency         9872           0    991        214 VALID i#1  03-MAR-16 03.00.13.029 PM   03-MAR-16 03.01.36.228 PM   5rrd8z9nt7t2j          1613548637 select 1 from dual where exists (select 1  from
  1 (USER)         cursor: pin S wait on X  Concurrency          474           0    986         17 VALID i#1  03-MAR-16 03.00.16.029 PM   03-MAR-16 03.01.31.218 PM   5rrd8z9nt7t2j           633295841 select 1 from dual where exists (select 1  from
...
  1 (USER)         cursor: pin S wait on X  Concurrency          135           0    988          4 VALID i#1  03-MAR-16 03.00.19.029 PM   03-MAR-16 03.01.29.218 PM   5rrd8z9nt7t2j          2447725225 select 1 from dual where exists (select 1  from
  1 (USER)         cursor: pin S wait on X  Concurrency          104           0    981          3 VALID i#1  03-MAR-16 03.00.14.029 PM   03-MAR-16 03.01.29.218 PM   5rrd8z9nt7t2j          3045292599 select 1 from dual where exists (select 1  from
...

с одним действующим PHV=1613548637 (и несколькими переходными «фантомными» не оставившими следов планами) в течение непродолжительной фазы hard [re-]parse последовавшей сразу после модификации параметра OPTIMIZER_DYNAMIC_SAMPLING. По природе ожидания конкуренция (WAIT_CLASS=»Concurrency») естественно наблюдалась между сессиями, ожидавшими окончания parse/разбора того же самого курсора (more…)

28.10.2015

12c: адаптивная оптимизация и CBO

Filed under: CBO,Oracle — Игорь Усольцев @ 00:20
Tags: ,

С удивлением надлюдал поведение стандартного запроса приложения OEBS в условиях напряжённой адаптивной оптимизации (optimizer_features_enable = 12.1.0.2 and optimizer_adaptive_features=TRUE):

SQL> @shared_cu12_noxml fwpd5tbgffy68
 
INST EXECS USERS_OPENING LAST_LOAD_TIME       PARSE_USER LAST_ACTIVE_TIME    ELA_PER_EXEC CURSOR_STATUS  PLAN_HASH_VALUE OPTIMIZER_COST CHILD BIND_SENSE BIND_AWARE SHAREABLE  USE_FEEDBACK_STATS REOPT REOPT_HINTS ADAPT SPD_Valid SPD_Used  DS_LEVEL BIND_EQ_FAILURE  REASON#1                        REASON#2
---- ----- ------------- -------------------- ---------- ------------------- ------------ -------------- --------------- -------------- ----- ---------- ---------- ---------- ------------------ ----- ----------- ----- --------- --------- -------- ---------------- ------------------------------- -------------------------------
   1    11             0 2015-10-23/01:05:07  APPS       23.10.2015 01:06:02      1810503 VALID               2124898932           1103     0 N          N          N          Y                  Y               6 Y     37        8         2        N                Auto Reoptimization Mismatch(1)                                
   1    11             0 2015-10-23/01:06:09  APPS       23.10.2015 01:07:01       978098 VALID               1544287943           3063     1 N          N          N          Y                  Y               9 Y     37        8         2        N                Auto Reoptimization Mismatch(1)                                
   1     1             0 2015-10-23/01:44:48  APPS       23.10.2015 01:44:58     10736147 VALID               3906421685           6915     2 N          N          N          Y                  Y              15 Y     35        9         2        N                Auto Reoptimization Mismatch(1)                                
   1     1             0 2015-10-23/01:44:59  APPS       23.10.2015 01:45:06      7286152 VALID               1726949873           5111     3 N          N          N          Y                  Y              17 Y     35        9         2        N                Auto Reoptimization Mismatch(1)                                
   1     1             0 2015-10-23/02:02:06  APPS       23.10.2015 02:02:12      7083138 VALID                773547478           9513     4 N          N          N          Y                  Y              31 Y     36        9         2        N                Auto Reoptimization Mismatch(1)                                
   1     1             0 2015-10-23/02:02:13  APPS       23.10.2015 02:02:16      2993535 VALID               1066558335           3952     5 N          N          Y          Y                  Y              15 Y     39        6         2        N                                                                               
   2    63             1 2015-10-22/00:49:53  APPS       22.10.2015 00:52:15       949616 INVALID_UNAUTH      1963710993      938052128     4 N          N          N          Y                  Y              31 Y     42        2         2        N                Auto Reoptimization Mismatch(1) Auto Reoptimization Mismatch(1)
   2     1             0 2015-10-23/01:12:00  APPS       23.10.2015 01:12:01      1184060 VALID                840067654            235     5 N          N          N          Y                  Y              11 Y     40        5         2        N                Auto Reoptimization Mismatch(1) Auto Reoptimization Mismatch(1)
   2    10             0 2015-10-23/01:20:05  APPS       23.10.2015 01:36:53      3232426 VALID               1064056405           2226     7 N          N          Y          N                  N                 Y     40        5         2        N                Auto Reoptimization Mismatch(1) Auto Reoptimization Mismatch(1)
   2     4             1 2015-10-22/00:52:41  APPS       23.10.2015 13:05:46  32593707246 INVALID_UNAUTH      1663364961  1373425052843     6 N          N          N          Y                  Y              45 Y     41        3         2        N                Auto Reoptimization Mismatch(1) Auto Reoptimization Mismatch(1)

— запрос по V$SQL_SHARED_CURSOR / V$SQL показывает набор динамично генерируемых планов с незначительными колебаниями ср.времени выполнения ELA_PER_EXEC, кроме последней строки: CHILD=6 на 2-м инстансе выполняется с PLAN_HASH_VALUE=1663364961 стоимостью 1373425052843 (что несколько превышает обычную) достаточно длительное время 32,593,707,246 ns = 32,593 секунд при ср.времени выполнения не более 10 секунд (more…)

15.07.2015

12c: Сравнение планов выполнения и выявление соответствий в паре PLAN_HASH_VALUE >-< FULL_PLAN_HASH_VALUE

Filed under: Active Session History,CBO,Oracle — Игорь Усольцев @ 00:44
Tags: ,

Для одного из запросов внезапно сработал Statistics Feedback, что в V$SQL отразилось следующим образом:

EXEC LOAD_TIME   OPENING LAST_ACTIVE_TIME ELA_PER_EXEC PLAN_HASH_VALUE    COST CHILD BIND_SENSITIVE BIND_AWARE SHARABLE FEEDBACK_STATISTIC    ROWS PARSE_CALLS
---- ----------- ------- ---------------- ------------ --------------- ------- ----- -------------- ---------- -------- ------------------ ------- -----------
   1 29.06 12:07       0      29.06 12:45   1912450710      2108937779  396162     0 N              N          N        Y                  1106472           1
   1 29.06 15:17       1      30.06 15:07  85765923098      3773907172 5597267     1 N              N          Y        N                        0           1

— т.е. 29.06 в 12:45 запрос выполнялся с нормальным планом 2108937779, а при следующем выполнении в 30.06 в 15:07 под действием FEEDBACK_STATISTIC=Y с новым планом 3773907172 наблюдается затянувшееся выполнение, что в принципе не является чем-то необычным, любопытно что в AWR таблице DBA_HIST_SQLSTAT оба выполнения записаны с одним планом 2108937779, что, мягко говоря, не способствует правильной диагностике (первая строка SNAP_ID=87604 соотв.1-му, последующие — 2-му выполнению):

12.1.0.2.@ SQL> @dba_hist_sqlstat "sql_id = '38dyq2ab12nju' and snap_id >= 87605"
 
INST BEGIN_SNAP_ID BEGIN_SNAP_TIME    EXECS ROWS_PROCESSED SQL_ID              PLAN       COST PARSE_PER_EXEC ELA_PER_EXEC CPU_PER_EXEC GETS_PER_EXEC DISK_READS_PER_EXEC READ_MB_PER_EXEC READS_PER_EXEC WRITES_MB_PER_EXEC WRITES_PER_EXEC DIRECT_WRITES_PER_EXEC ROWS_PER_EXEC FETCHES_PER_EXEC IOWAITS_PER_EXEC CLWAITS_PER_EXEC_US
---- ------------- --------------- -------- -------------- ------------- ---------- ---------- -------------- ------------ ------------ ------------- ------------------- ---------------- -------------- ------------------ --------------- ---------------------- ------------- ---------------- ---------------- -------------------
   2         87604 29.06 12:30            0              0 38dyq2ab12nju 2108937779     396162              0    553193496    117012000      10507935             1083047             8461         954997                910            7763                 116445       1106472           158068        462927031             3887793
   2         87609 29.06 15:00            0              0 38dyq2ab12nju 2108937779     396162              0            0            0             0                   0                0              0                  0               0                      0             0                0                0                   0
   2         87610 29.06 15:30            0              0 38dyq2ab12nju 2108937779     396162              0            0            0             0                   0                0              0                  0               0                      0             0                0                0                   0
...
   2         87655 30.06 14:00            0              0 38dyq2ab12nju 2108937779     396162              0            0            0             0                   0                0              0                  0               0                      0             0                0                0                   0
   2         87656 30.06 14:30            0              0 38dyq2ab12nju 2108937779     396162              0            0            0             0                   0                0              0                  0               0                      0             0                0                0                   0

(more…)

04.06.2015

12c: директивы плана выполнения — SQL Plan Directives

Filed under: CBO,Oracle — Игорь Усольцев @ 01:27
Tags: , ,

SQL Plan Directives (SPD) определяются как дополнительная информация/указания/инструкции, генерируемые и фиксируемые в бд в процессе выполнения запроса в тех случаях, когда оптимизатор на основе имеющейся статистики строит неточный в части оценки кол-ва возвращаемых строк (cardinality misestimate) план выполнения

В дальнейшем эти SPD инструкции, привязанные к объектам бд (таблицам, группам таблиц, столбцам и группам столбцов), используются:

  • в процессе Automatic Reoptimization (т.е. на основе статистики предыдущего выполнения стимулируя создание нового плана / дочернего курсора / hard parse запроса установкой флага V$SQL.IS_REOPTIMIZABLE=’Y’) для генерации более точного плана выполнения через форсированное выполнение Automatis Dynamic Statistics / Sampling (ADS) — запросов типа SELECT /* DS_SVC */ /*+ dynamic_sampling(0) …*/
  • для создания на основании этих SPD записей Extended Statistics по группам столбцов в процессе очередного ручного или автоматического сбора статистики с использованием процедур пакета DBMS_STATS

И поскольку и Automatis Dynamic Statistics — запросы, и автоматически создаваемая Extended Statistics легко могут стать причинами определённых неудобств после миграции на 12c, SPD директивы заслуживают внимания, например, в плане управления и контроля использования

1) Вкл/Выкл SPD (more…)

17.05.2015

12c: обратимость автоматической реоптимизации

Filed under: CBO,Oracle — Игорь Усольцев @ 21:54
Tags: , ,

На продуктивной системе 12.1.0.2 с изумлением и восторгом наблюдал случай обратимости automatic re-optimization, одной из компонент 12c adaptive optimizer features:

SQL> @shared_cu12 5v18j5jkr101w
 
INST    EXECS FIRST_LOAD_TIME      LAST_LOAD_TIME       LAST_ACTIVE_TIME    ELA_PER_EXEC PLAN_HASH_VALUE OPTIMIZER_COST CHILD BIND_SENSE BIND_AWARE SHAREABLE  REOPT REOPT_HINTS ADAPT USE_FEEDBACK_STATS SQL_PLAN_DIRECTIVES REASON1                            SQL_PLAN_BASELINE  SQL_PATCH  OUTLINE_CATEGORY  SQL_PROFILE IS_OBSOLETE
---- -------- -------------------- -------------------- ------------------- ------------ --------------- -------------- ----- ---------- ---------- ---------- ----- ----------- ----- ------------------ ------------------- ---------------------------------- ----------------- ---------- ----------------- ------------ -----------
   1      214 2015-05-11/23:10:35  2015-05-12/12:50:14  12.05.2015 15:09:32   5845453723      2439019836           1159     0 Y          N          N          Y              38 Y     Y                  valid:21; used:3    Auto Reoptimization Mismatch(1)  |                                                             N
   1      166 2015-05-11/23:10:35  2015-05-12/14:14:12  12.05.2015 15:09:35   1745816312      1905979086           1159     1 Y          N          N          Y              32 Y     Y                  valid:20; used:3    Auto Reoptimization Mismatch(1)  |                                                             N
   1      176 2015-05-11/23:10:35  2015-05-12/15:02:24  12.05.2015 15:55:41      1161262      2809591419           1459     2 Y          N          Y          N               0 Y     N                  valid:21; used:3    Auto Reoptimization Mismatch(1)  |                                                             N

— дочерние курсоры удачно создавались в порядке увеличения child_number, при этом в отличие от 2-х первых последний CHILD = 2 уже не используя реоптимизацию (REOPT=V$SQL.IS_REOPTIMIZABLE = N), формируется без дополнительных хинтов — REOPT_HINTS = 0. Baseline-ов, профилей, SQL Patch-ей запрос не использовал

Несмотря на увеличение стоимости, ср.время выполнения запроса ELA_PER_EXEC значительно сократилось, т.е. отключение автоматической реоптимизации в рамках собственно процесса [ре]оптимизации достигло поставленной цели, это действительно очень сильно

28.04.2015

12c: реоптимизация baseline-ов

Filed under: CBO,Optimizer features,Oracle,Oracle new features — Игорь Усольцев @ 13:49
Tags: ,

При тестировании Oracle 12c наблюдали с Леонидом Борчуком в своём роде замечательное поведение, адекватно отражаемое запросом shared_cu12.sql (V$SQL+V$SQL_PLAN+V$SQL_SHARED_CURSOR с добавлением адаптивных эффектов):

12.1.0.2@ SQL> @shared_cu12 ch28y57dby48a
 
EXECS LAST_LOAD_TIME      LAST_ACTIVE_TIME    ELA_PER_EXEC PLAN_HASH_VALUE OPTIMIZER_COST CHILD BIND_SENSE BIND_AWARE SHAREABLE  REOPT REOPT_HINTS ADAPT USE_FEEDBACK_STATS SQL_PLAN_DIRECTIVES OPTIMIZER_STATS  BIND_EQ_FAILURE  ROLL REASON1                              SQL_PLAN_BASELINE              SQL_PATCH OUTLINE_CATEGORY SQL_PROFILE IS_OBSOLETE
----- ------------------- ------------------- ------------ --------------- -------------- ----- ---------- ---------- ---------- ----- ----------- ----- ------------------ ------------------- ---------------- ---------------- ---- ------------------------------------ ------------------------------ --------- ---------------- ----------- -----------
    2 2015-04-23/17:37:22 23.04.2015 17:45:14    220816797      2061850922           3073     0 N          N          N          Y              19 Y     Y                  valid:13; used:3    N                N                N    Auto Reoptimization Mismatch(1)  |                                                                         N
    2 2015-04-23/18:25:09 23.04.2015 18:33:26    221786319      3290307628       19309221     1 N          N          N          Y              36       Y                  valid:13; used:3    N                N                N    Auto Reoptimization Mismatch(1)  |                                                                         N
    4 2015-04-24/12:41:54 24.04.2015 13:10:57     88755911      2061850922           3072     2 N          N          Y          Y              19 Y     Y                  valid:13; used:4    N                N                N    SQL Tune Base Object Different(3)  |                                                                       N
    1 2015-04-24/14:30:11 24.04.2015 14:30:14      3347403       506569056           3104     3 N          N          Y          N               0       N                  valid:9; used:2     N                N                N                                         SQL_PLAN_8aa3jkjfw98tf56386d53                                        N
    1 2015-04-24/14:31:09 24.04.2015 14:31:34     15259875       506569056           3104     4 N          N          N          Y              43       Y                  valid:9; used:2     N                N                N    Auto Reoptimization Mismatch(1)  |   SQL_PLAN_8aa3jkjfw98tf56386d53                                        N
    1 2015-04-24/14:42:43 24.04.2015 14:43:10     13913257       506569056           3104     6 N          N          N          Y              44       Y                  valid:9; used:2     N                N                N    Auto Reoptimization Mismatch(1)  |   SQL_PLAN_8aa3jkjfw98tf56386d53                                        N
    4 2015-04-24/16:50:05 24.04.2015 16:52:30      3762610       506569056           3105     5 N          N          Y          N               0       N                  valid:9; used:2     N                N                N                                         SQL_PLAN_8aa3jkjfw98tf56386d53                                        N

— запрос ch28y57dby48a, вызывавший опасения в плане скорости выполнения (ELA_PER_EXEC в первых 3-х строках вывода) после фиксации хорошего плана выполнения PLAN_HASH_VALUE = 506569056:

SQL> @spm_check4sql_id ch28y57dby48a
 
SPM_TYPE          SQL_HANDLE            PLAN_NAME                      ORIGIN      VERSION    LAST_MODIFIED       LAST_EXECUTED       ENABLED ACCEPTED FIXED REPRODUCED AUTOPURGE
----------------- --------------------- ------------------------------ ----------- ---------- ------------------- ------------------- ------- -------- ----- ---------- ---------
SQL Plan Baseline SQL_852871945dc4a32e  SQL_PLAN_8aa3jkjfw98tf56386d53 MANUAL-LOAD 12.1.0.2.0 24.04.2015 14:30:12 24.04.2015 14:30:12 YES     YES      NO    YES        YES

— одновременно с мирным использованием зафиксированного baseline-ом плана, формально продолжал применять SQL Plan Directives (SQL_PLAN_DIRECTIVES) и использовать реоптимизацию (столбцы REOPT и REOPT_HINTS) как следствие деятельности Statistics Feedback (USE_FEEDBACK_STATS), т.о. производя ненужную работу и генерируя избыточные дочерние курсоры (more…)

24.04.2015

12c: In-Memory деградация и адаптивная реоптимизация

Filed under: CBO,Oracle — Игорь Усольцев @ 00:59
Tags: ,

Вслед за опцией Oracle Database In-Memory версия 12.1.0.2 предлагает соответствующий In-Memory Advisor (в качестве инструментария настоящих DBA 2.0, полагаю), в соответствии с рекомендациями которого была предпринята попытка поместить указанные советчиком таблицы в предварительно выделенную (restart required) область SGA:

12.1.0.2.@ SQL> @param inmemory_size
 
NAME           VALUE        DSC
-------------- ------------ -------------------------------
inmemory_size  21474836480  size in bytes of in-memory area

Нежданно-негаданно запрос, в числе прочих отражённый, и, что было бы логично, учтённый/просчитанный IM Advisor-ом, стал выполняться значительно (в разы) медленнее. Т.е. на лицо деградация производительности после/в рез-те переноса нескольких таблиц запроса в быстрое IM хранилище. В общем случае не вижу в этом большой проблемы, т.к. запрос объективно непростой (2000+ строк плана), можно сказать, штучный, построение большого плана само по себе являет непростую задачу, и дополнительный учёт возможностей INMEMORY доступа эту задачу отнюдь не облегчает, полагаю)

Попытка отключить опцию для всего запроса простыми подсказками:

SQL> select/*+ NO_INMEMORY NO_INMEMORY_PRUNING PARALLEL(8)*/ *  from v_complicated_view; -- 230ywhm3knw1c
select/*+ NO_INMEMORY NO_INMEMORY_PRUNING PARALLEL(8)*/ *  from v_complicated_view
*
ERROR at line 1:
ORA-12801: error signaled in parallel query server P00B, instance orcl:orcl1 (1)
ORA-01555: snapshot too old: rollback segment number 99 with name "_SYSSMU99_1282318135$" too small

Elapsed: 11:20:53.32

— не сработала, в точном соответствии с документацией простые хинты отключают использование INMEMORY только на уровне конкретной таблицы плана запроса в виде: (more…)

07.03.2015

12c: управление адаптивными фичами

Filed under: CBO,Oracle — Игорь Усольцев @ 23:03
Tags: ,

По умолчанию, ответственный параметр OPTIMIZER_ADAPTIVE_FEATURES enables or disables all of the adaptive optimizer features, including adaptive plan (adaptive join methods and bitmap plans), automatic re-optimization, SQL plan directives, and adaptive distribution methods, установлен в TRUE и перечисленные функции оптимизатора 12c могут работать

Если же отключить параметр на уровне любого простого запроса:

12.1.0.2.SCOTT@/ORCL1201 SQL> select /*+ opt_param('optimizer_adaptive_features' 'false')*/ sysdate from dual;

1 row selected.

, секция Outline плана выполнения показывает параметы управления адаптивными компонентами по отдельности: (more…)

Следующая страница →

Создайте бесплатный сайт или блог на WordPress.com.