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

23.05.2005

Google
WWW CITForum.ru

Новости мира IT:

  • 11.05 - Intel создает свою группу по Open Source
  • 11.05 - Банк контролирует использование USB устройств при помощи DeviceLock
  • 11.05 - Microsoft устранила опасную дыру в Windows
  • 11.05 - "Корпорация ОСС" создает антимонопольный альянс операторов IP-телефонии
  • 11.05 - В Mac OS X найдены множественные уязвимости
  • 11.05 - "Билайн" запускает услугу "Мобильная почта"
  • 11.05 - Две критические уязвимости в браузере Firefox 1.0.3
  • 11.05 - IBM покупает начинающую Open Source-компанию Gluecode
  • 11.05 - Microsoft готова к битве с Open Source за школы
  • 11.05 - Sun завершит "открытие" Solaris в ближайшие 45 дней
  • 11.05 - Создатели браузера Firefox выпускают юбилейные монеты в честь 50 миллионов скачанных копий
  • 11.05 - Вышла пятая версия мобильной ОС от Microsoft
  • 11.05 - Поисковые движки умнеют быстрее, чем люди
  • 11.05 - Фишеры постоянно совершенствуются
  • 11.05 - Специалисты прогнозируют появление аналога Google Adsense от "Яндекс"
  • 06.05 - ICANN озаботилась проблемой торговых марок
  • 06.05 - Google патентует сортировку новостей
  • 06.05 - Intel готовит двуядерные процессоры второго поколения
  • 06.05 - Schoolforge-UK и OSC продвигают Open Source в школы
  • 06.05 - Новая версия рекламной программы подстрекает пользователей купить ПО для своего лечения
  • 06.05 - Microsoft продает ряд своих закрытых разработок
  • 06.05 - Google Labs анонсировал ускоритель интернета
  • 06.05 - Microsoft подвешивает пиратам "морковку"
  • 06.05 - В США входят в обиход "интеллектуальные" тележки для супермаркетов
  • 06.05 - Microsoft работает над аналогом PDF
  • 05.05 - Yahoo video search теперь доступен массам
  • 05.05 - Алмазы помогут бороться с хакерами
  • 05.05 - Интернет-охоту хотят запретить
  • 05.05 - Microsoft привлекает блоггеров для теста Longhorn
  • 05.05 - Основатель Red Hat предложил Стиву Джобсу помощь в решении проблемы с торговой маркой
  • 05.05 - Компьютерная система оргкомитета Кубка мира по футболу 2006 года пострадала от червя Sober
  • 04.05 - Cisco Systems представила многофункциональный продукт Adaptive Security Appliance 5500
  • 04.05 - Администрация Евросоюза поддержала идею всеевропейской интернет-библиотеки
  • 04.05 - Компьютерный вирус дарит билеты на чемпионат мира по футболу
  • 04.05 - Лаборатория Касперского: Обзор вирусной активности - апрель 2005
  • 04.05 - Microsoft хочет отсудить у россиянина два домена
  • 04.05 - Сделка между Lenovo и IBM завершена
  • 04.05 - Эпидемия червя Sober.p зафиксирована в Западной Европе
  • 04.05 - Panda Software публикует отчет о вирусной активности за апрель
  • 03.05 - Институт SANS обновил список наиболее опасных уязвимостей

    Архив новостей >>>


  • 2004 г.

    Статистическая информация уровня сегмента в событии 10046 Oracle 9.2

    Энди Ривенес, AppsDBA Consulting
    Перевод Валерия Кравчука

    Версия 1.1

    Copyright © 2003 by AppsDBA Consulting, All Rights Reserved.

    Введение

    В версии 9.2 в Oracle добавилась возможность получать "статистическую информацию уровня сегмента". К словарю данных было добавлено несколько представлений v$, и для сбора соответствующей информации можно избирательно включать сбор статистики на уровне сегмента. Однако при выполнении трассировки с помощью события 10046 эта статистическая информация тоже выдается1. По-видимому, хотя я и не нашел еще никакой определенной информации об этом, она появилась в наборе исправлений 9.2.0.2. Поскольку это - статистическая информация "источника строк" ("row source" statistics), она будет входить в строки STAT. Дополнительная информация - часть информации об операции доступа к источнику строк, а именно - поле "op=". В этой статье мы разберемся, как найти эту информацию и как ее можно использовать. В выдаваемых данных есть определенные рассогласования, но, в общем случае, эта статистическая информация уровня сегмента дает специалисту по анализу производительности дополнительную важную информацию для изучения времени выполнения транзакции и влияющих на него факторов.

    Формат строки STAT

    В файле трассировки события 10046 статистическая информация уровня сегмента выдается в строках STAT. Это - статистическая информация "источника строк", и дополнительная информация входит в общую информацию об операции доступа к источнику строк, в поле "op=". Вот два примера, один - из файла трассировки до 9.2, а другой - из файла трассировки 9.2.

    Файл трассировки до версии 9.2:

    STAT #5 id=1 cnt=1 pid=0 pos=0 obj=43135
    op='TABLE ACCESS CLUSTER SEG$ '

    Новый формат файла трассировки 9.2:

    STAT #1 id=1 cnt=1 pid=0 pos=1 obj=0
    op='SORT AGGREGATE (cr=167 r=4 w=0 time=31888 us)'

    Обратите внимание на новую информацию, "(cr=167 r=4 w=0 time=31888 us)". Значение "cr=" соответствует количеству операций логического ввода-вывода consistent reads, значение "r=" - количеству физических чтений, значение "w=" - количеству физических записей, а значение "time=" определяет время выполнения и единицу измерения времени (например, us - микросекунды). Учтите, что логический ввод-вывод "current mode" (т.е. cu= в трассировочном файле) не выдается.

    Статистическая информация уровня сегмента, по-видимому, выдается только для операций EXEC и FETCH. В контексте строк STAT для конкретного оператора, данные "накапливаются" ("roll-up") в иерархии плана выполнения, по крайней мере, в большинстве случаев 2. При интерпретации информации строка STAT с ненулевым значением "obj=" идентифицирует статистическую информацию о доступе к соответствующему сегменту. Эти значения будут "накапливаться" по ходу плана выполнения, и обычно строки STAT с нулевыми значениями "obj=" будут суммировать статистическую информацию подчиненных источников строк.

    Представление статистической информации

    Итак, что же можно определить по этой информации? В трассировочных файлах версий до 9.2 типичная итоговая информация в строке STAT будет иметь вид (Release 8.1.7.2):

    STATEMENT TEXT
    
    select count(*) from dba_users
    
    STATEMENT EXECUTION PLAN
    
       Rows  Row Source Operation
    -------  -----------------------------------------------
          1  SORT AGGREGATE
     12,047   MERGE JOIN
     12,048    SORT JOIN
     12,047     NESTED LOOPS
     12,048      NESTED LOOPS
     12,048       NESTED LOOPS
     12,048        MERGE JOIN
         10         SORT JOIN
          9          NESTED LOOPS
         10           TABLE ACCESS FULL USER_ASTATUS_MAP
          9           TABLE ACCESS BY INDEX ROWID PROFILE$
        162            INDEX RANGE SCAN (object id 43224)
     12,056         SORT JOIN
     12,047          TABLE ACCESS FULL USER$
     24,094        TABLE ACCESS CLUSTER TS$
     24,094         INDEX UNIQUE SCAN (object id 43126)
     24,094       TABLE ACCESS CLUSTER TS$
     24,094        INDEX UNIQUE SCAN (object id 43126)
     12,047      TABLE ACCESS BY INDEX ROWID PROFILE$
    216,846       INDEX RANGE SCAN (object id 43224)
     12,047    SORT JOIN
          7     TABLE ACCESS FULL PROFNAME$
    

    Сейчас, в версии 9.2, информация имеет следующий вид (Release 9.2.0.2):

    STATEMENT TEXT
    
    select count(*) from dba_users
    
    STATEMENT EXECUTION PLAN
    
       Rows  Row Source Operation
    -------  -------------------------------------------------
          1  SORT AGGREGATE (cr=167 r=4 w=0 time=31888 us)
         36   MERGE JOIN (cr=167 r=4 w=0 time=31863 us)
         36    SORT JOIN (cr=164 r=3 w=0 time=30441 us)
         36     TABLE ACCESS BY INDEX ROWID PROFILE$ 
    (cr=164 r=3 w=0 time=29994 us) 649 NESTED LOOPS (cr=163 r=3 w=0 time=25712 us) 36 NESTED LOOPS (cr=161 r=3 w=0 time=22979 us) 36 NESTED LOOPS (cr=87 r=3 w=0 time=21223 us) 36 MERGE JOIN (cr=13 r=3 w=0 time=19489 us) 9 SORT JOIN (cr=6 r=3 w=0 time=18519 us) 9 TABLE ACCESS BY INDEX ROWID PROFILE$
    (cr=6 r=3 w=0 time=18313 us) 163 NESTED LOOPS (cr=5 r=2 w=0 time=11319 us) 9 TABLE ACCESS FULL USER_ASTATUS_MAP
    (cr=3 r=1 w=0 time=1278 us) 153 INDEX RANGE SCAN I_PROFILE
    (cr=2 r=1 w=0 time=9769 us) (object id 139) 36 SORT JOIN (cr=7 r=0 w=0 time=837 us) 36 TABLE ACCESS FULL USER$ (cr=7
    r=0 w=0 time=420 us) 36 TABLE ACCESS CLUSTER TS$ (cr=74
    r=0 w=0 time=1535 us) 36 INDEX UNIQUE SCAN I_TS# (cr=2
    r=0 w=0 time=206 us) (object id 7) 36 TABLE ACCESS CLUSTER TS$ (cr=74
    r=0 w=0 time=1563 us) 36 INDEX UNIQUE SCAN I_TS# (cr=2
    r=0 w=0 time=145 us) (object id 7) 612 INDEX RANGE SCAN I_PROFILE (cr=2
    r=0 w=0 time=1219 us) (object id 139) 36 SORT JOIN (cr=3 r=1 w=0 time=1283 us) 1 TABLE ACCESS FULL PROFNAME$ (cr=3
    r=1 w=0 time=936 us)

    На основе этой информации мы можем получить статистику по сегментам и определить вклад каждого сегмента в использование ресурсов на этапах EXEC и FETCH выполнения оператора. С учетом представленного выше примера, для каждого сегмента получаем следующую статистику:

      
                                                                     Elapsed
     Object ID  LIO (cr=)        Physical Reads   Physical Writes  Time(sec)
    ------------  ---------------  ---------------  ---------------  ---------------
              94  2                1                0                0.011276
             139  4                1                0                0.010988
              16  144              0                0                0.002747
             280  3                1                0                0.001278
              95  3                1                0                0.000936
              22  7                0                0                0.000420
               7  4                0                0                0.000351
    ------------  ---------------  ---------------  ---------------  ---------------
           Total  167              4                0                0.027996
    

    Эти итоговые данные были получены с помощью описанного ранее подхода. В строке STAT каждого оператора будет идентификатор (параметр id=) строки и идентификатор родительской строки (параметр pid=). Самая верхняя строка в иерархии будет иметь идентификатор 1 и идентификатор родительской строки, равный 0. Строки STAT с ненулевым значением "obj=" будут содержать статистическую информацию о доступе к соответствующему сегменту. Эти значения будут накапливаться по иерархии плана выполнения, и, обычно, строки STAT со значениями 0 у параметра "obj=" будут суммировать статистические показатели своих порожденных источников строк.

    Проверка статистической информации

    Пример 1

    Если сравнить полученную в предыдущем примере итоговую статистическую информацию по объектам с представленной ниже реальной статистической информацией уровня оператора, можно увидеть, что общее количество логических чтений для всех сегментов равно количеству логических чтений в ходе операций EXEC и FETCH при выполнении оператора. То же самое верно и для физических чтений. Это не всегда верно, но в итоговую информацию заведомо войдет подмножество соответствующих значений, которые будут не больше и, возможно, равны суммарным значениям в статистической информации для оператора.

    STATEMENT STATISTICS
    
    Action Count        CPU    Elapsed  PIO Blks  LIO Blks  Consistent  Current   Rows
    -----  -----  ---------  ---------  --------  --------  ----------  -------  ------
    PARSE    1    0.090000   0.142649         6       149         149        0      0
    EXEC     1    0.000000   0.000465         0         0           0        0      0
    FETCH    2    0.020000   0.031909         4       167         167        0      1
    ------ ---  ----------  ---------  --------  --------  ----------  -------    -----
    Total    4    0.110000  0.175023        10       316         316        0       1
    

    Проверка реального времени выполнения (elapsed time) для статистической информации уровня сегмента представляет собой интересную проблему. Если посмотреть на реальное время выполнения операций EXEC и FETCH, и вычесть процессорное время (CPU), получаем значение 0.012374 секунды, или 12374 us. Если затем посмотреть на общее время выполнения в нашей статистике по сегментам, там можно увидеть значение 0.027996 секунды, или 27996 us, но, если вернуться и проанализировать общее время по всем источникам строк (т.е. time=31888 us), то получается немного меньше, чем общее время выполнения операций EXEC и FETCH, 0.032374 секунды, или 32374 us. В этом есть смысл, если учесть, что общее время выполнения в статистической информации уровня сегментов включает процессорное время (CPU time), необходимое для доступа к источнику строк (т.е. логического ввода-вывода), а не только время выполнения физического ввода-вывода. Следует также отметить, что в этом случае не было ввода-вывода "current mode", но подробнее об этом - в следующем примере.

    Давайте рассмотрим еще пару примеров. Что произойдет, если есть логический ввод-вывод current mode (т.е. cu= в операциях EXEC или FETCH), или в статистической информации на уровне оператора будут ненулевые значения и для EXEC, и для FETCH?

    Пример 2

    Следующий пример показывает использование ввода-вывода как consistent mode (cr=), так и current mode (cu=) в ходе операции EXEC при выполнении оператора. При изучении статистической информации уровня оператора и итогов по сегментам можно увидеть, что сервер Oracle на уровне сегмента сообщает только про ввод-вывод consistent mode. В этом примере ненулевые значения будут только в операциях EXEC, а в предыдущем примере они были только в операциях FETCH. Похоже, для операции PARSE статистическая информация уровня сегмента не выдается.

    STATEMENT TEXT
    
    delete from dependency$ where d_obj#=:1
    
    STATEMENT STATISTICS
    
     Action  Count      CPU    Elapsed  PIO Blks  LIO Blks  Consistent  Current  Rows
    -------  -----  -------  ---------  --------  --------  ----------  -------  ----
    PARSE        6  0.020000   0.012211         1        43          43        0   0
    EXEC         6  0.010000   0.019214         3        38          16       22   4
    FETCH        0  0.000000   0.000000         0         0           0        0   0
    -------  -----  --------  ---------  --------  --------  ----------  -------  -----
    Total       12  0.030000   0.031425         4        81          59       22   4
    
    
    STATEMENT EXECUTION PLAN
    
       Rows  Row Source Operation
    -------  --------------------------------------------------
          0  DELETE (cr=3 r=2 w=0 time=7656 us)
          1   TABLE ACCESS BY INDEX ROWID DEPENDENCY$ 
    (cr=3 r=0 w=0 time=63 us) 1 INDEX RANGE SCAN I_DEPENDENCY1
    (cr=2 r=0 w=0 time=37 us) (object id 127) Elapsed Object ID LIO (cr=) Physical Reads Physical Writes Time(sec) ------------ --------------- --------------- --------------- --------------- 127 2 0 0 0.000037 96 1 0 0 0.000026 ------------ --------------- --------------- --------------- --------------- Total 3 0 0 0.000063
    Пример 3

    Третий, и последний, пример показывает, что выдаваемая статистическая информация не всегда соответствует предполагаемой. В этом примере обратите внимание, что в SQL-операторе использована конструкция "FOR UPDATE", и в источниках строк мы получаем ситуацию, когда информация не накапливается, как можно было ожидать.

    STATEMENT STATISTICS
    
    Action   Count     CPU    Elapsed  PIO Blks  LIO Blks  Consistent  Current   Rows
    -------  -----  ------- ----------  --------  --------  ----------  ------- ------
    PARSE        1  0.000000  0.001438         0         0           0        0    0
    EXEC         1  0.000000  0.000430         0         4           3        1    0
    FETCH        2  0.000000  0.000143         0         3           3        0    1
    -------  -----  -------- ----------  --------  --------  ----------  ------- ------
    Total        4  0.000000 0.002011         0         7           6        1     1
    
    STATEMENT TEXT
    
    select mynum from andy
    where mynum = 99
    for update
    
    STATEMENT EXECUTION PLAN
    
       Rows  Row Source Operation
    -------  -------------------------------------------------
          1  FOR UPDATE (cr=3 r=0 w=0 time=113 us)
          2   TABLE ACCESS FULL ANDY (cr=6 r=0 w=0 time=276 us)
    
    Elapsed
    
       Object ID  LIO (cr=)        Physical Reads   Physical Writes  Time(sec)
    ------------  ---------------  ---------------  ---------------  ---------------
           30536  6                0                0                0.000276
    ------------  ---------------  ---------------  ---------------  ---------------
           Total  6                0                0                0.000276
    

    Обратите внимание, что теперь у нас есть ввод-вывод consistent read как для операции EXEC, так и для FETCH. Мы также выполнили один логический ввод-вывод current mode в ходе операции EXEC, который снова проигнорирован в статистической информации уровня сегмента.

    Вывод

    Как было продемонстрировано, статистика уровня сегмента при трассировке с помощью события 10046 в версии 9.2 дает тому, кто занимается анализом производительности, важную дополнительную информацию, помогающую выявить, какие компоненты замедляют транзакцию. Надеюсь, эта информация вдохновит на дополнительные исследования и поможет понять эти статистические показатели, а также их применение при оптимизации времени выполнения операторов.

    Ссылки

    Oracle9i Database Performance Tuning Guide and Reference, Release 2 (9.2), Oracle Corporation, March 2002, Part No. A96533-02

    Oracle9i Database Reference, Release 2 (9.2), Oracle Corporation, March 2002, Part No. A96536-02

    Note: 39817.1, Interpreting Raw SQL_TRACE and DBMS_SUPPORT.START_TRACE output, Oracle Corporation, 14-AUG-1998


    1 Поскольку статистическая информация уровня сегмента выдается в трассировке события 10046 любого уровня, она выдается и в простой трассировке SQL_TRACE.

    2 Мы представим пример оператора SELECT ... FOR UPDATE, когда это неверно, но, конечно, могут быть и другие случаи.


    Эта статья первоначально была опубликована на сайте AppsDBA Consulting. Перевод публикуется с разрешения автора.


     


    ХАЙВЕЙ - лучший российский хостинг-провайдер: хостинг, регистрация доменов, услуга Ваша@почта, поддержка 24 часа


    NetPromoter - единственный российский профессиональный комплекс программ и сервисов для раскрутки сайта и интернет-статистики


    STSS - известный поставщик надежных серверных решений различного назначения на платформе Intel (Xeon) и AMD.


    5-55: the ITIL company. Практический опыт и теоретические знания на лучших семинарах по ITIL и процессам ITSM.


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

    Новые поступления в on-line библиотеку:

    28 апреля

  • Выбор первого дистрибутива Linux: Пособие для начинающих
  • Обфускация и защита программных продуктов
  • Анализ и оптимизация циклов с помощью производящих функций
  • Стратегии объектно-реляционного отображения: систематизация и анализ на основе паттернов

    26 апреля

  • Business Intelligence обещает значительный рост в 2005 году
  • Десять основных тенденций 2005 года в области Business Intelligence и Хранилищ данных
  • Управление эффективностью бизнеса и предсказуемость
  • Увеличение эффективности бизнеса: пять ошибок управления, которых следует избегать
  • Потребность в организационных данных: модель комплексного управления эффективностью бизнеса
  • Технология Хранилищ данных для государственных учреждений
  • Оцените, насколько совершенно ваше Хранилище данных

    21 апреля

  • Исполнение моделей при помощи виртуальной машины
  • Параллельные алгоритмы компьютерной алгебры
  • От стандарта до стандарта (о стандартизации оптических разъемов)
  • За штурвалом IP-станции

    Продолжение дискуссии читателей:

  • Линукс и пользователи, или что мне не нравится в Linux
  • Еще один взгляд на альтернативные ОС (и софт для них)
  • О некомпетентности пользователя Windows
  • Переписка Долгачева В.С. и Монахова В.В.

    19 апреля

  • Межпротокольный шлюз NAT-PT с функциями DNS-ALG и FTP-ALG для обеспечения взаимодействия между сетями IPv4 и IPv6
  • Рефакторинг архитектуры программного обеспечения: выделение слоев
  • Комбинаторика слов и построение тестовых последовательностей
  • Функциональное тестирование Web-приложений на основе технологии UniTesK

    14 апреля

  • Как организовать двойную парольную защиту данных в Oracle
  • Деревянный интерфейс

    Продолжение дискуссии читателей:

  • Microsoft против мира
  • Впечатления от прочитанного

    12 апреля

  • Крупные проблемы и текущие задачи исследований в области баз данных
  • Глава 2 из книги Т.Кайта "Oracle для профессионалов"Архитектура

    Дискуссия читателей о Linux и Windows:

  • Деньги правят миром, и у кого их больше, тот и прав!
  • О злокозненности некомпетентных пользователей, или почему я не люблю ограниченных пользователей Windows

    7 апреля

  • О доблести Билла Гейтса, или почему Windows лучше, чем LINUX или Mac OS
  • Витая пара - все ли так просто?!
  • Выбираем сервер печати
  • Один слой хорошо, а два - лучше (о пишущих DVD-приводах)

    5 апреля

  • Использование Caché SQL Gateway
  • Глава 19 из книги Т.Кайта "Oracle для профессионалов"Хранимые процедуры на языке Java
  • Что такое PostgreSQL?
  • Обновлен PostgreSQL FAQ

    31 марта

  • Использование Веб-сервисов в Caché
  • Защита на уровне строк (Oracle)
  • Секции в реальном мире

    29 марта

  • Разработка успешных приложений для Oracle - первая глава из книги Тома Кайта "Oracle для профессионалов"
  • Web-сервисы: растущие опасения (мнение аналитиков IDC)
  • Технология OLAP - мощная альтернатива электронным таблицам
  • Какой модной стала подготовка отчетности

    24 марта

  • Многоверсионность данных и управление параллельными транзакциями
  • Исключение из правил. Опыт разработки и внедрения финансовой корпоративной системы
  • Обнаружение компрометаций ядра Linux с помощью gdb
  • Корпоративная сервисная шина - "бюджетный" подход к решению задач интеграции
  • Сервис-ориентированная архитектура
  • Бизнес-процессы и XML

    22 марта

  • Доступно. И точка! (обзор точек беспроводного доступа)
  • Коммутаторы Fast/Gigabit Ethernet для "большой" сети
  • Push to Talk: нажми на кнопку и ...говори
  • Сети нового поколения и технология softswitch

    17 марта

  • Часто задаваемые вопросы о proxy (proxy FAQ)
  • Самонастраивающаяся база данных: управляемые приложения и настройка SQL
  • Еще раз о волоконных трассах
  • Настраиваем русский Unicode в FreeBSD-5.3.

    10 марта

  • Еще не сказанное о волоконной оптике
  • Wi-Fi на службе оператора
  • Пора менять платформу?
    (о сокетах LGA775 и PGA478)

    Oracle:

  • Детальный аудит для практических целей
  • Шифруем свои ресурсы данных

    3 марта

  • Требования к проекту. Классификация - первый шаг к пониманию
  • Gtk vs. Qt: драки не будет
  • Управление бизнесом "по максимуму": BPM для финансовых учреждений
  • Реализация решения по управлению эффективностью бизнеса
  • Новые SerialATA-винчестеры
  • Карман для сервера

    1 марта

  • Выбрать корпус - нет ничего проще?
  • Создание виртуальной сети с удаленной загрузкой узлов
  • Текущее состояние и перспективы развития рынка интеграционных технологий
  • Интеграция корпоративной информации: новое направление
  • Архитектурные подходы к консолидации

    24 февраля

  • Каждому проекту своя методология
  • Императив интеграции
  • Безопасность IP-телефонии - полевые зарисовки
  • О злокозненности Билла Гейтса, или почему я не люблю Windows

    22 февраля

  • Oracle10: шифруем данные
  • В версии Oracle10 "виртуальные частные базы данных" данных стали избирательнее
  • Каждому (пользователю) свое (данное в таблице)
    Часть 1
    Часть 2
  • Ускоряем интернет
  • Сетевая аутентификация на практике
  • В фокусе Microsoft Virtual Server 2005

    17 февраля

    Открыт новый раздел
    Все об Open Source

    Все новости >>>



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

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