The forum will experience an outage sometime between February 10 at 7:00pm EST and February 12 at 11:59 EST for installation of security updates. The actual time and duration of the outage are unknown but attempts will be made to minimize the downtime. We apologize for any inconvenience.

I don't know whether this is related to that current issue with authenticated databases and current builds:

I'm trying to unload a v10 OEM database with v17.0.0.1211 (brand new, yes), and I get a misleading error with SQLCODE -1020: "Cannot use log file ... since it is shorter than expected".

However, the log is just fine (and the database runs successfully as a SQL Remote remote), and unloading with other current versions (12.0.1.4301 and 16.0.0.2058) is successful, too. That might give a clue that the problem is not related to the cited FAQ, as those versions are affected by that issue, as well.

Unloading other databases seems to work with 17.0.0.1211, so I don't think this is a general issue. (And it does not depend on whether option "-up" is used or not, the only additional option I'm using compared to unloading with v12/v16.)


FWIW, I tried to add the according connection_authentication string for DBUNLOAD via the InitString connection parameter but that seems to be unrecognized by DBUNLOAD (telling - translated - "Invalid or missing keyword after InitString"). However, as the current v12/v16 are able to unload from that database I don't think it's related to the missing authentication...

asked 02 Sep '15, 09:01

Volker%20Barth's gravatar image

Volker Barth
29.3k287438645
accept rate: 32%

Just to add: That's just for information, I'm gonna do a two-step unload/reload to move from v10 via v12 to v17 then...

