Re: [sqlite] Updating on 32bit os slower than 64bit?

[Jim "Jed" Dodgen]

Are theses tests being run on the same hardware?

On Tue, Jul 17, 2012 at 5:09 AM, Black, Michael (IS)  wrote:

> Something that might be useful is to strace that program   Use  the "-c"
> switch to summarize the system calls first.  Then use the "-tt" to show
> relative timestamps to identify specific bottlenecks.
>
>
>
> Also, set up a ram disk on the system and see if that's slow too.  That
> will test the LVM idea.
>
>
>
> Also, try using  a memory database and see how that does.
>
>
>
> Differential diagnostics will get you there eventually.
>
>
>
> Michael D. Black
> Senior Scientist
> Advanced Analytics Directorate
> Advanced GEOINT Solutions Operating Unit
> Northrop Grumman Information Systems
>
> 
> From: sqlite-users-boun...@sqlite.org [sqlite-users-boun...@sqlite.org]
> on behalf of xp [needforspeed1...@gmail.com]
> Sent: Monday, July 16, 2012 10:11 AM
> To: sqlite-users@sqlite.org
> Subject: EXT :Re: [sqlite] Updating on 32bit os slower than 64bit?
>
> Michael,
>
> Thanks for your reply.  My /home is not NFS mounted. It is mounted locally
> using LVM. I just tested on another 32 bit linux system (rhel 5, not using
> LVM). It ran much faster than the 32 bit fedora, not as fast as the 64 bit
> scientific linux but close. I also tried to test on /tmp on the fedora, but
> it is very slow. The /tmp is also mounted using LVM.  Do you think LVM
> might
> be the problem?
>
> Thanks!
>
> --
> View this message in context:
> http://sqlite.1065341.n5.nabble.com/Updating-on-32bit-os-slower-than-64bit-tp63292p63313.html
> Sent from the SQLite mailing list archive at Nabble.com.
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>



-- 

*Jim Dodgen*


*
*
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] 3.7.9 amalgamation file in VS2005

[Jim "Jed" Dodgen]

In my experience I find that most syntax highlighters fail
on occasion, especially with large files.  Trust the compiler not the
editor.

2011/12/27 Alexandr Němec 

>
> Dear all,
>
> I have one question that is not strictly a SQLite question (sorry), but
> maybe someone encountered this problem and found the solution. I have
> upgraded from an older SQLite release to 3.7.9 and loaded the amalgamation
> file into a Visual Studio 2005 project. But the syntax code highlighter
> does not behave correctly with the 3.7.9 amalgamation file because it greys
> out not only the sections of code that are not compiled at all (because of
> if(n)def's) but also other sections that DO compile. Well, I think that
> this is a bug of the VS 2005 syntax highlighter for such a large source
> file, because the file compiles ok, but working with such a file in VS 2005
> is frustrating.
>
> Did anyone see (did anyone find a solution for) this problem? I have not
> seen this for older versions of the amalgamation file.
>
> Best regards
>
> Alex
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>



-- 

*Jim Dodgen*


*
*
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] [OT] Re: Tool for database designer

[Jim "Jed" Dodgen]

Dezign is a nice cost effective tool, I used it in the past.

google wwwsqldesigner it is free, a little odd, but free is good.

On Mon, Sep 19, 2011 at 6:49 PM, Kai Peters  wrote:

>
> Dezign for databases lets you do that:
>
> http://www.datanamic.com/dezign/supporteddatabases.html
>
>
> Cheers,
> Kai
>
>
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>



-- 

*Jim Dodgen,*


*If you can read this:

01000111
01000101
01000101
01001011

You are one too*.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] How do I UN-subscribe from the mailing list?

[Jim "Jed" Dodgen]

As additional help in gmail click on "show details" to see the link

On Thu, Jul 15, 2010 at 11:22 AM, Simon Slavin <slav...@bigfraud.org> wrote:
>
> On 15 Jul 2010, at 7:04pm, Abder-Rahman Ali wrote:
>
>> How do I UN-subscribe from the mailing list?
>
> Start by clicking the link included at the bottom of every post.
>
> Simon.
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>



