HDTenEightyP/NetNews huggingface dataset:
From: michael@cutler.com (Michael D. Shields)
Newsgroups: comp.databases.ingres
Subject: CKPDB /VERIFY and /IGNORE=INTERLOCK (was Re: Compressing Checkpoints)
Date: 13 Apr 92 22:28:52 GMT
Article-I.D.: cutler.1992Apr13.142852.219
Organization: Cutler & Company, Inc., Medford OR (503) 770-9000

In article <9APR199218514052@moose.cccs.umn.edu>,
rao@moose.cccs.umn.edu (Rao V. Akella) writes:
> 
> So, if you're checkpointing to tape (like me), here's another tip
> for you VMS users: I reduced the wall time of taking a 450 MB
> checkpoint from an hour to 15 mins (per tape) by modifying
> II_SYSTEM:[INGRES.FILES.CHECKPOINT]CKP_TO_TAPE.COM
> to take the /VERIFY out of BACKUP.  In fact, I modified
> 	$ backup/verify/ignore=label_processing...
> to
> 	$ backup/ignore=(interlock,label_processing)...
> 
> BACKUP by itself does such a good job that the /VERIFY is largely redundant
> (IMHO).  A problem with /VERIFY is that BACKUP writes to a 225,000 block tape
> in only 12 minutes on the first pass -- and then takes 45 minutes on the
> second pass verifying the save-set!
> 
> The /ignore=interlock is required if you're taking on-line checkpoints.
> I strongly urge you to modify your file to include this option too.

Having just completed a recovery from an inconsistent production database (the
database upon which our company thrives), I feel the need to comment.

Our site uses a 4mm DAT drive on a dual-hosted SCSI bus as it's primary backup
device.  Occasionally, when a significant tape media error is encountered,
the original pass is performed flawlessly and the verification pass fails,
as seen in the following log file fragment of our system backups:

$ BACKUP/IGNORE=(INTERLOCK,LABEL_PROCESSING)/RECORD/VERIFY -
    /FAST/SINCE=BACKUP -
    $disk111:[*...]/EXCLUDE=([nobackups...] -
    ,[gnusoftware...] -
    ,[uucp...] -
    ) _MUB0:$disk111.BCK/SAVE_SET
%BACKUP-I-STARTVERIFY, starting verification pass
%BACKUP-F-READERRS, excessive error rate reading _MUB0:[]$DISK111.BCK;
-SYSTEM-F-PARITY, parity error

I would much rather know about this problem during CKPDB, rather than while
trying to perform a ROLLFORWARDDB operation.  It's quite true that the
verification pass can take much longer than the original pass.  But
it's time well invested, IMHO.

Regarding /IGNORE=INTERLOCK, you'll note that we use it during our system
backups.  Recently, there was an article regarding it's use (wish I can
remember where I saw the article).  In summary, the article pointed out
that by using the option, the backup may contain corrupt data, since the
valid data was in memory maintained by the application that had the file
locked.  We can live with this possibility during our system backups, but
our checkpoints need to be just that - valid checkpoints of the database.
I would recommend against it's use in the CKPDB procedure.

  Michael

Michael D. Shields      |  Internet: michael@cutler.com
AVP, MIS                |  UUCP: ...hplabs!hp-pcd!orstcs!cutler!michael
Cutler & Company, Inc.  |  Voice: (503) 770-9000
Medford, OR  97504      |  FAX: (503) 779-0006
From: kerry@Ingres.COM (Kerry Kurasaki)
Newsgroups: comp.databases.ingres
Subject: Re: inserts within a loop using cursors
Keywords: esql, cursors
Date: 14 Apr 92 23:10:02 GMT
Reply-To: kerry@Ingres.COM (Kerry Kurasaki)
Organization: Ask Computer Systems Inc., Ingres Division, Alameda CA 94501

