cancel
Showing results for 
Search instead for 
Did you mean: 

Upgrading SQL Remote: How to use DBUNLOAD -ar and change database options like blank padding?

VolkerBarth
Contributor
0 Kudos
2,772

I'm about to upgrading an ASA 8.0.3 SQL Remote setup to SA 11.0.1 (and testwise to SA 12 RC1).

The old database uses some CREATE DATABASE options I would like to change in the new one, e.g. to turn

  • blank padding off
  • ase compatible off
  • checksum on.

As the database is involved in replication, I would like to use the easy way by DBUNLOAD -ar. However, this seems to make me unable to change the above settings as DBUNLOAD does not support to change these options - and lateron it's too late, as they must be specified at database creation time.

Question:

Do I have to use the "unload process with manual intervention", i.e. with dblog -x -z, or is there a further alternative to change these options? (Not that the manual process would not be feasible.)

Accepted Solutions (1)

Accepted Solutions (1)

MarkCulp
Participant

You cannot change any of the database settings when using the dbunload -ar or -an switch since the new database is created (by dbunload) with the exact same attributes as the original. There are some exceptions to this rule. For example you can change the encryption of the database and the page size of the rebuilt database.

Therefore if you want to change the settings that you have listed, you must use the manual process.

VolkerBarth
Contributor
0 Kudos

Thanks for the confirmation! In the end, this is not a real limitation in my case, as I will have to use the manual process in order to achieve further changes, e.g. naming check constraints and other stuff not possible wie ASA 8...

VolkerBarth
Contributor
0 Kudos

By the way, in SA 12 RC1, CHECKSUM ON seems to be the default for CREATE DATABASE (which is fine to me) - in contrast to the docs. Haven't checked with 11.0.1 yet.

MarkCulp
Participant

Yes, the docs were a little behind with the s/w changes at the time we released RC1. We have decided to turn checksums on by default because there are many advantages and not a lot of disadvantages. The GA docs will have the required changes. Note also that in GA even if the database was created with CHECKSUM ON you will be able to turn checksums off by running ALTER DATABASE CHECKSUM OFF but then you will not be able to turn checksums back on without rebuilding the database.

VolkerBarth
Contributor
0 Kudos

I welcome that change - Breck's statement that you guys tend to use sensible defaults (in my words) continues to be right:)

Answers (0)