[
https://issues.apache.org/jira/browse/DERBY-5325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13067584#comment-13067584
]
Knut Anders Hatlen commented on DERBY-5325:
---
Thanks for the detailed analysis,
[
https://issues.apache.org/jira/browse/DERBY-5343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13067630#comment-13067630
]
Knut Anders Hatlen commented on DERBY-5343:
---
I think clearing private fields
[
https://issues.apache.org/jira/browse/DERBY-5343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Knut Anders Hatlen reassigned DERBY-5343:
-
Assignee: Knut Anders Hatlen
Starting 7/13/2011 weme 6.2 upgrade tests started
[
https://issues.apache.org/jira/browse/DERBY-5342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Houx Zhang updated DERBY-5342:
--
Attachment: 5342-1.patch
Hi, Bryan.
This project doesn't related to DERBY-5332, as in
[
https://issues.apache.org/jira/browse/DERBY-5343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Knut Anders Hatlen updated DERBY-5343:
--
Attachment: d5343.diff
Attaching a patch that makes the workaround for DERBY-23 take a
[
https://issues.apache.org/jira/browse/DERBY-5343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Knut Anders Hatlen resolved DERBY-5343.
---
Resolution: Fixed
Fix Version/s: 10.9.0.0
Committed revision 1148302.
Actually this is Derby 10.5.3 that is running in production.
I could really use some help in trying to figure out what triggers Derby not
cleanup its DAT files. The system is started and running now and as expected
the files in the log directory of the database are varying between about 4
[
https://issues.apache.org/jira/browse/DERBY-5329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13067715#comment-13067715
]
Kim Haase commented on DERBY-5329:
--
Thanks, Dag! So it looks as if UPDATE_STATISTICS is
[
https://issues.apache.org/jira/browse/DERBY-5325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13067719#comment-13067719
]
Dag H. Wanvik commented on DERBY-5325:
--
Thanks for looking at this, Knut. I am aware
[
https://issues.apache.org/jira/browse/DERBY-5342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13067717#comment-13067717
]
Bryan Pendleton commented on DERBY-5342:
Thank you for the clear explanation.
I
Bergquist, Brett bbergqu...@canoga.com writes:
I have a database in production that has been running fine for a few
years. It started out having about 100K inserts per day into it and
now is up to about 4.6M inserts per day and this has been working
fine.
Tonight the customer called because
Thanks for taking the time to respond Knut. It is much appreciated.
Some information:
The log files total 64Gb of disk space. So this clearly went way past the 10Mb
of transaction log.
So the And the checkpoint will only delete log files older than the oldest
transaction that's still
[
https://issues.apache.org/jira/browse/DERBY-5312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13067735#comment-13067735
]
Dag H. Wanvik commented on DERBY-5312:
--
Committed derby-5312-simplify-reopen-1 as svn
[
https://issues.apache.org/jira/browse/DERBY-5312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dag H. Wanvik resolved DERBY-5312.
--
Resolution: Fixed
Fix Version/s: 10.9.0.0
Issue fix info: (was: [Patch
[
https://issues.apache.org/jira/browse/DERBY-5325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13067748#comment-13067748
]
Dag H. Wanvik commented on DERBY-5325:
--
Fixed the cut/paste typo and committed as svn
[Auto-generated mail]
*Daily* 1147942/2011-07-18 18:03:47 MEST
Failed TestsOK Skip Duration Suite
---
*Jvm: 1.6*
lin
NA NA NANA suitesAll
NA NA NANA jdbcapiAutoLoad
NA
[
https://issues.apache.org/jira/browse/DERBY-5333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13067803#comment-13067803
]
Dag H. Wanvik commented on DERBY-5333:
--
Data point: I did *not* see this when running
[
https://issues.apache.org/jira/browse/DERBY-5325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dag H. Wanvik updated DERBY-5325:
-
Attachment: derby-5325-refactor.stat
derby-5325-refactor.diff
Attaching a patch
[
https://issues.apache.org/jira/browse/DERBY-1903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13067815#comment-13067815
]
Kathey Marsden commented on DERBY-1903:
---
Running the old test at revision 1147981 it
It is likely the database is corrupt now that you booted without letting
recovery do its job. Just because there are no applications accessing
the db it does not mean it is safe to delete the log files. Derby
maintains an in memory cache of data that along with info in the
recovery log files
I would suggest you boot the backup database somewhere where you can
let it run and let it finish, and then shut it down cleanly with
shutdown=true. And then boot
it again and see if that fixes the problem.
If you have the ability to run with a debug server we can give you debug
options that
Did not have a choice Mike. I have taken the chance and will go from there.
I cannot get the old database, it is in a protected networking environment and
is simply too large to transfer. Only slow speed telnet access into the
network.
I can probably get the last online database backup, if
[
https://issues.apache.org/jira/browse/DERBY-5333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13067854#comment-13067854
]
Dag H. Wanvik commented on DERBY-5333:
--
I was able to see this in the debugger by
I will try to get a copy of the backup database. It will probably take a
while. I have the system administrator monitoring the transaction log
directory and will call me if it starts to grow again. At that point I will
use IJ and try to look at the transactions table and locks table.
On
I did get a sampling of the transaction logs over the days. The oldest ones
were July 12'th and the newest ones were July 18'th. I had the sysAdmin copy
some of these aside so I can get a sample of every couple of days.
Will the utility that you mention look at specific transaction log
I believe the consistency checker is going to lock each table for the
duration of the checking. The time it takes is dependent on size of
table.
When possible post a directory listing of the files in log directory
with the following if possible: size of each file, date modified, and
name
Good idea on the backup strategy!
The one problem that I have is that I have no access to the customer's system
and it is pretty much running hands off. I do have to say that we have been
using Derby for about 5 years and have never had a problem up until these last
couple of weeks. So
[
https://issues.apache.org/jira/browse/DERBY-5333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dag H. Wanvik updated DERBY-5333:
-
Attachment: derby-5333-repro.diff
Uploading a patch (derby-5333-repro) which when applied
[
https://issues.apache.org/jira/browse/DERBY-5333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dag H. Wanvik reassigned DERBY-5333:
Assignee: Dag H. Wanvik
Intermittent assert failure in testInterruptShutdown: thread's
[
https://issues.apache.org/jira/browse/DERBY-5329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13067923#comment-13067923
]
Dag H. Wanvik commented on DERBY-5329:
--
Affirmative! :)
Document who is allowed to
Do you change the size of the Derby buffer cache? One problem Derby can
have at these performance levels is that the checkpoint has to compete
with I/O from the regular transactions as your load increases this just
becomes more and more of a problem.
62k files does seem crazy, and I have seen
[
https://issues.apache.org/jira/browse/DERBY-5208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kathey Marsden resolved DERBY-5208.
---
Resolution: Not A Problem
Closing not a problem as It looks like this is just a matter of
Enable updateClob2 test in LobLimitsTest (was LobLimits.java)
-
Key: DERBY-5344
URL: https://issues.apache.org/jira/browse/DERBY-5344
Project: Derby
Issue Type: Improvement
[
https://issues.apache.org/jira/browse/DERBY-5332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Pendleton resolved DERBY-5332.
Resolution: Fixed
Fix Version/s: 10.9.0.0
The patch builds and runs cleanly in my
[
https://issues.apache.org/jira/browse/DERBY-5333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dag H. Wanvik updated DERBY-5333:
-
Attachment: derby-5333a.diff
Uploading a patch which fixes this issue. There was a remaining
[
https://issues.apache.org/jira/browse/DERBY-5333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dag H. Wanvik updated DERBY-5333:
-
Issue fix info: [Patch Available]
Intermittent assert failure in testInterruptShutdown:
[
https://issues.apache.org/jira/browse/DERBY-5333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dag H. Wanvik updated DERBY-5333:
-
Attachment: derby-5333a.diff
Intermittent assert failure in testInterruptShutdown: thread's
[
https://issues.apache.org/jira/browse/DERBY-5333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dag H. Wanvik updated DERBY-5333:
-
Attachment: (was: derby-5333a.diff)
Intermittent assert failure in testInterruptShutdown:
[
https://issues.apache.org/jira/browse/DERBY-5120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mamta A. Satoor updated DERBY-5120:
---
Fix Version/s: 10.8.1.6
Row from SYSDEPENDS gets deleted when a table has update triggers
39 matches
Mail list logo
