Галактика в вопросах и ответах

Nikos, переходить на Oracle только ради безопастности по-моему не имеет смысла... Может стоит попробовать "защититься" на Pervasive?.. Ну или попробуйте MSSQL, он проще в администрировании, да и не так требователен к железу... В вашем случае, как мне кажется, Oracle не выход!

'Galex', а как можно защититься на Pervasive, если должен быть доступ на файлы БД? А что касается MSSQL, то никто его не купит, т.к. Oracle уже закуплен (другие приложения на нем работают).

Где-то слышал, что 10-й первасив использует псевдонимы, т.е. базу "живьем" по идее не должно быть видно.

А затраты по обслуживанию MSSQL и Pervasive несоизмеримы просто.
Если Pervsive "поставил и забыл", то администрирование mssql - песня еще та...

Администрирование оракла уже тогда не песня а целый альбом.

Продолжаю разгонять Oracle, меняя параметры инициализации. Посмотрите кто-нибудь опытным взглядом на init.ora. Может, есть явный недочет?

galtest.__db_cache_size=1501560832
galtest.__shared_pool_size=402653184
*.audit_file_dest='D:\oracle\product\10.2.0/admin/GALTEST/adump'
*.background_dump_dest='D:\oracle\product\10.2.0/admin/GALTEST/bdump'
*.compatible='10.2.0.1.0'
*.control_files='D:\oracle\product\10.2.0/oradata/GALTEST/\control01.ctl','D:\oracle\product\10.2.0/oradata/GALTEST/\control02.ctl','D:\oracle\product\10.2.0/oradata/GALTEST/\control03.ctl'
*.core_dump_dest='D:\oracle\product\10.2.0/admin/GALTEST/cdump'
*.db_block_size=8192
*.db_domain=''
*.db_file_multiblock_read_count=16
*.db_name='GALTEST'
*.dispatchers='(PROTOCOL=TCP) (SERVICE=GALTESTXDB)'
*.java_pool_size=160M
*.job_queue_processes=10
*.large_pool_size=64M
*.nls_language='RUSSIAN'
*.nls_territory='RUSSIA'
*.open_cursors=5000
*.pga_aggregate_target=2G
*.processes=300
*.remote_login_passwordfile='EXCLUSIVE'
*.sga_max_size=2G
*.shared_pool_size=300M
*.undo_management='AUTO'
*.undo_tablespace='UNDOTBS1'
*.user_dump_dest='D:\oracle\product\10.2.0/admin/GALTEST/udump'

*.java_pool_size=0

open_cursors будет зависеть от текущих потребностей если не хватит словишь ошибку

*.processes=300 по моему для вас многовато

oiko, спасибо за ответ. java_pool_size мне не удалось установить в 0, не дает меньше 8 Mb. Но это, наверное, вряд ли скажется на производительности существенным образом? У меня по прежнему Галактика на Oracle работает медленнее чем на Pervasive (сейчас раза в 2,5). Может что-то не то с самим ораклом? Я запускаю на клиенте Enterprise Manager Console, так прежде чем открыться проходит порядка 30 сек (висит черное консольное окно). Не долго ли?

какие параметры у файлов табличных пр-в и самих табличных пр-в?
где сидит схема gal?

Параметры табличных пространств:
1. GAL_INDEX
Bigfile tablespace No
Status ReadWrite
Type Permanent
Extent Management local

Storage
Allocation Type Automatic
Segment Space Management Automatic
Enable logging Yes
Block Size (B) 8192

GALINDEX01.DBF
Status Online
File Size (KB) 20480000
AutoExtend Yes
Increment 100MB
Maximum File Size 32767MB


2. GAL_USER
Bigfile tablespace No
Status ReadWrite
Type Permanent
Default Permanent Yes
Extent Management local

Storage
Allocation Type Automatic
Segment Space Management Automatic
Enable logging Yes
Block Size (B) 8192

USERS01.DBF
Status Online
File Size (KB) 13312000
AutoExtend Yes
Increment 100MB
Maximum File Size 32767MB

3. GAL_JOURNAL
Bigfile tablespace No
Status ReadWrite
Type Permanent
Extent Management local

Storage
Allocation Type Automatic
Segment Space Management Automatic
Enable logging Yes
Block Size (B) 8192
GALJOURNAL.DBF
Status Online
File Size (KB) 614400
AutoExtend Yes
Increment 100MB
Maximum File Size 32767MB

4. GAL_TEMP
Bigfile tablespace No
Status ReadWrite
Type Temporary
Extent Management local

Storage
Allocation Type Uniform
Size (KB) 1024
Enable logging No
Block Size (B) 8192

GALTEMP01.DBF
Status Online
File Size (KB) 614400
AutoExtend Yes
Increment 100MB
Maximum File Size 32767MB

Схемы Gal у меня вообще нет, а есть схема TEST (в ней и все таблицы Галактики). А что значит где она сидит?

Nikos: вы ничего не пишите о конфигурации вашего железа, в частности, дискового массива. Например, использование raid1 шустрее чем raid5. Я сталкивался с необходимостью провесити analyze некотрых таблиц под версиями 7.11 и 7.12 (5.84 не помню уже), после перехода с 5.73. Сейчас только перешли на 8.1 этого не делал. На форуме уже обсуждалась тема дисковых массивов. Все стандартные рекомендации для оракла: файлы разных пространств - на разных дисках.

Сервер 2*2400 Mhz, RAM 6 Gb, RAID5.
RAID1 вряд ли на столько поможет, т.к. на ТОМ ЖЕ САМОМ сервере на Pervasive работает в разы быстрее (сейчас в 3 раза). Файлы разных пространств нет возможности поместить на разные диски. А табличные пространства правильно созданы?

С моей точки зрения, нельзя сравнивать Pervasive и Oracle. Архитектруа у них разная. Из собственного опыта: начинали работать с галактикой оракл, raid5, 2-х процессорный Xeon 500. Такая процедура как закрытие месяца продолжалась около 8 часов. После перехода на 2-х процессорный 1Ггц (перешли на новую версию галактики), raid1 для разных табл. пространств, та же процедура укладывалась минут в 30-40. Табл. пространства я создаю доверяя ораклу, ставлю только свой размер, размещение и количество файлов в пространстве.

У меня сомнения с табличным пространством GAL_TEMP (при создании БД я его указываю для временного пространства). Я ему указал тип Temporary - может, нужно было Permanent? Да и данных там нет совсем, хотя уже с месяц тестирую.

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