In article <patrick.701675788@marsh> patrick@marsh.cs.curtin.edu.au (Patrick Ko) writes:
>cfraizer@bronze.ucs.indiana.edu (Colin Fraizer) writes:
>
>>I'm writing an esql C program that does the following:
>>	while (TRUE) {
>>		exec sql fetch data into
>>			<:variables>;
>>		foo(variables)  /* I do some manipulation of the data */
>>		exec sql repeated insert
>>			into new_table (blah blah)
>>			values (:new_variables);
>>	}
>
>>My problem is that, my inserts into the new table succeed, but I
>>run out of log file space and my transaction gets aborted.  Essentially,
>>I just need to grab data from one table, manipulate it, and put the
>>new data in another table.  Of course, I can't commit in the middle
>>of the inserts, because that closes my cursor.

If you have Release 6.4, you can use the statement:

	set session with on_error = rollback transaction

This gives you transaction level rollback on errors.  INGRES by default
uses statement level rollback, and hence must necessarily write additional
log records between each invocation of the INSERT statement.

The problem varies slightly if you are updating 10, 10000, or 10 million
rows.  With 10 rows, the code can execute as above.  With 10,000 rows,
you can try transaction level rollback.  With 10 million rows, you
might have to checkpoint the database, and turn logging off (another
Release 6.4 feature, set nologging).  If you turn logging off, you are
on your own for recovering your transaction.

Kerry Kurasaki
From: gnb@duke.bby.oz.au (Gregory N. Bond)
Newsgroups: comp.databases.ingres
Subject: 6.3/02 & 6.4 need SunView: WORKAROUND
Date: 13 Apr 92 23:59:19 GMT
Organization: Burdett, Buckeridge & Young, Melbourne, Australia

As you may be aware, Ingres 6.3/02 and 6.4/01 releases on SPARC have a
bug in that every binary in the release has been linked against
-lpixrect, -lsuntool and -lsunwindow.  This is a problem for a couple
of reasons:

1) Performance in disk I/O, memory usage and startup time from
dynamically linking in these huge unused libraries.  

2) What if you don't have sunview installed?  

3) What if it didn't even come on your release tape (as is the case
with Solbourne release 4.0 and I suspect many of the other SPARC
machines)?

It turns out that all you need it a library with the appropriate name.
They can be empty.  Here is what I did:

1) cd /tmp
2) as -o null.o - < /dev/null 
3) ld -o /usr/local/lib/libsuntool.so.0.40 null.o
4) ld -o /usr/local/lib/libsunwindow.so.0.40 null.o
5) ldconfig

I recommend this for performance reasons on any ingres machine not
running SunView.  We have been running this way for a couple of weeks
with no problems (under 6.3/02) but it is UNSUPPORTED.

Greg.
--
Gregory Bond <gnb@bby.oz.au> Burdett Buckeridge & Young Ltd Melbourne Australia
"Take my archetypes - please!" - Henny Jungman (geoffm@purplehaze.Corp.Sun.COM)
From: ghica@fig.citib.com (Renato Ghica)
Newsgroups: comp.databases.ingres
Subject: Re: Compressing Checkpoints
Keywords: checkpoint compress
Date: 9 Apr 92 19:56:06 GMT
Organization: Citibank IBISM
Originator: ghica@duck


In article <1992Apr7.082440.16845@csc.canberra.edu.au>, mmr@asgserver.canberra.edu.au (Micheal Rainford-Watson) writes:
|> 
|> Has anyone tried compressing their checkpoints as it's being created.
|> ie by editing the ../files/cktmpl.def file and running it through
|> a compression program or by using a different backup program which
|> has a compression feature. We aren't interested in compressing the 
|> checkpoint after it's been created.
|> 
|> We are running INGRES 6.3/01 on Unix (Dynix V3.0)
|> 
|> 

for disk checkpoints, try this (in the cktmpl.def file). Offhand it seems
to work...

diffs follow


NEW < WSD:  cd %D; /bin/tar cf - * | compress > %A".Z" 
---
OLD > WSD:  cd %D; /bin/tar cf %A *
8c8
NEW < WRD:  cd %D; uncompress -c %A | /bin/tar xf -
---
OLD > WRD:  cd %D; /bin/tar xf %A



-- 
--------------------------------------------------------------------------
"These views are my own. / Mail me or Flame me"

