|
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... |
|
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).
"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 . . . 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.
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 (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
|
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...
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
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.
Let me give this a try and see if I can reproduce the error you are seeing.
Can you confirm the dbunload command line that you are executing?
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...
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}
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...):
For unloading with v12/v16, the command line would be almost identical but with according environment variables and without the new "-up" option, obviously.
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?
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.
You can send it to my email first.last@sap.com.
Done so...