Logo    
Деловая газета CitCity.ru CITKIT.ru - все об Open Source Форумы Все публикации Учебный центр Курилка
CitForum    CITForum на CD    Подписка на новости портала Море(!) аналитической информации! :: CITFORUM.RU
IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

24.02.2017

Google
WWW CITForum.ru
С Новым годом!
2006 г.

Потоки данных в Oracle - это очень просто

Владимир Пржиялковский
Преподаватель технологий Oracle
www.ccas.ru/prz/
 

Знает названье потока лишь тот, кто вблизи обитает.

Теогония, Гесиод

От Махачкалы до Баку
Луны плавают на боку,
И, качаясь, плывут валы
От Баку до Махачкалы.

Качка в Каспийском море. Стихи Б. Корнилова, музыка Ю. Визбора

Введение

Потоки данных в Oracle - более поздняя, чем "обычная" репликация (односторонняя, двусторонняя и многосторонняя), модель организации непрерывного переноса данных как внутри БД, так и между базами. Это значительно упрощенная реализация идей, изложенных, например, в http://www-db.stanford.edu/~widom/stream.ppt: в частности реализация Oracle Streams не предлагает языкового оформления, а только на уровне API. Технически потоки Oracle Streams опираются на созданный независимо и ранее аппарат организации очередей передачи сообщений, известный под названием Oracle Advanced Queuing.

Потоки данных появились в Oracle версии 9, а в версии 10 получили свое развитие в возможностях (например, Down Stream) и в организации (например, собственный источник памяти streams pool).

В отличие от "обычной" репликации Oracle Streams не требует заведения особых структур в БД (журналов таблиц, materialized views). Подбно механизму репликации, давно использовавшемуся в Sybase, репликация в Oracle Streams основана на обработке информации из журнала БД.

Основные понятия

В потоковой передаче данных участвуют следующие основные элементы:
  • Процесс захвата изменений (Capture Process). Фоновый процесс, постоянно просматривает средствами LogMiner рабочие и архивированные журналы; выбирает из них требуемые записи об изменениях в исходной таблице/схеме/БД (INSERT, UPDATE, DELETE, MERGE, обновления полей LOB); формирует из этих записей логическую запись об изменении, Logical Change Record (LCR); помещает LCR в качестве события в очередь, сформированную средствами Streams Advanced Queuing (SAQ)1.
  • Процесс передачи изменений (Propagation Process). Постоянно выбирает события из очереди в исходной БД и передает их в очереди на принимающих БД через Oracle Net.
  • Процесс внесения, применения изменений (Apply Process). Постоянно выбирает события из очереди в принимающей СУБД. LCR либо применяются непосредственно к таблицам принимающей БД, либо передаются программе обработки, написанной пользователем на свое усмотрение.
  • Очередь (queue). Она может складываться из упорядоченного множества (списка) объектов конкретного типа, но чаще используются очереди из объектов типа SYS.ANYDATA. В очередь попадают LCR (автоматически, в соответствии с заданными правилами, или же явным добавлением из программы) или более общие сообщения (вставляются и извлекаются вручную). Очередь моделируется с помощью специально создаваемых служебных таблиц, но для автоматически размещаемых в очереди событий LCR дополнительно имеется буфер в SGA.

Конфигурация СУБД и БД для возможности организации потоков

Параметры СУБД
Для организации потоков данных нужно иметь должные значения целого ряда параметров СУБД, однако чаще всего достаточно удостовериться в следующем:

COMPATIBLE >= 9.2
Далее предполагается >= 10.1.0.

GLOBAL_NAMES = TRUE
для каждой БД, участвующей в переносе данных.

STREAMS_POOL_SIZE >= 200m
Параметр существует с версии 10.1 и задает область памяти для временного размещения захваченных событий. Если STREAMS_POOL_SIZE = 0, будет использована память из shared pool, вплоть до 10% от этой области.

