DisCopy


Tuesday 22 July 2014

SAP ASE 16 - Extreme Transaction Ready. (Source - sdn.sap.com)

SAP Adaptive Server Enterprise 16 has been designed to deliver the speed, scalability, security and simplicity that enterprises need to meet the challenges of extreme transactional workloads, efficiently and economically. SAP ASE 16 is now on-par with competitors with all the features and options like automatic backup-schedule, create/replace object command support, relaxed database recovery and many more  with less TOC.

A few exciting features of ever-new SAP ASE 16.

In addition to the compression advisor utility and the automatic backup scheduling capability, a few of SAP ASE 16 features are added listed below:

Feature Support Provided in SCC

Full database encryption Manage database encryption for new and existing databases, 
                                                                      and key management encryption. 

Create or replace command Provide the Create wizard to implement these commands.

Partition-level locking Enable and disable partition locking and provide ‘online’ 
                                                                      option for move, merge, split, delete partition operations.

Index compression Enhance Create Table and Create Index wizards to set index 
                                                                      compression  for table/index/local index partition level.

Error log monitoring   Enhance Error Log monitoring support to import/ export error 
                                                                      flags to multiple servers for ease of configuration and use.

Server configuration alert Allows users to configure alerts to fire when the utilization of 
                                                                      monitored configurable resources exceeds a threshold.

Secure Store Allow removal of residual data when a database, table or index is dropped

Data Cache Spinlock Enhance Monitoring View for SAP ASE with metrics for data spinlock contention.

.

Sunday 20 July 2014

How to RESET Sybase ASA Replication after a Refresh or lost a LOG.


SQL Anywhere LTM
One of the differences between the Adaptive Server Enterprise LTM and the SQL Anywhere LTM is that while the Adaptive Server Enterprise LTM depends on a temporary recovery database for access to old transactions, the SQL Anywhere LTM depends on access to old transaction logs. No temporary recovery database exists for the SQL Anywhere LTM.
Replication depends on access to operations in the transaction log, and for SQL Anywhere primary site databases, sometimes access to old transaction logs. This section describes how to set up backup procedures at a SQL Anywhere primary site to ensure proper access to old transaction logs.
Issue of lost transaction logs
Good backup practices at SQL Anywhere primary database sites are crucial. A lost transaction log could mean rematerializing replicate site databases. At primary database sites, a transaction log mirror is recommended.
The LTM configuration file contains a directory entry, which points to the directory where backed up transaction logs are kept. This section describes how to set up a backup procedure to ensure that such a directory stays in proper shape.
How to reset/restart Replication, when we lost logs
With the Backup utility, you have the option of renaming the transaction log on backup and restart. For the dbbackup utility, this is the -r option. It is recommended that you use this option when backing up the primary database and replication database transaction logs.
For example, consider a database named primedb.db, in directory c:\prime, with a transaction log in directoryd:\primelog\primedb.log. Backing up this transaction log to a directory e:\primebak using the rename and restart option performs the following tasks:
  1. Backs up the transaction log, creating a backup file e:\primebak\primedb.log.
  2. Renames the existing transaction log to d:\primelog\YYMMDDxx.log, where xx are sequential characters ranging fromAA to ZZ.
  3. Starts a new transaction log, as d:\primelog\primedb.log.
    After several backups, the directory d:\primelog contains a set of sequential transaction logs. The log directory should not contain any transaction logs other than the sequence of logs generated by this backup procedure.
  4. Modify the LTM configuration file and set SQL_log_files to d:\primelog instead of e:\primebak. The e:\primebakdirectory is only used for recovery, not log scanning.