Pre-Grant Publication Number: 20070150488
Please help the USPTO examine the application by evaluating the relevance of the publicly submitted prior art to the patent application.
Peer To Patent forwards the Top 10 most relevant prior art submissions and their annotations to the USPTO.
Review this prior art and click on the thumbs up (or down) to indicate whether this submission should be forwarded to the USPTO.
If you login then you can add an annotation by typing in the box at the bottom of the screen to comment on the relevance of the prior art to the claims of the patent application.
Review this prior art and click on the thumbs up (or down) to indicate whether this submission should be forwarded to the USPTO.
If you login then you can add an annotation by typing in the box at the bottom of the screen to comment on the relevance of the prior art to the claims of the patent application.
Prior Art Detail
Summary / Description
| Summary / Description | The 2002 blog of news items released to participants of the SETI@Home project shows benchmarking activity to measure performance and a related database migration with subsequent benchmarking to check improvements of the system |
Basic Information
| Type of Prior Art | Online Publication |
| URL | http://seticlassic.ssl.berkeley... |
| Author/Creator | SETI@Home |
| Title | SETI@Home Technical news reports - 2002 |
| Publication Date | November 15, 2002 |
| Publisher | SETI University of California, Berkeley |
| Directions to Document Location | |
| Additional Information | This is a blog of all the e-mails sent out to SETI@Home participants |
Notes / To Do
| Notes | This does not show the process was also automated. Scripting these actions was state of the art but not needed for this application since it is a one of a kind database and application. |
Excerpt
Excerpt -===-
Feb 25, 2002 - We recently took the step of running our Informix online science database from the NetApp filer only. Our benchmark (insert rate) indicated that this would work and indeed it seems fine thus far. This is true even when the project has enough bandwidth to run full out.
-===-
Jun 3, 2002 - ...
The online science database has had to manage a doubling in transaction rate every year. We think this is proof of Moore's Law showing that PCs are getting faster every year. The other effect (as you have noticed!) is the need for more bandwidth.
...
We then turned off the local drives and ran from about October 2001 to March 2002 on the filer only, as a test. The reliability was excellent and the performance was good. While the Netapp box did not introduce any new data errors, it inherited those from the local drives which could not be detected by the utilities available.
So we moved towards a complete online reorganization, using techniques we learned while building the offline science database. Chief among these techniques was to establish multiple dbspaces. This allowed us to collapse our five spike tables into one and not be bothered again by the 32GB per structure limitation. It also allows informix to run queries in a more parallel fashion.
...
The migration itself was done with SQL scripts that moved each table, row by row. As we went, we hit the last remaining corrupt data pages and omitted them, leaving the new database clean. The new database was created in early April and in about three weeks all the data were copied over. We then validated the migration to ensure that the process had worked correctly and put the system on-line on April 27, 2002.
-===-
|
Relevance
Claims
1
Relevance
Benchmarking for performance before migrating a database is not novel. Creating a translation between schemas is not novel either. Computer implementing this process is difficult, but still a trivial step.
Benchmarking for performance before migrating a database is not novel. Creating a translation between schemas is not novel either. Computer implementing this process is difficult, but still a trivial step.
Claim Chart
All
11
Relevance
Benchmarking for performance before migrating a database is not novel. Creating a translation between schemas is not novel either. Computer implementing this process is difficult, but still a trivial step.
Benchmarking for performance before migrating a database is not novel. Creating a translation between schemas is not novel either. Computer implementing this process is difficult, but still a trivial step.
Claim Chart
All
21
Relevance
Benchmarking for performance before migrating a database is not novel. Creating a translation between schemas is not novel either. Getting a computer to imement this process is not easy, but still a trivial and obvious step.
Benchmarking for performance before migrating a database is not novel. Creating a translation between schemas is not novel either. Getting a computer to imement this process is not easy, but still a trivial and obvious step.
Claim Chart
All
26
Relevance
Benchmarking for performance before migrating a database is not novel. Creating a translation between schemas is not novel either. Getting a computer to imement this process is not easy, but still a trivial and obvious step.
Benchmarking for performance before migrating a database is not novel. Creating a translation between schemas is not novel either. Getting a computer to imement this process is not easy, but still a trivial and obvious step.
Claim Chart
All
0 days left