При расчете нужно учитывать следующее:

  • + 10m для каждого нового уровня параллелизма процесса захвата
  • + 1m для каждой степени параллелизма процесса применения
  • + 10m для каждой новой очереди захваченных событий.

В версии 9.2 нагрузка на выделение памяти под нужды потоков ложится на shared pool.

SHARED_POOL_SIZE
Каждый процесс захвата требует 10M в памяти shared pool для буфера очереди; в то же время все нужды Oracle Streams в shared pool не могут занимать более 10% этой области.

SGA_MAX_SIZE
(Если речь идет о версии 10). Значение должно учитывать нужды частей SGA (см. выше), особенно для выполнения захвата изменений с помощью LogMiner. Пример, приводимый ниже, в силу его простоты работает даже при значении SGA_MAX_SIZE = 400m.

Конфигурация БД
БД, поддерживающая процесс захвата изменений, должна работать в режиме архивирования.

БД, поддерживающая процесс захвата изменений, должна обеспечить на уровне отдельных таблиц или всей БД режим расширенной журнализации (supplemental logging). В этом режиме журнальные записи об изменениях в таблицах заносятся в расширенном формате, включая данные старых и новых значений полей (независимо от того, какие поля фактически изменялись) для того, чтобы процесс применения изменения в принимающей СУБД смог однозначно воспроизвести изменение.

Расширенную журнализацию можно включать не обязательно для всей БД, но достаточно для реплицируемых таблиц. Значение столбца в таблице исходной БД должно безусловно (ALWAYS, unconditionally) попадать в журнал, если соответствующий столбец в таблице принимающей БД:

  • индексирован (хотя бы вследствие имеющегося ограничения целостности)
  • участвует в правиле преобразования данных или обрабатывается программой обработки (handler)

Как БД-источник, так и БД-получатель используют рабочие таблицы для хранения данных очередей и прочих нужд. Для их размещения целесообразно выделить отдельные табличные пространства. В БД-источнике желательно назначить процессу LogMiner табличное пространство, иное, чем SYSTEM.

Системные пакеты
Технологически организация потоков осуществляется через употребление ряда встроенных пакетов из схемы SYS:

DBMS_APPLY_ADM
DBMS_CAPTURE_ADM
DBMS_PROPAGATION_ADM
DBMS_STREAMS_ADM
DBMS_STREAMS
DBMS_STREAMS_MESSAGING
DBMS_RULE_ADM
DBMS_RULE
DBMS_STREAMS_AUTH
2
DBMS_STREAMS_TABLESPACE_ADM2

Пример построения потока изменений

В этом примере БД-источник потока носит имя MAINDB.CLASS, БД-приемник потока носит имя SUBDB1.CLASS. Сетевые имена баз в Oracle Net соответственно SOURCE и DESTINATION. Предполагается, что в обеих БД имеется схема SCOTT.

Пример приводится для версии 10.2. Предполагается, что команды выдаются в SQL*Plus.

Подготовка
Переведем БД-источник в режим архивирования журнальных файлов:

CONNECT /@source AS SYSDBA
STARTUP MOUNT FORCE
ALTER DATABASE ARCHIVELOG;
ALTER DATABASE OPEN;

Создадим рабочие табличные пространства в обоих БД, например:

CREATE TABLESPACE streams_ts
DATAFILE 'C:\oracle\oradata\maindb\streams_ts.dbf' SIZE 25m;

CONNECT /@destination AS SYSDBA
CREATE TABLESPACE streams_ts
DATAFILE 'C:\oracle\oradata\subdb1\streams_ts.dbf' SIZE 25m;

В версия 9.2 в БД-источнике желательно назначить процессу LogMiner табличное пространство, иное, чем SYSTEM (в версия 10 оно уже SYSAUX), например:

CONNECT /@source AS SYSDBA
EXECUTE DBMS_LOGMNR_D.SET_TABLESPACE ( 'TOOLS' )

В обеих базах создадим администратора потоков:

CONNECT /@source AS SYSDBA

CREATE USER streamadmin IDENTIFIED BY streamadmin
DEFAULT TABLESPACE streams_ts
TEMPORARY TABLESPACE temp
QUOTA UNLIMITED ON streams_ts
;

GRANT dba TO streamadmin;

EXECUTE DBMS_STREAMS_AUTH.GRANT_ADMIN_PRIVILEGE ( 'streamadmin' )

Повторить те же действия для SUBDB1.CLASS.

В БД-источнике заведем связь с БД-получателем. Так как БД-получатель именована глобально, имя связи обязано совпадать с этим глобальным именем:

CONNECT streamadmin/streamadmin@source

CREATE DATABASE LINK subdb1.class
CONNECT TO streamadmin
IDENTIFIED BY streamadmin
USING 'destination'
;

Формирование потоков
Создадим очередь для передачи событий в БД-источнике и очередь для применения событий в БД-получателе, например:

EXECUTE DBMS_STREAMS_ADM.SET_UP_QUEUE ( )

CONNECT streamadmin/streamadmin@destination

EXECUTE DBMS_STREAMS_ADM.SET_UP_QUEUE ( )

Коли указано специально, очереди в обеих БД (и таблицы для данных этих очередей) получили умолчательные названия. Их можно наблюдать так:

SQL> CONNECT streamadmin/streamadmin@source
Connected.
SQL> SELECT name, queue_table FROM user_queues;

NAME QUEUE_TABLE ------------------------------ ------------------------------ STREAMS_QUEUE STREAMS_QUEUE_TABLE AQ$_STREAMS_QUEUE_TABLE_E STREAMS_QUEUE_TABLE

Очередь AQ$_*_E создается автоматически для сообщений об ошибках обработки событий.

Для возможности передавать потоком изменения в исходной таблице SCOTT.EMP требуется заявить расширенную журнализацию хотя бы для этой таблицы:

CONNECT scott/tiger@source

ALTER TABLE emp ADD SUPPLEMENTAL LOG DATA ( PRIMARY KEY ) COLUMNS;

Проверка:

SQL> SELECT always, table_name, log_group_type FROM user_log_groups;

ALWAYS      TABLE_NAME                     LOG_GROUP_TYPE
----------- ------------------------------ -------------------
ALWAYS      EMP                            PRIMARY KEY LOGGING

Теперь правка любого поля в таблице EMP будет сопровождаться (безусловно) занесением в журнал не только старого и нового значений этого поля, но также и значения ключевого поля (то есть EMPNO).

В БД-источнике создадим процесс захвата изменений, одновременно указав правила отбора изменений в очередь:

CONNECT streamadmin/streamadmin@source

BEGIN
DBMS_STREAMS_ADM.ADD_TABLE_RULES (
  table_name     => 'scott.emp'
, streams_type   => 'capture'
, streams_name   => 'capture_stream'
, include_ddl    => TRUE
);
END;
/
Проверка:
SQL> SELECT capture_name, queue_name, queue_owner, status
  2  FROM all_capture;

CAPTURE_NAME       QUEUE_NAME         QUEUE_OWNER        STATUS
------------------ ------------------ ------------------ --------
CAPTURE_STREAM     STREAMS_QUEUE      STREAMADMIN        DISABLED

Среди прочих умолчаний при создании процесса захвата изменений выше использовано подразумеваемое молчаливо имя очереди STREAMS_QUEUE. В нашем случае это можно было бы обозначить явно, указав параметр QUEUE_NAME => 'streamadmin.streams_queue'. Этим же параметром можно воспользоваться, когда процесс захвата потребуется связать с очередью под иным именем.

Правила отбора изменений в очередь STREAMS_QUEUE также были построены автоматически, но могли бы быть дополнены, или даже выписаны явно с помощью других параметров процедуры ADD_TABLE_RULES.

Создадим процесс переноса изменений:

