Simulating corruption
От | Jason J. Czerak |
---|---|
Тема | Simulating corruption |
Дата | |
Msg-id | XFMail.20000903183951.jason-czerak@jasnik.net обсуждение исходный текст |
Список | pgsql-general |
Hey, this is a little odd to be asking but... Anyone have any tools that woudl go in and corrupt the database. Like just break things. And then have step by step instructions on how to rebuild things and fix em up. I know a restore from the last backup tape would be best and easiest solution, but if rebuilding the DB and just ridding the one little broken part is easier or better (say you wanna not loose 4 hours of data by restoring but lose 10 minutes of data while rebuilding)... right now written a little perl script that is inserting 1,000,000 rows within a test database. It's inserting numbers. 1,2,3,4,5,6...10321,10322...etc... just a loop with num = num+1; insert num; kinda thing.. so every line is different. And for thoses of you that are stats hungy.. the box is a K6 500 128 megs ram and IDE drive. redhat 6.9.5. postgres 7.02.. perl DBI is the interface. X is't being run on the machine. but the Xterms are being displaed on my workstation. it's connecting to the DB server that's on it's own machine VIA TCP sockets. When I started it was going at 40 - 60% cpu.. 800 to 1Meg/sec disk access.... a good 20 to 30 minutes into the loop. 90% to 100% CPU and disk access is at 400K/sec.... I think the CPU is the limiting factor on the bigger DB's and DISK was the factor on smaller DB's... memeory isn't much of a problem since the user+share BUFF and CACHE ranges havn't changed. I wonder about turning off -F like talked about before :) ohh and the size of hte DB is now 14megs. -- Jason
В списке pgsql-general по дате отправления: