Hahn, Uwe | 1 Jun 2004 08:38
Picon
Favicon

RE: Eternal kernel problem

Hello Sven and others,

instead of using:

>recover_start data
>util_execute clear log

you should use since 7.5:

db_activate recover data

Kind regards,
Uwe

>-----Original Message-----
>From: maxdb [mailto:maxdb <at> ceroriesgo.co.cr] 
>Sent: Monday, May 31, 2004 2:46 AM
>To: maxdb
>Subject: Re: Eternal kernel problem
>
>
>Backup and Restore is not problem for me at anywhere and any 
>pc on suse 
>9 prof...
>I do a simple full backup and then can restore it on any other 
>maxdbserver without problems.... but when i recover full 
>backup i do it 
>ignoring the log of this form
>
>dbmcli -d $DB_NAME -u dbm,dbm
(Continue reading)

Claudia Henkel | 1 Jun 2004 10:16
Picon
Favicon

alter password of SYSDBA with dbmcli?

Hi,
can I alter the pasword of SYSDBA with dbmcli?

dbmcli sql_execute ALTER PASSWORD dba newpassword

returns ok, but has no result(?): anyway I have to login with the old 
password:

dbmcli -d dbname -u dba,newpassword
-> user authorization failed

dbmcli -d dbname -u dba,oldpassword
-> ok

Thanks,
Claudia

--

-- 
MaxDB Discussion Mailing List
For list archives: http://lists.mysql.com/maxdb
To unsubscribe:    http://lists.mysql.com/maxdb?unsub=gcdm-maxdb <at> m.gmane.org

Andre Reitz | 1 Jun 2004 11:08
Picon

Re: Pleas help: DEADLOCK ?

Sorry, sending my question again:

Scenario:
- We use Isolationlevel 1
- We *do not* use any explicit LOCKS

Questions:
- are the "tab_share" locks caused only by the 
  Lock Escalation strategy of sapdb, or is there 
  an other possible cause?
- Does the Dump show a real DEADLOCK?
- Why is the DEADLOCK not determined by the automatic DEADLOCK-Detection?

Greetings, and thank you very much in advance.

P.S.: I increased the MAXLOCKS Parameter to 50000.
      The problem is that we have huge peaks in our
      webapplication an so we cannot realy say if the
      problem is solved.

On Thu, 27 May 2004 19:18:05 +0200
Andre Reitz <reitz <at> inworks.de> wrote:

> Hy all, we have a "hang" in our web-based databaseapplication.
> 
> Something blocks our clients.
> 
> Please see the queryresult below or in the attachment.
> 
> Please tell me if my interpretation of the output is correct:
(Continue reading)

Alexander Papadopulos | 1 Jun 2004 16:25
Picon

Trigger Translation from Oracle and PostgrSQL

Hello everybody,

I desperately need documentation on MaxDB Triggers.
I have the reference manual, I need something more basic with
examples.
I have to translate Oracle PL/SQL and PostgreSQL PL/PGSQL Triggers to
MaxDB. 

Here is a PL/PGSQL Trigger, if anyone has the skill and time to
translate this I would be forever grateful. It is a temporal integrity
constraint for a valid time table. The development of the annual
salary of an employee through time in recorded. An employee identified
by NAME has a SALARY for a specific period of time from START to END.
The periods of time should not overlap.

CREATE TRIGGER seq_key AFTER INSERT OR UPDATE ON salary
FOR EACH ROW EXECUTE PROCEDURE seq_key_salary();

CREATE OR REPLACE FUNCTION seq_key_salary() RETURNS OPAQUE AS '
DECLARE
  VALID INTEGER;
