Prepare for your exams
Get points
Guidelines and tips
Sell on Docsity
Docsity AI

Prepare for your exams

Study with the several resources on Docsity

Earn points to download

Earn points by helping other students or get them with a premium plan

Guidelines and tips

Sell on Docsity

Docsity AI

Log in Sign up

Prepare for your exams

Study with the several resources on Docsity

Find documents

Prepare for your exams with the study notes shared by other students like you on Docsity

Search for your university

Find the specific documents for your university's exams

Docsity AINEW

Summarize your documents, ask them questions, convert them into quizzes and concept maps

Explore questions

Clear up your doubts by reading the answers to questions asked by your fellow students

Earn points to download

Earn points by helping other students or get them with a premium plan

Share documents

20 Points

For each uploaded document

Answer questions

5 Points

For each given answer (max 1 per day)

All the ways to get free points

Get points immediately

Choose a premium plan with all the points you need

Study Opportunities

Choose your next study program

Get in touch with the best universities in the world. Search through thousands of universities and official partners

Community

Ask the community

Ask the community for help and clear up your study doubts

Free resources

Our save-the-student-ebooks!

Download our free guides on studying techniques, anxiety management strategies, and thesis advice from Docsity tutors

Recovering a SimpleDB Database using a Log File, Lab Reports of Deductive Database Systems

Texas A&M University (A&M)Deductive Database Systems

The steps to recover a simpledb database using an existing log file. The process involves creating instances of logmgr for reading the log file and building a list of committed transactions. A new redo log file is then created by writing each log record to it. The program iterates through the records in the redo log file and calls the undo method on each record belonging to a committed transaction. However, the code provided does not work correctly as it redoes database modifications using their old values for committed transactions.

Typology: Lab Reports

Pre 2010

Uploaded on 02/10/2009

koofers-user-hjt-1 🇺🇸

10 documents

1 / 8

This page cannot be seen from the preview

Don't miss anything!

CPSC 310 Lab 3, Summer 2008, Ronnie Ward, 515C HRBB

Assigned 7/9/08. Hardcopy due 7/21/08. Also turn in on CSNET.

1

If you haven’t already done so, download Ed Sciore’s SimpleDB 2.6

(www.cs.bc.edu/~sciore/simpledb/intro.html)

The goals of this project are for you to understand how db logging is implemented, and

gain more experience with implementing ad hoc tools needed in a database environment.

Answer any specific questions contained in this document, COMMENT the java code

you write, and turn it in on the due date. When you modify any SimpleDB code,

comment out the affected lines and enter your new code.

The goal of the overall lab is to reconstruct a studentdb instance using an archived

version and a log file. Our proof of correctness is the identical output of SELECT

statements issued before and after recovering studentdb.

1. As a first step, run CreateStudentDB to create a new instance of studentdb tables.

This will create a log file simpledb.log and a set of tables. Note: if you already have

an instance of studentdb, I recommend that you delete it and start from a new

instance. Turn in this version of the log file (simply copy it out of the studentdb

folder). Start RMI. Start the SimpleDB server. Run CreateStudentDB. Shut down the

server. See attached simpledb.log file.

App console:

Table STUDENT created.

STUDENT records inserted.

Table DEPT created.

DEPT records inserted.

Table COURSE created.

COURSE records inserted.

Table SECTION created.

SECTION records inserted.

Table ENROLL created.

ENROLL records inserted.

Server console:

new transaction: 1

creating new database

transaction 1 committed

database server ready

new transaction: 2

transaction 2 committed

new transaction: 3

transaction 3 committed

new transaction: 4

transaction 4 committed

new transaction: 5

transaction 5 committed

new transaction: 6

transaction 6 committed

new transaction: 7

transaction 7 committed

new transaction: 8

transaction 8 committed

new transaction: 9

transaction 9 committed

Discover Lab Reports of Deductive Database Systems Texas A&M University (A&M)

Partial preview of the text

Download Recovering a SimpleDB Database using a Log File and more Lab Reports Deductive Database Systems in PDF only on Docsity!

