Multi-Path Replication (MPR) technology : Replication Server 15.7

0

 The imminent release of Replication Server 15.7 continues pushing envelop and maintaining its leading edge by introducing new Multi-Path Replication (MPR) technology.

So, what is MPR? MPR improves replication performance and reduces latency by enabling parallel paths of data from the source database to the target database. These parallel paths will process data independently of each other to improve overall efficiency, performance and load balancing.

Full Source @ http://blogs.sybase.com/zhangb/2011/12/replication-server-improves-performance-and-reduces-latency-with-mpr/#respond

Note :

 What about the order of transacation , that need to maintain at target side?
Even transaction can come rapidally at target , but it must be applying in a order.

Commit order is maintained within single path. To increase performance on a single path, one can employ parallel DSI, Bulk copy and HVAR features RS has introduced in earlier releases. To take advantage of MPR, users need to fully understand application schema to divide them as commit order is not guaranteed among paths.

 

Inserting data into a data-only-locked heap table

0

When users insert data into a data-only-locked heap table, Adaptive Server tracks page numbers where the inserts have recently occurred, and keeps the page number as a hint for future tasks that need space. Subsequent inserts to the table are directed to one of these pages. If the page is full, Adaptive Server allocates a new page and replaces the old hint with the new page number.

/***********************************************************************************************************
Blocking while many users are simultaneously inserting data is much less likely to occur during inserts to data-only-locked heap tables. When blocking occurs, Adaptive Server allocates a small number of empty pages
and directs new inserts to those pages using these newly allocated pages as hints.
**********************************************************************************************************/

For datarows-locked tables, blocking occurs only while the actual changes to the data page are being written; although row locks are held for the duration of the transaction, other rows can be inserted on the page. The row-level locks allow multiple transaction to hold locks on the page.

If conflicts occur during heap inserts
————————————–
Conflicts during inserts to heap tables are greatly reduced for data-onlylocked tables, but can still take place. If these conflicts slow inserts, some workarounds can be used, including:

• Switching to datarows locking, if the table uses datapages locking
• Using a clustered index to spread data inserts
• Partitioning the table, which provides additional hints and allows new pages to be allocated on each partition when blocking takes place

Inserting data into an allpages-locked heap table

0

When you insert data into an allpages-locked heap table, the data row is always added to the last page of the table. If there is no clustered index on a table, and the table is not partitioned, the sysindexes.root entry for the heap table stores a pointer to the last page of the heap to locate the page
where the data needs to be inserted.

If the last page is full, a new page is allocated in the current extent and linked onto the chain. If the extent is full, Adaptive Server looks for empty pages on other extents being used by the table. If no pages are available, a new extent is allocated to the table.

Conflicts during heap inserts
—————————-
If many users are trying to insert into an allpages-locked heap table at the same time, each insert must
wait for the preceding transaction to complete.

This problem of last-page conflicts on heaps is true for:
• Single row inserts using insert
• Multiple row inserts using select into or insert…select, or several insert statements in a batch
• Bulk copy into the table

Some workarounds for last-page conflicts on heaps include:
———————————————————
• Switching to datapages or datarows locking
• Creating a clustered index that directs the inserts to different pages
• Partitioning the table, which creates multiple insert points for the table, giving you multiple “last pages” in an allpages-locked table

Sybase Interview Questions

0

Same has been updated in @http://sybaseblog.com/interviewquestions/
How can we configure the dbcc database?

How can you configure sybsecurity?

Have you ever worked on terabyte size of  database? How are you taking backup for the same?

Whats the diff between MSA and WS?  Can we consider MSA as a Ws?

You are not able to execute any command in ASE as tempdb is full and you cant create user defined tempdb on the fly , how will you investigate ?

What are the new features fo Sybase ASE 15?

What are the different options avilable with reorg ?

Why we require reorg ?

Suppose if every thing is fine in REplication enviorment  and data is not replicating , how will you troubleshoot the same?

What is gen id in rep server?

How can you check the latency in the replication enviorment?

Whats is HA in Sybase? How can we monitor the HA status?

 

Adaptive Server pages

0

The size of Adaptive Server‘s logical pages (2K, 4K, 8K, or 16K) determines the server’s space allocation. Each allocation page, object allocation map (OAM) page, data page, index page, text page, and so on
are built on a logical page. For example, if the logical page size of Adaptive Server is 8K, each of these page types are 8K in size. All of these pages consume the entire size specified by the size of the logical page. OAM pages have a greater number of OAM entries for larger logical pages (for example, 8K) than for smaller pages (2K).