(02 Sep '15, 09:03) Volker Barth
Replies hidden

You need to use authenticate.sql to supply the DATABASE_AUTHENTICATION option when the database is initialized on an Authenticated Edition server. That file should have the following content:

SET OPTION PUBLIC.database_authentication = 'authentication-statement' go

The file should be in the %sqlany17%\Scripts directory.

Full details can be found here:

http://dcx.sap.com/index.html#sqla170/en/html/814c3bca6ce210148100cbc950c42f82.html*loio814c3bca6ce210148100cbc950c42f82

(02 Sep '15, 09:15) Chris Keating
Replies hidden

Hm, I don't want to create an authenticated database, I just want to unload it. The database runs fine (and accordingly authenticated) with v10 OEM, so that option has already be set for v10.

(02 Sep '15, 09:27) Volker Barth

Let me give this a try and see if I can reproduce the error you are seeing.

(02 Sep '15, 09:29) Chris Keating

Can you confirm the dbunload command line that you are executing?

(02 Sep '15, 09:57) Chris Keating

Correction: I have compared the output of v16/v17 dbunload for another database, and they are identical (at least w.r.t. the relevant topics), so I'll use the v16 unload to build a v17 database...

(02 Sep '15, 10:06) Volker Barth

I am a bit confused about the concern about the bug with OEM authentication and the admin tools. Are you doing a multistep manual rebuild?

Or is this error occurring as part of your running with dbunload -ar?
{and in that event maybe you can provide exact cmdline so we can simulate}

(02 Sep '15, 10:43) Nick Elson S...
Replies hidden

Well, sorry for the concern about that OEM bug - it's just what came to my mind when I noticed the failing unload. It's just one single OEM database I want to reload (primarily for testing purposes), and yes, I'm doing a manual reload.

Several not-OEM databases from v8-v12 have been successfully reloaded to higher versions (v12-v17), that one is the only one that fails when unloading with v17, so I suspected a relationship to the authentication...

Here's the command line for v17 (names/pathes adapted...):

SET REPLNAME=4711_SB3
"%SQLANY17%\bin32\dbunload" -v -c "UID=dba;PWD=***;DBF=C:\DATA\%REPLNAME%\MyDb.DB" -r "C:\DATA\%REPLNAME%\Reload10.sql" -ii "C:\DATA\%REPLNAME%\Unload10" -up -o C:\DATA\%REPLNAME%\Unload10.log
pause

For unloading with v12/v16, the command line would be almost identical but with according environment variables and without the new "-up" option, obviously.

(02 Sep '15, 10:56) Volker Barth

So I am getting an authentication violation that is likely associated with the authentication bug cited. I believe that is the expected outcome with builds that have this issue. It may be something specific to that file. Is it something that can be provided for review?

(02 Sep '15, 15:35) Chris Keating

Chris, I could supply those files (totally around 20 MB) - what are my options?

Note, I'm not really up to open a support incident, I'm gonna solve the problem via an (intermediate) migration to v16 for that particular database to let v16 handle the old logs accordingly, and then possibly move to v17.

My posting is primarily aimed to hint at a possible bug...


As stated, I don't think anymore this is related to a authentication violation, see my comment on Nick's answer.

(03 Sep '15, 04:39) Volker Barth

You can send it to my email first.last@sap.com.

(03 Sep '15, 09:15) Chris Keating

Done so...

(04 Sep '15, 04:06) Volker Barth
Comment Text Removed
More comments hidden
showing 5 of 12 show all flat view

This issue has not been fixed in Engineering Case #789369. The problem relates to decryption of a simply encrypted transaction log file created in pre-v17. This has now been fixed and will be available in a future update to v17 (build 1271 or later).

permanent link

answered 18 Sep '15, 14:01

Chris%20Keating's gravatar image

Chris Keating
2.4k1444
accept rate: 22%

converted 28 Dec '15, 06:30

Volker%20Barth's gravatar image

Volker Barth
29.3k287438645

This issue has not been fixed

"has not" or "has now"? - Anyway, thanks for the fix:)

FWIW: Given Chris's bug descrption, I guess in my case the workaround to migrate the v10 database to v16 and then to v17 has - rather incidentally - worked since v17 could handle the old v16 logs as these were strongly encrypted while the v10 logs were simply obfuscated. Lucky me.

(18 Sep '15, 14:25) Volker Barth
Replies hidden

Tests with the fresh 17.0.0.1328 EBF have proven that this error has been fixed, and such old logs can be opened with v17. Here's the according CR note:

    ================(Build #1271  - Engineering Case #789369)================

    Simple-encrypted version 10 databases would have failed to start on a version 
    17 server. This has been fixed.
(28 Dec '15, 06:32) Volker Barth

hmmm . . .

   · Manual rebuild  (no -ar, -an or -ac switch)             √
   · V17 dbeng starting database during dbunload operation   √
   · The error is coming from the V17 database unload server √
   · Not an issue for V12 or V16                             √
   · Not an issue for dbeng17 starting the database directly √

Sounds like we would need to see the database and transaction log to debug this further.

It is likely to be self-correcting if you backup and rename the current transaction log (possibly with V17 dbeng17) if that helps any.

permanent link

answered 02 Sep '15, 17:22

Nick%20Elson%20SAP%20SQL%20Anywhere's gravatar image

Nick Elson S...
6.2k2890
accept rate: 30%

Not an issue for dbeng17 starting the database directly

No, that's wrong - I can start the database directly with v10 (OEM), v12 and v16, however, I cannot start it with v17 as that claims "Cannot use log file ... since it is shorter than expected" - i.e. the same message I get when trying to unload.

If I rename the log as requested and start the database with v17, it starts fine (and creates a fresh log, as expected).


The issue seems to be based on the fact that v17 does not accept logs built with v10 (at least for that database, I have no other v10 remote to check...) but treats them as damaged.

My attempt to use the v16 dbunload to extract data and then to build a v17 database has worked (see my 2nd comment on the question), however SQL Remote also claims the older v10 (offline) logs as damaged. And when I try to use DBTRAN against the old logs, that's what v16 DBTRAN tells - I hope the German locale is no problem here:

SQL Anywhere-Dienstprogramm Transaktionslogübersetzung Version 16.0.0.2158
Transaktionslog "150819AB.LOG" beginnt am Offset 0085182763
Transaktionslog endet am Offset 0085863845

SQL Anywhere-Dienstprogramm Transaktionslogübersetzung Version 16.0.0.2158 Transaktionslog "MyDb_SA10.log" beginnt am Offset 0085863845 Transaktionslog endet am Offset 0086035446

(Apparently v16 cannot translate the new v17 log...)

In contrast, that's v17 DBTRAN output:

SQL Anywhere-Dienstprogramm Transaktionslogübersetzung Version 17.0.0.1211
Transaktionslog "150819AB.LOG" beginnt am Offset 0085182763
Logdatei beschädigt (ungültiger Seitenheader)
Beschädigung des Logs beginnt bei Offset 0085186878
Logvorgang bei Offset 0085186879 hat beschädigte Daten bei Offset 0085186879

SQL Anywhere-Dienstprogramm Transaktionslogübersetzung Version 17.0.0.1211
Transaktionslog "MyDb_SA10.log" beginnt am Offset 0085863845
Logdatei beschädigt (ungültiger Seitenheader)
Beschädigung des Logs beginnt bei Offset 0085867960
Logvorgang bei Offset 0085867961 hat beschädigte Daten bei Offset 0085867961

SQL Anywhere-Dienstprogramm Transaktionslogübersetzung Version 17.0.0.1211
Transaktionslog "MyDb.log" beginnt am Offset 0086035446
GUID der aktuellen Zeitleiste: 26550fa9-098d-4306-9d55-349e0708bbb0
UTC-Erstellungszeitpunkt der aktuellen Zeitleiste: 2015-09-02 14:12:52.526000+00:00
GUID des aktuellen Transaktionslogs: 00000000-0000-0000-0000-000000000000
Transaktionslog endet am Offset 0086039672

(03 Sep '15, 04:35) Volker Barth
Replies hidden

Just for the record:

Chris has been able to reproduce the problem for v17 to read these particular v10 log files, and in the meantime the announced two-step migration was successful:

The v10 database was migrated to v16, and once the old v10 offline logs were no more needed by SQL Remote and were automatically deleted, the database could be migrated to v17 and runs now successfully as a v17 remote.

(11 Sep '15, 02:01) Volker Barth
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:

×63
×35
×18

question asked: 02 Sep '15, 09:01

question was seen: 1,222 times

last updated: 28 Dec '15, 06:33