Assigned 7/9/08. Hardcopy due 7/21/08. Also turn in on CSNET.

If you haven’t already done so, download Ed Sciore’s SimpleDB 2.

(www.cs.bc.edu/~sciore/simpledb/intro.html)

The goals of this project are for you to understand how db logging is implemented, and

gain more experience with implementing ad hoc tools needed in a database environment.

Answer any specific questions contained in this document, COMMENT the java code

you write, and turn it in on the due date. When you modify any SimpleDB code,

comment out the affected lines and enter your new code.

The goal of the overall lab is to reconstruct a studentdb instance using an archived

version and a log file. Our proof of correctness is the identical output of SELECT

statements issued before and after recovering studentdb.

1. As a first step, run CreateStudentDB to create a new instance of studentdb tables.

This will create a log file simpledb.log and a set of tables. Note: if you already have

an instance of studentdb, I recommend that you delete it and start from a new

instance. Turn in this version of the log file (simply copy it out of the studentdb

folder). Start RMI. Start the SimpleDB server. Run CreateStudentDB. Shut down the

server. See attached simpledb.log file.

App console:

Table STUDENT created. STUDENT records inserted. Table DEPT created. DEPT records inserted. Table COURSE created. COURSE records inserted. Table SECTION created. SECTION records inserted. Table ENROLL created. ENROLL records inserted.

Server console:

new transaction: 1 creating new database transaction 1 committed database server ready new transaction: 2 transaction 2 committed new transaction: 3 transaction 3 committed new transaction: 4 transaction 4 committed new transaction: 5 transaction 5 committed new transaction: 6 transaction 6 committed new transaction: 7 transaction 7 committed new transaction: 8 transaction 8 committed new transaction: 9 transaction 9 committed

Assigned 7/9/08. Hardcopy due 7/21/08. Also turn in on CSNET.

new transaction: 10 transaction 10 committed new transaction: 11 transaction 11 committed new transaction: 12 transaction 12 committed new transaction: 13 transaction 13 committed new transaction: 14 transaction 14 committed new transaction: 15 transaction 15 committed new transaction: 16 transaction 16 committed new transaction: 17 transaction 17 committed new transaction: 18 transaction 18 committed new transaction: 19 transaction 19 committed new transaction: 20 transaction 20 committed new transaction: 21 transaction 21 committed new transaction: 22 transaction 22 committed new transaction: 23 transaction 23 committed new transaction: 24 transaction 24 committed new transaction: 25 transaction 25 committed new transaction: 26 transaction 26 committed new transaction: 27 transaction 27 committed new transaction: 28 transaction 28 committed new transaction: 29 transaction 29 committed new transaction: 30 transaction 30 committed new transaction: 31 transaction 31 committed new transaction: 32 transaction 32 committed new transaction: 33 transaction 33 committed new transaction: 34 transaction 34 committed new transaction: 35 transaction 35 committed new transaction: 36 transaction 36 committed

2. Next, simulate archiving the database by copying the entire studentdb folder to a new

location (eg. thumb drive). I would do this while the SimpleDB server is not running

Assigned 7/9/08. Hardcopy due 7/21/08. Also turn in on CSNET.

StudentMajor console (first run):

Name Major joe compsci max compsci lee compsci sue math kim math pat math amy drama bob drama art drama

StudentMajor console (second run):

Name Major joe compsci max compsci lee compsci amy math sue math kim math pat math bob drama art drama

Log file difference after the recovery:

<COMMIT,3>

<START,3>

<COMMIT,2>

<START,2>

<COMMIT,1>

<START,1>

StudentMajor The console outputs differ because the modified database (Amy as a drama

major) was destroyed. When we restored the archived database, the modification was lost

since SimpleDB does undo recovery when the server initializes. Even though the log file

contains the modification, the change is not applied since its corresponding transaction

committed. Undo recovery does not change transactions already committed. Tx.recover ()

flushes all the buffers, and calls recover() in the RecoveryMgr. This method calls undo()

on each log record corresponding to an uncommitted transaction. Afterwards, the