The logical page size is a server-wide setting; you cannot have databases with varying size logical pages within the same server. All tables are appropriately sized so that the row size is no greater than the current page size of the server. That is, rows cannot span multiple pages.

Sybase Improves Performance with SAP Business Suite on ASE

0

Source : Sybase Ince on youtube

Sybase IQ : Architecture & Benefits

0

Sybase IQ ??
================

Sybase® IQ is a high-performance decision-support server designed specifically for data warehousing.

Sybase IQ is part of the Sybase product family that includes Adaptive Server Enterprise and SQL Anywhere. Component Integration Services within Sybase IQ provide direct access to relational and nonrelational databases on mainframe, UNIX, or Windows servers.

 

Architecture ??
===============

Sybase IQ architecture differs from most relational databases. Sybase IQ focuses on readers, not writers, which provides a fast query response for many users.

Data is stored in columns, not rows

Placing indexes on all columns provides a performance advantage

A large page size provides a performance advantage

A large temporary cache provides a performance advantage for most operations

Access to data occurs at the table level

Most query results focus on data at the table level

Most insertions and deletions write data for an entire table, not for a single row.

 

Benefits ??
=========
Sybase IQ is a decision support system optimized to deliver superior performance for mission-critical business solutions.

Intelligent query processing that use index-only access plans to process any type of query.

Ad hoc query performance on uniprocessor and parallel systems.

Multiplex capability for managing large query loads in a multi-server configuration.

Fully-flexible schema support.

Efficient query execution without query-specific tuning under most circumstances.

Fast initial and incremental loading.

Fast aggregations, counts, comparisons of data.

Parallel processing optimized for multi-user environments.

Stored procedures.

Increased productivity due to reduced query time.

Entire database and indexing stored in less space than raw data.

Reduced input/output (I/O).

Benefits of Normalization

0

Normalization produces smaller tables with smaller rows:
• More rows per page (less logical I/O)
• More rows per I/O (more efficient)
• More rows fit in cache (less physical I/O)
• Searching, sorting, and creating indexes is faster, since tables are
narrower, and more rows fit on a data page.
• Index searching is often faster, since indexes tend to be narrower and
shorter.
• More tables allow better use of segments to control physical
placement of data.
• You usually have fewer indexes per table, so data modification
commands are faster.
• You usually have more tables. You can have more clustered indexes (one per table), so you get more
flexibility in tuning queries.
• Fewer null values and less redundant data, making your database
more compact.
• Triggers execute more quickly if you are not maintaining redundant
data.

Happy,Healthy & Successful New Year 2012

0

Wishing You Happy , Healthy & Successful New Year 2012!   Happy Learning Sybase!

 

 

 

 

 

 

 

ASE database for SAP ERP

0

Hello all,

These are copilataion for Sybase ASE on SAP from the Rob’s Blog :

Read Full Story : http://blogs.sybase.com/database/2011/12/so-what-does-an-ase-database-look-like-in-sap-erp/

  • SAP has released Business Suite on ASE version 15.7.
  • All SAP application data resides in a single ASE database. There is another small database for use by SAP tools.
  • The ASE database uses a 16KB page size.
  • For ERP only (i.e. not counting CRM and the other Business Suite modules), the database contains about 80,000 tables and 170,000 indexes. This is because SAP ERP has many features and functions, all with their own set of tables. SAP customers typically run only a subset of all those functions so in practice a large part of those 80,000 tables will always remain empty.
  • All SAP tables use datarowslocking (there is an interesting historical dimension.
  • All tables names are in uppercase; some table names contain special characters, like the slash character in “/BCV/C_QATTR” (I don’t have a clue what that name means, BTW)
  • Apart from the tables, there are also about 10,000 views. No stored procedures or triggers are used.
  • SAP makes heavy use of dynamic SQL (also known as “prepared statements”).
  • Many tables have a text or image column.
  • All tables are owned by one database user (and that’s not the dbouser).
  • The ASE database is accessed through ODBC.
  • SAP makes frequent use of the built-in ASE Job Scheduler (originally added in ASE 12.5.1).
  • The ASE server uses Unicode with the utf8 character set.
Go to Top