No subject

inventory to me - we did until recently have some lost assets after SI =
sessions due to asset server crashing - previously the code would =
attempt to store assets with descriptions bigger than database field =
length. This seemed to happen mostly with SI uploaded items but also was =
100% reproducible if you had a sim with a long name and a parcel with a =
long name and attempted to create a landmark - there are checks now to =
stop this from happening that Justin kindly committed (and he was good =
enough to add similar checks for MySQL) and we've not had a crash since =
applying that patch over a week and a half ago. In terms of actual =
inventory, no-one has reported loss of specific items. Sometimes slow to =
load, but not loss.

Is this something that has happened since 0.6.6 tag?

Chris

-----Original Message-----
From: opensim-dev-bounces at lists.berlios.de =
[mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of Melanie
Sent: 27 July 2009 14:32
To: opensim-dev at lists.berlios.de
Subject: Re: [Opensim-dev] Inventory loss

Those MySQL issues listed below and others like it are corner cases=20
that OpenSim would never trigger. OpenSim is a very simplistic=20
database user, it doesn't even really use any relational features of=20
the database.
So, I don't think that MySQL errors are something we need to concern=20
ourselves with at this point. Especially, your suggestion would not=20
help in those cases, as they are all about complete loss of rows.=20
That is unaffected by a "deleted" type flag.

That is neither here nor there anyway, since such a "deleted" flag=20
would have to live under OpenSim.Data.XXXX.

It has no business being in core at all.

Melanie


Colin B. Withers wrote:
> Reason I wondered is simply the number of websites dedicated to =
recovering from MYSQL database corruption, and offering tools for the =
same. Google returns over 250,000 sites for 'mysql database corruption'.
>=20
> MYSQL has had numerous bug fixes to fix database corruption, =
introduced by differing versions of MYSQL, eg
>=20
> Fixed in 4.0.18
> INSERT DELAYED ... SELECT ... could cause table corruption because =
tables were not locked properly. This is now fixed by ignoring DELAYED =
in this context. (Bug #1983)=20
>=20
> Fixed in 4.0.16
> Fixed bug in overrun check for BLOB values with compressed tables. =
This was a bug introduced in 4.0.14. It caused MySQL to regard some =
correct tables containing BLOB values as corrupted. (Bug #770, Bug =
#1304, and maybe Bug #1295)=20
>=20
> Fixed in 4.0.15
> Fixed rare bug in MYISAM introduced in 4.0.3 where the index file =
header was not updated directly after an UPDATE of split dynamic rows. =
The symptom was that the table had a corrupted delete-link if mysqld was =
shut down or the table was checked directly after the update.
>=20
> Fixed in 4.0.14
> Comparison/sorting for latin1_de character set was rewritten. The old =
algorithm could not handle cases like "s=E4" < "=DFa". See section =
5.6.1.1 German character set. In rare cases, it resulted in table =
corruption.
>=20
> and so on..
>=20
> My own experience with Opensim is that in the last 12 months there has =
been three occasions where residents complained of stuff 'missing' (not =
a single resident, but several at once) and a roll-back to the last =
database backup cured the problems.
>=20
> Rock
>=20
> -----Original Message-----
> From: opensim-dev-bounces at lists.berlios.de =
[mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of Melanie
> Sent: Monday, July 27, 2009 2:07 PM
> To: opensim-dev at lists.berlios.de
> Subject: Re: [Opensim-dev] Inventory loss
>=20
> IMHO, inventory loss due to MySQL errors and/or corruption are below=20
> the radar.
> Any losses would occur in OpenSim code, I believe.
>=20
> Melanie
>=20
> Colin B. Withers wrote:
>> I wonder what proportion of inventory items that go astray are the =
result of the success/failure of an operation, or are due to database =
corruption issues.
>>=20
>> Rock
>>=20
>> -----Original Message-----
>> From: opensim-dev-bounces at lists.berlios.de =
[mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of Melanie
>> Sent: Monday, July 27, 2009 12:30 PM
>> To: opensim-dev at lists.berlios.de
>> Subject: Re: [Opensim-dev] Inventory loss
>>=20
>> There is a question here of why inventory loss occurs at all. At=20
>> what stage do we actually lose (as opposed to failing to bump the=20
>> folder serial) inventory items at all, and why?
>>=20
>> While a "deleted" flag and an undelete function do make an admin's=20
>> life easier, I believe the real focus should be on the inventory=20
>> code. It will be redesigned anyway and once that happens, I think a=20
>> strong focus needs to be placed on data integrity preservation.
>>=20
>> That would then mae the undelete functionality largely unnecessary.=20
>> Current inventory code often doesn't check for success of an=20
>> operation at all. That needs to be revisited.
>>=20
>> Melanie
>>=20
>> Thomas Grimshaw wrote:
>>> Hey folks.
>>>=20
>>> Been thinking a lot about inventory loss in OpenSim, something that =
I=20
>>> think we should really do as much as possible to avoid. We've been=20
>>> experiencing numerous cases of lost inventory in K-Grid recently.
>>>=20
>>> What i'd like to implement, is..
>>>=20
>>> When an item is removed from inventory (deleted, or rezzed if it's=20
>>> no-copy), it is not actually deleted by instead an "available" flag =
is=20
>>> set in the inventory database.
>>> All inventory queries will check for the flag and thus it will =
appear as=20
>>> deleted to the user, but it can be restored easily by an admin if=20
>>> needed.  A timestamp should also be set which indicates when the =
item=20
>>> was made unavailable, so that routine cleanup can be performed on =
items=20
>>> which were made unavailable a long time ago.
>>>=20
>>> I wanted to get people's opinons of this before I implemented it in=20
>>> code. Can anyone think of any drawbacks or possible issues? Any =
further=20
>>> room for improvement?
>>>=20
>>> Cheers
>>>=20
>>> Thomas Grimshaw
>>> (RemedyTomm)
>>> _______________________________________________
>>> Opensim-dev mailing list
>>> Opensim-dev at lists.berlios.de
>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>>=20
>>>=20
>> _______________________________________________
>> Opensim-dev mailing list
>> Opensim-dev at lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>> _______________________________________________
>> Opensim-dev mailing list
>> Opensim-dev at lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>=20
>>=20
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>=20
>=20

_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

No virus found in this incoming message.
Checked by AVG - www.avg.com=20
Version: 8.5.392 / Virus Database: 270.13.29/2261 - Release Date: =
07/27/09 05:58:00