>@)
From: daryl@piano.adept.ih.att.com (Daryl Monge)
Newsgroups: comp.databases.ingres
Subject: Re: my wiew on ingres
Date: 13 Apr 92 23:19:58 GMT
Organization: 5ESS(TM)-US Release Management
In-reply-to: expert@diku.dk's message of 13 Apr 92 16:14:25 GMT

In article <1992Apr13.161425.12861@odin.diku.dk> expert@diku.dk (Stephan Grubbe) writes:

>   We just finished a report where we had to use ingres system.
>   The only conclusion is that
>
>   INGRES SUCKS

This is a pretty useless post.  Please discuss:
	- What source (commercial, university)
	- What version
	- What type of host
	- Types of things that take a long time
	- Installation parameters
	- comparisons to other DB's (relational or otherwise)
From: drb@achilles.ams.com (Drew Burton)
Newsgroups: comp.databases.ingres
Subject: SunOS 4.1.2 and Ingres 4.1
Date: 10 Apr 92 19:15:44 GMT
Distribution: comp
Organization: American Math. Society


     I tried to post this earlier and I don't think it got through:

	In an earlier posting by Alexander Smith and confirmed by Joao
Pedro Leao, they had problems with Ingres 6.4 on SUNos 4.1.2.  

	We have what appears to be the very close to the same setup and
Ingres comes up just fine for us.  More specificly, we have SUNos 4.1.2
that came installed on a SPARCstation IPX that we just received.  The
Ingres tape is
  	6.4/01(su4.u42/01)
	QIC-24
	Date:	3/04/92.

	Alexander's Ingres tape was dated two days earlier.  Also, we're
working with a pre-installed SUNos 4.1.2.  Maybe Ingres or Sun got
something right in the interim.

	Drew Burton		drb@math.ams.com
	American Math Society
From: leao@BUPHY0.BU.EDU (Joao Leao)
Newsgroups: comp.databases.ingres
Subject: RE: Relational Systems set back DP by at least 10 yrs.
Date: 17 Apr 92 18:56:35 GMT

