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.
The file should be in the %sqlany17%\Scripts directory.
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?
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?
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.
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.
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.
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).
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.
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.
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.