Апр. 152010
 

Събрали са се разните министри, със синдикати и работодатели, да мислят. И мислили те дни и нощи, и са решили – има криза. Трябват мерки.

И ето, дни и седмици мъдруват, ала на края сал една велика мярка ще излезе – и те я отделиха специално, че даже май не са се доразбрали и за нея. За туй говорят, 59+1 са мерките. Не са 60, а 59+1.

Каква е тази мярка тъй специална? Таз мярка важна се оказва: когато се разболееш, първите 2 дни ти се изплащат от работодателя. И после има един трети ден за пост с молитва, през който никой не ти плаща – чай ще пиеш. Ако преминеш изпитанието кратко, то значи си достатъчно безценен, за да си заслужава и държава, в която данъци, осигуровки плащаш, да ти повърне нещо и да започне да ти плаща.

Така решиха, щото много тарикати се извъдили: със болничния, вместо платен отпуск, за да източат свежи кинти от държавата. И тъй се чува два-три дена, но подир туй настана друга приказка.

Работодателите, като се видяха в тясно, и като знаят най-добре за тез тарикатлъци, предложиха ни друго. Предложиха да се обърне схемата и вместо третия, през първи ден да е пием само чайче. Тъй всеки ще се чувства някак задължен да ходи да се труди, дори и да не е в кондиция. Защото тук ден-два, там друг… заплатката стремглаво намалява.

Правителството се заслуша, и ни каза, че може и така да стане. Зер простия работник като мене няма глас в тристранката. Че синдикати знаят само да полайват, ама и гледат да не се разсърди някой, че те са най-зависими от другите и нямат власт освен властта на блъфа. Пък и е важно много следното: да не погледне някой и към обичните им топли придобитъци, че те и без това са паразитна структура. Ако не ги държи закона и търпи работодателя, направо са умрели.

Но породи се в мен идея друга. Аман от недовършени реформи, предложени и одобрени от страхливи хора. Нали се знае, има криза. И трябва спешно да се съберат пари в бюджета. Та се зачудих… Не може ли като се разболея, на първий ден да давам аз пари на шефа си, за да потръгне бизнеса; на втория и трети ден да давам надник на държавата, че тя и без това го е закършила. И ако жив съм след това, да ме оставят да си се лекувам и да рушветчийствам с к’вото е останало. Така ще има и пари за бизнеса, и за бюджетните лапачи!

* * *

Но минаха и други мерки през ушите на народа. Понеже много нагли майки вдигали си доходите преди раждане, че даже месеци преди да се заченат, така източват касата; за туй държавата подхвърли, да се пресмята майчинството върху 2 до 3 години.

Сега ще кажа тази мярка как не се прие. Защото твърда е ръка правителствена, а тази мярка беше твърде мека, за да зачене, че и да роди голяма полза.

Предвид че доста дами раждат в уиниврситета или пък малко подир туй, преди да имат кариера и развитие, предлагам да се смятат за заплата всичките години след десетата. Да вземем средно от стипендии и джобните от вкъщи; да ги пресметнем с първите, най-малките заплати, така че ако някой е решил, че се е закрепил и може да роди, да си помисли пак.

И други мерки мога да предложа.
Обаче свърши ми ракията.

 Posted by at 22:12
Апр. 152010
 

Записвам си да не забравя.

Проблем: боркера мрънка, че нещо не му е на кеф:

DGMGRL> show configuration

Configuration
  Name:                DG_DEV
  Enabled:             YES
  Protection Mode:     MaxPerformance
  Fast-Start Failover: DISABLED
  Databases:
    prim  - Primary database
    stb1 - Logical standby database
    stb2 - Physical standby database

Current status for "DG_DEV":
Warning: ORA-16608: one or more databases have warnings

Проблема… хм, не че става ясен, ама поне долу-горе се вижда от Primary базата:

DGMGRL> show database prim

Database
  Name:            prim
  Role:            PRIMARY
  Enabled:         YES
  Intended State:  ONLINE
  Instance(s):
    prim

Current status for "prim":
Warning: ORA-16801: redo transport-related property is inconsistent with database setting

Това съобщение, всъщност, никак не е по-ясно от предишното. Отново свободния превод е „абе бачкам, ама нещо не ми е съвсем на таман“. Ама поне с пооглеждане в google за точно тая грешка се вижда, че има някаква разлика от зададените в конфигурацията опции и реални действащите. С още малко въображение се намира и как са попитам „добре, де, какво точно не ти е на кеф?“:

DGMGRL> show instance prim 'InconsistentLogXptProps';
INCONSISTENT LOG TRANSPORT PROPERTIES
   INSTANCE_NAME         STANDBY_NAME        PROPERTY_NAME         MEMORY_VALUE         BROKER_VALUE
           prim                stb1             LogXptMode       (missing SRLs)                ASYNC

Ахааа… и малко опит да имаш с DataGuard, научава се неписаното правило, че STLs означава standby redo logs. Значи на stb1 няма точно такива. Правим ги на бързо:

ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 GROUP 110 SIZE 50M
                                           ,GROUP 111 SIZE 50M
                                           ,GROUP 112 SIZE 50M;

Следващия въпрос към брокера е „сега уйдисва ли ти всичко?

 show configuration

Configuration
  Name:                DG_DEV
  Enabled:             YES
  Protection Mode:     MaxPerformance
  Fast-Start Failover: DISABLED
  Databases:
    prim  - Primary database
    stb1 - Logical standby database
    stb2 - Physical standby database

Current status for "DG_DEV":
Warning: ORA-16608: one or more databases have warnings

Оф, пак ми намира кусури! Хайде да видим сега пък какво не му харесва:

DGMGRL> show database stb1

Database
  Name:            stb1
  Role:            LOGICAL STANDBY
  Enabled:         YES
  Intended State:  ONLINE
  Instance(s):
    lintgr

Current status for "stb1":
Warning: ORA-16826: apply service state is inconsistent with the DelayMins property

Тук грешката е ясна. Според документацията, тази грешка означава:

Cause

This warning was caused by one of the following reasons:

– The apply service was started without specifying the real-time apply option or without the NODELAY option when the DelayMins property was set to zero.

– The apply service was started with the real-time apply option or with the NODELAY option when the DelayMins property was set to a value greater than zero.

Action

Reenable the standby database to allow the broker to restart the apply service with the apply options that are consistent with the specified value of the DelayMins property.

Много ясно – standby базата е пусната, когато е нямало SRLs. След добавянето, Apply-я трябва да се пусне отново, за да захапе с NODELAY.

DGMGRL> disable database stb1
Disabled.
DGMGRL> enable database stb1
Enabled.
DGMGRL> show configuration

Configuration
  Name:                DG_DEV
  Enabled:             YES
  Protection Mode:     MaxPerformance
  Fast-Start Failover: DISABLED
  Databases:
    prim  - Primary database
    stb1 - Logical standby database
    stb2 - Physical standby database

Current status for "DG_DEV":
SUCCESS

Ей, най-после всичко му е наред! Сега вече мога да го чупя…

 Posted by at 10:50