Azure storage account file share backup costs

Difficult to read the title, right? Yes, a lot of prefixing to set the costs into some context, as we’re going to talk about Azure, sub – storage accounts, sub – files shares, sub – (snapshots) backups and, yet finally, the resulting costs. I’m looking back on a three-month service request with Azure now to just get answered what I’m actually paying for. Well, most of the Azure people didn’t even understand my question, so the request took these ages to be serviced… but that’s another topic and other “big” companies disappoint no differently.

So, what’s the problem? As you might know, there is plenty of cost factors related to storage accounts (https://azure.microsoft.com/en-us/pricing/calculator). Storage, transactions, transfer, sync and so on. A certain cost factor is backup snapshot storage allocation, if you follow the recommended way of backing up your file shares (https://docs.microsoft.com/en-us/azure/backup/azure-file-share-backup-overview , https://docs.microsoft.com/en-us/azure/storage/files/storage-snapshots-files).

Since the overall monthly cost for the storage account went way beyond the expected numbers, I opened the portal to examine the latest monthly amounts for storage, transactions, transfer, sync… That’s easy for e.g. regular storage account allocation. I recommend consulting the included storage browser for an over view.

But, you guess it, there is no easy way to find out about the backup snapshot storage allocation. No info the the Snapshots View of the file share, neither in the Backup View. And, since the snapshots only save an incremental change difference of the actual file share content, there also is no straightforward rule to estimation.

So, maybe, the newly introduced Backup Center / Backup Reports may help, since this is all Azure standard backup architecture. Nope, they obviously have a datum for file share backup allocation in place but it always reads 0 😕

Ok, now, after the three months mentioned above, they directed me to the storage account Metrics view, metric: File Share Snapshot Size, to verify the invoiced allocation.

Given these numbers throwed to the Azure pricing calculator finally justifed the invoiced sum for the overall storage accounts cost. And btw, you’re not strained to rely on the pricing calculator all alone. Azure also offers an XLS based calculator (https://aka.ms/AzureBackupCostEstimates) with documentation (https://docs.microsoft.com/en-us/azure/backup/azure-backup-pricing#estimate-costs-for-backing-up-azure-file-shares) that also allows for a perspectivce cost calculation in a variety of scenarios.

Closing up on this post, there is one advice: don’t try to understand what you might have downloaded as an XLS daily usage file along with cost and Invoices (https://docs.microsoft.com/en-us/azure/cost-management-billing/understand/download-azure-daily-usage), if you don’t really need to. This is true undocumented science 🤣 For example, the daily backup snapshots of the file share in question were just marked as Hot LRS Data Stored, as any regular file share action. Well encrypted…

Have fun!

Oracle Database “RMAN-20216: backup piece is missing”

Got dizzy the other day when, after moving around backup files, a final “restore database preview summary;” got me a :

A web search straight away pointed me to Restore Database Preview Not Working (Doc ID 2652539.1) on metalink, proposing a solution. First off, rman needs to be started in debug/trace mode as follows (credits to https://oraclespin.com/2010/11/28/how-to-turn-on-debugtrace-when-running-rman) :

We’ll now need to identify the backup piece causing the problem by looking out for some pattern like “... getBackupPiece with error 20216“. In this case, a backup piece in backup set 6803 was incorrectly registered obviously :

ID 2652539.1 now recommends to do a crosscheck on the backup piece by tag name, followed by an uncatalog and a (re-)catalog. The tag name can be found by executing a "list backup of database;", the “select * from RC_BACKUP_PIECE where BS_KEY = 6803;” from the document didn’t work for me.

…

Now the crosscheck and the uncatalog :

The (re-)catalog, as given, failed due to a language error, maybe the document is already out of date in that respect :

I instead just did the well-known cataloging by file pattern and succeeded :

Yet another “crosscheck …” of the backup piece only returned one file, as compared to the output above :

And now, finally, the “restore … preview …” is working again :

Enjoy

Undo retention, flashback query and ora-01555 snapshot too old

Setting up a fault aware database environment is in charge of regarding possible physical and logical error scenarios. On the physical side of the medal, you got real-application-cluster or dataguard at your disposal. The logical one usually comprises backup and replication. Recently, oracle and others introduced features that enables a database to recover from logical errors without or with less remote systems and data. Namely flashback is a powerful technology to look back into (query), back out (transaction) or fully restore (database) the history of data. Flashback of course takes accompanying (history) (meta)data to do its job, namely again, undo-before-images, archived-redo-logs and flashback-logs. So, essentially, the convenience of your course into history depends on the amount of history metadata that is available to the database at the time of a logical error, say an inadvertant delete from.

You may already have learned or heard about or even hardly experienced that flashback-logs may be purged from the recovery-area in favour of archived-redo-logs, rendering your configured flashback-retention-time (DB_FLASHBACK_RETENTION_TARGET) a value of theory. So far, sizing the file-system recovery-area is a task to be performed in a clear-sighted manner. The same is true then for undo-before-images (compare to logs) und the undo-tablespace (compare to area) to accomodate enough data to meet your configured undo-retention-time (UNDO_RETENTION) in UNDO_MANAGEMENT=AUTO mode, while in addition still support long running workload queries (not to overwrite old undo). This article discusses the usability of the (enterprise-manager) undo-advisor in sizing your undo-tablespace to always foster successful flashback queries up to the configured undo-retention-time (as opposed to the nasty surprise of getting an ora-01555, see below, which is also misleading here, imho, in suggesting that the undo-tablespace is to small now, as we know it from workload queries – nope, it has been to small before now, in the past, as regarded to flashback queries – also see : ora-01555 snapshot too old when running flashback query).

Investigating DBV-00201: Block, DBA number, marked corrupt for invalid redo application

More or less forced 😉 by the procedures discussed in my last post (Rman duplicating an oracle 11g database in active state on the same host), this post will investigate how to verify and fix data corruption induced by RMan trying to restore nologging objects. Indeed, we know, there’s no actual restore of nologging objects, since there’s no cold or hot redo to process. But what does this mean in practice? Me, I learned now. Let’s have a look.

Ok, there’re some (partitioned) tables in the database duplicated, previous post, that for performance reasons (see : Oracle global temp tabs or nologgingappend saved redo in numbers) have been set nologging. I won’t explain the why here, that’s another subject, but, however, the first post-duplicate database backup showed up with block corruption errors in Quest’s Backup Reporter for Oracle Community. I today examined the overall database integrity status with a rman validate, verified the affected tablespace, but rman list failures, asking Data Recovery Advisor under the covers, did not seem to be up to complain about anything. We see that 10 blocks have been marked corrupt but the file check status is ok though.

RMAN> validate check logical database;
Starting validate at 22.07.2016-08:55:54
allocated channel: ORA_DISK_1
...
File Status Marked Corrupt Empty Blocks Blocks Examined High SCN
---- ------ -------------- ------------ --------------- ----------
31   OK     10             58357        557056          8784584429990
  File Name: H:\ORACLE\SAN_4\ORADATA\UTL_01.DBF
  Block Type Blocks Failing Blocks Processed
  ---------- -------------- ----------------
  Data       0              265313
  Index      0              223903
  Other      0              9483
...
File Type    Status Blocks Failing Blocks Examined
------------ ------ -------------- ---------------
SPFILE       OK     0              2
Control File OK     0              778
Finished validate at 22.07.2016-08:59:46

RMAN> list failure all;
no failures found that match specification

Rman duplicating an oracle 11g database in active state on the same host

I already published a post about rman> duplicate... a couple of years ago (Rman duplicating an oracle database in a new sid two host scenario), still on 10g at that time and using a backup set being transfered to a new host. With 11g, however, rman> duplicate... offers another option to not only restore from a source backup, leaving source online, but from an up and running database (with takes archivelog mode and some rman catalogued entries in the control file or catalogue nevetheless). Following below therefore, I’m going to show the do’s for an rman> duplicate ... from active database... in a same host scenario, on windows again, using orapwd and oradim as well as lsnrctl this time. The main difference, however, is employing the spfile clause of the duplicate command, such that rman will set up the destination spfile on its own. Only some file name mappings, actually like before, need to be specified. My main reference to review any new features was Duplicating a Database from the oracle 11g1 docs, other references, concerning errors that showed up underway, will be given below.

Ok, working on the same host, nothing is due to be done for software installation and stuff and we can immediately set up the new instance (note that source will be denoted tgt, for target and the destination aux for auxiliary, respectively). Firstly, we create a new password file for destination, with the same sysdba password as on source.

cd /d e:\oracle\product\11.2.0\dbhome_1\database
orapwd file=PWDAUX.ora ignorecase=y force=y