BEGIN
DBMS_STREAMS_ADM.ADD_TABLE_PROPAGATION_RULES (
  table_name            => 'scott.emp'
, streams_name      	=> 'maindb_to_subdb1'
, source_queue_name 	=> 'streamadmin.streams_queue'
, destination_queue_name
                        => 'streamadmin.streams_queue@subdb1.class'
, source_database   	=> 'maindb.class'
, include_ddl       	=> TRUE
);
END;
/
Проверка:
SQL> SELECT propagation_name, source_queue_name,
  2         destination_queue_name, status
  3  FROM dba_propagation;

PROPAGATION_NAME SOURCE_QUEUE_NAME DESTINATION_QUEUE_NAM STATUS
---------------- ----------------- --------------------- -------
MAINDB_TO_SUBDB1 STREAMS_QUEUE     STREAMS_QUEUE         ENABLED

Теперь для правильного воспроизведения изменений в принимающей БД требуется передать ей в качестве "точки отсчета" номер изменений в БД-источнике. Передаваться получателям будут только изменения в EMP с номерами более поздними:

BEGIN
DBMS_APPLY_ADM.SET_TABLE_INSTANTIATION_SCN@subdb1.class (
  source_object_name   => 'scott.emp'
, source_database_name => 'maindb.class'
, instantiation_scn    => DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER
);
END;
/
Убедиться в учете процессом применения для таблиц точки отсчета можно запросом:
SQL> COLUMN source_database FORMAT A20
SQL> SELECT
  2    source_object_name, source_object_type, instantiation_scn
  3  FROM  dba_apply_instantiated_objects@subdb1.class;

SOURCE_OBJECT_NAME             SOURCE_OBJE INSTANTIATION_SCN
------------------------------ ----------- -----------------
EMP                            TABLE                 1200698
Принимающая БД готова к активации процесса применения изменений:
CONNECT streamadmin/streamadmin@destination 

BEGIN
DBMS_STREAMS_ADM.ADD_TABLE_RULES (
  table_name      => 'scott.emp'
, streams_type    => 'apply'
, streams_name    => 'apply_stream'
, source_database => 'maindb.class'
, include_ddl     => TRUE
);
END;
/
Проверка:
SQL> SELECT apply_name, queue_name, status FROM all_apply;

APPLY_NAME               QUEUE_NAME               STATUS
------------------------ ------------------------ --------
APPLY_STREAM             STREAMS_QUEUE            DISABLED
Для удобства отключим реакцию на ошибки, иначе процесс применения изменений может самопроизвольно прекращаться:
BEGIN
DBMS_APPLY_ADM.SET_PARAMETER (
  apply_name  => 'apply_stream'
, parameter   => 'disable_on_error'
, value       => 'N'
);
END;
/
Осталось запустить процессы захвата и примения изменений:
CONNECT streamadmin/streamadmin@source 

EXECUTE DBMS_CAPTURE_ADM.START_CAPTURE ( 'capture_stream' )

EXECUTE -
DBMS_APPLY_ADM.START_APPLY@subdb1.class ( 'apply_stream' )
Проверка:
SQL> CONNECT streamadmin/streamadmin@source
Connected.
SQL> SELECT empno FROM scott.emp MINUS
  2  SELECT empno FROM scott.emp@subdb1.class
  3  .
SQL> SAVE delta REPLACE
Wrote file delta.sql
SQL> @delta

no rows selected

SQL> INSERT INTO scott.emp ( empno ) VALUES ( 3333 );

1 row created.

SQL> @delta

     EMPNO
----------
      3333

SQL> COMMIT;

Commit complete.

SQL> @delta

no rows selected
Заметьте, что поток переносит изменения только в одну сторону. Таблица-приемник при этом не закрыта от обычной правки. Однако же такую правку следует выполнять осмотрительно, поскольку она может привести к ошибкам при автоматическом изменении данных потоком (эта проблема решается специально седствами разрешении конфликтов). Вдобавок учтите, что множественные операции INSERT, UPDATE, DELETE применяются в принимающей БД в рамках одной (автономной) транзакции (невзирая на то, что в журнале БД множественные изменения фиксируются набором однострочных изменений). Следовательно ошибка хотя бы в изменении одной-единственной строки приведет к отказу изменений всей множественной операции.