recover() method in the RecoveryMgr writes a CHECKPOINT record.

5. Turn in one page detailing a program (logic and data structures) that could be used to

restore the database using the existing log file. Explain why it should work. Then for

complete credit on this step, actually write this program. Turn in its output, and run

StudentMajor.java to show that the archived database was at least functionally

restored. As a last step, file compare the *.TBL files resulting from this step 5 with

the archived *.TBL files created in step 4. Are there any differences?

Use the log file existing at the time the database was lost (step 3), and the archived

database. The program should instantiate SimpleDB on the database filename

(studentdb). Then (a) the program should create an instance of the LogMgr for reading

the existing log file (backwards), looking for two CHECKPOINT records, and building a

list of committed transactions (locate COMMIT records). (b) In parallel, it should use

Assigned 7/9/08. Hardcopy due 7/21/08. Also turn in on CSNET.

another instance of LogMgr to create a new redo log file by writing each SETINT or

SETSTRING log record read in (a) out to the redo log. Next, it should iterate backwards

thru the records in this redo log, which amounts to traversing the original log forward

from the earliest CHECKPOINT to the end of the file. As the program traverses the redo

log file, it should call the undo method (or write equivalent code) on each record

belonging to a committed transaction registered in the list of committed transactions. Be

sure and flush() the buffers used to make sure they are written back to the database. This

code will NOT work since it redoes database modifications using their OLD values for

committed transactions in the order in which they were originally entered.

The following code works correctly, but the update records contain OLD values, not new

values. So the redo process won’t work with undo data! The student.tbl is different since

it has the OLD value not the NEW value.

age simpledb.log; import static simpledb.tx.recovery.LogRecord. CHECKPOINT ; import static simpledb.tx.recovery.LogRecord. COMMIT ; import static simpledb.tx.recovery.LogRecord. SETINT ; import static simpledb.tx.recovery.LogRecord. SETSTRING ;

import java.util.ArrayList; import java.util.Collection; import java.util.Iterator;

import simpledb.buffer.Buffer; import simpledb.buffer.BufferMgr; import simpledb.server.SimpleDB; import simpledb.file.Block;

Assigned 7/9/08. Hardcopy due 7/21/08. Also turn in on CSNET.

To actually recover a database from an archived database and a current log file, we need

to modify the RecoveryMgr setString and setInt methods to save new values in

addition to old values. This necessitates a change in the classes SetIntRecord and

SetStringRecord. We do this in a way that is transparent to SimpleDB undo recovery.

Instead we will still rely on our external tool to actually recover an archived database.

Making these changes means that SimpleDB is no longer backward compatible with

database instances created with the previous version!

Steps 1 and 2 are re-executed as above. For step 3, we re-run ChangeMajor and notice the

difference in the log file given below (required mods to PrintLog, too).

<COMMIT,3>

<START,3>

<COMMIT,2>

<SETINT,2,student.tbl,0,42,20,30> ←notice the new value of 30 <START,2> <COMMIT,1> <START,1>

For Step 4, we get the same information as above on the first and second runs of

StudentMajor (amy goes from drama back to majoring in math). So the recovery process

in SimpleDB did not restore the database.

Now we redo step 5, and this time use a modified restore program that takes into account

a new value stored in a log record. This data is used to restore the database. Here is the

result of re-running StudentMajor after performing the restore.

Name Major joe compsci max compsci lee compsci sue math kim math pat math amy drama bob drama art drama

Recovering a SimpleDB Database using a Log File, Lab Reports of Deductive Database Systems

Related documents

Partial preview of the text

Download Recovering a SimpleDB Database using a Log File and more Lab Reports Deductive Database Systems in PDF only on Docsity!

Assigned 7/9/08. Hardcopy due 7/21/08. Also turn in on CSNET.

If you haven’t already done so, download Ed Sciore’s SimpleDB 2.

(www.cs.bc.edu/~sciore/simpledb/intro.html)

The goals of this project are for you to understand how db logging is implemented, and

gain more experience with implementing ad hoc tools needed in a database environment.

Answer any specific questions contained in this document, COMMENT the java code

