| Newsgroups |
gmane.comp.db.mckoi |
| Message-ID |
<[email protected]> |
Toby, I will do that, in the meantime, here is my start-log, my server has
2GB of RAM, so I changed McKoi default cache values, it has been working
Ok with these values for several weeks:
**** Debug log started: Mon Nov 22 12:38:50 VET 2004 ****
% Storage System: v1 file storage mode.
% Internal Data Cache size: 67108864
% Internal Data Cache max cell size: 64000
% lookup_comparison_list = false
% read_only = false
% transaction_error_on_dirty_select = true
% ignore_case_for_identifiers = false
% Java NIO API is available.
% io_safety_level = 10
% Using stardard IO API for heap buffered file access.
% [Buffer Manager] Using IO API: Java IO
% [Buffer Manager] Page Size: 8192
% [Buffer Manager] Max pages: 256
% Using regex bridge: gnu.regexp
% No 'function_factories' config property found.
% statement_cache = true
% Max worker threads set to: 10
% Starting Database Server
Regards,
Martin
> Martin,
>
> What I suggest you do is take the database offline completely and make a
> manual copy of the database file. Run the repair tool on the copy of
> the database and see if it detects any problems.
>
> This could be a cache or file fragmentation issue. You might want to
> try running the online backup procedure on the copy of the database and
> see if the times stay the same, which would rule out a fragmentation
> problem.
>
> Toby.
>
>
>
> [email protected] wrote:
>> Toby, the database size did not change significantly, the actual size
>> of the backup -compressed with TAR- is about 16MB.
>>
>> I am concerned, because the backup process jump from 1 minute to 8
>> minutes overnight, after the server restart.
>>
>> I wonder if setting a debug-level=20 would shed more light about it,
>> while executing the backup.
>>
>> I checked the server boot log and did not find relevant ReiserFS
>> messages regarding filesystem corruption, the SATA disk seems to be
>> working OK. No patches has been applied to this system after the
>> restart. This is a very fast disk (Raptor 10000RPM - 54.7MB/sec
>> reported with hdparm -t), and online backups take no longer than 1-1.2
>> minutes before the forced restart.
>>
>> Should I run the repair tool to see if it does detect something?
>>
>> Any help will be appreciated.
>>
>> Best regards,
>> Martin
>>
>>
>>
>>>Did the database change in size since the Linux server was restarted?
>>> What size is the database? Did the configuration of the machine
>>> change in any way? I don't think this is something to be too
>>> concerned with because there's many reasons why it may take a little
>>> longer.
>>>
>>>Toby.
>>>
>>>
>>>[email protected] wrote:
>>>
>>>
>>>>Toby:
>>>>
>>>>I have database with several schemas, regular online backup takes
>>>> about 1 minute, sometimes a little more. Three days ago the server
>>>> (linux) was restarted without properly shutting down the McKoi
>>>>service. After that, the backup takes about 8 minutes!
>>>>
>>>>I tried restoring a backup to see if backup process comes back to
>>>> normal times, but it keeps executing for 8 minutes.
>>>>
>>>>We have not detected any data loss after the reset -yet-, no problems
>>>> reported when starting McKoi with debug-level=30.
>>>>
>>>>Any ideas?
>>>>
>>>>Best regards,
>>>>Martin
>>>
>>>
>>>
>>>---------------------------------------------------------------
>>>Mckoi SQL Database mailing list http://www.mckoi.com/database/
>>>To unsubscribe, send a message to [email protected]
>>
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------
>> Mckoi SQL Database mailing list http://www.mckoi.com/database/
>> To unsubscribe, send a message to [email protected]
>>
>>
>
>
>
> ---------------------------------------------------------------
> Mckoi SQL Database mailing list http://www.mckoi.com/database/
> To unsubscribe, send a message to [email protected]
---------------------------------------------------------------
Mckoi SQL Database mailing list http://www.mckoi.com/database/
To unsubscribe, send a message to [email protected]