Упражнение. Внести изменения в таблицу SCOTT.EMP на принимающей БД. Убедиться в сохраняющихся расхождениях в таблицах БД-источника и БД-получателя.

Упражнение. Проверить передачу изменений DDL. Добавить столбец в таблицу SCOTT.EMP@MAINDB.CLASS. Наблюдать результат в SCOTT.EMP@SUBDB1.CLASS. Изменить тип столбца, наблюдать результат в базе-получателе.


1 До версии 10 использовалось название Advanced Queuing (AQ).

1 Начиная с версии 10.2.

Размещение рекламы — тел. +7 495 4119920, ICQ 232284597

Подписка на новости IT-портала CITForum.ru
(библиотека, CITKIT.ru, CitCity)

Новые публикации:

24 декабря

CITKIT.ru:

  • Новогодние поздравления
  • Сергей Кузнецов. Цикл Операционные системы: Ностальгия по будущему:

  • Алексей Федорчук. OpenSolaris 2008.11 Release

  • Сергей Голубев:

  • Евгений Чайкин aka StraNNik (Блогометки):

    17 декабря

  • С.Д.Кузнецов. Базы данных. Вводный курс

    10 декабря

    CITKIT.ru:

  • OpenSolaris 2008.11 Release

  • Альтернативные ОС: две грустные истории (С.Кузнецов)
  • Nokia N810 — доведение до ума
  • CitCity:

  • Платформа 2009: заоблачные перспективы Microsoft

    4 декабря

  • Лекция С.Д.Кузнецова Понятие модели данных. Обзор разновидностей моделей данных

    CITKIT.ru:

  • OpenSolaris 2008.11 Release. Первые впечатления

  • Linux vs FreeBSD: продолжим "Священные войны"?

  • Nokia N810 as is

  • Индульгенция для FOSS

  • Друзья СПО'2008

    26 ноября

  • Нечеткое сравнение коллекций: семантический и алгоритмический аспекты

    CitCity:

    CITKIT.ru:

  • Глава из книги А.Федорчука
    Сага о FreeBSD:
  • 19 ноября

  • Проблемы экономики производства крупных программных продуктов

  • Язык модификации данных формата XML функциональными методами

    CITKIT.ru:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:

    Заметки к книге:

  • FreeBSD: монтирование сменных устройств и механизм HAL
  • Текстовый редактор ee

    12 ноября

  • Правило пяти минут двадцать лет спустя, и как флэш-память изменяет правила (Гоц Грейф, перевод: Сергей Кузнецов)

    CITKIT.ru:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:
  • OSS в России: взгляд правоведа (В.Житомирский)

  • Новая статья из цикла С.Голубева "Железный марш":

    29 октября

  • О некоторых задачах обратной инженерии

  • Веб-сервисы и Ruby

  • Тестирование web-приложений с помощью Ruby

    CITKIT.ru:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:

  • PuppyRus Linux - беседа с разработчиком (С.Голубев)

  • Сергей Кузнецов. Заметка не про Linux

    22 октября

  • Обзор методов описания встраиваемой аппаратуры и построения инструментария кросс-разработки

    CITKIT.ru:

  • Сергей Кузнецов. Почему я равнодушен к Linux

  • Глава из книги А.Федорчука
    Сага о FreeBSD:
  • Что надо иметь
    3. Базовые познания

    CitCity:

  • Управление IT-инфраструктурой на основе продуктов Microsoft

    15 октября

  • Методы бикластеризации для анализа интернет-данных

    CitCity:

  • Разъемы на ноутбуках: что они дают и зачем их так много?
  • AMD Puma и Intel Centrino 2: кто лучше?

    CITKIT.ru:

  • Новый цикл статей С.Голубева
    Железный марш:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:

    8 октября

  • Автоматизация тестирования web-приложений, основанных на скриптовых языках
  • Опыт применения технологии Azov для тестирования библиотеки Qt3

    Обзоры журнала Computer:

  • SOA с гарантией качества
  • Пикоджоуль ватт бережет
  • ICT и всемирное развитие

    CitCity:

  • Пиррова победа корпорации Microsoft

    CITKIT.ru:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:

    Статья из архива:

  • Я живу в FreeBSD (Вадим Колонцов)

    Новые Блогометки:

  • Перекройка шаблона Blogger или N шагов к настоящему
  • Blogger. Comment style
  • Screenie или глянцевый снимок экрана

    2 октября

    CITKIT.ru:

  • Сага о FreeBSD (А. Федорчук)

    Zenwalk: пакет недели

  • Банинг — интеллектуальное развлечение (С.Голубев)

    CitCity:

    25 сентября

  • Клермонтский отчет об исследованиях в области баз данных

    CITKIT.ru:

  • Пользователям просьба не беспокоиться... (В.Попов)

  • Снова про ZFS: диск хорошо, а два лучше
  • Командная оболочка tcsh (А.Федорчук)

    Zenwalk: пакет недели

    17 сентября

  • T2C: технология автоматизированной разработки тестов базовой функциональности программных интерфейсов
  • Технология Azov автоматизации массового создания тестов работоспособности

    CITKIT.ru:

  • FreeBSD: ZFS vs UFS, и обе-две — против всех (А.Федорчук)

    Zenwalk: пакет недели

  • Дачнет — практика без теории (С.Голубев)

    10 сентября

  • За чем следить и чем управлять при работе приложений с Oracle
  • Планировщик заданий в Oracle
    (В.Пржиялковский)

    CITKIT.ru:

  • Microsoft: ответный "боян" (С.Голубев)

  • Причуды симбиоза, или снова "сделай сам" (В.Попов)

  • Файловые системы современного Linux'а: последнее тестирование
  • Zsh. Введение и обзор возможностей
    (А.Федорчук)

    Описания пакетов Zenwalk: Zsh, Thunar, Thunar-bulk-rename, Xfce4-places-plugin, Xfce4-fsguard-plugin

    Блогометки:

  • Google Chrome
  • Лончер для ASUS Eee PC 701

    3 сентября

    CITKIT.ru:

  • Заметки о ядре (А.Федорчук):

    Добавлены описания пакетов Zenwalk: Galculator, Screenshot, Gnumeric, Pidgin

    В дискуссинном клубе:

  • И еще о Википедии и Google Knol

  • Лекция для начинающего линуксоида (С.Голубев)

    26 августа

  • Транзакционная память (Пересказ: С. Кузнецов)

    CITKIT.ru:

  • Открыт новый проект Zenwalk: пакет недели

  • Статья Текстовые процессоры и их быстродействие: конец еще одной легенды?

    21 августа

    CITKIT.ru:

  • Почему школам следует использовать только свободные программы (Ричард Столлман)
  • Беседа Сергея Голубева с учителем В.В.Михайловым

  • Википедия или Гуглезнание? Приглашение к обсуждению (Алексей Федорчук)
  • Народная энциклопедия от Google (StraNNik)

  • Обзор Mandriva 2009.0 Beta 1 Thornicrofti
  • Новичок в Линукс: Оптимизируем Mandriva 2008.1

  • Книга Zenwalk. Приобщение к Linux:

    13 августа

    CitCity:

  • Мирный Atom на службе человеку. Обзор платы Intel D945GCLF с интегрированным процессором
  • Обзор процессоров Intel Atom 230 на ядре Diamondville

  • iPhone - год спустя. Скоро и в России?

    CITKIT.ru:

  • Интермедия 3.4. GRUB: установка и настройка (из книги Zenwalk. Приобщение к Linux)

    6 августа

  • СУБД с хранением данных по столбцами и по строкам: насколько они отличаются в действительности? (Пересказ: С. Кузнецов)

    CITKIT.ru:

  • Интермедия 2.2. Что неплохо знать для начала (из книги Zenwalk. Приобщение к Linux)

  • И снова про шрифты в Иксах (А.Федорчук)

  • 20 самых быстрых и простых оконных менеджеров для Linux

  • Дело о трех миллиардах (С.Голубев)

    30 июля

  • OLTP в Зазеркалье (Пересказ: С. Кузнецов)

    CitCity:

  • Будущее BI в облаках?
  • Тиражные приложения и заказная разработка. Преимущества для заказчика
  • Дискуссия со сторонниками заказной разработки

    CITKIT.ru:

  • Новые главы книги Zenwalk. Приобщение к Linux:
  • Глава 8. Пакеты: средства установки, системы управления, системы построения
  • Глава 9. Zenwalk: репозитории, пакеты, методы установки

    23 июля

    CITKIT.ru:

  • Все против всех. 64 vs 32, Intel vs AMD, tmpfs vs ext3
  • Две головы от Intel

  • Zenwalk: обзор штатных приложений (глава из книги "Zenwalk. Приобщение к Linux")

  • Нормально, Григорий...

    16 июля

    Обзоры журнала Computer:

  • Перспективы и проблемы программной инженерии в XXI веке
  • Большие хлопоты с большими объемами данных
  • Перспективы наноэлектроники

    CITKIT.ru:

  • Интермедия о лицензиях (А.Федорчук. "Zenwalk. Приобщение к Linux")

  • Есть ли будущее у KDE?

  • Linux в школе: альтернативный вариант в задачах

  • Шифр (приключения агента Никодима)

    10 июля

    CITKIT.ru:

  • Новые разделы книги А. Федорчука Zenwalk. Приобщение к Linux:
  • Интермедия вступительная. Linux или GNU/Linux? Как вас теперь называть?
  • Глава 5. Среда Xfce
  • Глава 6. Xfce: приложения и плагины

  • ZUR (Zenwalk User Repository) FAQ

    2 июля

  • Персистентность данных в объектно-ориентированных приложениях (С. Кузнецов)

    CITKIT.ru:

  • Новые разделы книги А. Федорчука Zenwalk. Приобщение к Linux:
  • Интермедия 1.2. Дорога к Zenwalk'у. Период бури и натиска
  • Интермедия 3.3. Немного о Linux'е и "железе"
  • Глава 4. Настройка: инструментами и руками
  • Интермедия 4.1. Zenpanel и конфиги: поиски корреляции

  • Интервью с Жан-Филиппом Гийоменом, создателем дистрибутива Zenwalk

  • Linux в школе: первые итоги (С. Голубев)

    25 июня

    CITKIT.ru:

  • Zenwalk. Приобщение к Linux (А. Федорчук)

  • Логика и риторика (С.Голубев)

  • Технология Tru64 AdvFS

  • Ханс Райзер предлагает отвести полицейских к телу Нины

    18 июня

  • Проекты по управлению данными в Google (Пересказ: С. Кузнецов)

    CITKIT.ru:

  • ОС и поддержка "железа": мифы и реальность (А. Федорчук)

  • Linux в школе: другие дистрибутивы

  • Пинок (С. Голубев)

    4 июня

  • Ландшафт области управления данными: аналитический обзор (С. Кузнецов)

    CITKIT.ru:

  • Linux в школе: слово заинтересованным лицам

  • SlackBuild: пакеты своими руками

  • Linux от компании Novell. Установка и обзор openSUSE Linux

    Все публикации >>>




  • IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

    Информация для рекламодателей PR-акции, размещение рекламы — тел. +7 495 4119920, ICQ 232284597 Пресс-релизы — pr@citcity.ru
    Послать комментарий
    Информация для авторов
    Rambler's Top100 TopList liveinternet.ru: показано число просмотров за 24 часа, посетителей за 24 часа и за сегодня This Web server launched on February 24, 1997
    Copyright © 1997-2000 CIT, © 2001-2007 CIT Forum
    Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав. Подробнее...