1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
|
/*
Derby - Class org.apache.derbyTesting.functionTests.harness.procedure
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements. See the NOTICE file distributed with
this work for additional information regarding copyright ownership.
The ASF licenses this file to You under the Apache License, Version 2.0
(the "License"); you may not use this file except in compliance with
the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
*/
package org.apache.derbyTesting.functionTests.tests.store;
import org.apache.derby.shared.common.sanity.SanityManager;
import java.sql.CallableStatement;
import java.sql.Connection;
import java.sql.PreparedStatement;
import java.sql.ResultSet;
import java.sql.SQLException;
import java.sql.Statement;
import org.apache.derby.tools.ij;
/**
The purpose of this test is to reproduce JIRA DERBY-662:
Sometimes during redo the system would incorrectly remove the file associated
with a table. The bug required the following conditions to reproduce:
1) The OS/filesystem must be case insensitive such that a request to delete
a file named C2080.dat would also remove c2080.dat. This is true in
windows default file systems, not true in unix/linux filesystems that
I am aware of.
2) The system must be shutdown not in a clean manner, such that a subsequent
access of the database causes a REDO recovery action of a drop table
statement. This means that a drop table statement must have happened
since the last checkpoint in the log file. Examples of things that cause
checkpoints are:
o clean shutdown from ij using the "exit" command
o clean shutdown of database using the "shutdown=true" url
o calling the checkpoint system procedure
o generating enough log activity to cause a regularly scheduled checkpoint.
3) If the conglomerate number of the above described drop table is TABLE_1,
then for a problem to occur there must also exist in the database a table
such that it's HEX(TABLE_2) = TABLE_1
4) Either TABLE_2 must not be accessed during REDO prior to the REDO operation
of the drop of TABLE_1 or there must be enough other table references during
the REDO phase to push the caching of of the open of TABLE_2 out of cache.
If all of the above conditions are met then during REDO the system will
incorrectly delete TABLE_2 while trying to redo the drop of TABLE_1.
<p>
This test reproduces the problem by doing the following:
1) create 500 tables, need enough tables to insure that conglomerate number
2080 (c820.dat) and 8320 (c2080.dat) exist.
2) checkpoint the database so that create does not happen during REDO
3) drop table with conglomerate number 2080, mapping to c820.dat. It looks
it up in the catalog in case conglomerate number assignment changes for
some reason.
4) exit the database without a clean shudown, this is the default for test
suites which run multiple tests in a single db - no clean shutdown is done.
Since we only do a single drop since the last checkpoint, test will cause
the drop during the subsequent REDO.
5) run next test program dropcrash2, which will cause redo of the drop. At
this point the bug will cause file c2080.dat to be incorrectly deleted and
thus accesses to conglomerate 8320 will throw container does not exist
errors.
6) check the consistency of the database which will find the container does
not exist error.
**/
public class dropcrash extends BaseTest
{
boolean verbose = false;
public dropcrash()
{
}
/**
* create tables, commit, and cause checkpoint of db.
**/
public void drop_crash_setup(
Connection conn,
int num_create)
throws SQLException
{
beginTest(conn, "creating " + num_create + " tables.");
String create_stmt_str1 = "create table dropcrash_";
String create_stmt_str2 = " (a int)";
for (int i = 0; i < num_create; i++)
{
executeQuery(conn, create_stmt_str1 + i + create_stmt_str2, false);
}
conn.commit();
// during redo insure that drop is the only thing redone, if there
// are other files in the open file cache then bug will not reproduce
// because delete on the open file will fail.
executeQuery(
conn, "CALL SYSCS_UTIL.SYSCS_CHECKPOINT_DATABASE()", false);
endTest(conn, "creating " + num_create + " tables.");
}
/**
* Reproduce JIRA DERBY-662
* <p>
* Find the conglomerate with number 2080, and drop it. The bug is
* that during redo the system, on windows, will incorrectly delete
* C2080.dat because it did not do the hex conversion on the conglomerate
* number. This will result in conglomerate 8320 not having it's
* associate data file c2080.dat.
*
* @exception StandardException Standard exception policy.
**/
public void drop_crash_drop_table(Connection conn)
throws SQLException
{
beginTest(conn, "dropping table with conglomerate number 2080.");
PreparedStatement ps =
conn.prepareStatement(
"select sys.systables.tablename, sys.sysconglomerates.conglomeratenumber from sys.systables, sys.sysconglomerates where sys.systables.tableid = sys.sysconglomerates.tableid and sys.systables.schemaid = sys.sysconglomerates.schemaid and sys.sysconglomerates.conglomeratenumber = ?");
ps.setInt(1, 2080);
ResultSet rs = ps.executeQuery();
if (!rs.next())
{
System.out.println("ERROR, did not find conglomerate to drop");
}
String drop_name = rs.getString(1);
// don't print table name out to test output as it could change if
// other recovery tests are added, or system catalogs are added.
// System.out.println("dropping table:" + drop_name + " with conglomerate number " + rs.getInt(2));
executeQuery(conn, "drop table " + drop_name, false);
conn.commit();
// at this point it is important for this test to exit with not a
// clean shutdown, so that the next test will force recovery redo
// of this drop.
endTest(conn, "dropping table with conglomerate number 2080.");
}
public void testList(Connection conn)
throws SQLException
{
// create enough tables to insure congloms 2080 and 8320 exist
drop_crash_setup(conn, 500);
// drop 2080 and exit program so that drop will be in REDO recovery
drop_crash_drop_table(conn);
}
public static void main(String[] argv)
throws Throwable
{
dropcrash test = new dropcrash();
ij.getPropertyArg(argv);
Connection conn = ij.startJBMS();
conn.setAutoCommit(false);
try
{
test.testList(conn);
}
catch (SQLException sqle)
{
org.apache.derby.tools.JDBCDisplayUtil.ShowSQLException(
System.out, sqle);
sqle.printStackTrace(System.out);
}
}
}
|