-- 
Jim "Jed" Dodgen
j...@dodgen.us
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite turns 10 years old

[Jim "Jed" Dodgen]

Happy birthday and thanks for the memories.

This has been a damn nice project.


On Sat, May 29, 2010 at 6:57 AM, D. Richard Hipp <d...@hwaci.com> wrote:
> The first code check-in for SQLite occurred on 2000-05-29 14:26 UTC -
> ten years ago today.
>
>     http://www.sqlite.org/src/timeline?c=2000-05-29+14:26
>
> Some of the code in SQLite (such as the Lemon parser generator and the
> printf implementation) dates back to the late 1980s.  But the core of
> SQLite was not started until 10 years ago.  Ten years is not that long
> ago, though it has been long enough to amass 7114 check-ins - an
> average of 2.1 check-ins per day.  If you are overseeing such a
> project, 10 years seems like forever.  It has hard for me to remember
> a time when I wasn't working on SQLite.
>
> In celebration of SQlite's 10th birthday, we are revamping the look of
> the SQLite website.  You can see a preview of the new look at
>
>     http://www.sqlite.org/draft/index.html
>
> We won't push the new look out to the main website until we do the
> next release which might not be until July or maybe even August.  We
> had hoped to have SQLite version 3.7.0 ready in time for the 10th
> birthday celebration, but http://www.sqlite.org/draft/wal.html is
> taking longer than planned.  We want to make sure to get things right
> so that SQLite lives to see its 20th and 30th birthdays!
>
> Thanks, everybody, for helping to make SQLite the most widely deployed
> SQL database engine in the world.  And Happy 10th Birthday to SQLite!
>
> D. Richard Hipp
> d...@sqlite.org
>
>
>
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>



-- 
Jim "Jed" Dodgen
j...@dodgen.us
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] One more on .import

[Jim "Jed" Dodgen]

On Thu, May 6, 2010 at 3:56 PM, Simon Slavin <slav...@bigfraud.org> wrote:
>
> On 6 May 2010, at 11:19pm, Matt Young wrote:
>
>> I need a version of import that reads what it can, filling in defaults
>> when too few columns, discarding data when too many.
>
> Great.  Go ahead and write one.  You have our permission.
>
> Simon.


I recommend using the dynamic computer language of you choice, I
prefer Perl for these kind of activities,


-- 
Jim "Jed" Dodgen
j...@dodgen.us
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Berkeley DB adds SQL using SQLite API !!

[Jim "Jed" Dodgen]

On Wed, Mar 31, 2010 at 8:50 AM, Wiktor Adamski
<bardzotajneko...@interia.pl> wrote:
>> There were many problems with
>> that approach:
> ...
>> (3) Each table and index is in a
>> separate file so your "database" was a directory full of files instead
>> of a single file
>
> This one is not a problem. Actually I don't see how 1 file is better
> than 1 directory. For example mac application is a directory not a
> file and no one complains. And with several files database would be
> faster (for example dropping a table is instant or fragmentation is
> handled by OS without need for vacuuming whole database). Also with
> current SQLite implementation only tables would be locked by a
> transation not a whole database (a few years ago there were even
> document on SQLite website listing  splittnig database to several
> files as one way to implement table level locks in SQLite).
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>

Two reasons I prefer the single file approach:

1. Simpler copy, tables and indexes don't get lost or mismatched.

2. fewer handles to open a database. Lower overhead.

This still is a small footprint, high-performance, low overhead SQL
implementation. It does what it needs to do and no more.





-- 
Jim "Jed" Dodgen
j...@dodgen.us
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Unable to recover the DB by vacuum

[Jim "Jed" Dodgen]

I recently had a similar problem,  not wanting to fall back to a week
old dump of the database, what I did was to command line ".dump"ed the
defective database and attempt a reload.
I only had two problem tables and luckily these seldom change,  for
these I went back to the week old backup and cut them out of the dump
file and applied them to the newly created database. Now I
integrity_check more often.