you write, and turn it in on the due date. When you modify any SimpleDB code,

comment out the affected lines and enter your new code.

The goal of the overall lab is to reconstruct a studentdb instance using an archived

version and a log file. Our proof of correctness is the identical output of SELECT

statements issued before and after recovering studentdb.

1. As a first step, run CreateStudentDB to create a new instance of studentdb tables.

This will create a log file simpledb.log and a set of tables. Note: if you already have

an instance of studentdb, I recommend that you delete it and start from a new

instance. Turn in this version of the log file (simply copy it out of the studentdb

folder). Start RMI. Start the SimpleDB server. Run CreateStudentDB. Shut down the

server. See attached simpledb.log file.

App console:

Server console:

Assigned 7/9/08. Hardcopy due 7/21/08. Also turn in on CSNET.

2. Next, simulate archiving the database by copying the entire studentdb folder to a new

location (eg. thumb drive). I would do this while the SimpleDB server is not running

Assigned 7/9/08. Hardcopy due 7/21/08. Also turn in on CSNET.

StudentMajor console (first run):

StudentMajor console (second run):

Log file difference after the recovery:

<COMMIT,3>

<START,3>

<COMMIT,2>

<START,2>

<COMMIT,1>

<START,1>

StudentMajor The console outputs differ because the modified database (Amy as a drama

major) was destroyed. When we restored the archived database, the modification was lost

since SimpleDB does undo recovery when the server initializes. Even though the log file

contains the modification, the change is not applied since its corresponding transaction

committed. Undo recovery does not change transactions already committed. Tx.recover ()

flushes all the buffers, and calls recover() in the RecoveryMgr. This method calls undo()

on each log record corresponding to an uncommitted transaction. Afterwards, the

recover() method in the RecoveryMgr writes a CHECKPOINT record.

5. Turn in one page detailing a program (logic and data structures) that could be used to

restore the database using the existing log file. Explain why it should work. Then for

complete credit on this step, actually write this program. Turn in its output, and run

StudentMajor.java to show that the archived database was at least functionally

restored. As a last step, file compare the *.TBL files resulting from this step 5 with

the archived *.TBL files created in step 4. Are there any differences?

Use the log file existing at the time the database was lost (step 3), and the archived

database. The program should instantiate SimpleDB on the database filename

(studentdb). Then (a) the program should create an instance of the LogMgr for reading

the existing log file (backwards), looking for two CHECKPOINT records, and building a

list of committed transactions (locate COMMIT records). (b) In parallel, it should use

Assigned 7/9/08. Hardcopy due 7/21/08. Also turn in on CSNET.

another instance of LogMgr to create a new redo log file by writing each SETINT or

SETSTRING log record read in (a) out to the redo log. Next, it should iterate backwards

thru the records in this redo log, which amounts to traversing the original log forward

from the earliest CHECKPOINT to the end of the file. As the program traverses the redo

log file, it should call the undo method (or write equivalent code) on each record

belonging to a committed transaction registered in the list of committed transactions. Be

sure and flush() the buffers used to make sure they are written back to the database. This

code will NOT work since it redoes database modifications using their OLD values for

committed transactions in the order in which they were originally entered.

The following code works correctly, but the update records contain OLD values, not new

values. So the redo process won’t work with undo data! The student.tbl is different since

it has the OLD value not the NEW value.

Assigned 7/9/08. Hardcopy due 7/21/08. Also turn in on CSNET.

To actually recover a database from an archived database and a current log file, we need

to modify the RecoveryMgr setString and setInt methods to save new values in

addition to old values. This necessitates a change in the classes SetIntRecord and

SetStringRecord. We do this in a way that is transparent to SimpleDB undo recovery.

Instead we will still rely on our external tool to actually recover an archived database.

Making these changes means that SimpleDB is no longer backward compatible with

database instances created with the previous version!

Steps 1 and 2 are re-executed as above. For step 3, we re-run ChangeMajor and notice the

difference in the log file given below (required mods to PrintLog, too).

<COMMIT,3>

<START,3>