BEGIN
IF (
 EXISTS (
  SELECT * FROM SALARY AS S1 WHERE 1 < ( 
   SELECT COUNT(NAME) FROM SALARY AS S2 
   WHERE S1.NAME = S2.NAME 
   AND (S1.START, S1.END) OVERLAPS (S2.START, S2.END)
   )
  )
(Continue reading)

Florian Rieffel | 1 Jun 2004 17:16
Picon

bug in outer join with (+)

hello community,

I'm using the latest Version of MaxDB 7.5.0.14.

To demonstrate the problem, I've created this tables with content:

-----------------------------------------

CREATE TABLE test_1 (
id int,
primary key (id)
)

CREATE TABLE test_2 (
id int,
primary key (id)
)

CREATE TABLE test_3 (
id int,
primary key (id)
)

INSERT INTO test_1 VALUES (1)
INSERT INTO test_1 VALUES (2)
INSERT INTO test_1 VALUES (3)
INSERT INTO test_1 VALUES (4)

INSERT INTO test_2 VALUES (1)
INSERT INTO test_2 VALUES (2)
(Continue reading)

Becker, Holger | 1 Jun 2004 19:16
Picon
Favicon

AW: bug in outer join with (+)

Florian Rieffel wrote:

> I'm using the latest Version of MaxDB 7.5.0.14.
> 
> To demonstrate the problem, I've created this tables with content:
> 
> -----------------------------------------
> 
> CREATE TABLE test_1 (
> id int,
> primary key (id)
> )
> 
> CREATE TABLE test_2 (
> id int,
> primary key (id)
> )
> 
> CREATE TABLE test_3 (
> id int,
> primary key (id)
> )
> 
> INSERT INTO test_1 VALUES (1)
> INSERT INTO test_1 VALUES (2)
> INSERT INTO test_1 VALUES (3)
> INSERT INTO test_1 VALUES (4)
> 
> INSERT INTO test_2 VALUES (1)
> INSERT INTO test_2 VALUES (2)
(Continue reading)

Andre Reitz | 1 Jun 2004 22:17
Picon

Re: Pleas help: DEADLOCK ?

Sorry, but still a little question.

Is it possible that "temp" "tab_share" Locks
result from:

- Joined-Selects on several Tables
- DELETE FROM Table WHERE A1=...
- SELECT FROM Table WHERE A1=... AND A2 IN (1,2,3,...)

(perhaps in combination with Lock Escalation?)

In other words:

- The question is: what kind of queries make "temp" "tab_share" Locks?
- Or: What kind of Queries make Locks that will be transformed into "temp" "tab_share" Locks
  in case of a LOCK ESCALATION? 

[all in Isolation Level 1]

(I looked into our sources, but I cannot imagine where the temp tab_share-Locks on 
IQ_ZUO_FB_SA, IQ_ZUO_FB_WF,IQ_ZUO_FB_TF, IQ_ZUO_FB_MA,
IQ_ZUO_FB_EA and IQ_ZUO_FB_AV come from...)

By the way: what means LOCKSTATE/REQSTATE "temp"?

Greetings, Andre'

On Tue, 1 Jun 2004 13:18:43 +0200 
"Schroeder, Alexander" <alexander.schroeder <at> sap.com> wrote:

(Continue reading)

Zabach, Elke | 2 Jun 2004 09:55
Picon
Favicon

AW: Pleas help: DEADLOCK ?

Andre Reitz wrote:
> 
> Sorry, but still a little question.
> 
> Is it possible that "temp" "tab_share" Locks
> result from:
> 
> - Joined-Selects on several Tables
> - DELETE FROM Table WHERE A1=...
> - SELECT FROM Table WHERE A1=... AND A2 IN (1,2,3,...)
> 
> (perhaps in combination with Lock Escalation?)
> 

The check of referential constraints during DELETE/UPDATE will cause TEMP table share locks.
Queries, no matter if join, subselect or the like, will cause TEMP table locks only with ISOLATION LEVEL 15/2/20/3/30.
LOCK ESCALATION will cause non-TEMP table locks.

Elke
SAP Labs Berlin
> 
> In other words:
> 
> - The question is: what kind of queries make "temp" "tab_share" Locks?
> - Or: What kind of Queries make Locks that will be transformed into "temp"
> "tab_share" Locks
>   in case of a LOCK ESCALATION?
> 
> [all in Isolation Level 1]
> 
(Continue reading)

Andre Reitz | 2 Jun 2004 10:23
Picon

Re: AW: Pleas help: DEADLOCK ?

On Wed, 2 Jun 2004 09:55:25 +0200 
"Zabach, Elke" <elke.zabach <at> sap.com> wrote:

> Andre Reitz wrote:
> > 
> > Sorry, but still a little question.
> > 
> > Is it possible that "temp" "tab_share" Locks
> > result from:
> > 
> > - Joined-Selects on several Tables
> > - DELETE FROM Table WHERE A1=...
> > - SELECT FROM Table WHERE A1=... AND A2 IN (1,2,3,...)
> > 
> > (perhaps in combination with Lock Escalation?)
> > 
> 
> The check of referential constraints during DELETE/UPDATE will cause TEMP table share locks.

Everytime? or only sometimes?

> Queries, no matter if join, subselect or the like, will cause TEMP table locks only with ISOLATION LEVEL 15/2/20/3/30.
> LOCK ESCALATION will cause non-TEMP table locks.

Thanks,
but what will be done first:

Will the ROW to be deleted / updated be locked first,
or the TEMP Table Share Locks be set on the referenced tables?

(Continue reading)

Andre Reitz | 2 Jun 2004 12:27
Picon

Re: AW: Pleas help: DEADLOCK ?

On Wed, 2 Jun 2004 09:55:25 +0200 
"Zabach, Elke" <elke.zabach <at> sap.com> wrote:

> Andre Reitz wrote:
> > 
> > Sorry, but still a little question.
> > 
> > Is it possible that "temp" "tab_share" Locks
> > result from:
> > 
> > - Joined-Selects on several Tables
> > - DELETE FROM Table WHERE A1=...
> > - SELECT FROM Table WHERE A1=... AND A2 IN (1,2,3,...)
> > 
> > (perhaps in combination with Lock Escalation?)
> > 
> 
> The check of referential constraints during DELETE/UPDATE will cause TEMP table share locks.
> Queries, no matter if join, subselect or the like, will cause TEMP table locks only with ISOLATION LEVEL 15/2/20/3/30.
> LOCK ESCALATION will cause non-TEMP table locks.

I analyzed my deadlocks and I believe that this is my Scenario:

parenttable
  -> childtable1
  -> childtable2
  -> childtable3

Transaction1:           Transaction2:
 update parenttable       
(Continue reading)


Gmane