(In Article: 194 of comp.databases.ingres Chandrasekaran Periannan posts:

		...a complete reproduction of a letter to the editor of
>Commmunications of the ACM, published in April 1992 issue. This letter was
>written in response to an article by Ullman et al.
>that appeared in the Oct 91 issue of CACM
>(which was devoted to "Next Generation Databases") which said, "Relational
>Databases was one of the three major achievements of the past two
>decades".

------------Begin letter        -----------------------------------------
>Copyright ACM 1992.

>Henry G. Baker,
>Nimble Computer Corp,
>16231 Meadow Ridge Way,
>Encino,CA 91436.


>Relational databases:

>	I had great difficulty in controlling my mirth while I
>read the self-congratulatory article, "Database Systems: Achievements
>and Opportunities" (Oct 1991, p110), because its authors consider
>_relational databases_ to be one of the greatest achievements of the
>past decades. As a designer of commercial manufacturing applications
>on IBM mainframes in the late 1960s and early 1970s, I can
>categorically state that relational databases _set the data processing
>industry back at least ten years_ and wasted many of the billions of
>dollars that were spent on data processing. With the recent arrival of
>object-oriented databases, the industry may finally achieve some of
>the promises which were made 20 years ago about the capabilities of
>computers to automate and improve organizations.
>

[...followed by biological-evolutionary-corporate diatribe in the
defence of the old hierarchical databasing systems... and endictment
of Codd's relational db model...]

Mister Baker is very obviously one of the many hierachical DBMS 
designers who lost their confy patch since the advent of the
relational model. All his biological metaphors cannot hide the
fact that it was the demise of the mainframe "dinossaurs" which
condemned the hierarchical DB systems which he so much misses.
It was on these beasts and their horde of attendants that
billions of dollars were burried by the corporate clientele
of IBM in the 60s and 70s.
 
It is quite funny and telling that Baker berates the "Church of
Relationism" when it is the "Church of the DP Center" and its
priesthood which was overthrown by the development of distributed
desktop systems and relational dbms which are historically associated 
with them. Object Oriented DBMS come out quite naturaly off the
relational model and 4GLs as Ingres very much exemplifies.


Joao Leao 
Boston University - Physics Dept. Boston MA 02215)
 leao@buphy.bu.edu | leao@buphyc.bitnet | BUPHYC::LEAO 
"Well I am sitting here in Tahiti/ I am laying in the sun and sipping a...
...chartreuse tropical drink!/ and I say: I know those Bermuda shorts!..."
   
Newsgroups: comp.databases.ingres
From: sue@netcom.com (Sue Miller)
Subject: INGRES sites worldwide
Date: Fri, 10 Apr 92 17:48:24 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 

This may be a strange question, but here goes.  Does anyone here
know the relative distribution of INGRES worldwide?  Are there many
installed sites in Europe, Australia, Asia?  I'm curious, being that
I'll be moving to the UK soon (to do some INGRES stuff).  I'd like
to find out if I'll be able to find other INGRES work in the UK
and maybe in other places in Europe or Oz. 

Also, are many people out there doing Windows/4GL?

sue
sue@netcom.com
From: sljn6@cc.usu.edu
Newsgroups: comp.databases.ingres
Subject: Features Ultrix/SQL (Ingres 6.2)
Date: 15 Apr 92 13:00:28 MDT
Organization: Utah State University


I got a copy of Ultrix/SQL  S/W.  but have not got all the manuals
etc. The operations manual says the release is based on Ingres 6.2
I was wondering as to what all features of Ingres  does the Ultrix/
SQL support.  I could see that as far as architecture is concerned
it is almost ingres but I could not locate the 4GL features and 
vifred (or any other form's editor).  Besides I would like to know
what all Language interface's does this provide.(3GL)

I am                               
RAJIV GOYAL                           E-mail  SLJN6@cc.usu.edu
CS Dept  Utah State University        Ph.  801-753-2761
Logan Utah.
Organization: University of Illinois at Chicago
Date: Friday, 10 Apr 1992 23:02:06 CDT
From: Parisa Sepehri <U33720@uicvm.uic.edu>
Newsgroups: comp.databases.ingres
Subject: heard of AEGIS?

 hello;
We are planning to upgrade from version 5.3 or maybe 5.4 to 6.0, We have
a lot of source written in embedded QUEL and SQL:.QB .SB .SC.
This comapany with name AEGIS  claims   to have conversion softwre that would
convert our sources to Ingres 6.0. I should mention that their software is not
out yet: They want to use us as a Beta site.

I was wondering if anyone had any experience with AEGIS. I thank you
for your responses in advance.
Newsgroups: comp.databases.ingres
From: leath@atlas.cs.upei.ca (Stephen Leath)
Subject: Re: by clause in quel
Organization: University of Prince Edward Island
Date: Mon, 6 Apr 1992 16:21:40 GMT

In article <1992Apr1.205115.94@gems.vcu.edu> brooks@gems.vcu.edu writes:
>I have a QUEL problem which has racked my brain all afternoon.  Maybe another 
>programmer can see the faulty logic.  The following behavior happens under 
>INGRES 6.3/03  or INGRES 6.4/01 (VMS 5.4-3 on both machines):
>
>Consider a heap table called DAN with two fields:  XXX and NUMBER.  The fields 
>can be of any numeric type (I1, I2, I4, F4, F8).
>
>The contents of the table are:
>
>XXX     Number
>1         1
>1         2
>1         3
>
>The following QUEL gives a correct result:
>
>range of d is dan
>RETRIEVE  (D.XXX,Z=SUM(abs(d.number-avg(d.number)))) 
>Executing . . .
>
>
>+------+-----------+
>|xxx   |z          |
>+------+-----------+
>|     1|      2.000|
>|     1|      2.000|
>|     1|      2.000|
>+------+-----------+
>(3 rows)
>continue
>
>The following 2 QUEL statements give the identical incorrect result (correct 
>meaning the number I want!):
>
>ramge pf d is dan
>RETRIEVE (d.xxx,Z=SUM(abs(d.number-avg(d.number by d.xxx)))) 
>Executing . . .
>
>
>+------+-----------+
>|xxx   |z          |
>+------+-----------+
>|     1|      1.000|
>|     1|      1.000|
>|     1|      1.000|
>+------+-----------+
>(3 rows)
>continue
>
>range of d is dan
>RETRIEVE (d.xxx,Z=SUM(abs(d.number-avg(d.number by d.xxx))by d.xxx)) 
>Executing . . .
>
>
>+------+-----------+
>|xxx   |z          |
>+------+-----------+
>|     1|      1.000|
>|     1|      1.000|
>|     1|      1.000|
>+------+-----------+
>(3 rows)
>continue
>
>When I change the values of NUMBER to be something other that one apart, all 
>three statements give the identical correct result.  Also, if I change the 
>minus sign to a plus, divide, or multiply, all three give the correct result.  
>The above code is part of the algorithm I use to calculate a standard 
>deviation.  I was horrified to find incorrect results with certain data.  
>
>Thanks in advance for sharing your experience or advice. Wish I could call 
>tech support, but I only have update service.

Try this:

range of d is dan
RETRIEVE  (D.XXX,Z=SUM(abs(d.number-avg(d.number)) by d.xxx )) 

Steve.
From: rayt@cix.compulink.co.uk (Ray Turner)
Newsgroups: comp.databases.ingres
Subject: Ingres Tracepoints
Date: 9 Apr 92 03:12:48 GMT
Reply-To: Ray Turner <rayt@cix.compulink.co.uk>
Organization: Gated to News by demon.co.uk


I have noticed that some tracepoints are now being documented in the
6.4 DBA Guide. Does anyone know if a complete list exists. The one
to list out the DMF cache details DM420 doesn't seem to work with
our current 6.4 setup.

Ray

rturner@cix.compulink.co.uk
Newsgroups: comp.databases.ingres
From: sljn6@cc.usu.edu
Newsgroups: comp.databases.ingres
Subject: cost of ingres(UNIX)
Date: 6 Apr 92 15:27:56 MDT
Organization: Utah State University


I wish  to know  if a version is available for HP-workstations 400 series
of Ingres. (UNIX)
Also I would like to know as to what the price would be for buying 
the same for an Educational institution  (UTAH STATE UNIVERSITY)
CS. Dept.  with the follwing configuration.

   1. Ingres 6.3  or later
   2.  Ingres -Star
   3. 3-GL Interface to "C" , Pascal
and of course any other relevent data.


If  you have any  such information or the ph. no. of where this info
can be available  can you please  email me the same.


RAJIV GOYAL                           e-mail   sljn6@cc.usu.edu
CS DEPT  UTAH STATE UNIVERSITY
LOGAN UTAH. 84321
From: heim@vms.macc.wisc.edu (JOHN HEIM	)
Newsgroups: comp.databases.ingres
Subject: Re: Row level locking?
Date: 14 Apr 92 16:31:09 GMT
Organization: University of Wisconsin Academic Computing Center

In article <9204100843.AA10575@asgserver.canberra.edu.au>, mmr (Micheal Rainford-Watson) writes...

>In article <5413@otc.otca.oz> you write:
>>In the ULTRIX/SQL version of Ingres, I haved noticed that there is no row level locking.
>>
> 
>It's the same with all ingres platforms
> 
>>Page locking yes - 2048 bytes of data can be locked at a time, by not at row level. :-(
>>
>>Anyone over come this "feature" without making all rows pages?
>>
>Implement you own row level locking, eg add a column to each row and flag it
>when updating, then reset when finished. And there are other stratergies....
> 
>BUT, I wouldn't recommend this! 
> 
>Better to briefly ...
> 
>SELECT into fields, then COMMIT (release locks)
>Update the fields on the form.
>Then UPDATE the database with these changed fields, then COMMIT (release locks).
> 
>ie Dont hold any locks longer than necessary

I think the above strategy defeats the purpose of locks altogether.  
For instance ...

        Process 1:               Process 2:
        ----------               ----------

T       SELECT tuple_x
I       COMMIT
M                                SELECT tuple_x
E                                COMMIT

|       <<Changes>>
V       UPDATE
                                 <<Changes>>
                                 UPDATE


Process 1's changes would be lost.

******************************************************************************
John G. Heim                                 Email:  heim@macc.wisc.edu
UW-Madison Academic Computing Center         Phone:  608-262-9887
1210 W. Dayton St.                           Fax:    608-262-4679
Madison, WI 53706                            CIS:    76376,3635
**************** Not responsible for lost or stolen articles. ****************
From: thomasl@mtl.mit.edu (Thomas J Lohman)
Newsgroups: comp.databases.ingres
Subject: Re: maxrows ?
Date: 6 Apr 92 14:33:32 GMT
Organization: MIT Microsystems Technology Laboratories

In article <59Y17DR@zelator.in-berlin.de> thf@zelator.in-berlin.de (Thomas Funke) writes:

>What I want, is a SELECT which just delivers one row, even if
>the selection criteria would usually deliver many rows. I believe, 
>this would speedup my application. I don't care which of the rows will
>be delivered first.

I have often wondered this as well.  One way in which I used to 
pick one row out of a several thousand row select was to randomize 
one of my where clause variables.  This way it would hopefully
choose different rows if I were to run it more than once.  After 
randomizing, you can then just end the select after one fetch.

As I remember to randomize a string you put % character and it will match 
any character.  So for instance all name that begin with 
sam for a 6 character field would be "sam%%%".  If I am wrong,
someone please correct me.


--tom
Newsgroups: comp.databases.ingres
From: ghica@fig.citib.com (Renato Ghica)
Subject: online checkpoint
Originator: ghica@duck
Organization: Citibank IBISM
Date: Mon, 6 Apr 1992 18:40:25 GMT



	Environment :
		client/server SunOS 4.1.1 with INGRES 6.4/01-2 (4.1.2 version)

	
	The ingres release notes mention that the lock taken by a client
	which "disappears" due to it crashing or disconnected TCP/IP
	connection now goes away after 2 hours and 10 minutes. This is
	done, presumably with keep-alive timers.

	Does anyone know if this is in fact the case, and if yes, can
	this be made much shorter ?

	The problem that I'm trying to address is that of doing an online
	checkpoint when a client crashes and leaves its lock around. Currently
	(6.3) ckpdb returns DATABASE_IN_USE (even though there are no clients)
	when doing a ckpdb database_name +j.

	If anyone knows how the get around this, please let me know.




-rg
-- 
--------------------------------------------------------------------------
"These views are my own. / Mail me or Flame me"

>@)
From: hevern@cac.washington.edu (M. Hevern)
Newsgroups: comp.databases.ingres
Subject: Re: Concurrency (was Re: Row level locking?)
Date: 17 Apr 92 21:43:51 GMT
Organization: U.W. Information Systems

In article <1992Apr15.113021.27858@jupiter.sun.csd.unb.ca>, leath@atlas.cs.upei.ca (Stephen Leath) writes:
> How does this get around page locking, does it not only postpone it to a
> later date. ? If so why not save the updates in script form and perform them
> in order later. ?

The method I mention avoids page level locking by selecting the data, commiting (release locks), modifying the data, updating (with concurrency checking values), and commiting. The locks are held only as long as it takes to select or update. With readlock set to nolock the only complication is when two people try to update a row on the same page of the table or one of it's secondary indexes, and the locks are held only as long as an update takes. The user will not notice the extra time (on a loaded VAX) it




 takes for the locks from the first transaction to be released, unless there is a concurrency problem.

-- 	MH
       *--------------------------------*------------------------------*
       | Michael Hevern			| Voice: (206) 685-3229        |
       | University Of Washington	| * "I can't dance...          |
       | Information Systems		|    I can't talk...           |
       | 4545 15th Ave. NE		|    The only funny thing about|
       | Seattle, WA 98105		|    me is the way I walk."    |
       | Mail Stop: JE-41               |       -- Genesis             |
       *--------------------------------*------------------------------*
	Disclaimer: If I said it I probably meant it.  My employer isn't
		responsible for my opinions.