On Tue, Feb 23, 2010 at 3:54 AM, Pavel Ivanov <paiva...@gmail.com> wrote:
>> How can i recover this kind of DB, is it possible? and is there any way
>> to avoid these
>> unused pages, will enable auto_vacuum solve the problem ?
>
> 'VACUUM' is not designed to recover malformed database. Yes, there are
> some kinds of problems that can be eliminated during vacuuming, but
> not all of them. And automatic vacuuming will never guarantee you
> protection against database corruption. When properly used SQLite will
> protect from database corruption itself. If you've got corrupted
> database it means that you have either bad application or your
> database file resides on some bad file system.
>
>
> Pavel
>
> On Tue, Feb 23, 2010 at 5:33 AM,  <ramesh.kotab...@wipro.com> wrote:
>> Hi All,
>>
>> I found the DB corruption (malformed database), reporting some unused
>> pages,
>> please find the below trace,
>>
>> *** in database main ***
>> Main freelist: 21 of 21 pages missing from overflow list starting at 0
>> Page 1604: sqlite3BtreeInitPage() returns error code 11
>> Page 1461 is never used
>> Page 1468 is never used
>> Page 1469 is never used
>> Page 1472 is never used
>> Page 1473 is never used
>> Page 1474 is never used
>> Page 1475 is never used
>> Page 1478 is never used
>> Page 1480 is never used
>> Page 1482 is never used
>> Page 1484 is never used
>> Page 1485 is never used
>> Page 1486 is never used
>> Page 1488 is never used
>> Page 1489 is never used
>> Page 1491 is never used
>> Page 1517 is never used
>> Page 1531 is never used
>> Page 1536 is never used
>> Page 1578 is never used
>> Page 1581 is never used
>>
>> I tried to recover the DB, by running "vacuum", its failed again saying
>> "SQL error: database disk image is malformed".
>>
>> How can i recover this kind of DB, is it possible? and is there any way
>> to avoid these
>> unused pages, will enable auto_vacuum solve the problem ?
>>
>> I am using 3.5.8 version. and DB size is 1.6M
>>
>> Thanks in advance.
>>
>> Regards,
>> Ramesh
>>
>>
>> Please do not print this email unless it is absolutely necessary.
>>
>> The information contained in this electronic message and any attachments to 
>> this message are intended for the exclusive use of the addressee(s) and may 
>> contain proprietary, confidential or privileged information. If you are not 
>> the intended recipient, you should not disseminate, distribute or copy this 
>> e-mail. Please notify the sender immediately and destroy all copies of this 
>> message and any attachments.
>>
>> WARNING: Computer viruses can be transmitted via email. The recipient should 
>> check this email and any attachments for the presence of viruses. The 
>> company accepts no liability for any damage caused by any virus transmitted 
>> by this email.
>>
>> www.wipro.com
>> ___
>> sqlite-users mailing list
>> sqlite-users@sqlite.org
>> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>>
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>



-- 
Jim "Jed" Dodgen
j...@dodgen.us
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] In-memory database backup

[Jim "Jed" Dodgen]

or simply .dump it

On Wed, Sep 30, 2009 at 8:37 AM, Martin.Engelschalk
<engelsch...@codeswift.com> wrote:
> Hi,
>
> you can use the online backup api described here:
> http://www.sqlite.org/backup.html
>
> Martin
>
> Andres Velasco Garcia schrieb:
>> Hello,
>>
>> Do any of you know if it is possible to backup an in-memory database to disk 
>> so it can be recovered later from disk.
>>
>> Thanks
>>
>> Andres Velasco
>> M: +34 670 40 73 69
>> Skype: newwwave.andres.velasco
>>
>>
>>
>> ___
>> sqlite-users mailing list
>> sqlite-users@sqlite.org
>> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>>
>>
> _______________
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>



-- 
Jim "Jed" Dodgen
j...@dodgen.us
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Sqlite profiler

[Jim "Jed" Dodgen]

how would your profiler differ from "explain"?

http://sqlite.org/lang_explain.html

On Wed, Sep 23, 2009 at 6:32 AM, Christian Schwarz
<c.schw...@systemtechnik-online.de> wrote:
>> Maybe, what is it?
>
> http://en.wikipedia.org/wiki/Profiling_(computer_programming)
>
> Cheers, Christian
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>



-- 
Jim "Jed" Dodgen
j...@dodgen.us
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users