sybase mpp™ administration guide for ibm rs/6000 scalable

Sybase MPP™ Administration Guide forIBM RS/6000 Scalable POWERparallel System

Sybase MPP Release 11.0.x

Document ID: 35376-01-1100-03

Last Revised: June 27, 1996

Principal author: Gwendolyn Stringer

Contributing authors: Joyce Simmonds, Ellie Lief

Document ID: 35376-01-1100

This publication pertains to Sybase MPP Release 11.0.x of the Sybase databasemanagement software and to any subsequent release until otherwise indicated innew editions or technical notes. Information in this document is subject to changewithout notice. The software described herein is furnished under a licenseagreement, and it may be used or copied only in accordance with the terms of thatagreement.

Document Orders

To order additional documents, U.S. and Canadian customers should callCustomer Fulfillment at (800) 685-8225, fax (617) 229-9845.

Customers in other countries with a U.S. license agreement may contact CustomerFulfillment via the above fax number. All other international customers shouldcontact their Sybase subsidiary or local distributor.

Upgrades are provided only at regularly scheduled software release dates.

Copyright ©, 1987, 1996 Sybase, Inc. All Rights Reserved.Copyright ©, 1994, 1996 NCR Corporation (AT&T-Global Information Solutions).All Rights Reserved.

No part of this publication may be reproduced, transmitted, or translated in anyform or by any means, electronic, mechanical, manual, optical, or otherwise,without the prior written permission of Sybase, Inc.

Sybase Trademarks

Sybase, the Sybase logo, APT-FORMS, Data Workbench, DBA Companion, Deft,GainExposure, Gain Momentum, PowerBuilder, Powersoft, Replication Server, S-Designor, SQL Advantage, SQL Debug, SQL SMART, SQL Solutions, SQR,Transact-SQL, and VQL are registered trademarks of Sybase, Inc. AdaptableWindowing Environment, ADA Workbench, AnswerBase, Application Manager,AppModeler, APT-Build, APT-Edit, APT-Execute, APT-Library, APT-Translator,APT Workbench, Backup Server, BayCam, Bit-Wise, Client-Library, Client/ServerArchitecture for the Online Enterprise, Client/Server for the Real World, ClientServices, Column Design, Connection Manager, DataArchitect, DatabaseAnalyzer, DataExpress, Data Pipeline, Datawindow, DBA Companion ApplicationManager, DBA Companion Resource Manager, DB-Library, Deft Analyst, DeftDesigner, Deft Educational, Deft Professional, Deft Trial, Designor, DevelopersWorkbench, DirectCONNECT, Easy SQR, Embedded SQL, EMS, EnterpriseBuilder, Enterprise Client/Server, Enterprise CONNECT, Enterprise Manager,Enterprise SQL Server Manager, Enterprise Work Architecture, Enterprise WorkDesigner, Enterprise Work Modeler, EWA, Gateway Manager, InfoMaker,InformationCONNECT, Intermedia Server, InternetBuilder,

MainframeCONNECT, Maintenance Express, MAP, MDI, MDI Access Server, MDIDatabase Gateway, media.play, media.splash, MetaWorks, MethodSet, Movedb,Navigation Server Manager, Net-Gateway, Net-Library, New Media Studio,ObjectCONNECT, ObjectCycle, OmniCONNECT, OmniSQL Access Module,OmniSQL Server, OmniSQL Toolkit, Open Client, Open ClientCONNECT, OpenClient/Server, Open Client/Server Interfaces, Open Gateway, Open Server, OpenServerCONNECT, Open Solutions, Optima++, PB-Gen, PC APT-Execute, PC DB-Net, PC Net Library, PowerBuilt, PowerBuilt with PowerBuilder, PowerScript,PowerSocket, Powersoft Portfolio, PowerWare Desktop, PowerWare Enterprise,ProcessAnalyst, Replication Agent, Replication Driver, Replication ServerManager, Report-Execute, Report Workbench, Resource Manager, RW-DisplayLib,RW-Library, SAFE, SDF, Secure SQL Server, Secure SQL Toolset, SKILS,smart.partners, smart.parts, smart.script, SQL Anywhere, SQL Code Checker, SQLEdit, SQL Edit/TPU, SQL Server, SQL Server/CFT, SQL Server/DBM, SQL ServerManager, SQL Server Monitor, SQL Server SNMP SubAgent, SQL Station, SQLToolset, SQR Developers Kit, SQR Execute, SQR Toolkit, SQR Workbench,StarDesignor, Sybase Client/Server Interfaces, Sybase Development Framework,Sybase Gateways, Sybase Intermedia, Sybase Interplay, Sybase IQ, Sybase MPP,Sybase SQL Desktop, Sybase SQL Lifecycle, Sybase SQL Workgroup, SybaseSynergy Program, Sybase Virtual Server Architecture, Sybase User Workbench,SybaseWare, SyBooks, System 10, System 11, the System XI logo, Tabular DataStream, The Architecture for Change, The Enterprise Client/Server Company, TheOnline Information Center, Turning Imagination Into Reality, Warehouse WORKS,Watcom, Watcom SQL, Watcom SQL Server, web.sql, web.works, WebSights,WorkGroup SQL Server, XA-Library, and XA-Server are trademarks of Sybase, Inc.

All other company and product names used herein may be trademarks orregistered trademarks of their respective companies.

Restricted Rights

Use, duplication, or disclosure by the government is subject to the restrictions setforth in subparagraph (c)(1)(ii) of DFARS 52.227-7013 for the DOD and as set forthin FAR 52.227-19(a)-(d) for civilian agencies.

Sybase, Inc., 6475 Christie Avenue, Emeryville, CA 94608.

Sybase MPP Administration Guide for IBM RS/6000 POWERparallel v

Table of Contents

About This BookAudience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiHow to Use This Book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiRelated Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiiConventions Used in This Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiii

Formatting SQL Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiiiSQL Syntax Conventions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiii

Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxivEllipsis: Do It Again (and Again)... . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiv

If You Need Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxv

1. The Sybase MPP SystemSybase MPP Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1The Power of Parallelism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1

Partitioned Parallelism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2Pipelined Parallelism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2

Scalable Database Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-3Speed Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-3Scale Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-3

Data Partitioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-4Sybase MPP Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-4

Control Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-5DBA Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-5DBA Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-5Schema Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-6Split/Merge Server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-6Alternate Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-6Global Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-6Recovery Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-7Realms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-7

Base Realm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-7Regular Realm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-8

Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-8Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-8

Primary Installation Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-8Alternate Installation Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-8

vi Table of Contents


Server Naming Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-8

2. Starting Up and Shutting Down the Sybase MPP SystemStart-Up. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1

Using mppinstall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1Using nav_startup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1Start-Up Syntax. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2Verifying Sybase MPP Start-Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-4Viewing Sybase MPP Version Information . . . . . . . . . . . . . . . . . . . . . . . . . 2-4

Shutdown . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-4The Shutdown Process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-5Using Shutdown . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-5

Environment Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-5Environment Variables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-6

Interfaces File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-7Modifying the Interfaces File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-9

Port IDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-9Server Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-10Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-10

3. Adding RealmsRealms and Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1Before Adding a Realm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2Adding a Realm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2After Adding a Realm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-3

Redistributing Data to New Realms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-3

4. Creating and Managing DatabasesDatabase Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1Adding Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1

Disk Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1Log Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2

Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2Using sp_logdevice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2

Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-3After Adding and Dropping Database Devices. . . . . . . . . . . . . . . . . . 4-3Restoring Databases. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-3

Defining a Database Home . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-4Extending Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-5

Sybase MPP Administration Guide for IBM RS/6000 POWERparallel vii


How to Extend a Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-5Partitioning Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-6

Partitioning Schemes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-7Range Partitioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-8Hash Partitioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-9Schema Partitioning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-10

Multicolumn Partitioning Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-10Rules for Creating Partitioned Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-11Using sp_place_table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-11

sp_place_table Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-12sp_place_table Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-12Schema Declustering Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-13Hash Declustering Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-14Range Declustering Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-14

5. Using Parallel Bulk Copypbcp Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1How pbcp Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-2

Differences Between pbcp and Standard bcp . . . . . . . . . . . . . . . . . . . . . . . . 5-4Preparing to Use pbcp. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-4Using the Command Line Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-5

pbcp Configuration File Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-6Clarification of Escaping Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-10Setting the Wait Interval Between Load Clients. . . . . . . . . . . . . . . . . . . . 5-11Performance Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-11Configuration File and pbcp Run Examples . . . . . . . . . . . . . . . . . . . . . . . 5-12

Example 1: Three Data Files and Three Load Clients . . . . . . . . . . . . 5-12Example 2: Three Data Files and Six Load Clients . . . . . . . . . . . . . . 5-13Example 3: A Failed Batch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-14

Aborting pbcp. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-16Designing a Master Client for pbcp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-17

Master Client Interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-17Sample Sequence of Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-18

Trace Flags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-19

6. Backup and RestoreAbout the Backup and Restore Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1

Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1Hardware and Software Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-2Tape Management System. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-3

viii Table of Contents


Dump Devices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-3Modifying Dump Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-3Restoring from Dump Devices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-3

Backup and Restore Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-4Backup Device Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-4

Tape Backup Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-5Backup Device Naming Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 6-5Backup Device Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-6

Data Devices and Log Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-9Systems Configured for Failover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-10

Changing Volume Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-10Backing Up to Disk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-10Backing Up to Tape . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-10Restoring from Disk. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-11Restoring from Tape. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-11Logging into a Control Server after Failover . . . . . . . . . . . . . . . . . . . 6-12

Configuration Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-12Peripherals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-13Database Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-13

Backup History Catalog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-13Database Consistency and Concurrency During Backup. . . . . . . . . . . . . . . . . . . . . 6-14

Global Consistency. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-15Local Consistency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-15Database Consistency and Concurrency During Restore . . . . . . . . . . . . 6-16

The master and gdnavdb Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-16Backing up master . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-16Restoring master . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-17Backing up gdnavdb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-17Restoring gdnavdb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-18

Command Line Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-18The dump Command and Sybase MPP . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-19

dump database. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-19dump transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-20

The load Command and Sybase MPP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-21load database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-22load transaction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-23

Backup Strategies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-24Backup Protection from Media Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-25

Example Backup Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-25Backup Protection from Application Errors . . . . . . . . . . . . . . . . . . . . . . . 6-26

Example Backup Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-26

Sybase MPP Administration Guide for IBM RS/6000 POWERparallel ix


Backup Protection from Site Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-26Example Backup Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-27

Sample Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-27Case One . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-27Case Two . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-28Case Three . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-28

Backing Up to Tape . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-28Using the Tape Management System. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-29

Error Handling and Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-31Graphical User Interface vs. Command Line Requests . . . . . . . . . . . . . . . . . . . . . . 6-31

Advantages of Using Sybase MPPM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-31Using the Command Line Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-32

Restoring an Entire Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-32Using the Auto Load Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-33

Restoring All of a Database’s Transaction Logs . . . . . . . . . . . . . . . . . . . . 6-33Restoring a Database on a Single Server . . . . . . . . . . . . . . . . . . . . . . . . . . 6-34

Using the Auto Load Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-35Restoring Database Transaction Logs for a Single Server. . . . . . . . . . . . 6-35

Backup and Restore Error Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-37Error Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-37

Stored Procedures for the Command Line Interface . . . . . . . . . . . . . . . . . . . . . . . . 6-38

7. Using Transact-SQL and System ProceduresSQL Server 9.1-MPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1Transact-SQL Implementation in Sybase MPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1

Data Definition Language (DDL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-2alter database. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-2create database. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-2create index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-2create proc, create rule, create default, and create trigger . . . . . . . . . . . . . . 7-3create table. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-4create view. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-4

Data Manipulation Language (DML) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-4Aggregates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-4insert select . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-5Subqueries. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-5Update Decluster Column(s) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-8Update or Delete Commands with an Outer Join Clause . . . . . . . . . 7-8group by all . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-9Views Defined with Aggregates, group by, or Subqueries . . . . . . . . . 7-9

x Table of Contents


Joins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-9Miscellaneous . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-10

Other Transact-SQL Commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-10checkpoint, kill, and shutdown. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-10dbcc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-10disk refit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-11disk reinit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-11execute. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-11Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-11order by Clause . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-12readtext . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-12save transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-12set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-12waitfor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-12writetext . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-12

System Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-12Datatypes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-13tempdb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-13

Temporary Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-14Variables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-14

System Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-15Executing System Procedures with Insufficient Permission . . . . . . . . . 7-15Multiple Concurrent Access by the Same User . . . . . . . . . . . . . . . . . . . . 7-15Changes to Existing System Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 7-16New System Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-18

System Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-19Object ID, Database ID, and Index ID Access Differences . . . . . . . . . . . 7-19Storing User Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-19

Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-19Updates and Joins. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-19Rollback Behavior. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-20Two-Phase Commit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-20

8. Performance and TuningHardware Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-1Software Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-1

Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-1External SCSI Disks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-2

RAID Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-2File Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-3

Sybase MPP Administration Guide for IBM RS/6000 POWERparallel xi


Sizing tempdb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-3Configuring Sybase MPP SQL Server and Schema Server. . . . . . . . . . . . . . . . . . . . . 8-3

Workload Configurable Values. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-6Split Server Subsystem Configurable Values . . . . . . . . . . . . . . . . . . . . . . . 8-7

default network packet size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-7maximum network packet size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-7additional netmem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-7

Choosing Packet Sizes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-8default network packet size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-8maximum network packet size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-9additional netmem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-9

Tuning Split Server Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-10Flow and Congestion Control of Split Servers . . . . . . . . . . . . . . . . . . . . . 8-11

SQL Server Packets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-11Disabling Packet Coalescing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-12Split Packets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-12

Large I/O Buffer Pool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-12SQL Server Optimizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-13

One Server Optimization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-13Physical Data Design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-15

Indexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-15Using Covered Indexes to Speed Up Repartitioning . . . . . . . . . . . . 8-15

Writing Queries in Sybase MPP’s Parallel Environment . . . . . . . . . . . . . . . . . . . . . . 8-16Multicolumn Partitioning Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-16Single Table Queries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-17Join Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-17

Advantages and Requirements for In-Place Joins . . . . . . . . . . . . . . . 8-18Joins and Datatypes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-21Multiway Join Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-21

Aggregate Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-23Optimal In-Place Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-24General In-Place Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-24Repartitioning Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-24

Sorting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-25

9. Using REELlibrarian with Sybase MPPInstalling REELlibrarian. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-1Managing REELlibrarian . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-1

Configuring REELlibrarian . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-2Starting REELlibrarian. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-3

xii Table of Contents


Add User Tape Pool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-3Test REELlibrarian . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-4Submit Tapes to user Pool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-4Configure Sybase MPP Dump Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-5Backup and Restore with Sybase MPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-6

10. Interpreting Parallel Query Plans Using the Explain UtilityParallel Query Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1Turning on Explain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2Explain Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2

Basic Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2Detailed Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-4

11. Large I/O Buffer ManagerLarge I/O Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-1Guidelines for Using Large I/O. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-1

Minimum Value for cfg16kbufpool (Default Value) . . . . . . . . . . . . . . . . 11-2Maximum Value for cfg16kbufpool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-2Choosing an Optimal Value for cfg16kbufpool . . . . . . . . . . . . . . . . . . . . 11-2

Enabling Large I/O. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-3Disabling Large I/O . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-4Technical Notes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-4

Determining the maximum number of 16K buffers . . . . . . . . . . . . . . . . 11-4Recovering from an Overly High Setting of cfg16Kbufpool . . . . . . . . . 11-5Config Block parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-5

12. The Parallel OptimizerOverriding the Parallel Optimizer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-1

Setting the Override Directives. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-1Selecting Participating Servers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-2Specifying Global Join Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-2Specifying Join Strategies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-4Selecting Participating Servers for Redecluster-2 Joins . . . . . . . . . . 12-5Report Processing Override Directives. . . . . . . . . . . . . . . . . . . . . . . . 12-6

Configuring the Parallel Optimizer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-6Cost Model Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-7

Cost Object-Response Time Parameter . . . . . . . . . . . . . . . . . . . . . . . . 12-7Cost Weight Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-8

Selectivity Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-10

Sybase MPP Administration Guide for IBM RS/6000 POWERparallel xiii


Search Space Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-11Reducing the Search Space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-12Limiting Search Time. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-13

Consider All Servers Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-14

13. Recovery ManagerEnabling Recovery Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-1Server Monitoring Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-2Input Used by Recovery Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-3Output Produced by Recovery Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-4Kerberos Ticket Expiration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-4

14. Using Sybase MPP UtilitiesUsing dpst. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-1Using pst. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-3Using nav_util . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-4

15. TroubleshootingSybase MPP Start-Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-1

Checklist for Start-Up. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-1Global Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-1Interfaces File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-2Confirm All Nodes Are Up. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-2File Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-2mppdba User. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-3“sa” Password for Start-Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-3SQL Server Command Line Parameters . . . . . . . . . . . . . . . . . . . . . . . 15-3Transaction Logs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-3Disk Space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-3Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-3

Performance Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-4Skew . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-4

Diagnosis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-4Recommendation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-4

Inserts into Indexed Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-4Diagnosis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-5Recommendation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-5

CPU Utilization of Sybase MPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-5

xiv Table of Contents


Diagnosis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-5Recommendation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-6

High Operating System Paging Activity. . . . . . . . . . . . . . . . . . . . . . . . . . 15-6Diagnosis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-6Recommendation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-6

Concurrent Table Scans by Multiple Users . . . . . . . . . . . . . . . . . . . . . . . . 15-7Diagnosis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-7Recommendation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-7

Sybase MPP Administration Guide for IBM RS/6000 POWERparallel xv


A. Sybase MPP System Tablesgd_access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-1gd_cabinets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-1gd_control_servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-1gd_database_device_usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-2gd_database_devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-2gd_dba_servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-3gd_dbadepends . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-4gd_dbrf_activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-4gd_dbrf_db_info . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-4gd_dbrf_defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-5gd_dbrf_device_info . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-5gd_dbrf_dump_device_aliases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-6gd_dbrf_navtape_defaults. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-6gd_dbrf_profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-6gd_dbrf_profile_devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-7gd_dbrf_profile_schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-7gd_dbrf_sql_server_info . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-7gd_dbrf_tape_sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-8gd_decluster_columns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-9gd_disks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-9gd_dump_devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-9gd_extend_recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-10gd_global_params. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-10gd_history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-11gd_indexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-11gd_modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-11gd_nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-12gd_object_aliases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-13gd_range_decluster_info. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-13gd_rm_history_log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-13gd_saved_dnconfig. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-14gd_schema_servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-14gd_scsi_buses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-15gd_scsi_device_units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-15gd_scsi_devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-15gd_scsi_unit_controls. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-15gd_segment_home_info . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-16gd_split_servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-16

xvi Table of Contents


gd_sql_servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-17gd_sqlmodules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-18gd_table_decluster_info . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-18gd_table_home_info . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-18gd_table_stats. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-18gd_triggers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-19

Index

Sybase MPP Administration Guide for IBM RS/6000 POWERparallel xvii

List of Figures

Figure 5-1: Overview of pbcp ..........................................................................................................5-3Figure 13-1: Server monitoring relationships ................................................................................13-3

xviii List of Figures


Sybase MPP Administration Guide for IBM RS/6000 POWERparallel xix

List of Tables

Table 1: Syntax statement conventions .................................................................................. xxiiiTable 1-1: Server ID naming convention ......................................................................................1-9Table 5-1: Differences between bcp and pbcp .............................................................................5-4Table 5-2: Trace flags for pbcp......................................................................................................5-20Table 6-1: New database default settings...................................................................................6-13Table 8-1: sp_configure parameters for SQL Server ...................................................................8-4Table 8-2: sp_configure parameters for Schema Server .............................................................8-5Table 11-1: New Config Block Entries ..........................................................................................11-5Table 12-1: Cost model parameters ...............................................................................................12-7Table 12-2: Cost model parameter weights..................................................................................12-9Table 12-3: Selectivity parameters ...............................................................................................12-10Table 12-4: Search space parameters...........................................................................................12-11Table 12-5: Join server participation ...........................................................................................12-15

xx List of Tables


Sybase MPP Administration Guide for IBM RS/6000 POWERparallel xxi

About This Book

This manual provides information to help you manage andadminister the Sybase MPP™ parallel database system.

Audience

This manual is for database system administrators and databaseowners who administer Sybase MPP and Sybase® SQL Server™.

You should have a working knowledge of the following:

• X Window System

• OSF/Motif graphical environment

• UNIX operating system

• Transact-SQL and System Procedures

How to Use This Book

Chapter 1, “The Sybase MPP System,” describes the structure andcapabilities of the Sybase MPP system, including the softwareconfiguration.

Chapter 2, “Starting Up and Shutting Down the Sybase MPPSystem,” describes the start-up and shutdown flow and syntax forthe Sybase MPP system.

Chapter 3, “Adding Realms,” describes how to expand your SybaseMPP system.

Chapter 4, “Creating and Managing Databases,” describes how tocreate and extend databases and partition tables.

Chapter 5, “Using Parallel Bulk Copy,” describes using the parallelversion of bcp.

Chapter 6, “Backup and Restore,” describes the Sybase MPP backupand restore process and utilities.

Chapter 7, “Using Transact-SQL and System Procedures,” discusseshow Transact-SQL®, system procedures, transaction management,and system table access are implemented in the Sybase MPPenvironment.

xxii About This Book

Related Documents Sybase MPP Release 11.0.x

Chapter 8, “Performance and Tuning,” provides information toassist you in improving the performance of your Sybase MPPinstallation.

Chapter 9, “Using REELlibrarian with Sybase MPP,” providesinstructions for using the REELlibrarian tape manager.

Chapter 10, “Interpreting Parallel Query Plans Using the ExplainUtility,” describes how to use the Explain utility to examine parallelquery plans.

Chapter 11, “Large I/O Buffer Manager,” describes how to configurethe Large I/O Buffer Manager.

Chapter 12, “The Parallel Optimizer,” describes how to configure theparallel optimizer, and how to override its directives.

Chapter 13, “Recovery Manager,” describes recovery managerfunctionality.d

Chapter 14, “Using Sybase MPP Utilities,” describes using theavailable Sybase MPP utilities.

Chapter 15, “Troubleshooting,” provides information to help youdiagnose problems.

Appendix A, “Sybase MPP System Tables,” lists the Sybase MPPsystem tables in the global directory.

Related Documents

Other Sybase manuals you can use with the Sybase MPP systeminclude the following:

• Sybase MPP Manager User’s Guide

• Release Bulletin Sybase MPP

• Release Bulletin Sybase MPP Language Module

• Sybase MPP Installation Guide

• SQL Server Installation Guide (release 4.9.2)

• SQL Server Commands Reference Manual (release 4.9.1)

• SQL Server System Administration Guide (release 4.9.1)

• SQL Server Transact-SQL User’s Guide (release 4.9.1)

Sybase MPP Administration Guide for IBM RS/6000 POWERparallel xxiii

Sybase MPP Release 11.0.x Conventions Used in This Manual

Conventions Used in This Manual

File names, datatypes, and database objects are displayed in italics.

Words to be emphasized or defined are displayed in bold.

An arrow (→) represents a command that is accessed by selectinganother command, for instance, Display→Color Legend.

Formatting SQL Statements

SQL is a free-form language: There are no rules about the number ofwords you can put on a line, or where you must break a line.

However, for readability, all examples and syntax statements in thismanual are formatted so that each clause of a statement begins on anew line. Clauses that have more than one part extend to additionallines, which are indented.

SQL Syntax Conventions

The conventions for syntax statements in this manual are as follows

Table 1: Syntax statement conventions

Key Definition

command Command names, command option names, utilitynames, utility flags, and other keywords are in boldCourier in syntax statements, and in bold Helveticain paragraph text.

variable Variables, or words that stand for values that you fillin, are in italics.

{ } Curly braces indicate that you choose at least one ofthe enclosed options. Do not include braces in youroption.

[ ] Brackets mean choosing one or more of the enclosedoptions is optional. Do not include brackets in youroption.

( ) Parentheses are to be typed as part of the command.

| The vertical bar means you may select only one ofthe options shown.

, The comma means you may choose as many of theoptions shown as you like, separating your choiceswith commas to be typed as part of the command.

xxiv About This Book

Conventions Used in This Manual Sybase MPP Release 11.0.x

• Syntax statements (displaying the syntax and all options for acommand) are printed like this:

sp_helpdevice [ device_name ]

or, for a command with more options:

select column_namefrom table_namewhere search_conditions

In syntax statements, keywords (commands) are in normal fontand identifiers are in lowercase; user-supplied words are shownin italics.

• Examples showing the use of Transact-SQL® commands areprinted like this:

select * from publishers

• Examples of output from the computer are printed like this:

pub_id pub_name city state------- ------------------- --------- -----0736 New Age Books Boston MA0877 Binnet & Hardley Washington DC1389 Algodata Infosystems Berkeley CA

(3 rows affected)

Case

You can disregard case when you type keywords:

SELECT is the same as Select is the same as select

Ellipsis: Do It Again (and Again)...

An ellipsis (...) means that you can repeat the last unit as many timesas you like. In this syntax statement, buy is a required keyword:

buy thing = price [cash | check | credit] [, thing = price [cash | check | credit]]...

You must buy at least one thing and give its price. You may choose amethod of payment: one of the items enclosed in square brackets.You may also choose to buy additional things: as many of them asyou like. For each thing you buy, give its name, its price, and(optionally) a method of payment, separating things with a comma.

Sybase MPP Administration Guide for IBM RS/6000 POWERparallel xxv

Sybase MPP Release 11.0.x If You Need Help

If You Need Help

Help with your Sybase software is available in the form ofdocumentation and Sybase Technical Support.

Each Sybase installation that has purchased a support contract hasone or more designated people who are authorized to contactTechnical Support. If you cannot resolve your problem using themanuals, ask the designated person at your site to contact SybaseTechnical Support.

xxvi About This Book

If You Need Help Sybase MPP Release 11.0.x

Sybase MPP Administration Guide for IBM RS/6000 POWERparallel 1-1

1 The Sybase MPP System 1.

This chapter introduces Sybase MPP and defines related terms andconcepts. This chapter includes the following topics:

• Sybase MPP Overview 1-1

• The Power of Parallelism 1-1

• Scalable Database Performance 1-3

• Data Partitioning 1-4

• Sybase MPP Software 1-4

• Server Naming Conventions 1-8

Sybase MPP Overview

Sybase MPP is a powerful and flexible database management systemthat allows Sybase users superior scalability for workloads thatrequire greater capacity and faster response time than a standardSQL Server.

Sybase MPP is comprised of a parallel database engine and acomplete set of tools, utilities, and system software necessary foreffective database installation, tuning, and execution of all aspects ofthe lifecycle of an enterprise’s database.

The Power of Parallelism

Sybase MPP takes advantage of parallel processing systems toincrease the performance of very large databases.

Parallel processing systems contain multiple processors on one ormore nodes. Each node is made up of one or more independentprocessors with its own, or shared, memory and disk storage.

Sybase MPP partitions a database across SQL Server realmsdeployed on the nodes of the computer system. A realm is a unit ofservers, coordinated and installed at run time; refer to “Realms” onpage 1-7 for more information. Each node runs its own set of SQLServer realms.

Sybase MPP divides a client’s query into many pieces based on thefollowing:

• Its corresponding SQL Servers and data partitions

1-2 The Sybase MPP System

The Power of Parallelism Sybase MPP Release 11.0.x

• Per node, depending upon the number of realms on that node

The pieces of the query are executed simultaneously and return theirresults to Sybase MPP, which combines the results and returns themto the client.

Parallelism allows programmers to code as if they were using astandard SQL Server where applications run identically. Sybase MPPuses two forms of parallelism to increase performance: partitionedparallelism and pipelined parallelism.

Partitioned Parallelism

The key to Sybase MPP’s performance and scalability is its datapartitioning. The data is divided physically so that it can be accessedand managed separately, minimizing contention for resources. A bigtable becomes a series of smaller tables, each accessed independentlywith its own processing resources. Because each partition isexplicitly defined by table and key values, partitioning can bemaintained by the system as data is loaded and as the data changes.

The parallel optimizer uses system-wide schema information toensure that each request is only sent to partitions with data involved.Each SQL Server does the following:

• Controls its own data partition and works independently on itsassigned piece of the client request.

• Utilizes one or more processors to resolve the query.

Partitions are transparent to the application and can be changed asneeded for optimum performance.

Sybase MPP scales the number of processors deployed based on thenumber of client requests so that transaction rates do not diminishwith an increase in the number of concurrent users.

Pipelined Parallelism

In pipelined parallelism, the next sequential step in a multistepoperation is begun before the preceding step has completed. Forexample, in a SQL statement with insert into Table A, select from Table B,the rows being scanned from the select from Table B command canbegin being inserted into Table A as soon as the first row is returnedfrom Table B. Pipelined parallelism allows two processors to work onthe same command at the same time.


Sybase MPP Release 11.0.x Scalable Database Performance

Pipelined parallelism also improves the rate at which rows arereturned to client applications. As soon as the first set of result rowsfills the output buffer, they can be returned to the user.

Scalable Database Performance

The parallel shared-nothing implementation of Sybase MPP enablesall workloads to be processed at a higher capacity and a reducedresponse time, otherwise known as “scalable performance.” Scalableperformance is measured by speed up and scale up.

Speed Up

The goal of speed up is to produce a faster completion or responsetime while processing the same amount of data (a fixed workload)when adding more hardware resources.

In Sybase MPP, this can mean greatly reducing the response time ofaccessing large tables and processing complex queries. This includesmost forms of Transact-SQL, but is commonly used for long-runningcommands, such as table scans, joins, subqueries, aggregatecommands, database or table loads (bcp), and backup, restore, dump,and load operations).

Scale Up

Scale up processing makes it possible to handle an increasingworkload while maintaining a fixed completion time when addingmore hardware resources.

Scale up can be categorized in two general ways, or a combination ofboth ways:

• Maintaining the response time while increasing the number oftransactions completed in the same time period. For example,increasing the transaction rate from 100 to 1000 transactions persecond.

• Maintaining the response time and transaction rates whileincreasing the size of the database against which the transactionsare run. For example, a 5GB database on a standard SQL Servercan achieve 100 transactions a second. Sybase MPP allows thatdatabase to grow to 500GB and maintain the transaction rate.


Data Partitioning Sybase MPP Release 11.0.x

Data Partitioning

Partitioning allows more computer resources to be applied toachieve scale up and speed up of database requests.

All forms of partitioned database parallelism require databases to befragmented in some way. Any kind of fragmentation or partitioningrequires greater use of I/O channels. To avoid bottlenecks in an I/Osubsystem, databases historically have been striped, or spread outacross several disks with separate I/O channels. In the past, thisstriping has been done at the segment or disk level, with randomblocks spread across disks that are accessed by separate channels.This practice has allowed some scale up for I/O operations, but it islimited by the number of processors that can have simultaneousaccess to the I/O channels. Since computer systems are built with afixed number of I/O channels that can be shared, scalability islimited. Furthermore, this form of partitioning is done withoutregard to the actual logical operations of the database, which limitsthe usefulness of the partitioning.

Shared-nothing parallel database systems take fundamental stripingto a higher level by actually defining the partitioning to be managedat the database row level associated with each table. Each row in atable is distributed to a disk, based on a value, or group of values, inthe column(s) of the row. These columns are called the partitioningkey. Based on the value of the partitioning key, the entire rowassociated with that key is placed on a specific disk. To determinewhich rows are placed on which disks, a partitioning scheme mustbe defined.

Refer to “Partitioning Tables” on page 4-6 for information on how topartition data in Sybase MPP.

Sybase MPP Software

Sybase MPP is comprised of several server processes. Each process ismulti-threaded, capable of handling many concurrent events. Usethe Sybase MPP Manager (MPPM) Configuration Managementutility, described in the Sybase MPP Manager User’s Guide, foradministration and tuning of these servers.

The next sections contain a brief description of each if the followinginternal server process, and terms related to their functionality:

• Control Server

• DBA Server


Sybase MPP Release 11.0.x Sybase MPP Software

• DBA Monitor

• Schema Server

• Split/Merge Server

• Alternate Server

• Global Directory

• Recovery Manager

• Realms

• Instance

• Node

Control Server

The Control Server is the interface between clients and the SybaseMPP system. Control Server receives client requests and sends themto the appropriate parts of Sybase MPP, and after receiving theresults, it passes them back to the client. To an applicationprogrammer, the Control Server functions like SQL Server.

There can be many Control Servers; your deployment of ControlServers depends on the data you need to access.

DBA Server

The DBA Server is the central coordinating process for Sybase MPPfor data definition, converting SQL to parallel SQL plans, andrecovery monitoring. The DBA Server must always have a SchemaServer associated with it. DBA Servers keep all global directory andSybase system tables synchronized. DBA Servers compile DataManipulation Language (DML) statements and interpret DatabaseDefinition Language (DDL) and security statements.

DBA Monitor

The DBA Monitor surveys the activities of the DBA Server. If theDBA Server becomes unavailable, the DBA Monitor acts as analternative DBA Server. The DBA Server is on the primaryinstallation node and the DBA Monitor is on the alternate installationnode.


Sybase MPP Software Sybase MPP Release 11.0.x

Schema Server

A Schema Server is a SQL Server that is dedicated to housing theSybase MPP global directory (GD) (described later in this section).The Schema Server must always be located on the same node as theDBA Server. The Schema Server has the same characteristics as SQLServer and can deploy several engines if the workload exceeds thatof a single SQL Server engine. User queries do not directly access theSchema Server, although some third-party client software may addtheir own tables to the Schema Server.

Normally, the Schema Server does not participate in any userrequests, nor control any user data. However, in some cases usertables are located on the Schema Server only. (For example, theSchema Server may control user data when the table has a columncontaining a value that is not consistent across all SQL Servers, suchas object ID, or if the “sa” user creates a table without usingsp_place_table to place it.)

Split/Merge Server

The Split/Merge Server is used by Sybase MPP to replicate andredistribute rows internally to optimize joins. Every Split/MergeServer is associated with a specific SQL Server.

Alternate Server

An alternate server exists only during failover and acts as asubstitute for the primary server. For example, the AlternateSplit/Merge Server comes up if the Split/Merge Server fails.

Global Directory

The global directory (GD) is a data dictionary of all database objectsknown by Sybase MPP. It is a SQL Server database that containsspecific information used to access physically partitioned data. User-allowed changes can be made through Sybase MPPM ConfigurationManagement and Log Manager utilities. It is strongly recommendedthat you access the global directory information through SybaseMPPM. If you incorrectly modify this database you could corrupt oradversely affect the Sybase MPP system.


Sybase MPP Release 11.0.x Sybase MPP Software

Recovery Manager

Recover Manager is a tool that detects Sybase MPP system failure,reports the failure, and provides server-level recovery.

If possible, the Recovery Manager restarts Sybase MPP in place. Ifthis is not possible, Recovery Manager moves the unit of servers it ismonitoring to the alternate node, and restarts them there. The unit ofservers consists of the Control Server, and the Split Server, and SQLServers that the Control Server is monitoring.

Any transactions in progress are lost.

You can set Recovery Manager to run under operator control if youwish. Setting Recovery Manager to run automatically is usually thepreferred method.

Refer to Chapter 13, “Recovery Manager,” for more information onRecovery Manager.

Realms

A realm is a set of servers, coordinated and installed at run time.There are two kinds of realms: base and regular (described in thenext section).

The Control Server is the managing server in a regular realm. TheControl Server coordinates and manages tasks across realms withother Split/Merge and SQL Servers.

Refer to Chapter 3, “Adding Realms,” for more information onrealms.

Base Realm

There is one base realm per Sybase MPP instance. It resides on theprimary installation node.

For each instance, there is one base realm which consists of thefollowing:

• DBA Server

• Master Split/Merge Server

• Schema Server


Server Naming Conventions Sybase MPP Release 11.0.x

Regular Realm

The regular realm consists of the following:

• Control Server

• Split/Merge Server

• SQL Server

Instance

An instance is an installation of Sybase MPP that has a base realmand one or more regular realms.

Nodes

A node is a separate machine that has its own memory and disk, andis connected to other machines via a high-speed connection. CPUswithin a node share memory and disk.

Primary Installation Node

The primary installation node is configured with the DBA Server, theSchema Server, and the Master Split/Merge Server.

Alternate Installation Node

The alternate installation node contains the DBA Monitor Server. Iffailover is configured, the Alternate DBA Server, the AlternateSchema Server and the Alternate Master Split/Merge Server are alsocreated, although not activated until an actual failover recoveryoccurs.

Server Naming Conventions

The different types of servers in the Sybase MPP environment can beidentified by their server name. The server name is made up of thefollowing:

• A letter that identifies the type of server.

• A 2-digit number representing the Sybase MPP instance, which isa value of 01–99.


Sybase MPP Release 11.0.x Server Naming Conventions

• A unique server number.

Schema servers are numbered in the range 20000–29999; Controlservers are 30000–39999; Split/Merge servers are 40000–49999;SQL Servers are 50000–59999; and DBA Servers are 60000–65535.The numbers 10000–19999 are reserved.

• The final digit of the server name indicates whether the server isprimary (number 1) or alternate (numbers 2–8).

The Server ID conventions are summarized in Table 1-1.

Examples

A server with the name D01600012 is a DBA Monitor Server onSybase MPP instance 01, with server number 60001, and is alternateserver number 2.

A server with the name C01300021 is a Control Server on SybaseMPP instance 01, with server number 30002, and is a primary server.

Table 1-1: Server ID naming convention

Server NameComponent Describes Value

A Server type C = ControlD = DBAM = Split/MergeQ = SQL ServerS = Schema

XX Sybase MPP instance number 01 = instance number one

99=maximum instancenumber.

YYYYY Logical number of server 10000–19999 = Reserved20000–29999 = Schema30000–39999 = Control40000–49999 = Split/Merge50000–59999 = SQL60000 = DBA Master60001 = DBA Monitor

Z Primary or alternate 1 = Primary2–8= Alternate


Server Naming Conventions Sybase MPP Release 11.0.x


2 Starting Up and Shutting Down theSybase MPP System 2.

The commands used to start up and shut down the Sybase MPPsystem are described in this chapter.

This chapter includes the following topics:

• Start-Up 2-1

• Shutdown 2-4

• Environment Variables 2-5

• Interfaces File 2-7

Start-Up

After installing Sybase MPP on your system, you can use either oneof two utilities to start Sybase MPP:

• mppinstall

• nav_startup

Using mppinstall

The mppinstall utility is used to install and configure Sybase MPP.Choose Option 8, “Startup MPP”, from the mppinstall Sybase MPPInstallation Main Menu. See the Sybase MPP Installation Guide.

➤ NoteThe mppinstall utility calls the nav_startup utility.

Using nav_startup

You can start Sybase MPP by executing nav_startup from any node onwhich Sybase MPP has been installed. The nav_startup utility starts theDBA Server on the appropriate node. The Sybase MPP system is in a“startup” state from the time you invoke the Sybase MPP nav_startupcommand until the message “Sybase MPP is up” appears in the DBAServer’s log file.

The DBA Server starts Sybase MPP in two phases. During the firstphase, the Schema Server, DBA Monitor Server, Master Split/Merge

2-2 Starting Up and Shutting Down the Sybase MPP System

Start-Up Sybase MPP Release 11.0.x

Server, and all Control Servers are started. During the second phase,after all Control Servers have started, the DBA Server sends amessage to each server, telling it to start its Split/Merge and SQLServers.

Start-Up Syntax

You use the nav_startup utility to start Sybase MPP. nav_startup requiresthat the following environment variables are defined:

Log in as the user “mpp” to use nav_startup.

The syntax of the nav_startup command is:

nav_startup [-d integer ] [-I interfaces_file ][-n instance_number ] [-a] [-o]

nav_startup options are described as follows:

Variable Description

NAVIGATOR The absolute path name of the Sybase MPP home directory.The home directory contains the subdirectories bin, startup,log, and others.

SYBASE The absolute path name of the directory in which the Sybaseinterfaces file resides.

nav_startup Option Function

-a Starts DBA Server on its alternate node. Use this option to startSybase MPP when the DBA Server’s primary node is not usable.This option is not available on platforms where the following istrue:

• That do not support shared SCSIs.

• On which alternate servers have not been installed.


Sybase MPP Release 11.0.x Start-Up

nav_startup prompts you to enter the password for the “sa” user. Thepassword is checked by starting the DBA and Schema Servers. Athread in DBA Server logs into Schema Server using the “sa” loginname and user-supplied password. If the password is incorrect, thelogin is rejected, and Sybase MPP does not start.

On a newly installed system, the “sa” user’s password is null. PressReturn when prompted for the password. The password can bechanged by executing the system procedure, sp_password. For moreinformation on this system procedure, refer to the SQL Server SystemAdministration Guide.

-dinteger Starts Sybase MPP in debug level integer, where D may be 0, 1 or4. The debug levels are:

• Debug level 0 – nav_startup prompts for a password. EachControl, Split, and DBA Server creates or reuses its ownworking directory called servername, under $NAVIGATOR/bin.For example, a Control Server called C01300021 creates thedirectory $NAVIGATOR/bin/C01300021. This is the defaultlevel.

• Debug level 1 – nav_startup displays debugging informationon stdout before and after prompting you for a password. EachControl, Split, and DBA Server creates or reuses its ownworking directory, called servername.pid, under$NAVIGATOR/bin. For example, a Control Server calledC01300021, with process ID 7086, creates the directory$NAVIGATOR/bin/C01300021.7086. Information is preservedin separate directories for each server restart.

• Debug level 4 – nav_startup displays debugging informationon stdout before and after prompting you for a password, butdoes not execute start up. Use this level to debug nav_startupitself.

-Iinterfaces Uses interfaces as the full path name of the interfaces file. Thisoption overrides the SYBASE environment variable.

-ninstance Starts Sybase MPP using instance number instance. instance mustbe a 2-digit number; for example, 01. This option overrides theDN environment variable.

-o Starts only the DBA Server and the Schema Server.

nav_startup Option Function


Shutdown Sybase MPP Release 11.0.x

Verifying Sybase MPP Start-Up

Once you have issued the start-up command, the command lineprompt is returned. This does not mean that Sybase MPP is up andrunning. To verify that Sybase MPP is running, monitor the outputfile located in $NAVIGATOR/bin/D01600001.pid#/stdout until you seethe following message:

< < < Sybase MPP is Up > > >

The .pid# extension only appears if the debug level is 1 or greater. Ifnav_startup is issued without the -d option, the output file locationwould be $NAVIGATOR/bin/D01600001/stdout. Additionally, theD01 prefix may vary depending upon the instance number.

➤ NoteThe amount of time it takes before the “Sybase MPP is Up” message

appears varies, depending upon the system configuration.

Viewing Sybase MPP Version Information

Use the nav_server -V option to view the following Sybase MPPinformation:

• Copyright message

• Sybase MPP version string

• SQL Server binary version string

• Open Server library version string

• Open Client library version string

(Using the nav_server -v (small v) option displays information listed inthe first two bullets.)

Shutdown

The shutdown utility provides an easy and immediate way to bringdown or terminate the operation of the Sybase MPP system.Theshutdown utility can be called using the MPP Manager (MPPM) orby issuing shutdown from the command line prompt. The shutdownutility provides the options to execute the Transact-SQL shutdown orshutdown with nowait commands, for all nodes, from a graphical


Sybase MPP Release 11.0.x Environment Variables

interface. You can also shut down Sybase MPP by issuing theshutdown command using isql, while logged in to the DBA Server.

The section begins with a technical overview of shutdown, followedby descriptions of the shutdown dialog boxes.

The Shutdown Process

The Sybase MPP system enters shutdown state when a databasesystem administrator issues the Transact-SQL shutdown commandfrom the command line or uses the Sybase MPPM Shutdownapplication.

In the DBA Server, a shutdown thread is spawned. The shutdownthread propagates the shutdown command from the DBA Server to allControl Servers.

The Control Servers wait for the servers in their realms to shut downbefore shutting down themselves. The DBA Server waits for allControl Servers to shut down before shutting down the DBAMonitor Server, Master Split/Merge Server, and Schema Server, andfinally itself.

Using Shutdown

There are two types of shutdown:

• shutdown

Waits for currently executing SQL statements to complete beforeshutting down.

• shutdown with nowait

Shuts down the Sybase MPP system immediately, withoutwaiting for currently executing statements to finish and withoutexecuting checkpoints in the databases.

Environment Variables

This section defines the environment variables used by Sybase MPP.


Environment Variables Sybase MPP Release 11.0.x

Environment Variables

The following environment variables are added to the “mpp” user’s.profile file during installation:


DISPLAY This variable is used by the X environment. It specifiesthe network name of the X workstation display beingused by the user. Example: DISPLAY=beagle:0.0

DN Sets the Sybase MPP instance number. This number isrepresented by any two digits. Example: DN=02

DSQUERY Usually set to D$DN60000, where $DN is the SybaseMPP instance number. This is the logical name of theDBA Server. Example: DSQUERY=D0160000

IFFILE Points to the location of the interfaces file and includesthe interfaces file name.Example: IFFILE=/mpp/SQLSERVER/interfaces

Note: $IFFILE must be a file name, not a subdirectoryname. Otherwise, the subdirectory and its contentsare overwritten by the interfaces file.

LANG This variable is used if the primary language used by thesystem is not U.S. English. LANG must be set in order todisplay text and help information in a language otherthan U.S. English. The syntax is as follows:

LANG_language [_territory[.characterset]]

Example: LANG=De_A.88591

This example is set for a user who speaks German as it isspoken in Austria and uses the ISO 8859/1 character set.If no value is set, the default is U.S. English.

This variable is used in the same way as LC_ALL ifLC_ALL is not set.


Sybase MPP Release 11.0.x Interfaces File

Interfaces File

The interfaces file is used to establish client-to-server and server-to-server connections. The interfaces file contains an entry for eachphysical server (for example, DBA Server, SQL Server, or SchemaServer) to which a client might connect.

The interfaces file is automatically generated during installation andpropagated to all machines.

LC_ALL This variable is used if the primary language used by thesystem is not U.S. English. It has no value if U.S. Englishis the default language. LC_ALL must be set in order todisplay text and help information in a language otherthan U.S. English. The syntax is as follows:

LC_ALL=language [_ territory [. charset ]]

where language is a two-letter code representing thelanguage, territory is a two-letter code representing theregion where the language is spoken, and charset is acode representing the character set. For example:

LC_ALL=en_US.437

This example is set for a user who speaks English as it isspoken in the United States and uses the cp437 characterset.

NAVIGATOR Points to the home directory of the Sybase MPPsoftware. Example: NAVIGATOR=/mpp/MPPSERVER

NAV_VDIR Points to the location of the Sybase MPP run-time files.Example: NAV_VDIR=/mpp/MPPSERVER.

PATH Specifies the path where executable files reside.$NAVIGATOR/bin should be appended to $PATH, whichis the existing path established for any new user whenthe “mpp” user is added. Thus, the default should be$PATH:$NAVIGATOR/bin:$NAVIGATOR/boot:\$SYBASE/bin:

SYBASE Points to the location of the Sybase SQL Server directory,which is normally the same as the location of theinterfaces file. Example: Sybase=/mpp/SQLSERVER

XENVIRONMENT Points to the file containing the X resources that are to beconsulted each time an X application is started.



Interfaces File Sybase MPP Release 11.0.x

➤ NoteThe interfaces file on all nodes of a Sybase MPP system must always be

exactly the same. An exception is that client nodes outside of the Sybase

MPP system can have interfaces files which are not identical to the

interfaces files within Sybase MPP.

The interfaces file associates the name of each server with its networklocation. Two named entries for each type of server appear in theinterfaces files: a logical name, such as D0160000, and a physicalname, such as D01600001, where the last digit represents whether itis a primary server (1) or an alternate server (2–8). User connectionsto any server should be to the logical server name. Refer to “ServerNaming Conventions” on page 1-8 for information on server names.

For each server, both system interconnect and external networkentries can be listed, depending on whether both networks wereindicated during the installation. Each entry includes an access portfor the server and an IP address for the network location of the nodethe server is running on.

The location of the interfaces file is in the directory$SYBASE/interfaces, specified by the IFFILE environment variable.

A sample excerpt of the interfaces file for Sybase MPP, containingjust a DBA Server entry (server name D01600001), follows:

# Created: 01/27/96 (mpp)## D0160000 (logical server) on sphps01# services: query (8999/0x2327) on D03600001/sphps01/129.34.160.1# services: query (8996/0x2324) on D03600001/sp01/217.99.99.37#D0160000 query tcp power-ether sphps01 8999 query tcp power-ether sp01 8996## Created: 01/27/96 (mpp)## D01600001 on sphps01 (129.34.160.1) using power-ether# services: query (8999) master (8999)# services: query (8996/0x2324) on D03600001/sp01/217.99.99.37# services: master (8996/0x2324) on D03600001/sp01/217.99.99.37#D01600001 query tcp power-ether sphps01 8999 master tcp power-ether sphps01 8999 query tcp power-ether sp01 8996 master tcp power-ether sp01 8996


Sybase MPP Release 11.0.x Interfaces File

Modifying the Interfaces File

To add or delete a server after installation, use mpp_netutil to modifythe interfaces file. mpp_netutil is provide with Sybase MPP instead ofthe utility provided with the standalone SQL Server, sybtli. Do not usesybtli in the Sybase MPP environment.

The mpp_netutil utility is provided. Use the following syntax:

mpp_netutil {add | delete} server {tcp} port hostname

For example:

mpp_netutil add D01600001 tcp 9876 sphps36

mpp_netutil delete M01400001 tcp 9583 sphps36

Modifications are made to the interfaces file pointed to by the IFFILEenvironment variable.

➤ Note$IFFILE must be a file name, not a subdirectory name. Otherwise, the

subdirectory name and its contents are overwritten by the interfaces file.

Port IDs

When adding a server to the interfaces file, use a port ID and node IDcombination that is not already being used in /etc/services. SybaseMPP uses the port.sh utility to search for a pair of port IDs in/etc/services prior to calling mpp_netutil.

If the server entry is for a SQL Server or Schema Server (or if theserver type is not recognizable), the server is assigned the same portID for master and query services and the next higher integer for theconsole (tape backup access) port ID. For all other Sybase MPP servertypes (Control, DBA, Split), a single port ID is used for master andquery.

Where Representsserver The name of the serverport The port ID; an integer between 0–9999hostname The name of the host


Interfaces File Sybase MPP Release 11.0.x

Server Names

Specify a physical server name. Logical servers are never enteredexplicitly; mpp_netutil implicitly adds or deletes them when thephysical server name is referenced. For example, if you are addingD01600001 to the interfaces file and there are no other physical servernames already in the interfaces file of the form D0160000x (where x isa digit equal to or greater than 1), then a server entry is created forlogical server D0160000.

Networks

For each server, the system interconnect entry appears above theexternal network entry, regardless of the order in which the serverentries were made. Within each set of system interconnect and theexternal network entries, entries are listed in the order in which theywere added. Their order is important because there can be more thanone connection route for accessing the server. The systeminterconnect entry should be tried first, because it provides the routewith the best performance.

However, if you are using a copy of the interfaces file on a client nodewhere the system interconnect does not exist, the external networkentries for the servers to which you are trying to connect from theclient should come before the system interconnect entries. If they donot, clients will take much longer to connect to the server.


3 Adding Realms 3.

This chapter describes the effect of realms on performance, how toadd realms and redistribute data, and MPP utilities for monitoring arealm’s server.


• Realms and Performance 3-1

• Adding a Realm 3-2

Realms and Performance

A realm is a unit of servers, coordinated and installed at run time.You can maximize MPP performance by adding realms if there areprocessors available on a node. How many realms to have on a nodedepends on the following factors:

• There cannot be more than one SQL Server engine per effectiveprocessor.

• You need to allow for other activity on the node that occupies orrequires processors.

• Sufficient memory is required on a node to give a realmadditional cache.

• The type of realm you choose: narrow or wide.

A narrow realm is a regular realm and consists of one SQLServer, one Control Server, and one Split/Merge Server. Thisconfiguration is useful for complex Decision Support Systems(DSS) and batch workloads.

A wide realm consists of a single SQL Server on each nodeconfigured with multiple engines and partnered with multipleControl Servers in the realm. This configuration is ideal forOLTP as it reduces the amount of two-phase commitcoordination.

➤ NoteDo not configure wide realms for a DSS and batch workload environment.

Wide realms should be used only if inter-request parallelism is the priority.

3-2 Adding Realms

Before Adding a Realm Sybase MPP Release 11.0.x

As a general rule, you should allow one SQL Server per effectiveprocessor. The Schema Server in the base realm should also be allocateda processor.

(As defined in the section entitled “Base Realm” on page 1-7, there is onebase realm per MPP instance. It resides on the primary installation nodeand consists of a DBA Server, Master Split/Merge Server, and SchemaServer.)

Before Adding a Realm

The following administrative tasks which must be performed beforeadding a realm:

1. Make sure that the Schema Server is running.

2. Identify which disk devices to assign to each realm and whichserver to install on the primary and alternate nodes. See “HardwareConfiguration” on page 8-1 for information on configuring diskdevices.

3. Back up the interfaces file and check whether a current back up ofthe global directory database gdnavdb exists. You should also createbackups of your user databases and each existing realm’s SQLServer master and model databases, and the Schema Server masterdatabase.

➤ NoteDue to resource contention, SQL Server user and master devices should not

be on the same disk as the Schema master device. If multiple SQL Servers are

configured on partitions of the same disk, make sure that SQL Servers using

the disk are not running when configuring a new realm. The resource

contention slows the process of adding a realm.

Adding a Realm

The mppinstall utility is used to install and add additional user realms.Choose Option 6, Add Additional User Realms, from the mppinstallSybase MPP Installation Main Menu.

See the Sybase MPP Installation Guide for instructions on adding a realm.


Sybase MPP Release 11.0.x After Adding a Realm

After Adding a Realm

After adding realms, perform the following steps:

1. Start up MPP as described in “Start-Up” in Chapter 2, “StartingUp and Shutting Down the Sybase MPP System”.

2. Run dpst on each participating MPP node to ensure that allservers are running. (See Chapter 14, “Using dpst” for moreinformation of the dpst utility.) You should see three additionalprocesses for each realm you added. Check error logs for anyproblems.

3. Use nav_util to view the global directory tables and verify that thecorrect entries were generated. (See Chapter 14, “Usingnav_util” for more information on the nav_util utility.)

Redistributing Data to New Realms

If realms are added after there is already data on existing realms, usethe following procedure to redistribute tables across all realms:

1. Make sure the realms have been added correctly.

2. Make sure there is enough space on the participating realms toduplicate the data.

3. Rename the table using the system procedure sp_rename.

4. Use sp_place_table and create table to define the home of the newtable. Include the old and new servers in the home option ofsp_place_table. For more information on sp_place_table, see “Usingsp_place_table” on page 4-11.

5. Copy the data from the old table to the new using the select intocommand.

6. Verify that the new table exists and has the correct data.

7. Delete the old table.

3-4 Adding Realms

After Adding a Realm Sybase MPP Release 11.0.x


4 Creating and Managing Databases 4.


• Database Overview 4-1

• Adding Devices 4-1

• Defining a Database Home 4-4

• Partitioning Tables 4-6

Database Overview

Databases are created on home. A database home consists of one ormore partitions. Each partition of the database can be located on adifferent device, including devices located on other SQL Servers. Forevery database, a 20MB partition is automatically created on theSchema Server’s gd_dev device.

The devices specified in the create database command must be userdevices that were created with the disk init command. Although amaster database and device for each SQL Server are automaticallycreated when realms are added, the master device should not beused for user databases.

Adding Devices

This section provides the following information about addingdevices:

• Disk Devices 4-1

• Log Devices 4-2

• Using sp_logdevice 4-2

Disk Devices

The disk init command is used to add devices. The device namingconvention for the Sybase MPP environment islogical SQL servername_device identifier, where the device identifiercan follow any user-defined conventions. Forexample:Q0150003_bdevice1

4-2 Creating and Managing Databases

Adding Devices Sybase MPP Release 11.0.x

Disk devices can be an entire disk or a unique partition. Masterdevices that are created when realms are installed have a logicalname in the format “$DN50002_master”, where “Q$DN50002” is thelogical SQL Server name and $DN is the instance number.

See “Server Naming Conventions” on page 1-8 for information onserver names.

Log Devices

If you specify a log device, you must specify a data device whichbelongs to the same SQL server.

Example

The following example illustrated data and log devices specifiedfrom the same device:

create database testdb onQ0150002_dbdev1 = 10,Q0150003_dbdev1 = 10log onQ0150002_logdev1 = 2,Q0150003_logdev2 = 2

go

Using sp_logdevice

The preferred method for placing a database’s transaction log (thatis, the system table syslogs) on a different device than the one onwhich the rest of the database is stored, is the log on extension to createdatabase. Alternatively, you can name at least two devices when youcreate the database, and then execute the system proceduresp_logdevice. You can also alter database to a second device and then runsp_logdevice.

➤ NoteThe log on extension immediately moves the entire log to a separated

device; the sp_logdevice method retains part of the system log on the

original database device, until transaction activity causes the migration to

become complete.


Sybase MPP Release 11.0.x Adding Devices

Examples

1. The example below creates two devices per partition of thedatabase:

create database testdb onQ0150002_dbdev1 = 10, Q0150002_logdev1 = 2,Q0150003_dbdev1 = 10, Q0150003_logdev1 = 2

go

Here you have created two devices per database partition. Thismeans that each partition can use a separate device as a log only.

2. The partitions can be configured by running sp_logdevice for eachpartition whose log you want to isolate. For example:

sp_logdevice testdb, Q0150002_logdev1

go

sp_logdevice testbd,Q0150003_logdev1

go

Example 2 moves the syslogs tables for each of the partitions to theirown private device.

➤ NoteThe syslogs tables cannot be moved on all partitions simultaneously. Each

partition must be moved separately using sp_logdevice. If a partition does

not contain at least two devices, you will not be able to execute sp_logdevicefor that partition.

After Adding and Dropping Database Devices

After adding or dropping database devices, you must enter thefollowing commands:

cd $NAVIGATOR/install./ai_lvolmain.sh

Restoring Databases

Before a database can be restored, all users who have recentlyaccessed that database must log out.


Defining a Database Home Sybase MPP Release 11.0.x

Defining a Database Home

The create database command defines the home for the database. Thehome is defined using the logical SQL servername part of the databasedevice name on which the database is created. See “Adding Devices”on page 4-1 for information on the device naming convention.

Databases can be partitioned across multiple SQL Servers formaximum performance. Large databases can include every SQLServer in the Sybase MPP environment in their home. Sybase MPPdatabases follow the same naming convention as standalone SQLServer databases.

Log devices for the database are specified with the create databasecommand. Log devices can only be created on SQL Servers that arepart of the database home. If you do not specify a log device for everySQL Server, you cannot use the dump transaction command. Considerthe placement of logs to minimize database and transaction back-upsneeded for recovery from single points of failure.

Examples

1. The following statement creates a database named “sample_db”on one realm of Sybase MPP instance 01. The database size is50MB, and the log size is 2MB.

create database sample_db on Q0150002_dbdev1 = 50log on Q0150002_logdev1

2. The following statement creates a database named “my_db” onfour realms of Sybase MPP instance 01. On each realm, thedatabase size is 500MB, and the log size is 100MB.

create database my_db onQ0150002_dbdev1 = 500,Q0150003_dbdev1 = 500,Q0150004_dbdev1 = 500,Q0150005_dbdev1 = 500log onQ0150002_logdev1 = 100,Q0150003_logdev1 = 100,Q0150004_logdev1 = 100,Q0150005_logdev1 = 100


Sybase MPP Release 11.0.x Defining a Database Home

Extending Databases

To extend a database in Sybase MPP, you add SQL Servers to thedatabase home. You do this by using the sp_extenddb systemprocedure as explained in the steps below.

Use the alter database command to expand the size of a database onservers that are already in the home.

To repartition data, you need to unload the data, re-create the tableswith appropriate partitioning, and reload the data.

How to Extend a Database

1. Log into the DBA Server and use the master database:

isql -Usa -P passwd -SD01600001use mastergo

2. Run sp_extenddb without parameters. You can run only oneinstance of sp_extenddb at a time.

Running sp_extenddb signals Sybase MPP that the next command,create database, is creating an extension of an existing databaseand not creating a new database.

3. Run the create database command and include the new device andthe size allocated for the database on the new device. You canspecify more than one device. The syntax is:

create database database_nameon database_device = size[, database_device = size ]...[log on database_device [= size ] [, database_device[= size ]]...]

➤ NoteWhen you use create database immediately after sp_extenddb, you must

specify a device name.

Where Represents

database_device Name of the database device onto which you want toextend the database.

size Amount of space in megabytes.


Partitioning Tables Sybase MPP Release 11.0.x

For more information about create database, see the Sybase SQLServer Commands Reference Manual (release 4.9.1).

4. As meta-data is migrated, the SQL Servers onto which thedatabase is being extended return a number of messages, such as“type added.” You can disregard these messages. Only the lastmessage, which states whether or not the extension wassuccessful, is important. If all or part of the database extensionfails (for example, if the database is extended to only some of thenew SQL Servers), the entire operation is rolled back, and SybaseMPP returns to its state prior to the sp_extenddb command.

Example

This example extends a database from its current home to include50MB on device Q0150003_dbdev1 on SQL Server Q01500031, and50MB on device Q0150004_dbdev1 on SQL Server Q01500041.

isql -Usa -Ppasswd -SD01600001use mastergosp_extenddbcreate database sample_db on Q0150003_dbdev1 = 50,

Q0150004_dbdev1 = 50go

Partitioning Tables

You can place a table on some, but not all servers in the system. Thisis called partial declustering. With partial declustering, you cansegment the query processing to a portion of the nodes in a fullsystem. For example, you can install a production (or active) OLTPdatabase on one segment of the nodes and a DSS (or passive)database on a different segment of the nodes.

Separating databases on different processing nodes facilitates a dualdatabase solution in a single-system configuration, which can beadministered with Sybase MPP Manager (MPPM). It also enables theseparation of production-quality data, which is frequently updatedand requires high availability and fault resistance, from a dedicated-information, warehouse database.


Sybase MPP Release 11.0.x Partitioning Tables

Partitioning Schemes

The most commonly used database requests can be divided intothree basic categories:

• Requests that have constraints, which are based on a certainvalue or range of values.

• Requests that aggregate, search, or update all the rows of a table.

• Requests accessing a small table, such as a look-up table.

Sybase MPP provides three fundamental partitioning schemes toaccommodate these three types of queries:

• Range partitioning – Use if you usually access the table by orwithin a range of values or if it is known that the partitioning keyexhibits an even distribution across a range. See “RangePartitioning” on page 4-8 for more information.

• Hash partitioning – Use if you require uniform distribution or ifnothing is known about the distribution of partitioning keyvalues. Hash distribution is intended to provide evendistribution across the partition. See “Hash Partitioning” on page4-9 for more information.

• Schema partitioning – Use for small tables (fewer than 5,000rows) or join queries involving a large table and one or moresmaller tables. See “Schema Partitioning” on page 4-10 for moreinformation.

The choice of a good partitioning key depends not only on thedistribution of rows in a table but also on the workload that willaccess the physical schema. In general, look for the followingcharacteristics in a column when choosing a good partitioning key:

• Good key value distribution to reduce or eliminate placementskew.

• Seldom updated. Frequently updating the partitioning keymeans that the updated rows move among partitions, which iscostly on intensive online transaction processing (OLTP)workloads and bulk update queries executed as part of batchworkloads.

• A suitable join key. If the partitioning key is frequently used as ajoin key, it is generally possible to process more joins as in-placejoins.



➤ NoteAlthough Sybase MPP supports multicolumn partitioning keys, using them

is not recommended, because the parallel optimizer does not recognize in-

place join conditions when joins occur on the partitioning key.

Range Partitioning

Range partitioning uses a defined range or set of values for a tablecolumn (or columns) to determine which rows are placed on whichdisks. Rows that are commonly requested together are placed on thesame disk to speed up access to these rows.

The following example creates a range partitioned table:

use DB_2go

execute sp_place_table "mode", "range","home", "4", "50002", "50003", "50004", "50005","columns", "1", "lastname""intervals", "a", "e", "i", "l", "p", "s", "v"

create table DB_2..table2(lastname varchar(20) not null,

firstname varchar(20) not null,middlename varchar(20) not null,column4 varchar(255) null)

go

See “Using sp_place_table” on page 4-11 for information on usingthe sp_place_table system procedure.

For example, a company with one million employees has employeerecords stored in a table with the following columns:

• employee_id

• department_id

• division_code

• div_location_code

• name

• address

• salary

• start_date

• job_class



In this company, employee information is referenced primarily bystart_date to update benefit program information. A sample query tolist employees hired in 1995 would be:

select name from employee where (start_date between"1/1/95" and "12/31/95")

The most efficient way to access the rows is by placing all of theemployee rows associated with a certain year on the same disk. Inthis case, inter-request parallelism is deployed by using one I/Ochannel to access one disk, minimizing the number of computerresources required to service the request. Since many benefitprograms are implemented based on the date the employee startedwith the company, this partitioning scheme yields maximumthroughput and response time by processing requests because eachrequest does not battle for the same I/O channel or disk. Thus,transaction rate scale -up is achieved by using range partitioning,which is the best choice for the employee table.

Hash Partitioning

Hash partitioning randomly and evenly partitions rows across disks.Sybase MPP has its own built-in hash function. Choose the columnsin the table on which you want to base the even distribution of therows.

The following example creates a hash partitioned table:

use DB_1go

execute sp_place_table "mode", "hash","home", "4", "50002", "50003", "50004", "50005","columns", "2", "column1", "column2"

create table DB_1..table1(column1 int not null,

column2 smallint not null,column3 varchar(255) null)

go


For example, in a company where data is frequently accessed for allemployees, sample queries would be:

select avg(salary) from employee

or:



select count(*) from employee group by job_code

In these cases, all employee rows must be accessed to fulfill therequests. By evenly distributing data with hash partitioning, allpartitions can be accessed at the same time, each returning in thesame amount of time. In this case, intra-statement parallelism is usedto speed up response time. Hash partitioning on employee_id is thebest choice to ensure even partitioning of the rows.

Schema Partitioning

There are times when the cost of partitioning a table outweighs thegains that are achieved from parallelism. As a general rule, thisapplies when:

• The number of rows in a table is small (fewer than 5,000 rows).

• Access to the table is mostly through a clustered index and thenumber of rows is fewer than 100,000.

For these cases, no partitioning is necessary and all rows are bestplaced on one SQL Server.

The default partitioning scheme is schema partitioning.

The following example creates a schema partitioned table:

use DB_2go

execute sp_place_table "mode", "schema","home", "1", "50002"

create table DB_2..table3(column1 int not null,

column2 smallint not null,column3 varchar(255) null)

go


Multicolumn Partitioning Keys

Using multicolumn partitioning keys is strongly discouraged.Sybase MPP will create valid query plans for multicolumnpartitioning keys, but they are sub-optimal for queries with joins.

For join queries the optimizer is unable to apply any optimizations,and does not recognize in-place join conditions. Since Sybase MPP



attempts to process as many queries in place as possible, this mayhave a significant impact on performance.

There are no limitations on the use of multicolumn indexes. Forexample, you can declare your primary clustered index on columnsc1, c2, and c3, and your partitioning key as column c1, and achievegood optimization at both the Sybase MPP and SQL Server levels.

Rules for Creating Partitioned Tables

Individual tables can be partitioned across multiple SQL Servers.The home of a table is defined by the system procedure sp_place_tablethat immediately precedes the create table statement. For moreinformation on sp_place_table, see “Using sp_place_table” on page4-11.

The following rules are true when sp_place_table is not used beforecreate table and:

Using sp_place_table

sp_place_table supplies declustering information for a table.sp_place_table does not partition the table, but sends partitioningdirectives to Sybase MPP. Sybase MPP interprets the parametersspecified with the sp_place_table command and acts on the directives.

sp_place_table should be used before create table and select into whendeclustering information does not already exist in the globaldirectory. sp_place_table must occur in the ad hoc batch or storedprocedure as the statement immediately before the create table or selectinto statement. It can be viewed as extended syntax for create table orselect into.

Rule• You specify a segment in the

create table statementThe table is hash partitioned on all SQLServers residing on that segment. Thefirst column is used as the hashdecluster key.

• You do not specify a segment inthe create table statement and youare the “sa” user

The table is schema partitioned on theSchema Server.

• You do not specify a segment inthe create table statement and youare not the “sa” user

The table is schema partitioned on arandom SQL Server in the home of thedatabase.



The syntax for sp_place_table is:

sp_place_table "mode", {"hash" | "range" | "schema"},"home", " number_of_servers ", " servername "[, " servername ", ...][, "columns", " number_of_columns ", " column_name "[, " column_name ", ...]][, "intervals"," value " [, " value ", ...]]

sp_place_table Rules

• All values must be in quotes.

• The lists of servers, columns, and interval values should bespecified in the order shown in the syntax.

• sp_place_table should be used before a create table or select intostatement. Arguments specified with sp_place_table apply to thecreate table or select into statement that immediately follows it.

• sp_place_table has no effect if specified by itself, although it is notillegal to do so.

sp_place_table Parameters

The sp_place_table parameters are as follows:

Parameter Description

mode{} Specifies the partitioning scheme. Select hash, range, orschema.

home Indicates that the information that follows describesthe table’s home.

number_of_servers Number of SQL Servers on which to partition the table.

servername Logical name of each SQL Server on which to partitionthe table. If range declustering is specified, the order ofthe interval values and their corresponding serversdetermines the order of the server list, instead of theserver list being in numeric order. For hashdeclustering, the first hash bucket corresponds to thefirst server in the list of servers.

columns Indicates that the information that follows describesthe decluster columns.

number_of_columns Number of columns in the decluster key.



Schema Declustering Example

1. use mastergoexecute sp_place_table "mode","schema",

"home", "1", "50001"create table t1 (name varchar (255), number

smallint)go

Specifies schema declustering on SQL Server 50001.

column_name Name of each decluster key column. Declustercolumns must be columns in the table being created.The order of columns is important for rangedeclustering since the order of the values of theintervals parameter corresponds to the order of thecolumns.

intervals Indicates that the information that follows describesthe range interval values. Applicable to range-partitioned tables only.

value Maximum value to be stored on each correspondingSQL Server for each of the columns in the declusterkey. The first number_of_servers value following theintervals keyword applies to the first column and mustbe in ascending order (there can be duplicates). Thesecond number_of_servers value applies to the secondcolumn and needs to be in ascending order only whenthe corresponding range interval values for the firstcolumn are the same. The “Range DeclusteringExamples” on page 4-14 demonstrate usingsp_place_table with range declustering.




Hash Declustering Examples

1. use mastergoexecute sp_place_table "mode","hash",

"home", "10","50000", "50001", "50002","50003", "50004", "50005","50006", "50007","50008", "50009","columns", "1", "empid"

create table t1 (name varchar (255), numbersmallint)

go

Specifies hash declustering on column empid across 10SQLServers.

2. use mastergoexecute sp_place_table "mode",

"hash", "home", "10","50002", "50003", "50004","50005", "50006", "50007","50008", "50009", "50010","50011","columns", "2", "number","name"


go

Specifies hash declustering on the composite key (number,name) across 10 SQL Servers.

Range Declustering Examples

1. use mastergoexecute sp_place_table "mode","range",

"home", "10","50002", "50003", "50004","50005", "50006", "50007","50008", "50009","50010","50011","columns", "1", "empid","intervals", "0", "1","2", "3", "4","5", "6", "7","8", "32767"select number into t1 from t2

go

Specifies range declustering on column empid across 10 SQLServers. The maximum key value stored on the first server is 0,



the maximum key value stored on the second server is 1, and themaximum key value stored on the last server is 32767.

2. use mastergoexecute sp_place_table "mode","range",

"home", "10","50002", "50003", "50004","50005", "50006", "50007","50008","50009", "50010","50011","columns", "2", "empid", "name","intervals", "0", "1","2", "3", "4","5", "6", "7","8", "32767","a", "c", "e","h", "l", "p","s", "t", "w", "z"


go

Specifies range declustering on the composite key (empid, name)across 10 SQL Servers.

The 10 numeric values following the intervals keyword specify themaximum values to be stored for the empid column on eachcorresponding SQL Server. The resulting 10-character string isthe maximum values to be stored on each corresponding SQLServer for the name column. Range interval values must be inascending order.


5 Using Parallel Bulk Copy 5.

This chapter describes how pbcp works. It includes the followingtopics:

• pbcp Overview 5-1

• How pbcp Works 5-2

• Preparing to Use pbcp 5-4

• Using the Command Line Interface 5-5

• Designing a Master Client for pbcp 5-17

• Trace Flags 5-19

pbcp Overview

Parallel bulk copy (pbcp) is a scalable, high-performance method ofloading data into Sybase MPP.

This utility is based on SQL Server bulk copy (bcp) and the OpenClient™ and Open Server™ applications. For more information onthese products, please consult the appropriate manuals.

The following terms are used in this chapter:

Term Description

load client Reads data from the data source and sends it acrossthe network to a router. Each input stream of a pbcpoperation has a load client.

master client Initiates and directs the progress of a pbcp operationby sending control commands to the master thread.

master thread An Open Server thread that runs on the Schema SplitServer.

merger A Split Server thread that receives data from therouters and then copies this data into the SQL Serverassociated with a partition of the table. Each partitionof the home of a target table has a merger.

router A Split Server thread that receives data from a loadclient and routes it to the appropriate mergers, basedon the decluster function of the table.

Schema Split Server The Split Server associated with the Schema Server.All master clients connect to the Schema Split Server.

5-2 Using Parallel Bulk Copy

How pbcp Works Sybase MPP Release 11.0.x

How pbcp Works

Parallel bulk copy supports multiple input streams for loading datainto Sybase MPP. Input streams are coupled with independentrouters. Each router receives data and routes the rows to theappropriate data partition, based on the declustering function of thetable. The rows are then merged together and copied into theappropriate SQL Server, as illustrated in Figure 5-1.

There are three major components to a pbcp operation:

• The master client

The master client connects to the Schema Split Server via OpenClient (for example, the master client may be the isql utility) andthen loads the data.

• One or more load clients

There is one load client for each input stream (data file).

• Sybase MPP Split Servers

You can run pbcp using a command-line interface or through a set ofpbcp control commands. The control commands can be incorporatedinto an Open Client application. Both of these methods are discussedin this chapter.

➤ NotePerformance is best when there is one load client per Split Server and no

batching is used. However, without the use of batching, if a failure occurs,

more data will have to be reloaded.


Sybase MPP Release 11.0.x How pbcp Works

Figure 5-1: Overview of pbcp

LoadClient

LoadClient

SplitServer

SplitServer

Split

MasterThread

Schema

pbcp

1 1

1

2 23

3

3

3

4

5 5

1 pbcp master client thread connects to Schema Split Server. Schema Split Servermaster server thread starts Split Server threads.

2 Master client thread starts a specified number of Load Clients.

3 Load Client connects to Split Server and performs standard bcp.

4 Data is redistributed between Split Servers based on redecluster.

5 Split Server performs “insert bulk” on associated SQL Server.

SQLServer

SQLServer

Data Data


Preparing to Use pbcp Sybase MPP Release 11.0.x

Differences Between pbcp and Standard bcp

pbcp is based on the functionality provided in bcp. There are,however, differences between the two utilities, as illustrated in thefollowing table:

Preparing to Use pbcp

Before you use pbcp, perform the following steps:

a. Use thebcp utility to transfer data out.

Table 5-1: Differences between bcp and pbcp

bcp pbcp

Lets you transfer data in or out. aSupports only transferring data in.

Requires that server permissions beset appropriately (see the SQL ServerSystem Administration Guide for moreinformation).

Requires that server permissions beset appropriately for all servers onwhich the table resides.

Supports text and image data. Does not support text and image data.

Single client. Multiple clients.

Single source of data. Multiple sources of data.

Parallel insert from a single client. Parallel insert from multiple clients.

Restart at row. Restart at batch.

Step Description

1. Decide whether to use pbcp or standard bcp. Both methods use parallelinserts in the Sybase MPP environment. If you are working with a smalltable, standard bcp is sufficient. If you are working with a large table, usepbcp to improve system performance.

2. Perform all of the procedures described for copying data with bcp in theSQL Server System Administration Guide when you use pbcp.

3. Know the logical name of the Schema Split Server. The name is in theformat M$DN400001, where $DN is a 2-digit instance number.

4. Know the logical names of all Split Servers that the load clients willconnect to. The name is in the format M$DN4xxxxx, where xxxxx isgreater than or equal to 00002 and less than or equal to the highest realmnumber.


Sybase MPP Release 11.0.x Using the Command Line Interface

Using the Command Line Interface

The command-line interface is sufficient for most pbcp operations.For developers who want to design an Open Client application, see“Designing a Master Client for pbcp” on page 5-17.

pbcp reads a configuration file that contains the pbcp parameters. Youneed to create this file. You can use any text editor that supports anASCII file format. Sample files are shown later in this chapter,starting with “Example 1: Three Data Files and Three Load Clients”on page 5-12. Each parameter is described in the section “pbcpConfiguration File Parameters” on page 5-6.

The syntax for the pbcp utility is:

pbcp [-C config_file ] [-l locale ] [-v]

➤ NoteNon-numeric parameter values in the configuration file should be in the

character set specified by locale.

If no locale is specified, the default values are used for language andcharacter set. See the SQL Server System Administration Guide (release4.9.2) for more information on the default values for your operatingsystem.

Where Represents

config_file Configuration file to use. The default is pbcp.config in thecurrent directory.

locale Designation of the language to use with the Sybase MPPLanguage Module. The locale should match one of the entriesin the locales.dat file. pbcp issues all messages in the specifiedlanguage and character set.

-v Flag to display the pbcp version and exit.


Using the Command Line Interface Sybase MPP Release 11.0.x

pbcp Configuration File Parameters

The following parameters are set in the pbcp configuration file.Examples of pbcp configuration files are provided in the section“Configuration File and pbcp Run Examples” on page 5-12.


x The first character in the file which is used as thecomment character.

tablename (required) The full name of the table, for example,database_name.owner.table. No defaults areallowed for database_name or owner.

datafiles (required) One or more input files. These must be diskfiles; tape drives and other serial devices are notsupported.If a data file is on a remote machine, the name ofthe file must be preceded by the machine nameand colon (:), then the full path to the file. Forexample, foo:/usr/u/sybase/datafile. The remotemachine must be accessible via the rsh UNIXremote shell command.

bcp_paths (required) The path(s) to the bcp executable, including theexecutable name.

If you are loading data files from a remotemachine, the bcp executable must exist on thatremote machine. To specify a remote machine,precede the path with the machine name andcolon (:). For example, foo:/home2/u/bin/bcp.



split_server_names(required)

The Split Servers you want to use for routers oneach machine. You must specify at least oneSplit Server name for each machine that has adata file. Do not list the same Split Server morethan once. It is recommended that the SplitServer(s) used for a particular machine berunning on that machine to avoid theperformance overhead of sending data over thenetwork. This is how you might specify the SplitServers on the local machine and on a remotemachine named “sybase7”:

split_server_names = M01400021,sybase7:M01400031

You can specify any number of Split Servers fora given machine. Do not list the same SplitServer more than once. For each machine, pbcpdistributes work from the load clients evenlyacross all specified Split Servers.

schema_split_server_name(required)

The name of the Split Server associated with theSchema Server. This is the server that the masterclient connects to. It has a standard name that isbased on the Sybase MPP instance number:M$DN400001. For example, if your instancenumber is 02, then the Schema Split Servername is usually M02400001.

num_load_clients (optional) The maximum number of load clients to be runfor this pbcp operation. There must be at leastone load client per data file. However, it ispossible to have multiple load clients accessingdistinct partitions of the same data file. Forexample, one load client could load rows 1–1000while another loads rows 1001–-2000.

To have more than one load client per data file, abatch size must be specified (see batchsize).

batchsize (optional) The number of rows pbcp should copy into thetable before committing a batch. This option isrequired if you want to have more than one loadclient per data file.

Use this option when copying in large amountsof data. Then, if failure occurs, you can startfrom the beginning of the batch that failed byusing the first_batch parameter to specify thestarting batch number




first_batch (optional) The batch number that pbcp should use as itsstarting point. Batch numbers start at 1.

Use this option if a previous pbcp failed afterone or more batches were committed. Thisallows you to start from the beginning of thebatch that failed, instead of starting over fromthe beginning of the pbcp operation.

format_files (optional) The file that describes the format of the inputdata, one for each machine that contains a datafile. See the SQL Server Commands Reference forinformation on bcp format files.

To specify a format file on a remote machine,precede the file name with the machine name, acolon (:), and then the full path to the file. Forexample, foo:/usr/u/mydir/bcp.fmt.

Either format_files or file_type must be specified.

file_type (optional) Accepted values are “ascii” or “native.” This isnot needed if you specify the format_filesparameter. This parameter is forwarded directlyto bcp. Either format_files or file_type must bespecified.

field_terminator (optional) The character used to delimit fields in the datafile. This is not needed if you specify theformat_files parameter. This parameter isforwarded directly to bcp.

row_terminator (optional) The character used to delimit rows in the datafile. This is not needed if you specify theformat_files parameter. This parameter isforwarded directly to bcp. The default is none.

username (optional) The name used when logging into Sybase MPP.The default is the login name.

password (optional) The password for server login. If none isspecified, a NULL password is assumed.

interfaces_files (optional) The location of the interfaces file, one for eachmachine that contains a data file.

To specify interfaces files for remote load clients,specify the machine name, a colon (:), and thenthe full path to the interfaces file. For example,foo:/usr/u/sybase/interfaces.




packet_size (optional) The size of the TDS packets being sent across thenetwork. A larger value provides higherthroughput. This parameter is forwardeddirectly to bcp. The default for pbcp is 2048bytes. For example: packet_size=2048

packet_size must be between the values of thesp_configure options default network packet sizeand maximum network packet size, and it must be amultiple of 512. See the section “ChoosingPacket Sizes” on page 8-8 for details onconfiguring these SQL Server values.

Use larger-than-default network packet sizes toimprove the performance of large bulk copyoperations.

outfile_dir (optional) The directory where all output and error filesare stored. Can only be on the local machine.The default is the current directory.

lc_outfile_name (optional) The base name of the output files that contain alloutput from the load clients. Each output file isthen appended with “_NNNNN.xxx” todistinguish separate load clients. NNNNN is the5-digit process ID of the master client, and xxx isa 3-digit number that is incremented by 1 foreach successive output file. For example, iflc_outfile_name is pbcp.out, there are two loadclients and the master client process ID is“76543”, then the two output file names arepbcp.out_76543.000 and pbpc.out_76543.001.

If you are using batching, the output file name isappended with a “.b” and a 2-digit batchnumber. For the above example, if there weretwo batches, there would be four output files:

• pbcp.out_76543.000.b01

• pbcp.out_76543.000.b02

• pbcp.out_76543.001.b01

• pbcp.out_76543.001.b02

All output files are stored in the directoryspecified by the outfile_dir parameter.




Clarification of Escaping Rules

There are two levels of escaping in pbcp:

1. configuration file escaping

2. shell escaping

The default escape character for configuration file is the backslash(\). A user can specify an escape character by adding the followingline to the file format section of the configuration file:

[file format]escape=|

Because pbcp generates command line options for bcp, and passes itto the shell, the special characters in the parameter values such as

lc_errfile_name (optional) The base name of the error files that the loadclient bcp process creates if the data files containsyntax errors. Each of the error file names isappended with “_NNNNN.xxx” to distinguishseparate load clients. NNNNN is the 5-digitprocess ID of the master client, and xxx is a 3-digit number that is incremented by 1for eachsuccessive error file. For example, iflc_errfile_name is pbcp.err, there are two loadclients and the master client process ID is“76543”, errors found by the first load client areplaced in the file pbcp.err_76543.000. Errorsfound by the second load client are placed in thefile pbcp.err_76543.001.

If you are using batching, the error file name isappended with a “.b” and a two digit batchnumber. For the above example, if an error wasfound by the first load client in the secondbatch, it would be placed in the filepbcp.err_76543.000.b02.

All output files are stored in the directoryspecified by the outfile_dir parameter.

maxerrors (optional) The maximum number of bcp errors permittedper load client before the load is aborted.

tracing=verbose (optional) Causes pbcp to write more information aboutwhat is happening internally to the output file.For information on trace flags that can also beused, see the section “Trace Flags” on page 5-19.




backslash (\) and pipe (|) should be escaped. Set up the escape asfollows:

If the escape character for a configuration file is \ and the escapecharacter for the shell is also \, the terminators for

field1|field2|field3

are as follows:

field_terminator=”\\|”

row_terminator=”\\\\n”

The generated bcp command looks similar to this:

bcp pbcptest.dbo.pbcptable1 in datafile.small -SM1140002

-Usa -P -c -r \\n -t \| -A 512 -F 1 -L 5

Refer to your SQL Server documentation on bcp for additionalinformation on field and row terminators.

Setting the Wait Interval Between Load Clients

The environment variable RB_SLEEP can be used to set the numberof seconds to wait between load-client spawns or forks. The defaultis 1 second. When there are more than two load clients, longer timesare needed to avoid network errors. pbcp uses RB_SLEEP only if it isset to a numeric value between 1 and 20.

Performance Guidelines

Avoid putting routers and data files on the primary node, since it isthe busiest node and load clients run more slowly there.

Always put routers on the same node as their associated data files.

pbcp batching slows performance. You can avoid using batchingwhile still having a non-zero recovery point. If your table has aunique index, add it to the ignore_dup_key parameter. If your tablehas a non-unique clustered index, add the ignore_dup_row parameter.Then use one or two load clients at a time per non-primary node.After each operation, truncate the transaction log, modify theconfiguration file to use another set of data files, and run anotheroperation. If there is a failure, clean up pbcp (see the example on page 5-15),truncate the logs, and start the operation again.

More than two load clients per non-primary node might not improveperformance due to resource requirements.



Configuration File and pbcp Run Examples

The following are examples of configuration files and the resultsafter running pbcp.

Example 1: Three Data Files and Three Load Clients

Configuration File

;;The semicolon is the comment character because;it’s the first character on the first line;of this file;[parameters]tablename=pbcptest.dbo.pbcptabledatafiles=datafile, bar:usr/u/sybase/datafile, \

foo:/usr/u/sybase/datafilebcp_paths=/mpp2/SQLSERVER/bin/bcp, \

bar:/mpp2/SQLSERVER/bin/bcp, \foo:/mpp3/SQLSERVER/bin/bcp

batchsize=10000file_type=asciifield_terminator=”,” ; quotes needed to distinguish

; this comma from a list; delimiter

row_terminator=”\\\\n”username=sainterfaces_files=/mpp2/SQLSERVER/interfaces, \

bar:/mpp2/SQLSERVER/interfaces, \foo:/mpp3/SQLSERVER/interfaces

split_server_names=M01400021, bar:M01400031, \foo:M01400041

schema_split_server_name=M01400001



Run Result

%pbcp -CconfigfileServer message:Message number: 5701, Severity 0, State 2, Line0Server ’M01400001’Message String: Changed database context to ’master’.Server message:Message number 5793, Severity 0, State 1, Line 0Server ’M01400001’Message String: Changed language setting to ’us_english’.Server message:Message number: 5701, Severity 0, State 2, Line0Server ’M01400001’Message String: Changed database context to ’pbcptest’.Starting up 3 load clients

Successfully copied 10000 rows

Example 2: Three Data Files and Six Load Clients

Configuration File

;;The semicolon is the comment character because;it’s the first character on the first line;of this file;[parameters]tablename=pbcptest.dbo.pbcptabledatafiles=datafile, bar:/usr/u/sybase/datafile \

foo:/usr/u/sybase/datafilebcp_paths=/mpp2/SQLSERVER/bin/bcp, \

bar:/mpp2/SQLSERVER/bin/bcp, \foo:/mpp3/SQLSERVER/bin/bcp

interfaces_files=/mpp2/SQLSERVER/interfaces, \bar:/mpp2/SQLSERVER/interfaces, \foo:/mpp3/SQLSERVER/interfaces



batchsize=10000num_load_clients=6file_type=asciifield_terminator=”,” ; quotes needed to distinguish

; this comma from a list; delimiter

username=sasplit_server_names=M01400021, bar:M01400031, \

foo:M01400041schema_split_server_name=M01400001

Run Result

%pbcpServer message:Message number: 5701, Severity 0, State 2, Line0Server ’M01400001’Message String: Changed database context to ’master’.Server message:Message number 5793, Severity 0, State 1, Line 0Server ’M01400001’Message String: Changed language setting to ’us_english’.Server message:Message number: 5701, Severity 0, State 2, Line0Server ’M01400001’Message String: Changed database context to ’pbcptest’.Starting up 6 load clients


Example 3: A Failed Batch

This example uses the same configuration file as Example 1, exceptthat, in this case, a failure occurs during the pbcp operation.

Run Result

%pbcpServer message:Message number: 5701, Severity 0, State 2, Line0Server ’M01400001’Message String: Changed database context to ’master’.Server message:Message number 5793, Severity 0, State 1, Line 0Server ’M01400001’Message String: Changed language setting to ’us_english’.Server message:



Message number: 5701, Severity 0, State 2, Line0Server ’M01400001’Message String: Changed database context to ’pbcptest’.Starting up 3 load clients

Error in bcp for load client 15159. See the file ./test11.0 formore detailsLoad client 15159 exited unsuccessfullyParallel BCP failedLast successful batch was 2Unable to kill child process 15159: No such process

*** IMPORTANT RECOVERY INFORMATION ***Please use isql to login to your Schema Split Server and cleanupthis failed pbcp operation as follows:---------------------------------------------------isql -Usa -SM01400001pbcp_kill pbcptest.dbo.pbcptablegoquit---------------------------------------------------

After you determine the cause of the failure and fix it, you cancontinue with the copy. Rather than truncating the table and startingover, add the first_batch parameter to the configuration file:

first_batch=3

The resulting run becomes:

%pbcpServer message:Message number: 5701, Severity 0, State 2, Line 0Server ’M01400001’Message String: Changed database context to ’master’.Server message:Message number: 5703, Severity 0, State 1, Line 0Server ’M01400001’Message String: Changed language setting to ’us_english’.Server message:Message number: 5701, Severity 0, State 2, Line 0Server ’M01400001’Message String: Changed database context to ’pbcptest’.Starting up 3 load clients




The same technique is used even if you have more load clients thandata files. pbcp is able to locate the beginning of the batch for eachload client, regardless of how many there are per data file.

Aborting pbcp

You can abort pbcp at any time by pressing the Delete key or Ctrl-c.

After pbcp is aborted, check to be sure that there are no leftoverthreads hanging in Sybase MPP by doing the following:

1. Run robopbcp node tablename on each node on which a load clienthas been spawned, where node is the machine name on whichthe load client was spawned, and tablename is the fully specifiedtable name, such as userDB.dbo.userTable.

2. As “sa,” run the script:

pbcp_kill tablename sa password

where tablename is the fully specified table name, and password isthe “sa” password.

This command terminates any leftover threads in the SplitServers and logs into each SQL and Schema Server to look forany threads that are holding an exclusive lock on the table.

3. Log into the SQL Server or Schema Server to verify that there areno leftover threads. If there are, issue a kill spid command, wherespid is the server process id, to terminate them.

4. If the table to be loaded was initially empty, log into each SQLServer and run truncate table to clean up the table.

or

If the table to be loaded was not initially empty, or if there will beseveral pbcp runs to load a table, you might want to add atimestamp column. Then, before starting a pbcp batch, you need tocreate a default value for the timestamp column that has not beenused in previous runs. Then delete rows from the table wherevalues in the timestamp column equal the default value:

delete table where timestampcolumn = defaultvalue

This removes any newly added rows in the table from the table’shome before pbcp is restarted.


Sybase MPP Release 11.0.x Designing a Master Client for pbcp

Designing a Master Client for pbcp

The master client sends control commands to the master thread, anOpen Server process that runs on the Schema Split Server.

➤ NoteBefore you include master client control commands in an Open Client

application, you should be familiar with writing Open Client applications.

Master Client Interface

The following list includes the valid pbcp control commands themaster client can send to the Schema Split Server.

Command Description

pbcp_init number of routers This is the first command sent. It indicatesthat a pbcp operation with a specified numberof routers is about to start.

insert bulk tablename Once the Schema Split Server returns from thepbcp_init command, the master client initiatesthe operation by sending this command.

Once the Schema Split Server returnssuccessfully from this command, load clientscan be started and data can be transferred.However, data is not transferred until all loadclients are started.

pbcp_done Commits the pbcp operation. This commandshould be issued only after all load clientshave finished loading data into the system.

If this command fails or is aborted in error,details are sent to the supplemental log of theSchema Split Server. You need to restore thedatabase to its state prior to the pbcp operation

pbcp_abort Aborts the pbcp operation. When pbcp_abort isused before the pbcp_done statement, all datais backed out, and the table is returned to itsoriginal state.


Designing a Master Client for pbcp Sybase MPP Release 11.0.x

Sample Sequence of Events

For the simplest example of executing a pbcp operation, isql is used asthe master client and bcp as the load client. In this example, there aretwo instances of the load client, one per data file. You use threeseparate sessions, one for the isql master client, and one for each ofthe two load clients.

pbcp_kill tablename Sometimes a previous pbcp operation is killedunexpectedly, for instance, due to a server or anode going down. Since there are multiplethreads distributed across multiple servers fora given pbcp operation, failure of one threadmight not be apparent to other threads in thepbcp operation. Threads that are still alivemight be left in a suspended state waiting tocoordinate with threads that will neverrecover.

These pbcp threads may hold a lock on thetarget table, either on the local SQL Server oron the Schema Server. A subsequent writeoperation on that table, such as an insert,update, delete, or bcp, will wait indefinitely forthe lock to be released. Threads left over froma failed pbcp operation are viewable byissuing an sp_who on each server. The cmdcolumn will show “bulk copy” as thecommand.

pbcp_kill allows you to remove these oldthreads and release the locks on the tables.The table name must be fully qualified touniquely identify the pbcp operation whosethreads should be cleaned up.

attention As with all Open Client applications, it ispossible to send an asynchronous attention tothe server using the Open Client routinect_cancel, or, if you are in an isql session, bypressing Ctrl-C. This aborts the pbcp operationif you are currently waiting for a responsefrom the server.

If you are not waiting for a response, anattention has no effect; instead, use thecommand pbcp_abort.

Command Description


Sybase MPP Release 11.0.x Trace Flags

1. From any node in the instance, connect the master client, in thiscase isql, to the Schema Split Server:

isql -Usa -P -SM01400001

2. Issue the commands:

pbcp_init 2go

3. Issue the commands:

insert bulk mydb.myname.mytablego

4. When the Schema Split Server returns (after the insert in step 3completes), initiate both load clients from their own sessions.Each session must be on the system where the data file, and therouter Split Server being used, reside:

bcp mydb.myname.mytable in datafile1 -SM01400021 -Usa -P -c

bcp mydb.myname.mytable in datafile2 -SM01400031 -Usa -P -c

➤ NoteAll bcp command line arguments can be used with the exception of -A, -E,

and -X, since they are not supported by SQL Server 9.1-mpp.

5. When both load clients complete, issue the following commandsfrom the isql master client session:

pbcp_donego

6. Exit isql:

quit

Trace Flags

In addition to the tracing=verbose option that can be added to theconfiguration file, there are a number of trace flags that can beincluded in the dnlogflags file to aid in gathering additional


Trace Flags Sybase MPP Release 11.0.x

information about a pbcp operation. The following table lists thoseflags:

Table 5-2: Trace flags for pbcp

Value Description

4200 Traces message types sent and received

4201 Hex dump of row data packets sent and received

4202 Traces SUSPEND and RESUME flow; useful for analyzingpossible bottlenecks

4203 Traces changes in the state of pbcp threads

4204 Prints out hex dump of all message data, except the row datapacket message

4205 Dumps memory heap allocation map to the bin subdirectorywhen a thread completes

4206 Additions and deletions to the association map

4207 Traces message flow through the gateway functions

4208 Traces additional events in the master thread

4209 Traces additional events in the router threads

4210 Traces additional events in the merger threads

4211 Traces activity of the queues used to pass inter-threadmessages, including inter-process messages

4212 Traces allocation of memory blocks used to send inter-threadmessages

4295 Parallel bcp routine entry

4296 Parallel bcp routine exit


6 Backup and Restore 6.

This chapter discusses the Sybase MPP Backup and Restore utility.This information has been divided by the following sections:

1. Performing the SQL dump and load operations for a paralleldatabase system residing in Sybase MPP

2. Maintaining system and data backups

3. Restoring full or partial databases or a partition of a database


• About the Backup and Restore Utility 6-1

• Backup and Restore Administration 6-4

• Database Consistency and Concurrency During Backup 6-14

• The master and gdnavdb Databases 6-16

• Command Line Interface 6-18

• Backup Strategies 6-24

• Backing Up to Tape 6-28

• Error Handling and Recovery 6-31

• Graphical User Interface vs. Command Line Requests 6-31

• Using the Command Line Interface 6-32

• Backup and Restore Error Logs 6-37

• Stored Procedures for the Command Line Interface 6-38

About the Backup and Restore Utility

Definition

Backup and Restore is a Sybase MPP utility that allows you toperform the following tasks:

• Back up and restore databases

• Partitions of databases

• Transaction logs that reside in a Sybase MPP system

6-2 Backup and Restore

About the Backup and Restore Utility Sybase MPP Release 11.0.x

Supported backup strategies range from disaster recovery and offsitestorage to recovery from single-point failures.

The Backup and Restore utility includes support for a single systemview, parallel processing of dump and load commands, and automaticscheduling of backups.

Backup and Restore coordinates and manages the back up andrestore of each individual partition of the database from a singlepoint of access.

Using Backup and Restore, you can:

• Designate the type of dump device to be used for storing backups

• Specify automatic restoration of transaction logs

• Specify the length of time a history of backup requests is stored

These options can be set either through the system proceduregd_set_dbrf_defaults or through the graphical user interface, SybaseMPP Manager (MPPM).

The Backup and Restore options you set are stored in thegd_dbrf_defaults table and define the default back up and restoreenvironment. The default environment can be overridden at thecommand line or through Sybase MPPM.

For more information about using the Backup and Restore utility inSybase MPPM, see the Sybase MPP Manager User’s Guide.

Hardware and Software Requirements

Backup and Restore operations require sufficient storage media tomaintain the database or transaction log information that resultsfrom a backup request. Backup and Restore supports disk and tapedevices as backup media.

The amount of space required to back up a database to disk must beconsidered when determining the space requirements for SybaseMPP databases.

See the Sybase MPP Release Bulletin for requirements specific to yourplatform.


Sybase MPP Release 11.0.x About the Backup and Restore Utility

Tape Management System

Since large databases supported by Sybase MPP generally require alarge quantity of backup media, a tape management system,REELlibrarian, is integrated into Backup and Restore.

REELlibrarian performs the following tasks:

• Controls access to devices in a multi-user system.

• Simplifies tape handling while backing up large databases.

• Validates all operator dump and load tape mount requests.

REELlibrarian controls access to devices in a multi-user system toensure that devices are reserved until the use of the devices has beencompleted. To make tape handling simpler while backing up largedatabases, the interactions with the tape management functions arecentralized on a single console. From this console, all dump and loadtape mount requests are performed and validated by the tapeoperator. This reduces the need for the requester to manage themounts. Refer to Chapter 9, “Using REELlibrarian with SybaseMPP,” for more information on REELlibrarian.

Dump Devices

Dump devices may need to be modified during Backup and Restoreoperations.

Modifying Dump Devices

Modifying dump devices should be done through Sybase MPPMwhen possible. If you administer a dump device from the commandline, you must connect to the Control Server or the DBA Server, notto an individual SQL Server. Dump devices that are administereddirectly from a SQL Server can cause problems for Sybase MPPBackup and Restore operations.

Restoring from Dump Devices

Backup and Restore always attempts to perform a restore from thesame devices that were used to back up the information beingrestored.

When restoring from tape, if, at the individual server level, the exactsame tape device is not available, another configured tape device ofthe same type is used. A configured tape device is a tape device that


Backup and Restore Administration Sybase MPP Release 11.0.x

has been configured using sp_addumpdevice. The device name thatsorts lowest in the list of dump devices is used. The restore cannot beinitiated if the same type of device does not exist.

Each SQL Server produces one or more tape volume per databasepartition. If any tape volume is missing, the restore operation fails onthat SQL Server only. The restore continues on all other SQL Serversas long as no other errors are encountered.

When restoring, the entire operation fails on all servers if the disk ortape device was not configured from a DBA or Control Server. Themoment of failure occurs when the device is validated before therequest is sent to the server.

When restoring from tape, if, at the individual server level, the exactsame tape device is not available, another configured tape device ofthe same type is used. A configured tape device is a tape device thathas been configured using sp_addumpdevice. The device name thatsorts lowest in the list of dump devices is used. The restore cannot beinitiated if the same type of device does not exist.

Each SQL Server produces one or more tape volume per databasepartition. If any tape volume is missing, the restore operation fails onthat SQL Server only. The restore continues on all other SQL Serversas long as no other errors are encountered.

When restoring, the entire operation fails on all servers if the disk ortape device was not configured from a DBA or Control Server. Themoment of failure occurs when the device is validated before therequest is sent to the server.

Backup and Restore Administration

This section defines the fundamentals of Backup and Restoreadministration.

Backup Device Administration

The type of backup media you use on your system determines howyou configure the Backup and Restore application. Disk devices andtape devices require different options.

The following sections describe disk and tape dump deviceconfigurations, the dump device naming conventions, and dumpdevice parameters.


Sybase MPP Release 11.0.x Backup and Restore Administration

Tape Backup Configuration

The Backup and Restore tape management system centralizes tapemanagement and administration of tape volumes and devices.

If you use tape devices as storage media, Backup and Restore usesthe REELlibrarian Tape Management System to manage the tapesystem. See “Using the Tape Management System” on page 6-29 forinformation about this tape management system.

As Backup and Restore performs the backup and populates tapevolumes, a naming convention is used to coordinate multipledevices for the same backup operation.

The naming convention for tape volumes is: XXYYYYYZZZZZ

Backup Device Naming Conventions

You need to run the sp_addumpdevice procedure for all tape devicesthat are used in Sybase MPP. The dump devices that are added to theSybase MPP system with sp_addumpdevice must use a namingconvention, described below, to allow Backup and Restore toidentify the physical location of the tape drive and its associated SQLServer. A backup or restore request can fail if the dump device namedoes not conform to the convention.

Because Backup and Restore performs the dump and load of thedatabase partitions in parallel, define the _devicename portioncarefully, using the dump device naming convention to avoid devicecontention.

The naming convention is:

QXXYZZZZZ_devicename

SXXYZZZZZ_devicename

Where Represents

XX The Sybase MPP system ID that represents the NS instance.

YYYYY Unique dump ID assigned by Backup and Restore.

ZZZZZ A sequencing number that sets the order of the tape volumes.(When you back up gdnavdb, use gdZZZ. See “Restoring gdnavdb”on page 6-18.)



Example

For example, a dump device named Q0150001_Tape3480 identifies adump device defined within SQL Server “50001” in the Sybase MPPinstance “01”. The _devicename indicates a 3480 tape that is:

• Numbered logically as the first in the system

• Physically accessible to the SQL Server via the node

For the primary server, you can name the dump device eitherQ0150001_Tape3480 or Q01500011_Tape3480.

To configure a dump device for the alternate server, specify a “2”before the “_”, as in Q01500012_Tape3480.

Backup Device Parameters

This section discusses the use of the dump_device parameter for thedump and load commands in the Sybase MPP environment.

Where Represents

Q Identifies a SQL Server.

S Identifies a Schema Server.

XX The Sybase MPP system number that defines the NSinstance: 01–99.

Y The server type: SQL Server is 5; Schema Server is 2.

ZZZZZ The number of the SQL Server: 00000–99999.

_devicename The specified portion of the dump device name. Sybase MPPexpects this name to identify the tape drive within thesystem. The specified ADN also represents the _devicename.ADN is a REELlibrarian term and is defined on page 6-29.



Backup and Restore provides special handling of dump devices inthree different situations. The dump_device parameter has one ofthree meanings in each case:

The following sections discuss each case in detail.

navtape_dumpdevice or navdisk_dumpdevice

The dump_device parameter for a dump or load request on the Transact-SQL command line accommodates the single-system view providedby Sybase MPP, since the database being backed up may be stackedon multiple partitions.

Sybase MPP has defined two special dump device names; use thesewhen you back up or restore an entire database or transaction log.These reserved names are:

• navtape_dumpdevice

Description Comments

1. navtape_dumpdevice ornavdisk_dumpdevice

This parameter provides a single view of thedatabase during a dump or load, so that onlya single command line is required to processthe dump or load command of an entiredatabase. Backup and Restore supports ageneric device name in this situation,because only one dump_device is specified onthe command line.

2. A specific SQL Server You may, at another time, want to back upor restore a database on a single SQL Serverusing any available dump device. In thiscase, Backup and Restore extends thesemantics of the dump_device parameter sothat an MPP SQL Server ID can bedesignated. You specify the logical name ofthe SQL Server to be backed up or restored,rather than a particular dump_device. The_ANY extension to the SQL Server name isthe placeholder for the dump device name.

3. A specific dump device It is possible to specify a dump device onthe command line request for dump or load.When you name a specific device on thecommand line, the database partition on theSQL Server where the dump device isdefined is the only partition backed up orrestored.



• navdisk_dumpdevice

Rather than identifying specific device names, these names specifythe media type to be used in the dump or load request. Then, Backupand Restore determines the actual dump devices to use to process therequest for each partition. The gd_dump_devices table in the SybaseMPP global directory supplies this information.

➤ NoteThe gd_dump_devices table cannot be accessed until the dump device is

defined with the sp_addumpdevice system procedure from a Control or DBA

Server. These device names cannot be used to restore the masterdatabase.

When using the single-system view case described in this section,remember these important points:

• The request backs up or restores the entire database ortransaction log(s).

• Backup and Restore automatically designates the specific dumpdevice(s) for the request.

• Each tape device specified by navtape_dumpdevice must be of thesame format.

For example, Backup and Restore does not allow some partitionsof a database to be stored on 3480 tapes and the remainderstored on 8-mm Exabyte tapes. The navtape_dumpdevice requiresthe tape device to be the same format to process the request; thedefault format is specified by executing the gd_set_dbrf_defaultsprocedure.

See “gd_set_dbrf_defaults” on page 6-39 for a complete explanationof the gd_set_dbrf_defaults procedure.

Here is an example of a request to back up the entire finance databaseusing tape devices that were configured for each database partitionof the system:

dump database finance to navtape_dumpdevice

Following is an example of a request to back up the transaction logsof the entire finance database to disks that were configured as dumpdevices on each SQL Server where the finance database resides:

dump transaction finance to navdisk_dumpdevice



Specific Dump Device Name and a Specific SQL Server

Backup and Restore allows you to include the Sybase MPP SQLServer ID in the dump_device parameter you enter on the commandline. This enables you to back up or restore a database partition to asingle SQL Server. This need could arise, for example, in the case ofmedia failure on a database device in one of the Sybase MPP SQLServers.

Use the dump device naming conventions defined earlier in thissection.

The following example demonstrates how a single SQL Server can berestored from the last database backup, using any available devicethat matches the format it was backed up on:

load database finance from Q0150002_ANY

The dump_device parameter identifies the unique SQL ServerQ0150002. The “_ANY” extension specifies to restore the databasepartition from the first available tape device with matching formatadded with sp_addumpdevice.

The next example shows how a specific device can be used to back upa partition of a database to a specific disk:

dump database finance to Q0150002_ MYDISK

The dump_device parameter identifies the unique SQL ServerQ0150002, and defines the unique device name on which to back upthe database or database partition. Again, this device must bedefined in Sybase MPP using the sp_addumpdevice procedure.

Data Devices and Log Devices

In both the Sybase MPP and SQL Server environments, thetransaction log can be backed up separately from database data onlyif the log is stored on its own device. In the Sybase MPPenvironment, since databases are partitioned, each partition musthave separate data and log devices in order to perform transactionlog backups. If separate devices have not been configured, errorsoccur when the dump transaction statement is issued. If globalconsistency is enabled, the entire dump transaction fails; if localconsistency is enabled, the backup on SQL Servers fails when dataand the transaction log are not on different devices.

Separate devices for data and the transaction log are specified whenyou issue the Transact-SQL command, create database. See Transact-SQL User’s Guide for more information.



Systems Configured for Failover

This section describes how Backup and Restore uses dump devices ifyour system is configured to allow failover.

For this situation, the specified dump device is for a server other thanthe currently running primary or alternate server.

Changing Volume Groups

If you are using failover, whenever changes are made to volumegroups on a node, make sure that identical volume group definitionsexist on that node’s failover node. This can be done by exportingvolume group configurations from one node to the other. For moreinformation, use IBM infoExplorer to view online information aboutthe importvg, exportvg, chvg, reducevg, varyonvg, varyoffvg and mkvgcommands, or refer to the AIX High Availability Cluster Multi-Processing/6000 Version 3.1 Administration Guide.

Backing Up to Disk

If you specify “_ANY”, Backup and Restore uses the first availabledevice for the currently running server.

If you specify a specific dump device, it must be defined on thesystem. Backup and Restore uses a dump device defined for thecurrently running server with the same _devicename, if it exists. If onedoes not exist, an error is returned.

See “Backup Device Naming Conventions” on page 6-5 for moreinformation on dump device names.

Example

You request the dump device Q0150002_dumpdisk, and the alternateserver is running.

If both Q0150002_dumpdisk and Q01500022_dumpdisk exist, Backupand Restore uses the latter. If neither exist, an error is returned.

Backing Up to Tape

If you specify “_ANY”, Backup and Restore uses the first availabledevice for the currently running server.

If you specify a specific dump device, it must be defined on thesystem. A dump device defined for the currently running server that



has the same physical _devicename as in the specified dump device isused, if it exists. If one does not exist, the first available device for thecurrently running server is used.


Example

You request the dump device Q0150002_tapeA, which has thephysical device name /dev/rmt0, and the alternate server is running.

If Q0150002_tapeA does not exist, Backup and Restore returns anerror.

If Q0150002_tapeA does exist, Backup and Restore selects a dumpdevice Q01500022_xyz, which also has the physical name /dev/rmt0, ifit exists. If it does not exist, Backup and Restore uses the firstavailable device for the alternate server.

Restoring from Disk

If you specify “_ANY”, Backup and Restore uses a dump device forthe currently running server that has the same _devicename as thedump device used for backup.


Example

The backup dump device name is Q01500022_dumpdisk, and theprimary server is running.

Backup and Restore uses Q01500021_dumpdisk if it exists. If it doesnot exist, Backup and Restore uses Q0150002_dumpdisk. If neitherexists, an error is returned.

If you specify a specific dump device, it must be defined on thesystem. Backup and Restore uses a dump device defined for thecurrently running server with the same _devicename, if it exists. If onedoes not exist, an error is returned.

Restoring from Tape

If you specify “_ANY”, Backup and Restore uses a dump device thathas the same physical device name as the backup dump device, ifone exists. If one does not exist, the first available device is used.




Example

Backup and Restore uses Q0150002_tapeA, if it has the physicaldevice name /dev/rmt0.

If you specify a specific dump device, it must be defined on thesystem. A dump device defined for the currently running server withthe same _devicename as in the backup dump device name is used, ifit exists. If one does not exist, the first available device is used.

Logging into a Control Server after Failover

The documentation for Recovery Manager should state that if youuse isql to try to log into a failed Control Server, you may experiencea 60-second delay. This is because isql attempts to connect to thefailed Control Server before timing out and connecting to theAlternate Control Server. To minimize the timeout period, use thefollowing command to log into Control Servers after failover:

isql -S server_name -l1

where server_name represents the name of the Control Server.

The -l1 (small L) parameter changes the timeout period to one second.

Configuration Considerations

This section discusses configuration and performance considerationsfor the different peripherals that are supported by Sybase MPPBackup and Restore.

Backup and Restore capitalizes on the Sybase MPP parallelprocessing capabilities that enhance performance; however, thefollowing all influence performance:

• Number of dump devices attached to the system

• Performance rating of each dump device

• Physical configuration of the dump devices

• Partitioning of the database

• Number of SQL Servers

• System activity



Peripherals

See the Sybase MPP Installation Guide for information regardingsupported peripherals.

Database Settings

For each database in Sybase MPP, default Backup and Restoreparameters must be defined. These parameters are used by Backupand Restore, as well as the dump and load commands.

See also “Stored Procedures for the Command Line Interface” onpage 6-38.

Default Settings

Whenever a database is added to the Sybase MPP system, use thegd_set_dbrf_defaults stored procedure to define the environment for adump or load request. The following defaults are for each newlycreated database:

Backup History Catalog

Backup and Restore maintains a history of all backup requests madewithin the Sybase MPP environment. The catalog primarily serves toassist in load operations and is maintained by the Sybase MPP globaldirectory.

This history is accessible in the Schema Server table, gd_dbrf_db_info,or from Backup and Restore. Backup and Restore provides easyaccess to the list and allows you to initiate a restore by selecting thedesignated backup.

Table 6-1: New database default settings

Variable Default Setting

consistency_option Local

aging 2

load_option Manual

default_dump_media Tape

default_tape_type 8-mm Exabyte

pool_name “mpp”


Database Consistency and Concurrency During Backup Sybase MPP Release 11.0.x

The history displays the dump ID, database name, the type ofbackup (transaction log or database), consistency (global or local),date, and time.

For backup requests that use tape media for the dump device, arecord of the tape volume name and the database partition isrecorded. When you restore a database, Backup and Restore directsthe Tape Management System to locate tapes for that database withthis information. You do not need to track the names of the tapevolumes in the backup set.

Database Consistency and Concurrency During Backup

When a database is added to or created in the Sybase MPP system,default parameters for the database dump and load environment areset. One of these parameters is the consistency_option value.

This value specifies whether update transactions to the database areallowed while the database is being backed up. The value must bebased on how much consistency is required for data recovery.

Backup and Restore manages the entire backup, including access tothe database during backup. You can designate one of twoconsistency options for a database:

• Global consistency

• Local consistency

When updates to the database are limited during backup, aconsistent image is maintained across all partitions of the database ata known point in time. This is global consistency.

When full, concurrent access to the database is allowed duringbackup, a consistent image is maintained only at the level ofindividual SQL Server partitions. This is local consistency.

You can set this option for a database by defining the value andexecuting the gd_set_dbrf_defaults stored procedure. This proceduresets the parameters for the backup environment. The databasesetting is maintained at the Sybase MPP system level and stored inthe global directory. This Backup and Restore stored procedure isdiscussed in “Stored Procedures for the Command Line Interface”on page 6-38.

You can also set database backup parameters from Backup andRestore. These options are available in the Settings window, whichyou access from Settings option of the Administration pull downmenu.


Sybase MPP Release 11.0.x Database Consistency and Concurrency During Backup

You can also see “Backup Strategies” on page 6-24 for illustrations ofglobal and local consistency.

Global Consistency

Global consistency maintains a consistent image of the databaseacross all partitions during a backup and can only be maintainedwhen all the database partitions participate in the backup.

Global consistency halts all update transactions to the databasebeing backed up within the Sybase MPP system. If a transactionattempts to update a database during the backup, the currenttransaction is suspended until the last SQL Server has started itsbackup. When the last checkpoint is issued, all processes that werehalted are reawakened and the processing continues. Between thispoint and the time that the backup completes, there is concurrentaccess to the database.

Only when this mechanism is used can the database owner beassured that the backup will be a consistent picture of the database atthe specific point in time that it was backed up.

If you require disaster recovery in an environment where there arefrequent updates to the database, you should set the consistencyvalue to “global.”

Local Consistency

The default value for the consistency option is “local.” Localconsistency allows full, concurrent access to the database duringbackup. This means that a consistent image of the database ismaintained only at the level of individual SQL Server databasepartitions.

When this value is selected for consistency, updates to the databaseare allowed at any point during the backup.

Local consistency maintains consistency within each SQL Serveronly. Update transactions might occur to a partition of the databaseduring the backup. Since an update might spread across multipleSQL Servers, it is possible that the database data is inconsistentacross SQL Servers.

Local consistency is usually sufficient to allow recovery from asingle-point media failure. For example, in the case of a disk failure,it is probable that a database or transaction log could be backed up,


The master and gdnavdb Databases Sybase MPP Release 11.0.x

the disk replaced, and the data or transaction log restored withoutany loss of data.

Local consistency is not usually sufficient to provide coverage fordisaster recovery.

◆ WARNING!Local consistency is generally acceptable only for recovery fromsingle-point failures, such as a disk failing. If, for example, twodatabase devices, each containing a partition of the same database,fail simultaneously, although the data from the last backup may berestored, the possibility exists that a distributed update to bothpartitions was only backed up in one of the partitions. This creates aninconsistency in the database.

Database Consistency and Concurrency During Restore

Data can be restored from a global backup or a local backup, but therestore operation itself is local. If you are restoring an entire databaseand the restore fails on one SQL Server, the restore continues on theother servers.

The master and gdnavdb Databases

It is particularly important to back up the master and gdnavdbdatabases regularly. The gdnavdb database contains the globaldirectory.

The dump and load commands for these two databases are describedhere. You can also select the databases and commands from theBackup and Restore menus.

For more general information about the dump and load commands, see“Command Line Interface” on page 6-18.

Backing up master

The master database backup follows the syntax and conventions forthe dump command described earlier in this section. Backups of theentire master database are especially critical after commands such ascreate database, alter database, and disk init are issued. Also, when the


Sybase MPP Release 11.0.x The master and gdnavdb Databases

system procedure sp_addumpdevice is executed, master should bebacked up. Since sp_addumpdevice updates the master database on theSchema Server and the specific SQL Server, only the local masterdatabase on the SQL Server needs to be backed up.

You can back up the master database of all SQL Servers within SybaseMPP with the command line request:

dump database master to navtape_dumpdevice

or

dump database master to navdisk_dumpdevice

To back up the master database of a specific SQL Server, see “BackupDevice Administration” on page 6-4. The dump command is directedto a specific SQL Server or a specific dump device by the _dumpdeviceparameter extension in Sybase MPP.

Restoring master

Restoring the master database can frequently mean recovering it. Theprocedure to recover a damaged master database is different than therecovery of user databases. The inability to start the SQL Serverbecause of segmentation faults, input/output errors, or a dbcc reportindicates that the master database is damaged.

In Sybase MPP, the master database is restored one SQL Server at atime. Complete instructions to recover the master database are foundin the SQL Server System Administration Guide.

Backing up gdnavdb

The gdnavdb database resides with the Schema Server that maintainsSybase MPP information. It requires regular backups. The gdnavdb isthe Sybase MPP global directory; the Sybase MPP gdnavdb databasecorresponds to the SQL Server master database.

Back up the gdnavdb database whenever a dump request is executed.Tables are modified in gdnavdb during the Backup and Restoreprocess.

To back up gdnavdb, use one of the following command line requests:

dump database gdnavdb to navtape_dumpdevice

dump database gdnavdb to navdisk_dumpdevice

dump transaction gdnavdb to navtape_dumpdevice


Command Line Interface Sybase MPP Release 11.0.x

Restoring gdnavdb

The gdnavdb database is the global directory. Backup and Restoreuses information in the gdnavdb database to automatically drive therestoration process. This information shows which volumes are to berestored and in which order they should be restored on the variousSQL Servers. Therefore, when the gdnavdb requires restoration, itmust be presumed that the running version is invalid and cannot beused to drive the restore process of gdnavdb.

In the event that the gdnavdb database requires restoration from aprevious backup request, special handling is needed. This needcould arise from software errors within the gdnavdb database itself.To restore the gdnavdb database from tape media, do the following:

1. Retrieve the last successfully completed backup of the gdnavdbdatabase. To determine which set of volumes contain the lastsuccessful backup, review the REELlibrarian volume set list forthe latest entry with the “gd” prefix.

2. Use isql to log on to the Schema Server and perform ansp_addumpdevice, if necessary.

3. Initiate the Sybase Console Program on the same node as theSchema Server.

4. Submit the following command line request, where dump_deviceis the name of the dump device:

load database gdnavdb from dump_device

5. Respond manually to the Sybase Console Program prompts tomount successive volumes until the load process completes.

Command Line Interface

In addition to the Backup and Restore application, Sybase MPPsupports backup and restoration of databases through the use of theTransact-SQL commands dump and load.

This command line interface allows you to:

• Save the administrative cost associated with backing up multiplepartitions

• Support the database consistency options that simplify datarecovery


Sybase MPP Release 11.0.x Command Line Interface

The following sections describe the Backup and Restore storedprocedures, the dump command syntax, and the load commandsyntax, in the Sybase MPP system.

The dump Command and Sybase MPP

The primary difference between the dump command in SQL Serverand in Sybase MPP is the use and meaning of the dump device. See“Backup and Restore Administration” on page 6-4 for informationabout the dump device.

In Sybase MPP, the dump command enables you to protect criticalinformation on your system from failure and disaster. By requestinga backup of the databases, the database definition and any changesto the definition are established. Once the base point has beencreated, you must initiate a regular backup schedule, using the dumpdatabase and/or dump transaction commands. If an unlogged operationis performed against the database (for example, dump transaction withno_log) you should request a backup immediately afterward.

In the Sybase MPP system, a database partition is the smallest unit ofbackup. The partition of the database is a subset of the entiredatabase, but is considered a complete database within the partitionand can be backed up.

There are two varieties of the dump command for backing updatabase information:

• The dump database command in Sybase MPP backs up an entiredatabase, including the system logs, user-defined tables,transaction log, the auxiliary database on the Schema Server, andall SQL Servers that are home to the database.

• The dump transaction command backs up only the transactionhistory of updates to the database since the last backup request.This type of backup usually requires less time than a full databasebackup request and provides a method for performingincremental backups. However, a transaction log backup must bepreceded by one complete database backup to be valid.

dump database

The syntax of the dump database command is:

dump database database_name to dump_device



The database_name is the name of the database to be backed up. Thedump_device specifies where to store the information. Thedump_device parameter includes semantic extensions indicatingwhether the entire database or a partition of the database is to bebacked up. It is discussed in detail in “Backup and RestoreAdministration” on page 6-4.

The dump database request backs up the entire database or databasepartition in a format that can be read only by the load databasecommand. A checkpoint is issued internally and all completedtransactions are forced out of memory.

In Sybase MPP, when the consistency option is set to “global,” at thetime Backup and Restore issues the dump database request for a specificSQL Server:

• Each database partition is checkpointed.

• All updates are halted until all servers have started to back up.

Then, the dump database request captures an exact image of thedatabase.

If consistency is set to “local,” Backup and Restore does not performa checkpoint across all servers, thus allowing concurrent access tothe database. The consistent image of the database is maintained atthe SQL Server level, not at the Sybase MPP level. See “LocalConsistency” on page 6-15 for more information.

Here are some examples of the dump database command in SybaseMPP:

dump database purchasing to navtape_dumpdevice

dump database purchasing to navdisk_dumpdevice

dump database purchasing to Q0150001_ANY

dump database purchasing to Q0150001_8MM01

dump transaction

The syntax of the dump transaction command is:

dump transaction database_name [to dump_device ][with truncate_only | with no_log | withno_truncate]

The database_name is the name of the database to be backed up; thedump_device specifies where to store the information. Thedump_device parameter includes semantic extensions indicatingwhether the entire log or the log of a partition is to be backed up,



which is discussed in detail in “Backup and Restore Administration”on page 6-4. Also see dump transaction in the SQL Server CommandsReference Manual.

The dump transaction request for a database is usually submitted morefrequently than the dump database request. For example, dumptransaction may be performed once each day to clear transaction logsand allow concurrent database access. Then, dump database can beperformed once each week to preserve a globally consistent image.

As with SQL Server, dump transaction can be issued only when the dataand the transaction log reside on separate devices. In Sybase MPP, ifyou are using the dump transaction command, each database partitionmust have separate data and transaction log devices.

Here are some examples of the dump transaction command in SybaseMPP:

dump transaction purchasing to navdisk_dumpdevice

dump transaction purchasing to Q0150001_navdisk

dump transaction purchasing to Q0150001_ANY

The load Command and Sybase MPP

As with the dump command, the Backup and Restore utility extendsthe usage and meaning of the dump_device parameter for the loadcommand in Sybase MPP. The load command manages therestoration of multiple SQL Servers.

➤ NoteLoading a database that is not user-owned requires a different command

line request. Two databases that need to be restored with this special

handling are the master and gdnavdb databases. See “Restoring master”

on page 6-17 and “Restoring gdnavdb” on page 6-18.

The load command retrieves the last complete backup that wasperformed against the database.

The restore process uses this information to direct the mounting andunmounting of the backup volumes to the correct databasepartitions, in the correct order. The load command performs thisfunction for both disk and tape media.

There are two varieties of the load command for restoring databaseinformation:



• The load database command in Sybase MPP is used to restore datafor an entire database, or to selected database partitions that havesuffered data loss or corruption. When you use load database thesystem logs, user-defined tables, transaction log, the databasepartition on the Schema Server, and all SQL Servers that are hometo the database are restored for the specified servers.

• Use load transaction to manually apply transaction logs to adatabase. The only time you are required to invoke load transactionis when the Backup and Restore gd_set_dbrf_defaults procedureparameter, load_option, is set to “manual.” When load_option is setto “automatic,” Backup and Restore performs the load database,and automatically performs the associated load transaction request.

The load transaction command is executed with the load databasecommand for the same database and restores the transaction logs inthe correct sequence.

load database

The syntax of the load database command is:

load database database_name from dump_device

database_name is the name of the database to be restored. Thedump_device specifies where to retrieve the information from. Thedump_device parameter includes semantic extensions indicatingwhether the entire database or a partition of the database is to bebacked up. See “Backup and Restore Administration” on page 6-4 fora complete discussion on dump device use and administration.

The gd_set_dbrf_defaults system procedure defines specific Backup andRestore parameters, and consistency and restore options. See“gd_set_dbrf_defaults” on page 6-39 and “Database Consistencyand Concurrency During Backup” on page 6-14.

If the consistency value is “global” for the database, the load databasecommand restores the last global backup. This is ignored if therestore is for a SQL Server.

If the consistency value is “local” for the database, the load databasecommand restores the last complete backup, which may or may nothave been global.

If the load_option value is “automatic,” Backup and Restoreautomatically initiates the load transaction commands for the databaseat the completion of the load database command. If the load_optionvalue is “manual,” you must manually invoke load transaction uponthe completion of load database. All associated dump transaction



commands are then applied. If the transaction logs for a specificdatabase partition need to be restored, use Backup and Restore. Youcan do this from the command line but it will restore all transactionlogs for that server. If you want to restore only some transaction logsfor a server, then you have to use Sybase MPPM’s Backup andRestore tool.

The load database command applies to user databases only. See “Themaster and gdnavdb Databases” on page 6-16 for information aboutrestoring other databases.

During the processing of the load database command in Sybase MPP,the database cannot be accessed for modification. However, otherdatabases are not affected. When the process is complete, the state ofthe database is dependent upon the consistency value that was setfor the database at the time the backup database request wasexecuted.

If the consistency value was “global,” the database image isconsistent across all Sybase MPP SQL Servers. If the consistencyvalue was “local,” only the data within each SQL Server may beconsistent. It is possible that the restored image of the databasecontains information in some SQL Servers that was updated duringthe backup of other Sybase MPP SQL Servers. See “DatabaseConsistency and Concurrency During Backup” on page 6-14.

To ensure that the database consistency setting for the restoreddatabase is the desired value, use the gd_set_dbrf_defaults procedurebefore you execute load database.

For example, to execute the load database command for the purchasingdatabase, you could request the following:

gd_set_dbrf_defaults “purchasing”, 3,2,2,3,3,“mpp”

load database purchasing from navtape_dumpdevice

The parameters for gd_set_dbrf_defaults are explained in the section“gd_set_dbrf_defaults” on page 6-39.

load transaction

The syntax of the load transaction command is:

load transaction database_name from dump_device

database_name is the name of the database of the transaction log thatis to be restored. The dump_device specifies where to retrieve theinformation from. The dump_device parameter includes semantic


Backup Strategies Sybase MPP Release 11.0.x

extensions indicating whether the entire database or a partition ofthe database is to be backed up. See “Backup and RestoreAdministration” on page 6-4 for a complete discussion on dumpdevice use and administration.

➤ NoteUse this command only when the load_option parameter of the

gd_set_dbrf_defaults procedure is set to “manual.”

Perform the load transaction command after the database has beenrestored using the load database command from a backup created withthe dump database command.

Loading the transaction log differs from restoring the databasebecause the data is not explicitly restored. Instead, committedtransactions are applied. Any uncommitted transactions are rolledback.

When you issue the load transaction command, it retrieves the first dumptransaction that was performed against the database following the lastcomplete backup of the database. Information about each backup isstored and maintained in the global directory. The load transactionrequest uses this information to reapply the transactions. The firsttransaction backup and each successive backup is restoredautomatically by Backup and Restore.

Since transaction logs for each partition may not always be backedup at the same time, there is the possibility that if the partitions arenot restored in the same order in which they were backed up, theconsistency of the database may not be maintained.

Backup Strategies

The following sections describe the backup and restore tools you useto customize your data backup strategies.

One of the most important concepts for backup and restoration in theSybase MPP is that of global and local consistency. See “DatabaseConsistency and Concurrency During Backup” on page 6-14 forinformation about global and local consistency.


Sybase MPP Release 11.0.x Backup Strategies

Backup Protection from Media Failure

Maintain the database and transaction logs on separate devices foreach database partition to protect against media failure. In a backupstrategy that includes backups of both the database and itstransaction logs, using separate devices prevents loss of both thedatabase and transaction logs should one of the devices fail. You maychoose settings of either “global” or “local” consistency for yourdatabase and transaction log backups. See the discussion below tohelp decide which is the best choice for your situation.

Example Backup Strategy

This backup strategy protects against media failure.

• Position the data and transaction logs of each database partitionon separate devices.

• Perform weekly database backups.

• Perform periodic transaction log backups.

Consider the following when you decide whether to set consistencyto “global” or “local.”

Global Consistency

If you set consistency to “global”:

• A backup instance across all SQL Servers of the database ensuresthat a globally consistent image of the database can be recovered.

• The same backup image can be used for recovery from anapplication and/or site failure.

However, the “global” consistency setting has disadvantages. If anybackup request to a SQL Server fails, you must restart the entirebackup. Also, database updates are delayed until all SQL Servershave initiated the dump command; this diminishes performance forusers who are accessing the database concurrently.

Local Consistency

If you set consistency to ”local,” you gain the following advantages:

• If a backup request to a SQL Server fails, only the SQL Server thatfailed needs to be restarted.

• Concurrent access to the database is allowed during the entirebackup.


Backup Strategies Sybase MPP Release 11.0.x

However, the disadvantage to “local” consistency is that, if updatesoccur during a backup, manual recovery may be required toreestablish a consistent image of the database across all SQL Serversat a known point in time.

Backup Protection from Application Errors

You can protect the database system from application errors byimplementing a backup schedule that consists of globally consistentbackups. Applications that update the database can cause an error. Inturn, these updates can potentially be propagated across multipleSQL Servers in the Sybase MPP environment. If an application erroroccurs, a consistency option setting of “global” ensures that you canrestore a consistent image of the database.

You can use a single database backup or a combination of a databasebackup and transaction log backups, all set to “global” consistency.

Local consistency is not recommended for database environmentswhere distributed transaction updates occur.


This backup strategy protects against data loss from applicationerrors.

• Place the data and transaction logs of each database partition onseparate devices.

• Perform weekly database backups, setting the consistency optionto “global.”

• Perform periodic transaction log backups, setting the consistencyoption to “global.”

• Perform regular database backups during application testing anddeployment, setting the consistency option to “global.”

Backup Protection from Site Failure

Protecting your database system from disasters is one of the mostcommon reasons for backup. Since you cannot know when such asituation will arise, a regular backup schedule of globally consistentbackups is the best prevention against irretrievable loss.


Sybase MPP Release 11.0.x Backup Strategies


This backup strategy protects against data loss from site failures.

• Place the data and transaction logs of each database partition onseparate devices.

• Perform weekly database backups, setting the consistency optionto “global.”

• Perform periodic transaction log backups, setting the consistencyoption to “global.”

• Store backup images in an off-site location.

The following section presents a simple example environment todemonstrate a backup strategy. Refer also to the SQL Server SystemAdministration Guide for further information on backup strategies.

Sample Configuration

This sample configuration is:

• Three SQL Servers.

• Database A is partitioned across all three SQL Servers. (The tablescan be schema, range, or hash partitioned.)

• The transaction log of each partition of the database is on adifferent device than the actual data. (A single disk failure wouldaffect only the database or the transaction log, not both.)

• No disk arrays or mirroring.

• The backup consistency has been maintained at globalconsistency.

Case One

The database device for Database A on Partition 1 fails. The followingsteps can be taken to recover successfully:

1. Disable Partition 1 of Database A. This eliminates distributedupdates from occurring on it during recovery.

2. Immediately back up the transaction log of Database A onPartition 1. No data is lost.

3. Replace the database device.


Backing Up to Tape Sybase MPP Release 11.0.x

4. Restore the globally consistent database for Partition 1 ofDatabase A. See “Database Consistency and Concurrency DuringBackup” on page 6-14.

5. Restore the transaction logs for Partition 1 of Database A.

6. Reenable Partition 1 of Database A. This allows distributedupdates to occur on Partition 1.

Case Two

The transaction log device of Database A on Partition 1 fails.

Partition 1 is now disabled because the SQL Server does not allowupdates to the database to occur when the transaction log is down.Perform the following steps to recover successfully:

1. Immediately back up Partition 1 of Database A. No data is lost.

2. Replace the disk device for the transaction log.

3. The SQL Server reenables Partition 1 of Database A. This allowsdistributed updates to occur on Partition 1.

Case Three

Both the database device and transaction log device fail. In thisscenario, some data has been lost. Either the latest data backup or thelast backup of the database partition, whichever is the latest, is notrecoverable. To recover from this situation, you can follow thesesteps:

1. Restore the globally consistent database for all of Database A. See“Database Consistency and Concurrency During Backup” onpage 6-14.

2. Restore all of the transaction logs for all partitions of Database A.

Backing Up to Tape

Backup strategies that specify tape devices require at least one tapedrive attached to each node. The optimum performanceconfiguration for tape devices associates one tape drive with eachSQL Server in the Sybase MPP system. In multi-node systems, theparallelization capabilities of Sybase MPP are extended to the dumpand load commands, thus processing each database in parallel.Optimum parallelization occurs when the ratio of SQL Servers totape devices is one to one.


Sybase MPP Release 11.0.x Backing Up to Tape

Examples of supported tape devices include:

• Exabyte High Density

• 8-mm Exabyte cartridge

• StorageTek 4220 tape subsystem (3480 compatible)

• StorageTek Tape silo

Using the Tape Management System

The Backup and Restore utility uses the REELlibrarian TapeManagement System when you perform backup and restoreoperations to tape. It organizes and centralizes tape managementand administration of tape volumes and devices.

Sybase MPP is connected to the REELlibrarian operator console viaTCP/IP. The console provides the primary interface to the librarianadministration software. All interaction with the tape managementfunctions, including all dump and load mount requests, are centralizedon this console, and are performed and validated by the tapeoperator. The client portion of the tape management system isinstalled on each node. The server portion and user interface areinstalled on the tape operator’s console.

See your REELlibrarian documentation, specifically theREELlibrarian Master Guide, for administration and configurationinformation.

Coordination between the backup and restore operations andREELlibrarian requires an understanding of these REELlibrarianconcepts: pools, volume sets, and ADNs.

• Pools are groups of tape volumes from which a requester obtainstapes to mount on a particular drive. Each tape volume in a poolhas a volume ID. If a tape is not in use, it is designated as a scratchvolume.

• Volume sets are groups of tapes used to store information that canspan more than a single volume. Volumes that make up a volumeset are drawn from the same pool. REELlibrarian obtains scratchvolumes from the pool as the requestor fills up tape volumes.There is only one volume (tape) per volume set in the SybaseMPP environment.

• ADNs are logical device names that REELlibrarian associateswith physical device names for identification.


Backing Up to Tape Sybase MPP Release 11.0.x

Sybase MPP requires that one or more volume pools be created. TheBackup and Restore utility allows the volume pool to be matched toa specific database.

Once the volume pool is defined in the Tape Management System,you specify which volume pool to use when backing up a specificdatabase. When defining database settings with the backup andrestore stored procedure, gd_set_dbrf_defaults, you can specify the TapeManagement System volume pool as one of the arguments. You cando this by:

• Using the Backup and Restore Administration→Settings menuoption.

• Running the gd_set_dbrf_defaults system procedure using eitherSybase MPPM’s SP_ tool or isql.

For additional information, see the following:

- “Stored Procedures for the Command Line Interface” on page6-38

- The Sybase MPP Manager User’s Guide

- The REELlibrarian documentation

- Chapter 9, “Using REELlibrarian with Sybase MPP”

The volume pools should be stocked with a sufficient number ofscratch volumes to handle regularly scheduled dump and loadoperations. Use REELlibrarian to stock these scratch volumes.During a backup, the Tape Management System supplies tapes fromthe volume set to satisfy the tape volume requirements of thedatabase. As Backup and Restore performs the backup andpopulates tape volumes, Sybase MPP follows a volume set namingconvention that allows the tape administrator to identify the tapes asbelonging to the same backup operation. The volume set names usedin the backup are recorded in the backup history.

The naming convention for tape volumes in REELlibrarian is thesame convention used for any tape management system in SybaseMPP.

Chapter 9, “Using REELlibrarian with Sybase MPP,” for moreinformation on using REELlibrarian.


Sybase MPP Release 11.0.x Error Handling and Recovery

Error Handling and Recovery

Backup and Restore provides different levels of error reporting,exception handling, and error recovery for both internal and externalcomponents.

In a system failure, if the system is shut down or crashes during abackup or restore operation, the Backup and Restore utility is haltedprematurely without the chance to report, handle, or recover fromthe failure. Because Backup and Restore maintains information inother Sybase MPP components, the recovery that would usually takeplace during exception handling is managed during Sybase MPPstart-up.

Graphical User Interface vs. Command Line Requests

Using command line requests is supported, yet the Backup andRestore utility shields the Sybase MPP database systemadministrator from the complexities of backing up a paralleldatabase that resides on one or more nodes.

The Backup and Restore utility is based on the Transact-SQL dumpand load commands. You can invoke these commands from the isqlutility. This command line support allows you to back up or restore adatabase, regardless of the size or number of partitions, using only asingle command line request.

Advantages of Using Sybase MPPM

Command line requests have inherent complexities in a parallelsystem. Using the Backup and Restore icon from within SybaseMPPM simplifies these complexities by presenting the databaseinformation clearly.

Rather than memorizing a command line syntax, you can select froma list of commands.

In addition to explicit options, the graphical interface provides aquick method of recovering previously saved data. You can displaya complete backup history of the Sybase MPP system, whichincludes all backup requests. Using this information, you can restorethe entire backup image or only selected partitions.

The monitoring capability allows you to determine the progress ofcurrent backup or restore operations. At a glance, you can notebackup completion time, or whether a device requires attention.



You can make configuration changes specific to backup and restoreoperations from the interface. For example, you can use SybaseMPPM’s SP_ tool to add or drop dump devices for specific SQLServers within Sybase MPP, and set system-wide defaults, such asbackup consistency parameters. See the Sybase MPP Manager User’sGuide for information on using the SP_ tool.

Using the Command Line Interface

Databases can be backed up on a system-wide or an individualserver basis. In a system-wide restore, the load database and loadtransaction commands use global directory information to conduct theoperation. If this information is removed from the global directory(typically via Sybase MPPM), the restore must be performed at theindividual SQL Server level.

Backup and Restore always selects the most recent backup or set oflogs referenced in the command-line syntax. If there is a problemwith the selected backup or logs (for example, duplicate devicenames or missing drives or tapes), the operation fails.

Following are examples of restoring databases and transactions logsboth system-wide and on single servers.

Restoring an Entire Database

For system-wide restores, you must indicate the type of media to use.The system selects the most recent backup or set of logs on thespecified type of media; this might not be the latest available data.

This example loads the most recent backup of db_name from the typeof device specified, either disk or tape.

load database db_name from {navdisk_dumpdevice |navtape_dumpdevice}

If navdisk_dumpdevice is specified, the backup disk devices are used. Ifyou use navdisk_dumpdevice, you cannot restore a database backupfrom disk files that have different logical device names from the filesto which the backup was originally done. If the backup files werecopied to tape, they must be returned to files configured with theexact logical device names used at the time of the backup. To usedifferent logical disk file names, see “Restoring a Database on aSingle Server” on page 6-34.

If navtape_dumpdevice is specified, the example restores the most recentbackup of the database available on the tape devices that were used



for the backup, if they are still configured on the system. Otherwise,it uses the first defined tape device that matches the default type inthe gd_dbrf_defaults table.

Using the Auto Load Option

If the Backup and Restore Load Option is set to automatic, anysubsequent transaction logs up to the next complete databasebackup are also restored, if they were created on the same type ofmedia (tape or disk) as the backup that is being restored. If theBackup and Restore Load Option is set to manual, you need tomanually issue the load transaction command.

For example, if the following backups have occurred:

• x data to navtape on 9/1

• x tran to navtape on 9/2


• x data to navdisk on 9/4



and navtape_dumpdevice was specified, the 9/1 backup and the 9/2,9/3, 9/4, and 9/5 transaction logs are restored.

The restore process cannot switch between media types (tape to diskor disk to tape). The restore progresses until the media type changes.

In the above example, if navdisk_dumpdevice was specified, the 9/4backup would be restored, but the 9/5 and 9/6 transaction logswould not due to the switch in media type. You cannot use thecommand-line interface to restore the transaction logs created on 9/5and 9/6. You can use Sybase MPPM, however, since it allows you tochange the media type.

Restoring All of a Database’s Transaction Logs

load transaction db_name from {navdisk_dumpdevice |navtape_dumpdevice}

In this example, the system looks for the most recent backup ofdb_name to the type of device specified, either disk or tape. It thenrestores any subsequent transaction logs backed up on the samemedia type.



If navdisk_dumpdevice is specified, the system is able to restore the logsas long as all of the disk files have different physical names at theindividual server level. If a Schema or SQL Server encounters logswith duplicate file names, the restore for one of the files fails with asequencing error, and the process on that server terminates. Therestore operations underway on other servers are not affected.

With the navdisk_dumpdevice command, you cannot restore a set oftransaction logs from disk files having different logical device namesfrom the files to which the backups were originally done. If the logswere copied to tape, they must be returned to files configured withthe exact logical device names used at the time of the backups.

From Sybase MPPM, however, transaction logs can be restored fromlogical device names that are different than those used when the logswere created.

If navtape_dumpdevice is specified, Backup and Restore uses the samebackup tape device for the restore, if it is still configured on thesystem. If the same device is not available, it uses the first defineddevice that has the same tape type as the backup device.

Restoring a Database on a Single Server

This example restores a database partition residing on a SQL Server.Individual partitions might need to be restored if a SQL Server failsand a database partition is rendered inaccessible.

In the second command, the server name ends in a “2,” indicatingthat the operation is to be run from the server’s alternate location,using devices available on that machine. If no such device wasconfigured from a DBA or Control Server, the command fails.

load database db_name fromservername_ {ANY | devicename }

or

load database db_name fromservername 2_{ANY | devicename }

This operation ignores the default backup media and default tapetype settings, because the device name is specified on the commandline.

If servername_ANY is specified, the example restores the most recentbackup of db_name from servername back onto servername. The mediatype used for the restoration depends on what was used for thebackup.



If servername_devicename is specified, the example restores db_name’smost recent backup from the device type (disk or tape) specified withservername_devicename back onto servername.

Using the Auto Load Option

When the Backup and Restore Load Option is set to automatic, thetransaction logs are restored after the database, depending on themedia type and whether “_ANY” or a specific device was selected:

• If “_ANY” is specified and a disk backup is being restored

The selected logs are restored onto servername from their originaldisk files. If multiple log backups were done to a single diskdevice on servername, the log restores fail because of sequencingproblems.

• If “_ANY” is specified and a tape backup is being restored

The subsequent transaction logs backed up on servername to anytype of tape are restored. Backup and Restore uses the samebackup tape devices for the restore if they are still configured onthe system. If they are not available, Backup and Restore uses thefirst defined device of the same tape type as the backup device.

• If a disk device name is specified

The system attempts to restore subsequent transaction logscreated on disk. The attempt fails because the system attempts torestore all the logs from the same disk file just used to restore thedatabase backup.

• If a tape device name is specified

Subsequent transaction logs backed up on servername on anytype of tape are restored. If the type of tape used in the backup isdifferent from the tape type specified by devicename, theoperation fails.

Restoring Database Transaction Logs for a Single Server

This example restores transaction logs for a database partitionresiding on a SQL Server. The system looks for the most recentbackup of db_name to the type of device specified, either disk or tape.It then selects the subsequent transaction logs backed up to the samemedia type.

In the second command, the server name ends in a “2,” indicatingthat the operation is to be run from the server’s alternate location,



using devices available on that machine. If no such device wasconfigured from a DBA or Control Server, the command fails.

load transaction db_name fromservername_ {ANY | devicename }

or

load transaction db_name fromservername 2_{ANY | devicename }

This operation ignores the default backup media and default tapetype settings, because the device name is specified on the commandline.

If servername_ANY is specified, the system looks for the most recentbackup of db_name performed on servername and then locates thesubsequent transaction logs. The command fails if the transactionlogs reside on media different than the media used for the databasebackup.

For disk backups, the specific file names used in the backup of thetransaction logs are used for the restore. The logs are restored intoservername from their original disk files. If multiple log backups weredone to a single disk device on servername, the log restores failbecause of sequencing problems.

For tape backups, the transaction logs backed up on servername toany type of tape are restored. If navtape_dumpdevice is specified,Backup and Restore uses the same backup tape device for the restore,if it is still configured on the system. If the same device is notavailable, it uses the first defined device that has the same tape typeas the backup tape device used.

If a disk device is specified with devicename, this command functionsproperly when only a single log backup was performed since themost recent disk database backup. If there are multiple log backups,the command fails due to sequencing problems.

If devicename is a tape device, the transaction logs backed up onservername to any type of tape are restored. If any backup tape typediffers from the _devicename tape type, the command fails. If it fails,you may be able to use Sybase MPPM’s Backup and Restore utility torestore the transaction logs. See the Sybase MPP Manager User’s Guidefor more information.


Sybase MPP Release 11.0.x Backup and Restore Error Logs

Backup and Restore Error Logs

Backup and Restore uses Sybase MPP logging to assist in debugging.The following logs are maintained:

• System Error Log – Contains critical errors.

• Supplemental Error Log – Contains all errors encountered byBackup and Restore when its logging flags are toggled on.Certain events, such as the start and completion of a backup, arelogged unconditionally. The Supplemental Error Log functions asan audit trail of all backups and restores performed.

The supplemental error log also contains the Entry/Exit logentries when logging flags are toggled on. These are the entryand exit points of all backup and restore routines, and specifictrace messages.

Error Messages

Error status settings are maintained for each backup request, eachSQL Server partition involved in a backup, and each tape volumethat is allocated for a backup.

Error status information for backup and restore requests aremaintained in the backup_status and restore_status fields of thefollowing tables:

• gd_dbrf_db_info

• gd_dbrf_sql_server_info

• gd_dbrf_device_info

The error ranges are:

• 100–299, non-fatal error affecting an entire backup or restorerequest

• 300–499, fatal error affecting an entire backup request

• 500–699, non-fatal error affecting a single SQL Server backup orrestore request

• 700–899, fatal error affecting a single SQL Server backup orrestore request

• 900–1099, non-fatal error affecting a single tape device

• 1100–1299, fatal error affecting a single tape device


Stored Procedures for the Command Line Interface Sybase MPP Release 11.0.x

Stored Procedures for the Command Line Interface

This section documents the stored procedures that are provided tosimplify backup and restore administration from the Transact-SQLcommand line interface. They allow you to set database backupparameters, review the default database backup parameters, reportinformation on requests in progress, report and change backup andrestore history.

To access these stored procedures, you must be logged on directly tothe DBA Server, Control Server, or Schema Server. These storedprocedures are maintained by the gdnavdb database:

The stored procedures include:

Stored Procedure Description

gd_set_dbrf_defaults Sets the default dump and load parameters for adatabase. See “Database Settings” on page 6-13.

gd_get_dbrf_defaults Reports information on the default dump and loadparameters for a database.

gd_return_dump_id Removes a load ID and its associated informationfrom Backup and Restore history.


Sybase MPP Release 11.0.x gd_set_dbrf_defaults

gd_set_dbrf_defaults

Function

This stored procedure is used to define the default parameters usedduring a backup or restore operation for each database.

Syntax

gd_set_dbrf_defaults db_name, consistency_option ,aging, load_option , default_dump_media ,default_tape_type , pool_name

Parameters

All parameters are required.

db_name – The name of the database for which the defaults are beingdefined. Only the database system administrator or the databaseowner can set the information for this database. The nav_defaultstable contains the system defaults that are used for any databasethat does not have its default settings identified.

consistency_option – The options are 1 (local consistency) and 3(global consistency). Local consistency is the default value inSybase MPP. See “Database Consistency and ConcurrencyDuring Backup” on page 6-14.

aging – The options are 1, 2, 3 and so on. The default is 2.

This setting indicates when the record of a database backupshould be aged out of Sybase MPP history. If, for example, youspecify 1 as the value for aging, the next time a backup of thedatabase is made, the record of the previous backup is purgedfrom the system.

load_option – The options are 1 (manual) and 2 (automatic). Thedefault is manual.

When you specify the manual option, you must enter the loadtransaction command following a load database command to restorethe database to a current point. The automatic setting uses thehistory of all previous backups that is maintained by the Backupand Restore utility, to automatically restores any subsequenttransaction backups after you restore a database.

default_dump_media – The options are 2 (disk) and 3 (tape). Thedefault is tape.


gd_set_dbrf_defaults Sybase MPP Release 11.0.x

This default setting is used whenever a backup or restore requestis made specifying a SQL Server in the dump device parameteron the command line. This information is required to directBackup and Restore to use the appropriate dump device media.

default_tape_type – The available options are 2 (8-mm Exabyte), 3(4220 StorageTek tape silo, 3480 compatible), and 10 (8-mmExabyte High Density). The default is 2, 8-mm Exabyte.

This default setting is used whenever a backup or restore requestis made that uses the navtape_dumpdevice as a dump device. Thisis required by Backup and Restore so that it can request theappropriate device type from the Tape Management System.

pool_name – Specifies the tape management system volume poolfrom which volumes are allocated to process backup requests forthis database. The default is “mpp.”

Example

gd_set_dbrf_defaults "purchasing", 3, 2, 2, 3, 3,"mpp"

This example defines:

• The default backup environment for the purchasing database.

• Dumps are processed with global consistency.

• Two backups are stored at any one time in the backup history.

• The load_option is set to automatic, so that the appropriate loadtransaction commands are run after you issue a load databasecommand.

• If you request the backup or restore of a specific SQL Server, thisbackup environment specifies that tape is the media to be used.

• If the navtape_dumpdevice is specified, the tape type requested byBackup and Restore is 3480 StorageTek.

• The tape volumes required to process the request are allocatedfrom the “mpp” volume pool in the tape management system.

Messages

(1) The specified database name is null

(12) No database with the specified name exists.

(2) Valid selections for consistency_option are 1(local) and 3 (global)


Sybase MPP Release 11.0.x gd_set_dbrf_defaults

(4) Valid selections for load_option are 1 (manual) and2 (automatic)

(5) Valid selections for default_dump_media are 2 (disk)and 3 (tape)

(6) Valid selections for default_tape_type are 2 (8MM),3 (3480), and 10 (XBYTEHD)

(7) The specified poolname is null

Table Used

gd_dbrf_defaults


gd_get_dbrf_defaults Sybase MPP Release 11.0.x

gd_get_dbrf_defaults

Function

This stored procedure is used to display backup history informationof completed backup and restore requests or in-progress backup andrestore activity of Backup and Restore. For in-progress backup andrestore requests, this stored procedure provides a snapshot of allcurrently active requests. You can also choose to display a history ofall completed backup and restore requests.

Syntax

gd_get_dbrf_info status

Parameters

status – The type of report to be obtained from the backup History.The options are 1 (monitor) and 3 (history). The default is history.

If you specify history, the report contains information on allcompleted backup and restore requests. If you specify monitor,the report contains a snapshot of all in-progress backup andrestore requests.

Example

gd_get_dbrf_info 1

The above example provides a report on all current backup andrestore requests.

Messages

(1) Valid selections for the status option are 1(monitor) and 3(history)

Table Used

gd_dbrf_db_info


Sybase MPP Release 11.0.x gd_return_dump_id

gd_return_dump_id

Function

This stored procedure is used by the system administrator or thedatabase owner to remove the information about a backup from theBackup and Restore history table. When this stored procedure isinvoked, all information pertaining to the specified dump ID ispurged from the Sybase MPP history table.

Syntax

gd_return_dump_id dumpid

Parameters

dumpid – The unique dump ID for the specific backup that is to bedeleted from the Backup history table.

Messages

(1) 0 is not a valid dump ID

(49) No such dump ID exists

Tables Used

gd_dbrf_db_info, gd_dbrf_sql_server_info, gd_dbrf_device_info

Comments

Be certain you want to delete the information about a backup beforeusing this stored procedure. Once the information about a backuphas been removed from the backup history of Sybase MPP, there is noautomatic restore capability.


gd_return_dump_id Sybase MPP Release 11.0.x


7 Using Transact-SQL and SystemProcedures 7.

This chapter describes differences in behavior in the standalone SQLServer and Sybase MPP environments for Transact-SQL, systemprocedures, system tables, and transaction management.


• SQL Server 9.1-MPP 7-1

• Transact-SQL Implementation in Sybase MPP 7-1

• System Procedures 7-15

• System Tables 7-19

• Transactions 7-19

SQL Server 9.1-MPP

Sybase MPP uses SQL Server release 4.9.1 with specialenhancements. This special release for Sybase MPP is called SQLServer 9.1-mpp. Functionally, release SQL Server 9.1-mpp isequivalent to release 4.9.1; however, it differs in two areas:

• Functional restrictions or deviations that are not supported inSybase MPP. These are described in the following sections.

• SQL Server 9.1-mpp does not contain all corrections (bug fixes)included in 4.9.1. If you need one of these corrections, pleasecontact your Sybase MPP Technical Support Specialist.

Transact-SQL Implementation in Sybase MPP

This section describes the specific implementation of SQL andTransact-SQL commands in Sybase MPP.

Sybase MPP provides a nearly complete set of Transact-SQLcommands as supported by SQL Server 9.1-mpp. The following listidentifies Transact-SQL commands which are currently unsupportedon Sybase MPP:

• readtext

• save transaction

• writetext

• views defined with aggregates, group by, or subqueries

7-2 Using Transact-SQL and System Procedures

Transact-SQL Implementation in Sybase MPP Sybase MPP Release 11.0.x

➤ NoteUnsupported commands caught by the SQL compiler return error number

14408.

The remaining Transact-SQL commands are supported in SybaseMPP with certain restrictions. The following section describes someof these restrictions.

Data Definition Language (DDL)

alter database

This command cannot be used to extend a database to new SQLServers. Use the system procedure sp_extenddb to add SQL Servers toa database. See “Extending Databases” on page 4-5.

create database

You cannot specify a log device on a different server than thedatabase device is on. For example, a database created on datadevice Q0150002_dbdev cannot have a log device on a server otherthan Q0150002.

If you do not specify a log device for every SQL Server listed, thedump transaction command cannot be used.

If create database fails, subsequent attempts to create the samedatabase by a different user may fail, unless you do one of thefollowing:

• Run create database again using the same user ID,

• Drop the database, or

• Request “sa” to run dbcc checkcatalog on the same database.

create index

Unique indexes must include all the decluster column(s) in the indexdefinition. For example, if table t1 is declustered on column col1, thefollowing statement is not supported:

create unique index i1 on t1 (col2)

This statement is supported:


Sybase MPP Release 11.0.x Transact-SQL Implementation in Sybase MPP

create unique index i1 on t1 (col2, col1)

create proc, create rule, create default, and create trigger

create proc, create rule, create default, and create trigger are executed in aninternal transaction regardless of whether you have started anexternal transaction. That is, if these commands are bracketed by abegin...commit/rollback, this explicit transaction is ignored during theexecution of these commands.

create procedure

The with recompile option is not supported and generates an error.

The create procedure command cannot reference temporary tables thatare not created in the body of the procedure. For example, this is notsupported:

create table #tmp(id int)gocreate proc p1 @id int as

insert into #tmp values (@id)go

Instead use:

create proc p1 @id int ascreate table #tmp(id int)insert into #tmp values (@id)

go

The prefixes “gd_”, “sp_”, “nav” and “mpp” are reserved forinternal use by Sybase MPP.

create trigger

Triggers are not supported or parallelized in Sybase MPP. Instead,referential integrity must be enforced by the client application.

Triggers can only be created on a table that is schema partitioned. Alltables referenced by the trigger must be schema partitioned on thesame SQL Server as the table on which the trigger is being created.

Each rollback transaction command must be immediately preceded bythe following statement:

raiserror 1010101010

The raiserror and rollback transaction commands must be in the body ofthe same trigger.



There can be no execution of stored procedures in the body of thetrigger.

create table

Columns cannot be of datatype text or image.

Tables cannot be partitioned based on bit or timestamp columns.

You can specify partitioning information for a table by using thesp_place_table system procedure. See “Using sp_place_table” on page4-11.

create view

The create view command cannot be used to give users access to a tablethey do not otherwise have permission to access. To use the view, theuser must have permissions on the underlying tables used in theview definition.

The view definition cannot have aggregates, or group by or havingclauses. Instead, use these in the query referencing the view.

Data Manipulation Language (DML)

This section uses the terms “vector” and “scalar” to mean theexistence of a group by clause and the lack of a group by clauserespectively.

The following Sybase release 4.9.1 Transact-SQL features are notavailable in SQL Server 9.1-mpp.

Aggregates

• Aggregates in update clause without a subquery. For example:

update t1 set col1+max(col2)

• Nested scalar aggregates anywhere in a query. For example:

select max(avg(col1)) from t1

• Certain forms of nested vector aggregates in a query:

- More than two nesting levels.

- Expressions involving the inner aggregate. For example:

select max(col2 + avg(col1)) from t1 group by col2



- Nested aggregates in insert-form2 select list

insert select

• insert select with an order by clause. For example:

insert t1select col1, col2 from t2

order by col1

• insert select with an embedded distinct clause and a group by clause inwhich any part of the inserted table’s decluster key is not part ofthe inserted columns list (this is an implied null key insertion).For example:

insert t1 (nonkey)select distinct count (col1) from t2

group by col2

or

insert t1 (nonkey)select distinct col1 from t2

group by col2

• select into with an order by clause. For example:

select col1, col2 into t1 from t2order by col1

• select into with a distinct clause and a group by clause. For example:

select distinct col3 = count(col1) into t1 from t2group by col2

or

select distinct col1 into t1 from t2group by col2

Subqueries

• Subqueries contained within having clauses. For example:

select t1.coll from t1having t1.col2 > (select t2.col11 from t2)

• Subqueries without a from clause, or with a constant value as thesubquery’s select value, if the subquery predicate type is one ofthe following:

- [not] (!=, =) all | any except for = any

- not in



For example:

select t1.col1 from t1where t1.col1 != all (select 6)

Use either = or != instead.

Or:

select t1.col1 from t1where t1.col2 not in (select 6 from 2)


• Subqueries with a predicate type of exists where the subquerydoes not contain a from clause but does contain a where clause. Forexample:

select t1.col1 from t1where exists (select 6 where 5 < 10)

In this case, since the subquery’s where clause can only containconstant values, whatever qualification is used always evaluatesto the same value (either TRUE or FALSE). This is also the valueto which the subquery evaluates, so the qualification used in thesubquery can be used to replace the subquery in the outer query.For instance, an equivalent query to the above example is:

select t1.col1 from tl where 5 < 10

• Subqueries with correlated columns anywhere other than thesubquery’s where clause. For example:

select t1.col1 from t1where tl.col2 >

(select t2.col3 from t2 group by t1.col1)

• Subqueries with correlated columns in a where clause in which acorrelated column is compared against a constant expression. Forexample:

select t1.col1 from t1where t1.col2 >

(select t2.col1 from t2 where t1.col3 < 5)

Correlated columns must be compared against columns fromtables specified in the subquery’s from clause.

• Subqueries contained within expressions in which the subqueriescontain complex or clauses or the predicate type is somethingother than a comparison operator.

This means that simple subqueries (without complex or clauses)contained within an expression involving comparison operators



are supported, but any other type of expression involvingsubqueries is not supported. For example:

Supported:

select t1.col1 from t1where (select t2.col2 from t2) > 5

Not supported:

select t1.col1 from t1where (select t2.col2 from t2) < all

(select t3.col3 from t3)

• Subqueries with aggregates in expressions for subqueries if thesubquery predicate type is one of the following:

- [not] (!=,=) all | any except for =any

- not in

For example:

... not = any (select max(col1) + 5 ...


Single aggregates containing an expression are supported. Forexample:

... not = any (select max(col1 + 5) ...

• Subqueries with predicate types: [not] (<, <=, >, >=) any | all or [not]exists preceding a subquery with a scalar aggregate in thesubquery’s project list.

The problem with this type of query is that, due to the way thesubquery is processed, even if nested aggregates are notexplicitly stated, nested aggregates are created. Since nestedscalar aggregates are not supported, these queries fail. However,if the subquery contains correlations in its where clause, whichcause a group by list to be created, the scalar aggregates arechanged to vector aggregates, which are supported.

This example generates nested scalar aggregates and fails:

select t1.col1 from t1where t1.col2 < any

(select min(t2.col2) from t2)

This example generates nested vector aggregates and succeeds:

select t1.col1 from t1where t1.col2 < any

(select min(t2.col2) from t2where t1.col3 = t2.col3)



The workaround for this is to add a group by clause or acorrelation to the subquery.

• Subqueries with predicate types: [not] (<, <=, >, >=) any | all or [not]exists that contain explicit two-level nested aggregates.

Due to the way these subqueries are processed, even if only twolevels of nested aggregates were specified, a third levelaggregate is created. Since three-level nested aggregates, scalaror vector, are not supported, these queries fail.

These examples fail:

select range01.unique1 from range01where range01.unique2 > all

(select max(min(range02.unique2))from range02group by range02.unique2)

if exists (select (max(max(avg(tsen))) from range01print "hello"

• Subqueries with a not exists predicate should not use select * from,but instead should use explicit column names. The not existspredicate is evaluated using a count aggregate, and if select * from isused, the resulting count(*) can cause problems, especially if NULLvalues are involved.

Update Decluster Column(s)

• update decluster columns with a join and no unique index on thetable being updated. For example:

update t1 set col1 = col1 * 2 from t1, t2where t1.col2 = t2.col2

where table t1 has no unique index and column col1 is thedecluster column.

• update decluster columns in browse mode and with no uniqueindex on tables being updated. For example:

update t1 set col1 = col1 * 2 from t1, t2where t1.col2 = t2.col2 and

tsequal (timestamp col, @ var1)

Update or Delete Commands with an Outer Join Clause

In certain cases, the processing of an outer join requires the left(outer) member of the outer join to be repartitioned by means of a



replicate operation. Such cases are restricted because the replicationcauses extraneous “null” rows to be returned. This situation occursmost often when the table being modified is the inner member of theouter join. For example:

update t1 set col1 = 0 from t1,t2where t2.nonkey = t1.nonkey

group by all

The purpose of all in a group by clause is to include all groups in theresult set, including those groups that do not have any rows thatqualify from the where clause. For certain queries, Sybase MPP fails toreturn those groups that did not have any qualifying rows. Thisproblem occurs when the query requires dynamic repartitioning ormaterialization prior to the calculation of groups. In general, suchsituations most often arise with join queries, especially multi-wayjoins.

This example returns correct results:

select col1 from t1where col1 > 10group by all col1

This unsupported example returns incorrect results:

select t1.col1 from t1, t2where t1.col1 > 10 and t1.nonkey = t2.nonkeygroup by all t1.coll

Views Defined with Aggregates, group by, or Subqueries

Use of view definitions that include aggregates, group by, having, orsubqueries is currently restricted. This restriction applies only to thecreate view statement. Using these features in select queries thatreference views is still supported. For example:

create view vname (grouping_col,aggregate)as select col1, sum(col2) from t1group by col1

Joins

Currently, Sybase MPP does not support the Transact-SQL commandset forceplan as a mechanism to control the local join order in a SQLServer. Use set forceplan only as an alternative syntax for overriding



the global join order. See “Specifying Global Join Order” on page12-2.

Miscellaneous

Currently, Sybase MPP does not support:

• Declustering on bit datatype

• Unique indexes on non-decluster columns unless the uniqueindex includes a decluster column.

For example, if t1 is declustered on column col1, all uniqueindexes on t1 must include col1.

This example is supported:

create unique index ind1 on t1 (col1, col2, col3)

This example is not supported because the index does notinclude the decluster column col1:

create unique index ind1 on tl (col2, col3)

Other Transact-SQL Commands

checkpoint, kill, and shutdown

checkpoint, kill, and shutdown cannot be executed in a user transaction.In the current implementation, the control server interpreter (CSI)does not invoke the data definition language interpreter (DDL-I)inside a user transaction.

dbcc

• The data definition language interpreter (DDL-I) only supportsdbcc options documented in the Sybase SQL Server CommandsReference Manual. Other options are supported by logging in as“sa” directly to an individual SQL Server. The supported optionsinclude checktable, checkdb, checkalloc, checkcatalog, dbrepair, reindex,fix_text.

• Table ID and index ID are not supported. Specify the table namefor reindex and fix_test.

• indexalloc – This option is not supported because it requires anindex ID. Use tablealloc instead.



• checkcatalog – This option is executed in the home of the database.The space utilization information in the global directory for thisdatabase is rebuilt.

• dbrepair(dbname, dropdb) – This option can only drop a databasewhich has been marked “suspect.” If the database is marked“suspect” only in some SQL Servers, the database may still existin other SQL Servers in the home of the database and the SchemaServer. Issue the drop database command after dbcc dbrepair() to dropthe database on the rest of the SQL Servers and Schema Server.

disk refit

To use disk refit, SQL Server needs to be in single-user mode. SinceSybase MPP does not run in single-user mode, you must shutdownSybase MPP, bring up an individual realm’s SQL Server in single-user mode, and then run disk refit.

disk reinit

The disk reinit command can only be used at the individual SQL Serverlevel.

➤ NoteDo not use disk reinit on Sybase MPP servers.

execute

The option with recompile is not supported and generates an error.

Remote procedure calls are not supported.

Procedures containing queries that require data repartitioning ortemporary tables cannot be executed concurrently by sessions usingthe same login name.

Identifiers

Identifiers beginning with the prefix “@nav@” are reserved forinternal use by Sybase MPP.



order by Clause

Using an order by clause in an insert select or select into statement is notsupported.

readtext

This command is not supported and generates an error.

save transaction

This command is not supported and generates an error.

set

The set command options offsets and textsize are not supported.

The set statistics i/o and set statistics time commands are not meaningfulin Sybase MPP.

waitfor

The waitfor command options errorexit, mirrorexit, and processexit are notsupported.

writetext

The writetext command is not supported and will generate an error.This includes writetext bulk, which is used by Open Client libraries.

System Functions

The following system functions are supported with the restrictionthat they should not be used on user tables unless the user tablesreside on the Schema Server:

• col_length()

• col_name()

• data_pgs()

• db_id()

• db_name()

• index_col()



• object_id()

• object_name()

• reserved_pgs()

• rowcnt()

• used_pgs()

The functions host_id() and host_name() cannot be used in a query thatreferences a table. For example, this is not supported:

select col1 from table1 where host_id() = col2

Instead use:

declare @var1 intselect @var1 = host_id()select col1 from table1 where @var1 = col2

Datatypes

The text and image datatypes are not supported.

text and image built-in functions are not supported. However, thepatindex() function is supported with other applicable datatypes.

tempdb

When a transaction is started, the current database should not betempdb. Because tempdb transaction logs are cleared during reboot ofSQL Server, there may be problems with database recovery.

For example:

use tempdbgobegin transactiongouse userdbgo(do some updates)gocommit transactiongo

If the system crashes before the commit completes, leaving the statusof the transaction “prepared,” an error message is displayed. (Sincethis is a multi-database transaction, the server first “prepares” thetransaction in each database and then “commits” it.) This is because



when recovery finds a transaction in the prepared state it attempts tolook in the log for the database where the transaction was initiated tosee if the transaction was committed or aborted. In this case, it is thetempdb log that has been truncated during recovery.

Temporary Tables

Fully qualified temporary table names do not follow the sameconvention used by SQL Server.

You cannot create a stored procedure that references a temporarytable created outside of the stored procedure. Therefore, thefollowing does not work:

create table #tmp(int id)gocreate proc myproc

@id int as insert into #tmp values (@id)go

You cannot use bcp to access a temporary table.

Variables

The following global variables return a value of -1:

• @@connections

• @@cpubusy

• @@idle

• @@iobusy

• @@pack_received

• @@pack_sent

• @@packet_errors

• @@timeticks

• @@total_errors

• @@total_read

• @@total_write

• @@spid

The value of @@rowcount in a command batch is undefined after astored procedure is executed. Instead, retrieve the @@rowcount value


Sybase MPP Release 11.0.x System Procedures

within the body of the procedure and pass it back to the caller as anoutput parameter.

The value of the @@max_connections variable is the maximumallowed number of user connections to the Control Server on whichthe current session is established.

The value of the @@servername variable is the name of the ControlServer on which the current session is established.

System Procedures

In general, Sybase MPP fully supports system procedures. Thesections below outline areas where system procedures have beenenhanced or behave differently due to Sybase MPP’s partitionedenvironment. System procedures that are used exclusively withSybase MPP are also described.

Executing System Procedures with Insufficient Permission

If, as part of a SQL Server batch, you attempt to execute a restrictedprocedure without having sufficient permission, the procedure fails,Sybase MPP displays an error message, and the rest of the batchaborts. This behavior is different from that of a standalone SQLServer, in which the procedure fails and the server displays an errormessage, but the remainder of the batch is executed.

Multiple Concurrent Access by the Same User

In Sybase MPP, the same system procedure cannot be executedmultiple times concurrently by the same user if temporary tables orcompiler-generated work tables are used. This is because theintermediate work tables generated and used by the compiler haveidentical names (except for the owner) for each execution of thatprocedure. This is also true for temporary tables.

Procedures using work tables or temporary tables may get erroneousresults if executed concurrently by the same user due to potential re-use of tables with the same name. Procedures that contain joinsbetween three or more tables or between tables with differentdeclustering schemes require compiler-generated work tables inorder to execute.

The following system procedures cannot be executed concurrentlyby the same user:


System Procedures Sybase MPP Release 11.0.x

sp_addumpdevicesp_configure (if configuration options are changed)sp_diskdefaultsp_dropdevicesp_dropdumpdevicesp_helpsp_helpdbsp_helpdevicesp_helpindexsp_helpjoinssp_helpserversp_helpsortsp_setreplicate (for certain options only)

The following catalog stored procedures are also restricted fromconcurrent execution by the same user:

sp_columnssp_column_privilegessp_databasessp_fkeyssp_pkeyssp_statisticssp_stored_proceduressp_tablessp_table_privileges

Changes to Existing System Procedures

The Sybase MPP versions of the following system procedures behavedifferently from those in SQL Server:

• sp_addumpdevice – Dump devices must adhere to a special namingconvention. See “Backup Device Naming Conventions” on page6-5 for rules on naming dump devices. When usingsp_addumpdevice you need to use an additional parameterspecifying tape type if a tape device is being used.

• sp_addlogin, sp_droplogin – These stored procedures can only beexecuted from the master database in Sybase MPP.

• sp_addmessage – The message number 1010101010 is reserved forinternal use by Sybase MPP and should not be used for user-defined messages.

• sp_configure – When issued with no options, this proceduredisplays all the configuration settings for the Schema Server.


Sybase MPP Release 11.0.x System Procedures

When issued with a single option without a new value, thecurrent value for the option for each server is displayed.

When used for the purpose of updating a configurationparameter, this procedure updates each SQL Server in thesystem with the specified value.

If you want to set different values for the same configurationparameter for each server, you must use the ConfigurationManagement utility in the Sybase MPP Manager (MPPM)application. Although sp_configure is supported, it is stronglyrecommended that you use the Configuration Management toolto display and update configuration parameters. See the SybaseMPP Manager User’s Guide for more information.

• sp_dboption – The single-user mode of sp_dboption is not available.

• sp_helpsort, sp_serverinfo – The sp_helpsort procedure and certainoptions of sp_serverinfo do not display all of the characters within agiven character set. Character set definitions are stored as imagedata within the table syscharsets and Sybase MPP does notcurrently support the image datatype. As a result, output fieldsrelated to a character set’s name and description appearnormally, but the definition field contains the value “n.a.” toindicate that it is not available.

• sp_monitor – This stored procedure is intended to display howbusy a SQL Server has been with statistics such as cpu_busy,io_busy, and so on. These values are stored in a series of globalvariables. However, in a multiprocessor system, these variablesdo not reflect meaningful values for the system. For example, asingle processor could be 100 percent busy but the remainingprocessors could be idle; so total system activity would be low,but sp_monitor would report 100 percent busy. Therefore, all of thevalues returned by sp_monitor are set to -1 under Sybase MPP toensure that these values are not interpreted as representative ofthe system state at any time.

• sp_password – The syntax and semantics of the system proceduresp_password remain unchanged. However, the Sybase MPPversion of sp_password encodes (scrambles) the original passwordso that the user is only able to log into the system through aControl Server and not to a SQL Server directly. The passwordassociated with the “sa” user is not encoded so that, if necessary,direct access to SQL Servers by a user with “sa” privileges ispossible.


System Procedures Sybase MPP Release 11.0.x

• sp_renamedb – In Sybase MPP, you cannot rename a database usingsp_renamedb. This is due to the restriction for sp_dboption, describedabove. You cannot change the name of a database from the nameused in the create database command. Instead, you need to drop thedatabase and re-create it with a different name.

• sp_spaceused – When you issue sp_spaceused without parameters itdisplays the sum of the space used for the current database acrossall SQL Servers, including the Schema Server, for each object.

When you issue sp_spaceused with a single parameter it displaysthe amount of space used by the object you specified on each ofthe SQL servers, including the Schema Server. You can use thisenhanced functionality of sp_spaceused to help detect data skewproblems.

• sp_who, sp_lock – These procedures are extended to display aSybase MPP process ID that uniquely identifies each processacross all SQL Servers, instead of the SQL process ID. The SQLServer process ID is not unique across the entire Sybase MPPenvironment and is not sufficient to accurately monitor and trackrelated processes across multiple servers.

New System Procedures

The following system procedures are new to Sybase MPP:

• sp_extenddb – To extend a database to new SQL Servers, usesp_extenddb in conjunction with the create database command. Forinformation on how to use sp_extenddb, see “ExtendingDatabases” in Chapter 4, “Creating and Managing Databases”.

• sp_place_table – To partition a table, use sp_place_table in conjunctionwith the create table or select into commands. For information onhow to use sp_place_table, see “Using sp_place_table” on page 4-11.

• sp_pragma – sp_pragma turns the Parallel SQL (PSQL) OptimizerExplain utility on or off and specifies the file name to send outputto. For information on using Explain, see to “Interpreting ParallelQuery Plans Using the Explain Utility” on page 10-1.

sp_pragma can also be used to override the processing strategychosen by the PSQL Optimizer. For information on the overridedirectives, see “Overriding the Parallel Optimizer” on page 12-1.


Sybase MPP Release 11.0.x System Tables

System Tables

Directly updating the system tables is strongly discouraged withinthe SQL Server environment due to the risk of damaging criticalinternal information. The risk is even higher in the Sybase MPPenvironment due to the complexity of maintaining consistent cataloginformation across all SQL Servers.

Object ID, Database ID, and Index ID Access Differences

For any given table, database, or index, the respective object ID,database ID, or index ID is not consistent across all SQL Servers.

Due to the complexity of managing these inconsistencies, storageand usage of such IDs is discouraged. If necessary, such IDs can bestored within a user table as long as the user table resides exclusivelyon the Schema Server. Object names and database names areconsistent across all SQL Servers so that the “local” ID of a particularobject or database can be obtained using the provided functionsobject_id(object_name) and db_id(database_name), respectively.

Storing User Databases

Storing user databases on the master device is not recommendedsince doing so greatly complicates disaster recovery. Disasterrecovery in this context refers to situations requiring a rebuild of themaster database and/or master device.

Transactions

Certain transactions behave differently under Sybase MPP due todata repartitioning. The following sections describe thesedifferences.

By rewriting Transact-SQL queries, performance can be improvedwith One Server Optimization (OSO). For information on how OSOworks and how to take advantage of this optimization, see Chapter8, “Performance and Tuning”.

Updates and Joins

In the Sybase MPP environment, some data manipulation occursoutside the scope of the transaction:


Transactions Sybase MPP Release 11.0.x

• Data repartitioning for joins and other complex queries thatrequire data redistribution.

• Selects from user tables during intermediate internal processingsteps (other than selects required for data partitioning, above).

Therefore, if one of the tables being repartitioned or selected fromhas been previously modified by the current transaction, therepartition or select operation blocks the write locks held by thetransaction indefinitely.

This prevents the transaction from ever completing, and you need toabort the transaction. To avoid this situation, keep joins and complexqueries in their own transactions, separate from other queries.

Rollback Behavior

The need for atomicity of updates when multiple SQL Servers areaffected results in behavior that is different from a standalone SQLServer:

• A rollback transaction statement always rolls back the transaction tothe outermost level, even when executed in a trigger.

• If a data modification statement affecting multiple SQL Serverssucceeds on some SQL Servers but fails on other SQL Servers, thecurrent transaction is rolled back to the outermost nesting level.

Two-Phase Commit

Sybase MPP can participate in two-phase commit transactions withother SQL Servers. It is recommended, but not required, that aControl Server act as the commit coordinator. All participating SQLServers must have access to the commit coordinator for transactionrecovery. Therefore, the interfaces file for each SQL Server mustcontain an entry for the commit coordinator. If you do not use aControl Server as a commit coordinator, you must manage theinterfaces file.


8 Performance and Tuning 8.

This chapter describes issues that affect performance in the SybaseMPP environment.


• Hardware Configuration 8-1

• Software Configuration 8-1

• Sizing tempdb 8-3

• Configuring Sybase MPP SQL Server and Schema Server 8-3

• Tuning Split Server Performance 8-10

• Large I/O Buffer Pool 8-12

• SQL Server Optimizations 8-13

• Physical Data Design 8-15

• Writing Queries in Sybase MPP’s Parallel Environment 8-16

• Aggregate Processing 8-23

Hardware Configuration

See the Release Bulletin for hardware and software configurationrequirements.

Software Configuration

Memory

There must be a minimum of 256MB of RAM per node. However,Sybase recommends that you have 512MB of RAM. Of the 512MB ofRAM, approximately 120MB can be comfortably allocated for thebuffer caches. With more memory, the Control, Split/Merge, andSQL Server caches can be maximized for performance.

➤ NoteNever let a SQL Server page fault. If you notice that this is occurring,

reduce the amount of memory for that SQL Server.

8-2 Performance and Tuning

Software Configuration Sybase MPP Release 11.0.x

External SCSI Disks

When using external SCSI disks devices such as IBM7134-010 diskcabinets, a SCSI Adapter is attached directly to an I/O channel on the7134. Up to 6 disks can be attached to the same Adapter Card Bus.Since the disk is attached directly to the bus through the channel, thedisk is seen as a UNIX device and can be referenced at the operatingsystem and database system levels.

Do not load the SCSI bus with the maximum configuration. Usemore adapter cards to reduce contention on the SCSI Bus. Try tospread the data across as many controller as possible. Use the sar -dutility to monitor data usage.

Disk Arrays

Disk arrays, such as IBM 7135-110, are typically implemented byinterposing a disk array controller (DAC) in between the channeland a subset of disks. Disk arrays are commonly used because theyprovide added functionality and robustness.

The DAC has a limited I/O bandwidth that typically is less than theaggregate I/O bandwidth of the disks that the disk controlleradministers. Thus, the aggregate I/O bandwidth of the system islimited by the aggregate I/O bandwidth of the DACs.

Refer to your hardware documentation for information on setting updisk arrays.

RAID Levels

All the RAID levels can be mixed in the same environment. This isencouraged, when possible, as each RAID level is suitable for aspecific purpose in the Sybase MPP environment.

RAID levels are described in the following sections.

RAID-0

RAID-0 is the fastest of the RAID levels, but the least safe, since thereis no built-in recovery.

RAID-1

RAID-1 mirrors all data transparently to the DBMS and DBA. RAID-1 is often a preferred mechanism for ensuring data redundancy at thehardware level. It is also recommended to store user data that is


Sybase MPP Release 11.0.x Sizing tempdb

subject to write or update intensive environments, such as OLTP orupdate batch processing, on RAID-1 if redundancy is required.RAID-0 provides better system throughput, but no redundancy.

RAID-5

Place user data that is mostly or always read on RAID-5, because itprovides better price per storage than RAID-1 (20 percent loss ofcapacity as compared to 50 percent for RAID-1). RAID-5 also hasread throughput that is similar to RAID-0 and RAID-1.

File Systems

In general, file systems devices (block devices) are used to store userand tempdb data. They provide an advantage over raw devices in theuse of large physical I/Os in that they speed up sort and joinoperations on non-indexed tables. However, file systems arecurrently not supported on Sybase MPP.

➤ NoteFile systems are currently not supported by Sybase MPP.

Sizing tempdb

Never allocate less than 25 percent of the total user database space totempdb. The exact amount of tempdb needed to execute a workload isapplication dependent. If the application contains concurrentrepartitioning joins or product joins, more tempdb space might berequired. The use of queries that copy entire tables or repartitionentire tables to tempdb is not recommended.

Configuring Sybase MPP SQL Server and Schema Server

Use the Sybase MPP Manager (MPPM) Configuration Managementtool to determine the existing configuration and to change anyvalues, if necessary. Compare these values among realms todetermine any differences. (See the Sybase MPP Manager User’s Guidefor information about using the Configuration Management tool.)


Configuring Sybase MPP SQL Server and Schema Server Sybase MPP Release 11.0.x

The default sp_configure parameters for SQL Server (one per realm)are listed in the following table:

Table 8-1: sp_configure parameters for SQL Server

Parameter Minimum Maximum config_value run_value

recovery interval 1 32767 0 0

allow updates 0 1 1 1

user connections 5 2147483647 80 80

memory 8192 2147483647 10800 10800

open databases 5 2147483647 0 10

locks 5000 2147483647 10000 10000

open objects 100 2147483647 1000 1000

procedure cache 1 99 0 20

fill factor 0 100 0 0

time slice 50 1000 0 100

database size 2 10000 0 2

tape retention 0 365 0 0

recovery flags 0 1 0 0

serial number 1 999999 0 0

nested triggers 0 1 1 1

devices 4 256 0 10

remote access 0 1 1 1

remote logins 0 2147483647 0 20

remote sites 0 2147483647 0 10

remote connections 0 2147483647 0 20

pre-read packets 0 2147483647 0 3

upgrade version 0 2147483647 910 910

default sortorder ID 0 255 50 50

default language 0 2147483647 0 0

language in cache 3 100 3 3

max online engines 1 32 1 1

min online engines 1 32 1 1

engine adjust interval 1 32 0 1


Sybase MPP Release 11.0.x Configuring Sybase MPP SQL Server and Schema Server

➤ NoteThe cache alignment (calignment) should not be adjusted by the user.

The default sp_configure parameters for Schema Server (one perSybase MPP instance) are listed below:

default character set ID 0 255 1 1

stack size 20480 2147483647 40960 40960

additional netmem 0 2147483647 0 0

default network packet size 512 524288 0 512

maximum network packet size 512 524288 0 512

cache alignment 2048 4096 2048 2048

16K buffer pool percentage 0 99 0 0

Table 8-2: sp_configure parameters for Schema Server


recovery interval 1 32767 0 5

allow updates 0 1 1 1




memory 8192 2147483647 20700 20700

open databases 5 2147483647 0 10

locks 5000 2147483647 40000 40000

open objects 100 2147483647 4000 4000

procedure cache 1 99 0 20

fill factor 0 100 0 0

time slice 50 1000 0 100

database size 2 10000 0 2

tape retention 0 365 0 0

recovery flags 0 1 0 0

Table 8-1: sp_configure parameters for SQL Server (continued)




➤ NoteThe cache alignment (calignment) should not be adjusted by the user.

Workload Configurable Values

The following values should be checked and adjusted accordinglyfor typical workloads for each SQL Server:

serial number 1 999999 0 0

nested triggers 0 1 1 1

devices 4 256 0 10

remote access 0 1 1 1

remote logins 0 2147483647 0 20

remote sites 0 2147483647 0 10

remote connections 0 2147483647 0 20

pre-read packets 0 2147483647 0 3

upgrade version 0 2147483647 910 910

default sortorder ID 0 255 50 50

default language 0 2147483647 0 0

language in cache 3 100 3 3

max online engines 1 32 1 1

min online engines 1 32 1 1

engine adjust interval 1 32 0 0

default character set ID 0 255 1 1

stack size 20480 2147483647 40960 40960

additional netmem 0 2147483647 0 0

default network packet size 512 524288 0 512

maximum network packet size 512 524288 16384 512

cache alignment 2048 4096 2048 2048

16K buffer pool percentage 0 99 0 0

Table 8-2: sp_configure parameters for Schema Server (continued)




• memory – specifies the number of 2K blocks set aside for a datacache for the SQL Server

• procedure cache – displays the percentage of the cache allocated toprocedures

Split Server Subsystem Configurable Values

There are three additional configuration parameters that must be setbefore SQL Servers can participate with the Split Server subsystem inexchanging larger network messages:

• default network packet size

• maximum network packet size

• additional netmem

default network packet size

This value is initially set to 512. If you want to change the packet sizefor every connection that logs in, you can change this value. It mustbe changed in increments of 512 and should be less than or equal tothe value of the maximum network packet size parameter.

maximum network packet size

This value is initially set to 512. It is the maximum packet size thatcan be used by a connection and must be greater than or equal to thevalue of the default network packet size parameter.

additional netmem

This value is initially set to 0. This value specifies the additionalmemory for the variable packet sizes. Depending on the number ofconnections you have and the size of the packets you plan to use (andremembering that each connection uses three packets), this valueneeds to be set appropriately. At start-up time, the system calculatesthe memory for the default packet size for each connection, adds thevalue of the additional netmem configured to it, and allocates asingle “network memory pool” out of which the network memorypackets are allocated.

The “Choosing Packet Sizes” section provides information ondetermining packet sizes.



Choosing Packet Sizes

For best performance, you should choose a server packet size thatworks efficiently with the underlying packet size on your network.The criteria are:

• Reducing the number of server reads and writes to the network

• Reducing unused space in network packets, thereby increasingnetwork throughput

default network packet size

The default network packet size option of the sp_configure commandconfigures the default packet size for all SQL Server users. Thedefault value is 512 bytes. You can set this option to any multiple of512 bytes, up to a maximum of 524,288. Values that are not multiplesof 512 are rounded down.

Memory for all users who log in with the default packet size isallocated from SQL Server’s memory pool, set with the memoryconfiguration option. This memory is allocated for network packetswhen SQL Server boots.

Each SQL Server user connection uses:

• 1 read buffer

• 1 read overflow buffer

• 1 write buffer

Each of these buffers requires default network packet size bytes. The totalamount of memory allocated for network packets is:

user connections * 3 * default network packet size

When you provide a new value for this option, SQL Server requiresthat amount of memory for each of the three buffers, for each userconnection. For example if you set the default network packet size to 1024bytes and have 50 user connections, the amount of network memoryrequired is:

50 * 3 * 1024 = 153600 bytes

If you increase default network packet size, check the memory configurationand user connections options of sp_configure to be sure that you leaveenough space for other SQL Server memory needs. When you rebootthe server after changing the default network packet size, check themessages that report buffer allocation to be sure that you haveenough memory remaining.



If you increase the default network packet size, you must also increase themaximum network packet size to at least the same size. Execute bothsp_configure commands, and then run reconfigure.

maximum network packet size

If some of your applications send or receive large amounts of dataacross the network, these applications can achieve significantperformance improvement by using larger packet sizes. Generally,you want to keep the value of default network packet size small for usersperforming short queries, and allow users who send or receive largevolumes of data to request larger packet sizes by setting the maximumnetwork packet size configuration option.

The default value for maximum network packet size is 512 bytes. It mustalways be as large or larger than the default network packet size. You canreset the maximum size without resetting default network packet size.Values that are not even multiples of 512 are rounded down. Themaximum value is 524,288 bytes.

additional netmem

SQL Server guarantees that every user connection is able to log in atthe default packet size. If you increase maximum network packet size, youshould increase additional netmem. additional netmem sets the maximumsize of additional memory that can be used for network packets thatare larger than SQL Server’s default packet size. The default valuefor additional netmem is 0, which means that no extra space has beenallocated for large packets. Memory allocated with additional netmem isadded to the memory allocated by memory. It does not affect otherSQL Server memory uses.

If additional netmem remains set to 0, clients cannot use packet sizes thatare larger than the default size: all allocated network memory isreserved for users at the default size. In this situation, users whorequest a large packet size when they log in receive a warningmessage telling them that their application will use the default size.

To determine the value for additional netmem if your applications uselarger packet sizes:

1. Estimate the number of simultaneous users who will request thelarge packet sizes and the sizes their applications will request.

2. Multiply this sum by three, since each connection needs threebuffers.


Tuning Split Server Performance Sybase MPP Release 11.0.x

3. Add 2 percent for overhead, rounded up to the next multiple of512.

For example, if you estimate these simultaneous needs for largerpacket sizes:

Tuning Split Server Performance

Sybase MPP has the following parameters for tuning theperformance of the Split Server:

• RS_MAX_DATA_PACKET (Inter Split Server network messagesize) – specifies the maximum size of the network messagesexchanged between Split Servers. Generally, the value should bein the range between 8K and 32K. This may be tuned to aparticular workload; 16K (16384) is a good size to start with.

• RS_Q_HIGH/RS_Q_LOW (High and low water marks on the SplitServer thread buffer pools) – specify the high and low watermarks on each Split Server threads network buffer pool. Thedefault values are set to 100 and 30, respectively. The propervalues generally depend on the size of the system. A good rule ofthumb is to have RS_Q_HIGH set to approximately 4 times thenumber of Split Servers (realms) in the system. For example, with24 servers, RS_Q_HIGH should be set to a minimum of 96.

It is also necessary to take the amount of available systemmemory into account. For example, if a node is configured with512MB, it may make sense to configure 10 percent of this amountto the Split Server subsystem network buffer pool; that is,approximately 48MB. If the example was 6 servers per node, thiswould be 8MB per server. With a packet size of 10K, this wouldcorrespond to an aggregate value of RS_Q_HIGH of 512 16Kpackages. The number of concurrent threads must be taken into

Application Packet Size Overheadbcp 8192Client-Library™ 8192Client-Library 4096Client-Library 4096Total 25476Multiply by 3 buffers/user *3

73728Compute 2% overhead * .02=1474Round up to a multiple of 512 1536Add overhead + 1536Total additional network memory 75264


Sybase MPP Release 11.0.x Tuning Split Server Performance

account. Assuming a maximum limit of 8 threads per server,corresponding to 8 concurrent decluster queries as a maximum,this translates into 64 16K packages/thread, so RS_Q_HIGHshould be set to 64.

• DN Packet Size – specifies the Split Server to SQL Server networkpacket size. This is the network packet size used by the SplitServer to bulk copy data into its local SQL Server and has adefault value of 512.

This parameter can improve network performance between theSplit Server subsystem and the SQL Server subsystem becausethe use of larger network packet sizes tends to make better use ofthe communications subsystem in the kernel. A packet size of8192 (8K) is recommended as a starting value.

➤ NoteTo make the parameters take effect, shut down and restart Sybase MPP.

See Chapter 2, “Starting Up and Shutting Down the Sybase MPP System.”

You can use MPPM to change any of these parameters. In fact, youmust use MPPM to change Open Server parameters.

It is recommend that you change the DN Packet Size parameter ofsp_configure to 8192, the maximum value.

Flow and Congestion Control of Split Servers

To minimize the number of times congestion control is invokedduring a redecluster operation, the merge threads should havesufficient buffer space to store incoming messages. The rule that isgenerally used is to configure each merge thread with a buffer of sizen, where n is four times the number of Split Servers in the system. Forexample, if the system consists of 16 Split Servers, n should be set to64 buffers. The number of buffers is set with the RS_Q_HIGHparameter in the Configuration Manager tool of Sybase MPPM. Theparameter must be applied to all Split Servers, and Sybase MPP mustbe restarted to allow the new settings to take effect.

SQL Server Packets

When the Split Server retrieves rows from its local SQL Server, thenetwork traffic between the two UNIX processes should be based onlarge network messages, for example, 16K messages. The use of 16K


Large I/O Buffer Pool Sybase MPP Release 11.0.x

messages can be invoked by configuring the SQL Server and the SplitServer appropriately.

Use sp_configure to set the following parameters in the SQL Servers.

sp_configure "additional netmemsize", 50000gosp_configure "maximum packet size", 16384goreconfigure with overridego

These settings allow the SQL Servers to support the use of 16Knetwork messages. The use of the message size is negotiated when aclient connects to the SQL Server during connection establishmenttime. Thus, the Split Server must be instructed to initiate thenegotiation of 16K messages when it connects to its SQL Server. Thatis accomplished by using Sybase MPPM to set theSRV_S_NETBUFSIZE parameter to 16384 for all Split Servers in thesystem.

Disabling Packet Coalescing

For SQL Server to issue packets in fast sequence, the SQL Server bootflag -T1610 should be enabled on all SQL Server boots. If the flag is notenabled in the RUN_Q start-up files for each SQL Server, it should beadded manually. When a SQL Server is booted with -T1610, it disablesTCP/IP packet coalescing.

Split Packets

To use large packets in the IPC between Split Servers, you must setthe Split Server parameter RS_MAX_DATA_PACKET to the value16384 for all Split Servers. This can be accomplished using SybaseMPPM’s Configuration Manager tool.

Large I/O Buffer Pool

Large I/O feature of the buffer manager consists of the followingfeatures:

• Named cache (also called buffer cache)

• Multiple buffer pools

• Ability to read and write I/O sizes greater than 2K


Sybase MPP Release 11.0.x SQL Server Optimizations

Among Large I/O benefits, there are two that help reduce the cost ofOnline Transaction Processing (OLTP) and Decision Support System(DSS) transactions.

Large I/O enables Sybase MPP to:

• Prefetch data required to satisfy immediate user query.

• Write more than a single page to disk with each I/O operation.

See Chapter 11, “Large I/O Buffer Manager,” and the SQL ServerSystem Administration Guide for additional information onconfiguring Large I/O.

SQL Server Optimizations

Most of the standalone SQL Server performance, tuning, andoptimization considerations apply to SQL Servers in the Sybase MPPenvironment.

If possible, increase each SQL Server’s memory from the default of20MB (10,000 2K pages) to 40–60MB (25,800–30,800 2K pages). It isadvisable to give equal allocations of memory to all SQL Servers.

If possible, decrease each SQL Server’s procedure cache from thedefault 20 percent. It is advisable to give equal procedure cachepercentages to all SQL Servers.

Use multiple SQL Server engines for high volume OLTP.

One Server Optimization

One Server Optimization (OSO) is a run-time optimization thatallows Sybase MPP to shortcut the usual execution path and performRPCs directly to a single SQL Server. OSO is useful in situationswhere a single short transaction is being executed on a single SQLServer. For typical OLTP workloads, where a substantial part of thetransactions are executed on a single SQL Server, OSO can providesubstantial performance improvements by shortening the responsetime and increasing throughput, since it requires fewer systemresources.

To take advantage of OSO, follow these rules:

• The stored procedure must have a begin transaction as its firstexecutable statement. The stored procedures cannot use thecommands prepare transaction, select into, select union, and it cannotupdate decluster key columns.


SQL Server Optimizations Sybase MPP Release 11.0.x

• Each data access command (select, insert, update, delete) mustreference a single table only. No system or temporary tables canbe referenced.

• All tables that are modified must reside in the same database.

• An equality constraint on the partitioning attribute of eachreferenced table must appear in the where clause, unless the tableis schema-partitioned.

• The procedure must contain a commit transaction or a rollbacktransaction before each possible return statement and as the lastexecutable statement.

• The procedure cannot reference any global variables.

• The procedure cannot use browse mode update or select forbrowse.

• No nested transactions.

• No output parameters.

For example, in the following debit/credit transaction:

create proc debit@aid int, @balance flow output, @delta intasbegin transaction

update accountset balance = balance + @deltawhere aid = @aidselect @balance = balance from accountwhere aid = @aid

commit transaction

The procedure created is not a candidate for OSO because of theoutput parameter @balance. To make the procedure a candidate forOSO, it can be rewritten, for example:

create proc debit @aid int, @delta intasbegin transaction

update accountset balance = balance + @deltawhere aid = @aidselect balance from accountwhere aid = @aid

commit transaction


Sybase MPP Release 11.0.x Physical Data Design

Physical Data Design

A performance-efficient physical data design reduces contention andprovides parallel disk access across many physical disk devices andI/O controllers (channels). In addition, it is important to reduce oreliminate the movement of rows or indexes to reduce the start-uptime for a query plan.

The guidelines for an efficient physical schema are:

• Design a physical schema that allows for in-place execution to thelargest possible extent. Knowledge of the queries or types ofqueries to be used should serve as a guide.

• Choose homes and a partition method with appropriate declusterkeys for the tables that lead to an even distribution of rowsamong the available partitions. Knowledge of the distribution ofkey values and what the query workloads will be doing arecritical to this choice.

• Spread objects (tables, indexes) across devices and I/Ocontrollers to maximize throughput and minimize interference.

• Ensure that physical disk accesses are evenly distributed acrossall partitions and across all I/O controllers and devices.

Indexes

The index optimizations that can be made with Sybase MPP areidentical to those that can be made with SQL Server, with theexception of processing redecluster join queries.

When a table is repartitioned, the Split Server retrieves only thosecolumns and rows that are needed in order to process the final joinstep. Therefore, the selection-projection of rows for the redeclusterstep can be optimized by applying a covered index on the columnsthat need to be repartitioned, as described below.

Using Covered Indexes to Speed Up Repartitioning

The following is an example of a redecluster-1 query:

select sum(t50x.in10)from t50x, t2xwhere t50x.in10m = t2x.inseqand t50x.inseq between 1000 and 100000


Writing Queries in Sybase MPP’s Parallel Environment Sybase MPP Release 11.0.x

Assume that the tables t50x and t2x have the homes {t50x.inseq, hash,all} and {t2x.inseq, hash, all}. Since the join key does not match thepartitioning key for table t50x, the join is processed by repartitioningthe columns t50x{in10, in10m} into a work table #w(in10, in10m) withthe home {#w1.in10m, hash, all}. In doing so, the predicate (t50x.inseqbetween 1000 and 100000) is applied to reduce the number of qualifyingrows in the redecluster step.

Assume that the only index on t50x is a clustered index ont50x.in10m. Since the work table #w1 is generated without indexes,the clustered index serves no purpose in the join query. It might beusable for other queries that access t50x, but not for the examplequery. Further, in filtering away those rows that do not qualify,according to the second predicate, the local servers are forced to scanall pages of t50x.

The query that is actually executed by the server(s) to retrieve andproject rows for repartitioning is:

select in10, in10mfrom t50xwhere t50x.inseq between 1000 and 100000

If a nonclustered index is used to cover the columns {inseq, in10,in10m}, the local optimizers will likely choose to scan the index toretrieve the rows {in10, in10m}. The column inseq is included in thisindex to allow the local server to retrieve qualifying rows based onthe index as well. The cost of the retrieval is now reduced from a fullscan of t50x to a full scan of the index, which typically is muchsmaller than the full table.

Writing Queries in Sybase MPP’s Parallel Environment

This section discusses the functioning of the PSQL optimizer. Byknowing how the PSQL optimizer functions you can write querieswhich take advantage of the most efficient query processingmethods available in Sybase MPP’s parallel environment.

Multicolumn Partitioning Keys

Using multicolumn partitioning keys is strongly discouraged,however, this restriction does not affect using composite indexes. Forexample, you can declare a primary-clustered index on columns c1,c2, and c3 and a partitioning key on c1 and achieve goodoptimization at both the Sybase MPP and SQL Server levels.


Sybase MPP Release 11.0.x Writing Queries in Sybase MPP’s Parallel Environment

➤ NoteAlthough Sybase MPP supports multicolumn partitioning keys, the

optimizer does not recognize in-place join conditions when joins occur on

the partitioning key.

Single Table Queries

For hash partitioning, querying on the partitioning key is useful onlyif all columns comprising the key are involved within an equalityconstraint.

For example, if the decluster columns of a table are c1 and c2, thefollowing constraint must be present for optimization to occur:

“c1 = constant and c2 = constant”

In all other cases involving a hash declustered table, the participatingdata partitions are all the partitions in the table’s home.

Join Processing

Sybase MPP supports four parallel join strategies:

• In-place – Both tables in a binary equijoin remain in place.

• Redecluster-1 – Rows from one table are moved into the home ofthe other table.

• Redecluster-2 – Rows from both tables are moved into a newhome.

• Replicate-1 – One of the tables is replicated onto partitions of theother table’s home.

Joins are processed at the local SQL Server level and all servers areautonomous with respect to all other servers. Therefore, it is oftennecessary to repartition one or all of the tables referenced by the joinquery. For the join to be processed completely, all matching rowsfrom the joining tables must reside on the same server.

For join queries, good index selections at the local SQL Server level,and minimized or reduced data movement at the parallel level,contribute to optimal performance.

Repartitioning and replication operations generate a copy of therows to be joined and store them in a temporary work table within



tempdb. This work table is then used in the join operation at the SQLServer level.

Advantages and Requirements for In-Place Joins

The PSQL optimizer chooses the strategy that results in the leastmovement of data. The in-place strategy is chosen wheneverpossible because it eliminates the overhead of data movement.Because the in-place strategy is the most efficient, it is important toknow the requirements for its usage so that you can take advantageof it whenever possible.

All the following conditions must be met before a join can beprocessed in place:

• Tables are joined on their partitioning keys: t1.decl_key =t2.decl_key.

• Tables have the same partitioning mode: hash, range, or schema.

• Tables are partitioned on the same SQL Servers, with the serversspecified in the same order in the sp_place_table commandpreceding the table definition.

• Tables have compatible partitioning keys. Both keys must bedefined with only a single column and have the same datatype(compatible datatypes are not enough to meet this criteria). If thetable is hash declustered, the string keys must have the samelength.

• Tables have identical range intervals or hash function.

Example of an In-Place Join

In the following query, two tables are being joined on theirpartitioning key column.

select h1.colA, h2.colBfrom hash_tab1 h1, hash_tab2 h2where h1.dkey = h2.dkey

Assuming the two tables are identically hash partitioned (the samehome servers and the same key datatypes), an in-place strategy canbe used. In this case, the end-user query can be executed verbatim onthe home SQL Servers of the two tables and the results collected bythe Control Server.

Binary (two-way) in-place joins do not involve any data movementvia the Split Servers nor do they require any Sybase MPP temporarywork tables. Rather, the original tables are joined in parallel by each



SQL Server that owns a fragment of the data. At the local level, eachSQL Server independently processes the join for its piece of the data(the SQL Servers are totally unaware of Sybase MPP and each other).Join processing at the SQL Server level centers around the use of thenested iteration strategy and indexed access methods.

Example of a Redecluster-1 Join

The query below is an example of when the redecluster-1 strategy isapplied:

select h1.colA, h2.colBfrom hash_tab1 h1, hash_tab2 h2where h1.dkey = h2.nonkey and h2.colB > 100

In this example, table hash_tab2 is being joined on a column that is notits partitioning key. Most likely, the query optimizer will choose tohash redecluster hash_tab2 onto the home servers of hash_tab1. Theresulting work table will reside in tempdb and will be partitionedidentically to the table that did not move, namely hash_tab1. After theredecluster operation, the SQL Servers are instructed to join tablehash_tab1 with the generated work table.

In an effort to minimize the amount of data to be moved, anyrelevant select constraints on the table being repartitioned are appliedimmediately. This technique is sometimes referred to as “pushingselects ahead of joins,” because it reduces the number of rowsinvolved in the subsequent join operation. In the example, theconstraint h2.colB > 100 is applied to the SQL module that is executedby the split thread.

The various sub-operations of repartitioning represent a pipeline. Assoon as rows begin arriving from the split thread’s select operation,they are piped through split/merge operations and into the bcp insertoperation. However, the pipelining does not continue into the joinoperation. The redecluster operation must fully complete before thesubsequent join step can proceed.

At the local SQL Server level, join processing proceeds as usualexcept that a work table is being used rather than the original table.To SQL Server, the work table is like any other user table that hasbeen created in tempdb.

A by-product of repartitioning is that any indexes on the originaltable are no longer available for the join operation. As a result, SQLServer frequently considers reformatting (dynamic index creation)when faced with Sybase MPP temporary work tables. Currently,



Sybase MPP does not explicitly instruct SQL Server to create indexeson work tables.

Example of a Redecluster-2 Join

This query exemplifies the use of the redecluster-2 strategy:

select h1.colA, h2.colBfrom hash_tab1 h1, hash_tab2 h2where h1.nonkey = h2.nonkey

In this example, neither table is being joined on its partitioningcolumn. Redecluster-2 is the standard method of handling suchjoins. Tables hash_tab1 and hash_tab2 are both repartitioned on theirjoining column onto a common set of home servers.

The actual execution of a redecluster-2 uses two back-to-backredecluster-1 operations. However, for the redecluster-1 strategy, theSQL Servers involved in the merge operation and subsequent joinoperation are dictated by the home servers of the table that does notmove. For a redecluster-2 strategy, the system is free to choose anycommon set of SQL Servers. The query optimizer chooses the homeservers of the table that has the greatest number of servers.

Example of a Replicate-1 Join

This query is an example of when one of the joining tables isreplicated.

select b.colA, s.colBfrom big_table b, small_table swhere b.nonkey = s.dkey

The replicate-1 strategy works for any join or cross product. It isalways legal to replicate either one (but not both) of the two tablesbeing joined regardless of the query. Replication involves buildingan entire copy of one table on every server in the other table’s home.For large tables, this is very time consuming and requires atremendous amount of tempdb space. Therefore, replicate-1 is usedonly when necessary, such as for non-equijoins.

Enough tempdb storage must be configured to hold the copy of thereplicated table on every server in the table’s home. The tempdbstorage requirement for the replicated table can be calculated as:

(sum of the columns being replicated, in bytes) * (number of rows in thetable)

If table s in the example above has a cardinality of 1M (rows), thetempdb storage requirement for all servers in the home of table b is:



card(s) * (byte(s.colB) + byte(s.dkey))

If columns colB and dkey are both 4-byte integers, the storagerequirement to hold the copy of s is 8MB per server in the home of theresident table.

In some cases, replicate-1 is the preferred strategy, such as when alarge table is joined with a small table, and the large table is notdeclustered on its joining column. Rather than repartitioning thelarge table, it can be more efficient to replicate the smaller table.

Joins and Datatypes

When joining two columns of different datatypes, one of the columnsmust be converted to the datatype of the other column. The columnwhose type is lower in the type hierarchy is the one that is converted.When processing joins between columns of different datatypes, keepthe following in mind:

• The local optimizer cannot choose an index on the column that isconverted.

• The global (parallel) optimizer does not recognize an in-placejoin, even if the two tables are declustered identically on thejoining columns.

To highlight the second point, consider the binary join query:

select sum(t5x.in10)from t5x, t5dxwhere t5x.in10m = t5dx.d08seq

in which t5x.in10m is of type integer and t5dx.d08seq is of type float.Semantically, the join adequately expresses a join relation betweentwo tables. However, Sybase MPP’s optimizer does not recognize thewhere clause as a usable join clause, and chooses to replicate one of thetables into the home of the other table, which is the most costlyprocessing strategy.

After the replicate step, the replicated work table and the residenttable are joined locally in the home of the resident table. During thisstep, the local optimizers are unable to recognize a usable index onthe join column of the resident table due to the need for convertingjoin column types.

Multiway Join Processing

Sybase MPP processes multiway joins as a series of binary join steps.The results from each binary join operation are either materialized



in-place or serve as input to a redecluster operation in preparationfor being joined with the next table in the chosen join order.

The optimizer chooses the global join order, which determines thesequence of binary join steps. For each binary join executed at theSQL Server level, SQL Server chooses the local join order, whichdetermines the inner and outer table during nested loops. Theexecution plans produced for multiway joins are always left-deep inthat they express join orders of the form (((A * B) * C) *D).

The binary joins steps are executed serially following the specifiedleft-to-right pair ordering. For a given query, only a single binary joinoperation is executing at any given time. In addition, a binary joinoperation must fully complete before the next step can begin.

The multiway join (((A * B) * C) * D) would be executed in thefollowing order:

1. (A * B) → worktab1

2. (worktab1 * C) → worktab2

3. (worktab2 * D) → results sent to Control Server

Multiway joins are currently executed in a strict binary join fashion,even in those cases where a block of three or more tables can beexecuted in-place. In the Sybase MPP environment, the local SQLServers are limited to executing binary joins. In such multiway in-place cases, the results from each binary join step are materialized in-place using a select into command.

Example of Repartitioning Intermediate Results

The repartitioning of intermediate results as they occur for multiwayjoin queries is illustrated by the following query:

select r1.colA, r2.colB, r3.colCfrom range_tab1 r1, range_tab2 r2, range_tab3 r3where r1.dkey = r2.dkey and r2.nonkey = r3.dkey

In this three-way join example, tables range_tab1 and range_tab2 canbe joined in-place based on the join predicate r1.dkey = r2.dkey.However, the join operation between range_tab2 and range_tab3requires some form of data redistribution. The query optimizer willmost likely choose a global join order consisting of ((range_tab1 *range_tab2) * range_tab3).

The results from the first binary join step represent a logical tablewhose partitioning key is column dkey. In the next binary join, thislogical table is to be joined with range_tab3 using the predicater2.nonkey = r3.dkey. Given the fact that range_tab3 is being joined on its


Sybase MPP Release 11.0.x Aggregate Processing

partitioning key, the likely strategy is to leave range_tab3 in-place andredecluster the step 1 results on column nonkey. For example:

1. Join tables range_tab1 and range_tab2 in place.

2. Redecluster the intermediate join results producing work_table.

3. Perform a join between range_tab3 and work_table.

Example of a Multiway In-Place Join

The query below illustrates the strategy employed for multiway in-place joins.

select r1.colA, r2.colB, r3.colCfrom range_tab1 r1, range_tab2 r2, range_tab3 r3where r1.dkey = r2.dkey and r2.dkey = r3.dkey

In this example, all three tables can be joined in-place without anydata redistribution. Assuming the optimizer chooses a global joinorder of ((range_tab2 * range_tab3) * range_tab1), tables range_tab2 andrange_tab3 will be joined in-place and the results materialized into awork table. This materialization is not done via the Split Serversubsystem, instead, a select into operation is added to the join queryexecuted by the SQL Servers. This work table is then joined in-placewith the next table in the global join order, range_tab1.

The in-place materialization of work tables is done using a select intocommand rather than an insert command. Issuing a create tablecommand followed by an insert command would cause unnecessaryoverhead from transaction logging. select into does not log the insertoperations. Because MPP work tables contain only copies of theoriginal data or intermediate results, they are not required to berecoverable via transaction logs.

Aggregate Processing

In Sybase MPP, the SQL features that are related to aggregation andsorting are collectively referred to as report features. This list offeatures includes aggregate functions and the group by, having, distinct,and order by options.

The primary goal of vector (aggregate) processing is to form groupsand compute any associated aggregates. The method in which theseoperations are carried out is dependent on whether or not the data isalready partitioned according to the grouping items.

For example, aggregation is typically performed by having each SQLServer compute the aggregate result for its partition. These partial


Aggregate Processing Sybase MPP Release 11.0.x

aggregate results are then sent to the Control Server, which mergesthem to form the final aggregate result.

Within the Control Server, the Control Server Interpreter (CSI)performs the centralized merging. The CSI computes final results bymaking a singe pass over a given set of data streams (the results froma single SQL Server form a “stream” of rows).

The basic aggregate processing steps are:

1. Divide rows into groups based on the group by list.

2. Eliminate duplicate column values for distinct aggregates.

3. Calculate aggregates.

4. Apply having clause to exclude groups that do not meetconstraints.

5. Eliminate duplicate result rows if distinct is applied.

6. Order the final results according to the order by list.

Optimal In-Place Strategy

When the data is partitioned on the group by clause, then all rows fora given group reside on the same SQL Server. Hence, steps 1–4,which include forming the groups, calculating aggregates, andapplying having constraints, can be carried out entirely at the SQLServer level. Steps 5 and 6 must still be carried out centrally by sortmerging the individual data streams. This is considered to be theoptimal strategy because the aggregates can be computedcompletely at the local level.

General In-Place Strategy

In a general in-place strategy, the data is not declustered on groupingitems. The SQL Servers are instructed to form groups and anyassociated aggregates for their local partition and return the resultsto the CSI in order of the group by clause. The CSI then merges theseresults to form the final groups and aggregates. For each groupedrow formed, the CSI then applies the having qualification, if any.

Repartitioning Strategy

In some cases, a query’s semantics require the data to berepartitioned on the group by list prior to processing the report


Sybase MPP Release 11.0.x Aggregate Processing

features. The query optimizer applies a list of rules that the querymust satisfy in order to remain in-place. If the query violates any oneof these conditions, the results are first repartitioned on the group bylist and processing continues as in the optimal in-place case.

In-place results cannot be merged; they must be repartitioned. Thedata is repartitioned on the group by list in an effort to place groupvalues onto the same SQL Server. Aggregate processing can thenproceed as in the optimal in-place strategy. Conditions that require aredecluster operation are as follows:

• Report features are embedded within an insert or select intocommand.

• The specified order by list does not match the group by list.

• A distinct result row clause is specified.

• Distinct aggregates are declared on non-partitioning keycolumns.

• Nested aggregates are specified.

Sorting

The general strategy for ordering results or eliminating duplicatesrelies on the merging services of the CSI. Within the context of aninsert command, the engine must rely solely on processing stepscarried out via SQL Servers and Split Servers.

In the case of distinct processing, the data is first repartitioned on oneof the select list items in an effort to place duplicate result rows ontothe same SQL Server. The distinct is then processed exclusively by theSQL Servers.


Aggregate Processing Sybase MPP Release 11.0.x


9 Using REELlibrarian withSybase MPP 9.

This chapter describes how to use REELlibrarian with Sybase MPP.

Installing REELlibrarian

Refer to the instructions in your REELlibrarian Installation Guide,which accompanies the REELlibrarian tape.

You must do one of the following tasks to set the REELlibrarianenvironment:

• Select /etc as the directory path for the REELlibrarianenvironment file, reelenv, or

• Set environment variable REELENV to the full path of theREELlibrarian environment file. REELENV must be set in .profile.

Although only one of these tasks is required, we recommend thatyou do both.

Managing REELlibrarian

You need to perform the following tasks when using REELlibrarianwith Sybase MPP:

• Configuring REELlibrarian

• Starting REELlibrarian

• Add User Tape Pool

• Test REELlibrarian

• Submit Tapes to user Pool

• Configure Sybase MPP Dump Devices

• Backup and Restore with Sybase MPP

Configuring REELlibrarian

➤ NoteMost REELlibrarian configuration changes require REELlibrarian to be

restarted.

9-2 Using REELlibrarian with Sybase MPP

Managing REELlibrarian Sybase MPP Release 11.0.x

Use rlconfig to configure REELlibrarian (refer to REELlibrarian MasterGuide for rlconfig usage) and then perform the following steps:

Step Description

1. Add the following operators:

rootmpp

2. Add all available tape drives.

Master List example:

Assigned name (ADN): fatty_tapeMachine: fattyAuto Density Detect: *YESAuto Density Select: *YES

Format List example:

Media Type: DATTapecap: DATNo Rewind: /dev/rmt0K byes/sec: 250K Eff. bsize:

Note: In Format List, press q to display the Other Device List. Once inOther Device List, press q to end the session.

3. Check media lengths.

• At the Rlconfig main menu, go to Media Type Aliases.

• In the tape types Master List, scroll to the type you wish and press efor edit.

• Press Enter to get the Default Length. (You may have to press Enterthree or four times.)

• Enter the tape capacity.

Note: This number must match1) the CAP value used when submitting scratch volumes, or2) the size parameter used on the sp_addumpdevice statements.

• Press q twice to return to Rlconfig main menu.

4. Suppress Unmount Requests

From the Rlconfig main menu, go to Miscellaneous screen, press Enterto get to Suppress Unmount Requests, select YES by pressing the spacebar, press Enter twice to return to the main menu.


Sybase MPP Release 11.0.x Managing REELlibrarian

Starting REELlibrarian

1. Start REELlibrarian on master node:

reel start

2. Start REELlibrarian on all the client nodes:

reel start

Add User Tape Pool

Add the “mpp” Tape Pool by performing the following tasks:

• a - adds a user

• Add “mpp” and “root”

5. site_exits File

Add the following line to $RLLIBDIR/REEL/Librarian/site_exits forevery drive:

drive_name stkmount stkunmount none

where drive_name is the REELlibrarian drive name (ADN) you areusing. (For example, “fatty_tape”.)

Note: These entries tell REELlibrarian to use stacker logic for tapemount and unmount requests against the named drives. This way,tape operators do not need to manually mount tapes through rlmon.However, manual tape changes are required when multiple realmsare backed up through one single slot drive.

Step Description

1. Select 3 , User Tape Access.

2. Select 9, Pools.

3. Space over the CREATE and press Enter.

For example:

Pool Name:mppCleaning Regime: *NOEnd-of-Lif Disposal: *NODays before Recycle: 0In User List

Step Description



• q - quits and saves

• q - quits, saves, and returns to main menu

Test REELlibrarian

Test REELlibrarian by performing the following tasks:

Submit Tapes to user Pool

Submit tapes to “mpp” pool.

rlpsubmit type= “2000” cap=2000 rack=310000 vid=310000vsn=310000 pool= “mpp”

rlid adn=fatty_tape 3100000

➤ NoteThis must be done on the node connected to fatty_tape.

Step Description

1. Type “rldtest”.

At the prompt, enter the REELlibrarian tape drive names (ADN)configured earlier.

2. Follow “A Test Run” in REELlibrarian Master Guide, Chapter 1.


Sybase MPP Release 11.0.x Managing REELlibrarian

Configure Sybase MPP Dump Devices

Follow these steps to configure Sybase MPP dump devices:

Task Description

1. Prepare a SQL script that adds the tape devices to the Sybase MPP server configuredinto REELlibrarian. For example:

sp_addumpdevice "tape", S1120000_fatty_tape,"/dev/rmt0", 3, skip, 2000, 8gosp_addumpdevice "tape", Q1150002_fatty_tape,"/dev/rmt0", 3, skip, 2000, 8gosp_addumpdevice "tape", Q1150003_fatty_tape,"/dev/rmt0", 3, skip, 2000, 8gosp_addumpdevice "tape", Q1150004_charles_tape,"/dev/rmt0", 3, skip, 2000, 8gosp_addumpdevice "tape", Q1150005_charles_tape,"/dev/rmt0", 3, skip, 2000, 8go

Note: Where:

• fatty_tape and charles_tape are logical names assigned to tape drives inREELlibrarian (ADN)

• 3 specifies a tape

• 2000 specifies the tape capacity in MB

• 8 specifies the drive type (2000)

2. isql -Usa -P -SC1130002 < script created above

3. Define database settings using gd_set_dbrf_defaults system procedure.



Backup and Restore with Sybase MPP

Perform backup and restore operations by following these steps:

Step Description

1. Initiate backup/restore requests through the Sybase MPP ManagerBackup/Restore option or isql.

Example:

dump database finance to navtape_dumpdevice

Note: If you have edited “site_exits” to do automounting. This task iscomplete. If not, go to step 2.

2. Login as “root” and type “rlmon”. (Refer to the REELlibrarian MasterGuide.) After issuing the dump database command, the rlmon screendisplays mount requests in the lower portion. Put the tape identifiedby the rack number displayed on the request line into the tape drive.Select *MNT-DONE at the bottom of the screen and press Return. Awindow displays and prompts for volume ID. Enter volume ID andpress Return.

3. One tape is used for each realm being backed up. Repeat step 2 untilall the tapes have been mounted.


10 Interpreting Parallel Query PlansUsing the Explain Utility 10.

This chapter describes how to interpret parallel query plans usingthe Explain utility.


• Parallel Query Summary 10-1

• Turning on Explain 10-2

• Explain Output 10-2

Parallel Query Summary

There are two levels of query processing:

The Explain utility allows you to display the query plans chosen bythe query optimizer. The Explain utility reports:

• The global parallel processing plan for a query.

• The local SQL Server query plan. This is the same information asis generated by using set showplan in SQL Server. The SQL ServerSystem Administration Guide explains the information set showplanprovides.

Explain serves as a tool for performance and tuning activities. Itprovides a means of learning more about the Sybase MPP queryprocessing strategies.

Query Description

Global This is performed by the Parallel SQL (PSQL) compiler.

In global optimization, the PSQL compiler determines the overallexecution strategy of a query, such as the number of SQL Serversparticipating in the request, whether data needs to berepartitioned, and the join order. The PSQL compiler does notinstruct the SQL Servers how to execute the query.

Local This is performed by each SQL Server.

At the local level, each SQL Server does its own local optimization,such as sorting, and index access methods.

10-2 Interpreting Parallel Query Plans Using the Explain Utility

Turning on Explain Sybase MPP Release 11.0.x

Turning on Explain

There are two ways to invoke the Explain utility:

execute sp_pragma "opt_explain", "on" | "off"

or

set showplan on | off

Explain displays output for the current session, and takes effectimmediately with respect to the current batch.

When using Explain, sometimes you may want to turn off theexecution of queries using the set noexec on command. If you do, thelocal SQL Server query plan is not displayed. The Explain utilityshould be turned on before issuing the set noexec on command. To turnquery execution back on, use the set noexec off command.

The Explain utility remains in effect until you end the session, orexplicitly turn it off.

Explain Output

Explain sends the local SQL Server query plan information back toyou in the form of messages. On a multi-node system this output canbe lengthy and hard to view on your screen. You can redirect theoutput to a file in the same way as described for basic output, below.

Explain automatically generates two versions of output informationon the parallel query plan, basic and detailed. These are described inthe following sections.

The Explain output consists of high-level descriptions of the internalprocessing steps chosen by the query optimizer. Certain classes ofqueries, most notably subqueries, are rewritten by Sybase MPP intosemantically equivalent queries during the compilation phase. TheExplain output for such queries describes the processing of therewritten query as opposed to the original end-user query.

The query text being compiled is included in the output. Currently,only U.S. English and the ASCII character sets are supported.

Basic Output

Basic information about the parallel plan is sent back to you in theform of messages. You can view the basic output on your terminal, orredirect it to a UNIX file by using:


Sybase MPP Release 11.0.x Explain Output

• The UNIX redirection command:

isql -Usa -P password -SC 0130002 > outputfile

• The isql -o output file option:

isql -Usa -P password -S C0130002 -o outputfile

The basic output includes a brief description of the query processingsteps executed at the parallel level, and the SQL commandsgenerated for the parallel query plan. Predictions about the local SQLServer processing are not included. The basic Explain output consistsof:

• Single-table processing

- Useful search arguments on the partitioning key.

- The number of participating servers in the request.

• Join processing

- Useful join clauses on the partitioning key

- Chosen table order for joining

- Repartitioning or replication steps

- Work tables and intermediate results

- Number of servers participating in the join

• Report-feature processing

- Required repartitioning (if any)

- Result merging done in the Control Server

• insert select processing


• Final result row estimate for the query

• SQL commands generated for the query batch

Example

For the following query:

execute sp_pragma "opt_explain", "on"goselect table1.tenPercent, count(table1.ten)from table1, table2where table1.ten = table2.tengroup by table1.tenPercentgo


Explain Output Sybase MPP Release 11.0.x

The basic Explain output is:

Step 1------Table ‘wiscFT.dbo.table1’ is redeclustered on column ‘ten’and stored in work table ‘#w1’.Table ‘wiscFT.dbo.table2’ is redeclustered on column ‘ten’and stored in work table ‘#w2’.tables ‘#w1’ and ‘#w2’ are joined on 3 SQL Servers.

The relevant join clause for this step is:wiscFT.dbo.table2.ten EQ wiscFT.dbo.table1.ten

The processing of report features (Aggregates, Group By,)is done inplace as part of this step.Vector aggregate processing(Aggregates-GroupBy-Having) isperformed by having each SQL Server calculate its partialaggregates/groups and sort-merging these results centrally.

Estimated #rows retrieved: 10Estimated response time: 0.79 secondsEstimated system cost: 2.38 secondsEstimated work space required: 2 pages

SQL Module(s) for the current batch-----------------------------------select a.tenPercent, a.ten from wiscFT.dbo.table1 a

create table tempdb..cg_30002_36_0 (cg_work_col_1 int null,cg_work_col_2 int null)

select a.ten from wiscFT.dbo.table2 a

create table tempdb..cg_30002_36_3 (cg_work_col_4 int null)

select a.cg_work_col_1, count(a.cg_work_col_2)from tempdb..cg_30002_36_0 a, tempdb..cg_30002_36_3 b,where b.cg_work_col_4 = a.cg_work_col_2group by a.cg_work_col_1 order by 1

drop table tempdb..cg_30002_36_0, tempdb..cg_30002_36_3drop table tempdb..cg_30002_36_0drop table tempdb..cg_30002_36_3

Detailed Output

By default, detailed information on the parallel query plan—outputfrom each user session using Explain—is sent to$NAVIGATOR/explain.detail on the primary Sybase MPP node.Output is appended to the end of existing files.



➤ NoteExplain output cannot be returned to the requesting client.

To send output from a session to a specific file, use:

execute sp_pragma "opt_explain", "filename"," myfile "

This command sends output to $NAVIGATOR/myfile.detail.

The output includes detailed descriptions of the query processingsteps executed at both the parallel and local level. Partitioning andindex information for each table referenced is also displayed. Thedetailed Explain output consists of the following:

• insert values processing

- Server ID on which the row is inserted

- The relevant partitioning key value

• Single-table processing

- Useful search arguments on the partitioning key

- List of servers (IDs) participating in the request

- If trace flag 1102 or 1250 is turned on, the predicted local accessmethod: chosen index (if any); estimated page accesses andqualifying rows

• Multi-table processing

- Binary join steps for n-way joins (join order)

- Repartitioning or replication steps (if any)

- Relevant join clauses on the partitioning keys

- Work tables and intermediate results

- List of servers (IDs) participating in the join steps

- If trace flag 1102 or 1250 is turned on, the local join method(nested iteration or reformat): chosen inner and outer tables;access method (index) for each table; estimated page accesses

• Report-feature processing


- Result merging done in the Control Server

• insert/select processing




• Final cost estimates for multi-table queries

- Row cardinality estimates

- Disk, CPU, and network costs

- Time estimates

• If trace flag 1102 or 1250 is turned on, exhaustive search statistics

- Number of query plans considered

- Whether or not a connected path was found

• Directory information for each table referenced

- Partitioning and index information

- If trace flag 1102 or 1250 is turned on, current table statistics

• Configuration values for the MPP optimizer

• Available system resources (cache, disk, workspace, and so on)

• SQL commands generated for the query batch

Example

For the following query:

execute sp_pragma "opt_explain", "on"goselect table1.tenPercent, count(table1.ten)

from table1, table2where table1.ten = table2.tengroup by table1.tenPercent

go

The detailed Explain output is:

===============================================================QUERY OPTIMIZER - PLAN INFORMATION Thu Jun 8 09:38:01 1995

------------------------------------------User Entered Commands------------------------------------------select table1.tenPercent, count(table1.ten)from table1, table2where table1.ten = table2.tengroup by table1.tenPercent



------------------------------------------Command being Optimized------------------------------------------select “tenPercent” = a.tenPercent, count(a.ten) fromwiscFT.dbo.table1 a, wiscFT.dbo.table2 b where a.ten = b.tengroup by a.tenPercent

------------------------------------------Parallel Join Processing------------------------------------------

Step 1------

Sybase MPP processing----------------------------

Table ‘wiscFT.dbo.table1’ is redeclustered on column ‘ten’and stored in work table ‘#w1’.Servers participating in the select-split operation:

50002, 50003, 50004,Servers participating in the merge operation:

50002, 50003, 50004

Table ‘wiscFT.dbo.table2’ is redeclustered on column ‘ten’and stored in work table ‘#w2’.Servers participating in the select-split operation:

50002, 50003, 50004,Servers participating in the merge operation:

50002, 50003, 50004Tables ‘#w1’ and ‘#w2’ are joined on 3 SQL Servers.

Servers participating in the join operation:

50002, 50003, 50004

The relevant join clause for this step is:wiscFT.dbo.table2.ten EQ wiscFT.dbo.table1.ten

The estimated number of result rows from this step is 33 (perserver).

-------------------------------------------------Join Processing - Final Query Plan Cost estimates-------------------------------------------------

Join Cardinality Estimates:Total qualifying rows: 99Avg. rows per server: 33



Average data server usage:logical page reads: 42physical page reads: 10network messages: 2rows split: 66rows merged: 66modules activated: 9

Total system resource usage:logical page reads: 126physical page reads: 30network messages: 6rows split: 198rows merged: 198modules activated: 27

Estimated response time cost: 794 milisecondsEstimated total system cost: 2382 millisecondsEstimated work space required per server: 2 pages

-------------------------------------------------Parallel Report Feature Processing-------------------------------------------------Report features being processed:

-Aggregates-Group By

Report features are processed inplace in conjunction with thecurrent select or join step.The data is NOT partitioned on the grouping items.Hence, the local SQL Servers compute partial report resultsand final groups and/or aggregates are formed centrally.

Estimated #qualifying rows from report processing: 10

-------------------------------------------------Selectivity Estimates - Number of Qualifying Rows-------------------------------------------------Table wiscFT.dbo.table1 - Search Predicates:

There are no relevant search predicatesEstimated compound selectivity: 1.000Estimated qualifying rows (per server): 33

Table wiscFT.dbo.table1 - Join Predicates

wiscFT.dbo.table2.ten EQ wiscFT.dbo.table1.tenEstimated join column(s) selectivity 0.030Estimate made WITHOUT statistics.

Matching rows per scan on this table (per server): 1

Table wiscFT.dbo.table2 - Search Predicates:



There are no relevant search predicatesEstimated compound selectivity: 1.000Estimated qualifying rows (per server): 33

Table wiscFT.dbo.table2 - Join Predicates

wiscFT.dbo.table2.ten EQ wiscFT.dbo.table1.tenEstimated join column(s) selectivity 0.030Estimate made WITHOUT statistics.

Matching rows per scan on this table (per server): 1

--------------------------------------------------Declustering Information - Table wiscFT.dbo.table1--------------------------------------------------

Decluster mode: RangeHome degree: 3Home servers: 50002, 50003, 50004,Decluster key: unique2,Range values: 33, 66, 2147483647,

Total Rows: 100Total data Pages: 12Rows per server: 33Pages per server: 4Row size: 210 bytes

Unique Clustered Index (id=1) on column ids (02)Index Statistics:

Density (sarg): 0.030Density (join): 0.030Histogram has 99 steps

Non-clustered Index (id=2) on column ids (08)Index Statistics:


--------------------------------------------------Declustering Information - Table wiscFT.dbo.table2--------------------------------------------------

Decluster mode: RangeHome degree: 3Home servers: 50002, 50003, 50004,Decluster key: unique2,Range values: 33, 66, 2147483647,

Total Rows: 100Total data Pages: 12Rows per server: 33Pages per server: 4Row size: 210 bytes



Unique Clustered Index (id=1) on column ids (02)Index Statistics:


Non-clustered Index (id=2) on column ids (08)Index Statistics:


-----------------------------------------------------Configurable Parameter Values - Optimizer-----------------------------------------------------

Cost Objective: Response TimeCost Model Weights:

network message: 10module startup: 20split overhead: 1merge overhead: 1bcp insert: 3logical read: 2physical read: 18reformat insert: 5reformat overhead: 10000

Join order pruning: Onmax outer rows: 25max tables: 2

Limit opt time: OffDefault Selectivities:

equality: 10open range: 33interval: 25

Consider all servers: Off

------------------------------------------------System Resources Available (per server)------------------------------------------------tempdb size (#pages): 47104data cache (#pages): 7663network buffer (#pages): 32768

SQL Module(s) for the current batch:------------------------------------

SQL Module name: sql_802629481_0;1

select a.tenPercent, a.ten from wiscFT.dbo.table1 a




create table tempdb..cg_30002_36_0 (cg_work_col_1 int null,cg_work_col_2 int null)


select a.ten from wiscFT.dbo.table2 a


create table tempdb..cg_30002_36_3 (cg_work_col_4 int null)


select a.cg_work_col_1, count(a.cg_work_col_2)from tempdb..cg_30002_36_0 a, tempdb..cg_30002_36_3 bwhere b.cg_work_col_4 = a .cg_work_col_2group by a.cg_work_col_1 order by 1


drop table tempdb..cg_30002_36_0, tempdb..cg_30002_36_3


drop table tempdb..cg_30002_36_3


drop table tempdb..cg_30002_36_0


Large I/O Buffer Manager 11.


• Large I/O Overview 11-1

• Guidelines for Using Large I/O 11-1

• Enabling Large I/O 11-3

• Disabling Large I/O 11-4

• Technical Notes 11-4

Large I/O Overview

Large I/O consists of the following features:

• Ability to read and write I/O in 16K increments, whichrepresents an 8-fold increase over the old limit of 2K per I/Ooperation.

• Prefetch the data required to satisfy user queries.

• This results, for some operations, in a three-four fold increase inthroughput.

16K buffers are only used in full table scan with no index, bcp loads,and building a new distribution page for an index (part of indexcreation). All other operations use 2K buffers.

Guidelines for Using Large I/O

Large I/O is controlled by a single sysconfigures parameter:cfg16kbufpool. When sp_configure is run, this parameter is displayed as“16K buffer pool percentage.”

cfg16kbufpool is a tunable parameter which controls the percentage ofcache memory which will be used for 16K I/O (the 16K buffer pool).The remaining percentage is allocated to 2K I/O operations (the 2Kbuffer pool). A buffer pool is an area of memory within the cache thatcontains like-sized buffers linked together on a most recentlyused/last recently used (MRU/LRU) list.

The first step for using Large I/O is to determine what value shouldbe used for cfg16kbufpool.The remainder of this section providesguidelines for choosing an appropriate value.

11

11-2 Large I/O Buffer Manager

Guidelines for Using Large I/O Sybase MPP Release 11.0.x

Minimum Value for cfg16kbufpool (Default Value)

The minimum value for cfg16kbufpool is 0. At this setting, alloperations use 2K I/O. This is the default setting.

Maximum Value for cfg16kbufpool

The absolute maximum for cfg16kbufpool is 99 (99% of the availablecache memory is allocated to the 16K buffer pool). However, there isanother limitation which must be considered.

The 16K buffer pool is only used in full table scan with no index, bcploads, and building a new distribution page for an index (used by thecreate index and update statistics T-SQL commands). All other operationsuse 2K buffers.

It is critical that enough memory be allocated to the 2K buffer pool toperform these other operations. The absolute minimum required bythe 2K buffer pool is 512K.

➤ NoteIf cfg16kbufpool is set so high that 512K of memory is not available to the

2K buffer pool, then the SQL Server will not boot. If you encounter this

situation, see the technical note at the end of this chapter for the recovery

process.

A rule of thumb is: Set cfg16kbufpool below 90 (90%).

At this setting you are guaranteed to have enough 2K buffers, even atthe minimum SQL server memory value. See the technical notessection at the end of this chapter for a procedure to determine themaximum setting which guarantees enough 2K buffers.

Choosing an Optimal Value for cfg16kbufpool

cfg16kbufpool is a tunable performance parameter. There is no hardand fast rule on how this should be set, since it is dependent uponseveral factors. You will have to experiment with various values todetermine an appropriate setting for your installation. The followingfactors should be taken into consideration when choosing a value.

• Workload: If your workload consists of mostly OLTPtransactions, cfg16kbufpool should be set low, since it is unlikely


Sybase MPP Release 11.0.x Enabling Large I/O

that your transactions are using full table scans. If the workload isDSS-oriented, set cfg16kbufpool higher.

• Full-table scans: The only operations which use Large I/O are fulltable scans without index, bulk copy in, and building a newdistribution page for an index. If you have a small number ofcanned queries, you may wish to run them with set showplan on tosee if the queries are use full table scans without index. If thequeries run full table scans, set cfg16kbufpool higher.

• Avoid the maximum value: Setting cfg16kbufpool to the maximumvalue is unlikely to increase performance, since this limits theamount of memory available to the 2K buffer pool. Use moderatevalues.

• Memory value: The lower the amount of memory allocated toSQL Server, the lower you should set cfg16kbufpool, in order toallow enough 2K buffers for other operations.

A good starting point is to set cfg16kbufpool to 50 and adjust fromthere.

Enabling Large I/O

Create the 16K buffer pool by following these steps:.

Example:

1. sp_configure “16K”, 50

2. go

3. reconfigure with override

4. go

Step Description

1. Connect to a Control Server using isql.

2. Run sp_configure “16K”, 16K_pool_percentage. 16K_pool_percentageis the percentage of cache you want to be used for 16K I/O(cfg16kbufpool)

3. Run reconfigure with override.

4. Shut down and restart the MPP instance.

5. Run sp_configure and confirm that the 16K buffer pool percentagevalue is set to the value chosen.


Disabling Large I/O Sybase MPP Release 11.0.x

5. <shut down and restart the MPP instance>

Disabling Large I/O

Delete the 16K buffer pool by following these steps:

Example:

1. sp_configure “16K”, 0

2. go

3. reconfigure with override

4. go

5. <shut down and restart the MPP instance>

Technical Notes

Determining the maximum number of 16K buffers

The following procedure allows you to determine the maximumsetting of cfg16kbufpool.

1. Start the MPP server up.

2. cd to the $SYBASE/install directory and examine an errorlog filefor one of the realm servers (not the schema server). Look for thephrase “Memory allocated for the default data cache.” This is theamount of memory available to the buffer pools.

3. Use the following formula to determine the maximum value forcfg16kbufpool. In the formula below, M is the number determinedin step 2.

Step Description

1. Connect to a Control Server using isql.

2. Run sp_configure “16K”, 0

3. Run reconfigure with override.

4. Shut down and restart the MPP instance.

5. Run sp_configure and confirm that the 16K buffer pool value is set tothe value chosen.


Sybase MPP Release 11.0.x Technical Notes

(M - 512KB)/M

For the default values of MPP this is:

(10092KB - 512KB)/10092KB = .949

The value of cfg16kbufpool must not be set higher than 94 (94%) usingthe default MPP Server memory value.

Recovering from an Overly High Setting of cfg16Kbufpool

To recover from a value of cfg16kbufpool which is so high that theserver will not boot:

1. Shut down the instance, and for every SQL server, do thefollowing:

2. cd to the $SYBASE/install directory

3. Look at the RUN_QXXXX files. These will tell you where theSQL server master devices are.

4. Run the following:

$SYBASE/bin/buildmaster -d<masterdevice>-ycfg16kbufpool=0

Example

buildmaster -d/dev/rlvqa3 -ycfg16kbufpool=0

5. After all SQL servers have been reconfigured, restart theinstance.

◆ WARNING!This is an emergency procedure only. If the server will start, runsp_configure to change the value instead.

Config Block parameters

Table 11-1: New Config Block Entries

Attribute Name Datatype Description

cfg16kbufpool long The percentage of the total default data cache tobe used for the 16K buffer pool.


Technical Notes Sybase MPP Release 11.0.x


12 The Parallel Optimizer 12.


• Overriding the Parallel Optimizer 12-1

• Configuring the Parallel Optimizer 12-6

Overriding the Parallel Optimizer

The Sybase MPP cost-based optimizer generally chooses efficientprocessing strategies. However, you can override the optimizer’schoices. The override directives are designed to control the choicesmade at the parallel level, although they do provide some controlover the choices made locally by SQL Server.

The override directives are normally used in conjunction with theExplain utility. If the output from the Explain utility shows that thechosen plan is suboptimal, a careful investigation of the problemshould be conducted. Check for poorly written queries or poordatabase design before deciding to use the override directives.

Setting the Override Directives

You can execute override directives using the system proceduresp_pragma as follows:

execute sp_pragma "opt_overide", directive

where directive is one of the following:

"select_servers", " #servers ", " server1 "[, " server2 " ...]

"nav_join_order", {"on" | "off"}

"strategy", " #binary_joins ", " strategy1 ",[, " strategy2 " ...]

"join_servers", " #servers ", " server1 "[, " server2 " ...]

"report_strategy", " strategy "

"report_servers", " #servers ", " server1 "[, " server2 " ...]

Except for the nav_join_order directive, all override directives arerelevant only to the immediate batch in which they are executed.

12-2 The Parallel Optimizer

Overriding the Parallel Optimizer Sybase MPP Release 11.0.x

Directives are applicable to an entire batch rather than individualcommands within the batch. For this reason, a given batch (or storedprocedure) should contain only a single DML command whenoverride directives are being used. If multiple directives of the sametype are issued within the same batch, only the last directive takeseffect.

The following sections explain each override directive.

Selecting Participating Servers

The override directive for specifying the participating servers forsingle-table commands is:

execute sp_pragma "opt_override" "select_servers"," #servers ", " server1 " [, " server2 " ...]

where #servers is the number of SQL Servers you want to process thequery, and server1 is a SQL Server logical name (50002 - 59999).

When processing single table selects, updates, and deletes, the queryoptimizer attempts to reduce the number of participating SQLServers by looking for relevant predicates on the decluster keycolumns. In certain cases, the optimizer might fail to recognize suchpredicates and execute the query on a wider set of servers than isnecessary. Use the select_servers override directive to specify theservers that should participate.

Consider overriding the optimizer when the keyword like predicateson a range partitioning key or when the keyword or predicates on thepartitioning key. For example:

exec sp_pragma "opt_override","select_servers", "1", "50002"

select * from range_tablewhere decl_key_col like "A%"

Specifying Global Join Order

The override directive for specifying global join order is:

execute sp_pragma "opt_override" "nav_join_order",{"on" | "off"}

or

set forceplan on | off

The sp_pragma syntax takes effect immediately within the currentbatch. The set forceplan syntax does not take effect until the next batch.


Sybase MPP Release 11.0.x Overriding the Parallel Optimizer

Sybase MPP processes multiway joins as a sequence of binary joinsteps. The optimizer’s chosen sequence of steps is referred to as theglobal join order. For example, the global ordering “t1-t2-t3-t4”results in the following binary steps:

(((t1 join t2) join t3) join t4)

Currently, Sybase MPP can only execute query plans with strict left-to-right join orderings. For example, a join order of ((t1 join t2) join(t3 join t4)) cannot be executed.

The nav_join_order override directive acts as an on/off toggle that isrelevant to the entire session. When turned on, the optimizer choosesa global join order that matches the left-to-right ordering of eachsubsequent from clause. The override remains in effect until thesessions ends or it is explicitly turned off.

➤ NoteThe global join order is different from the local join order used by SQL

Server. SQL Server chooses a local join order for each binary join step that

it executes. Sybase MPP does not support the Transact-SQL command setforceplan as a mechanism to control the local join order in a SQL Server.

Use set forceplan only as an alternative syntax for overriding the global join

order.

A typical situation in which the optimizer might fail to consideroptimum join orders is joins involving more than four tables, sincethe optimizer does not consider every permutation of table orders.Another case is when the optimal join order is an unconnected orderinvolving a cross product operation, because the optimizer tends toprefer connected join orders.

For example, to force the join order:

set forceplan ongoselect * from t2, t1, t4, t3, t5 where ...

To force cross products on small tables:

exec sp_pragma "opt_override", "nav_join_order","on"

select * from small1, small2, small3, big1where big.col = small1.col and big.col = small2.col

and big.col = small3.col


Overriding the Parallel Optimizer Sybase MPP Release 11.0.x

Specifying Join Strategies

The PSQL optimizer chooses a data movement strategy or “PSQLjoin strategy” for each binary join step in the query plan. To overridethe choices, use this directive:

exec sp_pragma "opt_override", "strategy"," #binary_joins ", " strategy1 ", [, " strategy2 " ...]

where #binary_joins is the number of binary join steps which is equalto (n-1), where n is the number of tables in the from clause. For eachjoin step, the strategy must be one of the following keywords:

• inplace – Both tables remain in place

• red1_inner – Redecluster the inner (right) table

• red1_outer – Redecluster the outer (left) table

• red2 – Redecluster both tables

• rep_inner – Replicate the inner (right) table

• rep_outer – Replicate the outer (left) table

• redn_inner – Redecluster one row from the inner (right) table

• redn_outer – Redecluster one row from the outer (left) table

Join strategies cannot be chosen until a particular join order isassumed. A given join order establishes which tables participate ateach step and the notion of inner (right) and outer (left) tables. Whenstrategy directives are present, the optimizer automatically assumesa join order that matches the left-to-right ordering of the query’s fromclause.

For a given join order, the inner table always refers to an originaltable from the query. The outer table refers to an original table onlyfor the initial binary join step. For subsequent steps, the outer tablessee the composite result of joining all tables from previous steps.

Some of the typical situations in which the optimizer fails to choosean efficient data movement strategy are:

• Joins between columns of compatible but different datatypes,such as smallint_col = int_col. The optimizer might fail torecognize the inplace strategy for such joins.

• Joins involving tables with multi-column decluster keys. Theoptimizer does not choose inplace joins for such tables.

• Queries that have implied predicates that are not explicitlyspecified. The optimizer does not derive implied predicates usingalgebraic rules.


Sybase MPP Release 11.0.x Overriding the Parallel Optimizer

• Joins that have highly selective select predicates and/orprojections that would benefit from repartitioning andmaterialization before executing the join.

The following example forces a two-way join with compatible joinkeys to execute inplace:

exec sp_pragma "opt_override", "strategy", "1","inplace"

select * from range_tab1, range_tab2where range_tab1.int_key = range_tab2.tinyint_key

This example forces an inplace join between composite declusterkeys:

exec sp_pragma "opt_override", "strategy", "1","inplace"

select * from t1, t2where t1.key1 = t2.key1 and t1.key = t2.key2

This example forces t1 and t2 to join inplace and then replicates theresults from the join into the home of t3:

exec sp_pragma "opt_override", "strategy", "2","inplace", "rep_outer"

select * from t1, t2, t3where t1.decl_key = t2.decl_key

and t2.nonkey = t3.nonkey

Selecting Participating Servers for Redecluster-2 Joins

The override directive for specifying the participating servers forredecluster-2 joins is:

execute sp_pragma "opt_override" "join_servers"," #servers ", " server1 " [, " server2 " ...]

where #servers is the number of SQL Servers you want to process thequery, and server1 is a SQL Server logical name (50002– 59999).

For most strategies, the choice of participating join servers is fixedbased on the required semantics of the strategy. For example, theredecluster-1 strategies require that the join be executed in the homeof the table that does not move. Using the redecluster-2 strategygives the optimizer and the user complete flexibility in choosing theparticipating join servers.


Configuring the Parallel Optimizer Sybase MPP Release 11.0.x

➤ NoteWhen using the join_servers override directive, ensure that a redecluster-2

operation is being done where expected by using the strategy override

directive.

Some typical situations in which it is useful to execute theredecluster-2 join strategy on a specified set of servers are:

• A join is being executed on only a subset of the system’s SQLServers, and the desired degree of parallelism is not beingachieved.

• A query plan is failing to execute due to an inadequate amount oftempdb space on the participating SQL Servers for eachredecluster-2 step in the current batch.

Report Processing Override Directives

The override directive for specifying report feature processing is:

execute sp_pragma "opt_override" "report_strategy"," strategy "

Valid strategies include:

See “Aggregate Processing” on page 8-23 for a description of reportfeatures.

Configuring the Parallel Optimizer

The optimizer parameters control the behavior of the Sybase MPPoptimizer and the resulting parallel query plans. Because querycompilation occurs within the DBA Server, the optimizer parametersare categorized as part of the DBA Server configuration.

Strategy Description

Redecluster Redeclustering is performed before processing group byclauses.

In-place Report features are processed in place.

In-place opt The optimal in-place aggregate and group by processing isperformed.


Sybase MPP Release 11.0.x Configuring the Parallel Optimizer

The optimizer parameters for the DBA Server can be displayed andmodified using the Sybase MPPM Configuration Managementutility. Parameters set apply to all queries in the instance. You cannotset these parameters for individual databases or queries. For moreinformation on using the Configuration Management utility toconfigure servers, see the Sybase MPP Manager User’s Guide.

Cost Model Parameters

The cost model parameters are shown in the following table:

Cost Object-Response Time Parameter

The Cost Object-Response Time parameter is a toggle that controlswhether the query optimizer attempts to minimize response time ortotal system costs. Response time is the elapsed time for queryexecution. Total system cost represents the amount of systemresources consumed across the entire system. Usually, these twoobjectives conflict. For example, a query plan might achieve goodresponse time but in the process it might consume a lot of resource,which in turn adversely affects other queries. Minimizing responsetimes is typically the primary object for DSS, whereas minimizingtotal system costs increases the throughput for OLTP.

By default, the optimizer is configured to choose query plans thatminimize response times. In the parallel environment, response timeis usually determined by the elapsed time of the slowestparticipating realm (assuming the centralized merge operation is notthe bottleneck). Currently, the query optimizer does not consider theeffects of skewed data or skewed workload and thus the concept of

Table 12-1: Cost model parameters

Parameter Default Minimum Maximum

Cost Object - Response Time TRUE n/a n/aCost Weight - Network Message 10 0 1000Cost Weight - Split Overhead 1 0 1000Cost Weight - Merge Overhead 1 0 1000Cost Weight - Logical Read 2 0 1000Cost Weight - Physical Read 18 0 1000Cost Weight - bcp Insert 3 0 1000Cost Weight - Module Start-up 20 0 1000Cost Weight - Reformat Insert 5 0 1000Reformatting Overhead Cost 10000 0 maxint



“slowest” is not accommodated. Instead, the optimizer assumes auniform distribution and estimates the response time for a typical oraverage realm.

When this parameter is set to FALSE, the optimizer estimates theCPU, disk, and network resources consumed across all participatingrealms and chooses plans that minimize this cumulative cost.

Cost Weight Parameters

The Sybase MPP optimizer estimates the costs of alternative queryplans through the use of statistics and a cost model.

The cost model is used to compute an estimate of the response timeor total resources consumed for a given query plan. The model iscomposed of cost components and represents basic run-timeoperations (for example, a network message) along with weightfactors (for example, the number of milliseconds to send a message)that are applied to each component. The intent of such weights is toassign a relative cost, in milliseconds, to each of the basic operations.

The query optimizer cost model is:

total system cost = response time * #participatingservers

and

response time = cpu cost + i/o cost + network cost +startup cost + split cost + merge cost + bcp cost

where

cpu cost = LOGICAL_WEIGHT * #logical page accesses

i/o cost = PHYSICAL_WEIGHT * #physical page accesses

network cost = MESSAGE_WEIGHT * #messages

startup cost = STARTUP_WEIGHT * #operations activated

split cost = SPLIT_WEIGHT * #rows split

merge cost = MERGE_WEIGHT * #rows merged

bcp cos t = BCP_WEIGHT * rows bcp inserted



The following table describes the different weights:

Normally, the default weight values should be sufficient. Theweights only need to be accurate to the extent that the optimizer canrank one plan over another. The absolute value of each weight is notas important as its ratio to the other weights.

➤ NoteThe optimizer weight settings should only be changed if the hardware

configuration characteristics dictate such a change.

There are cases when the optimizer weights should be configured fora particular system, such as if the default weights do not accuratelyreflect the hardware configuration. For example, the default weight

Table 12-2: Cost model parameter weights

Weight Definition

Logical page access Average time to perform one logical page accessthrough SQL Server. This includes the time requiredto search through a page in data cache and performthe necessary comparisons and arithmeticoperations on each row.

Physical page access Average time to perform one physical page accessthrough SQL Server. This includes the time requiredto transfer a page from disk to data cache.

Network message Average time to send one interhost network packetduring a split/merge operation. This includes bothwire transfer time and the CPU time incurred withinthe network protocol.

Module start-up Average time required to fetch and activate anexecution plan module; (that is, SQL, split, andmerge modules.

Split overhead Average time to split one row via a split thread. Thisincludes the overhead time required to compute theserver destination, copy the row into the networkbuffer, and so on.

Merge overhead Average time to merge one row via a merge thread.This includes the overhead time required to unpacka row from the network buffer, and so on.

bcp insert Average time to insert one row into a non-indexedtable using the bcp utility during a merge operation.



for a network message (10 ms) assumes the system has a fastinterconnect relative to the cost of other operations. If the system isusing a slower interconnect, the network message weight should beincreased to reflect its higher cost relative to the other weights. Byincreasing the cost of a network message, the optimizer is more likelyto choose plans (if possible) that minimize network costs.

Another situation that warrants a change is an uneven systembalance. The goal here is to set the cost model weights so that thesystem achieves an even balance among its resources (CPU, disk,network), overcoming system bottlenecks.

Setting the weights is of limited use for tuning queries or the systemworkload. The list of alternate plans for the optimizer to choose fromare determined by the queries themselves and their requiredsemantics. The correct processing of many queries demands that theoptimizer choose a correct plan regardless of its cost. For example, ifa query is full of joins on non-keys, Sybase MPP has no choice but toincur network costs.

Selectivity Parameters

The selectivity parameters control the default percentages used bythe optimizer when estimating the selectivity of search arguments.The term “selectivity” describes the percentage of rows that qualifywhen applying a where clause predicate.

In choosing optimal query plans, it is crucial that the optimizer makeaccurate selectivity estimates for the various predicates in the query.Selectivity percentages are used to estimate the number of qualifyingrows, the size of intermediate results, the predicted local index accessmethod, and so on. Because of the importance of selectivityestimates, Sybase MPP maintains advanced statistics for thispurpose.

When available, the optimizer uses histogram statistics to estimatethe selectivity of search arguments of the “column operatorconstant.” Such histograms store information about the distributionof the key values. If statistics are not available, the optimizer resortsto using the default percentages as follows:

Table 12-3: Selectivity parameters

Search Argument Selectivity Parameter DefaultValue (%)

column = constant Selectivity% - Equality 10%column < constant Selectivity% - Open Range 33%



Currently, statistics are maintained only on indexed columns, whichmeans that the selectivity of predicates on non-indexed columns isalways estimated using the default percentages. Therefore, thedefault selectivity percentages should be set to match the averageselectivity of non-indexed search arguments in the query suite.

You cannot configure the optimizer’s selectivity estimates for joinclauses. When statistics are available, the optimizer uses the density(average number of duplicates) of the joining column(s) to estimatethe number of qualifying rows. When the density is not available, theoptimizer uses a fixed algorithm that assumes the join involves aforeign key to primary key relationship such that each row in thelarger table matches with exactly one row in the smaller table.

Search Space Parameters

The search space parameters control the amount of time Sybase MPPspends optimizing queries. Because query optimization is done atcompile time, optimization time is rarely a problem when storedprocedures are used. However, when executing ad hoc complexqueries in an Online Complex Processing (OLCP) environmentwhere response might be an issue, the optimizer itself might becomea performance issue.

The search space parameters are as follows:

column > constant Selectivity% - Open Range 33%column < constant1 andcolumn > constant2

Selectivity% - Closed Range 25%

Table 12-4: Search space parameters

Parameter Default Minimum MaximumJoin Order Heuristic TRUE n/a n/aJoin Order Heuristic - #Rows 25 0 maxintJoin Order Heuristic - #Tables 2 2 16Limit Optimization Time FALSE n/a n/aSearch Limit - Seconds maxint 1 maxint

Table 12-3: Selectivity parameters

Search Argument Selectivity Parameter DefaultValue (%)



Reducing the Search Space

For multi-table queries, the optimizer uses an exhaustive searchalgorithm that enumerates all promising plans and picks the onewith the lowest estimated cost. Because the search space consistingof all possible plans is too large to thoroughly enumerate, theoptimizer employs certain techniques to make the search moreefficient. One of the more effective techniques is a Join OrderHeuristic.

The purpose of a Join Order Heuristic is to skip over those query plansthat result in a cross product, namely plans whose join order isunconnected. By default, this heuristic is enabled (set to TRUE).When disabled, the optimizer considers all joins.

➤ NoteWhen the Join Order Heuristic parameter is turned off, the optimizer

spends time considering n factorial join orders, where n is the number of

tables.

The following conditions must be met for the optimizer to ignoreunconnected join orders:

• The Join Order Heuristic parameter is turned on.

• There are no join clauses between the current table and the outertable (cartesian product).

• The query is connected. That is, there are other paths that do notproduce cartesian products.

• The number of outer rows is greater than CO_OUTER_ROWS.Cartesian products involving few rows are not consideredexpensive. This involves the Join Order Heuristic - #Rowsparameter.

• There are more than CO_JOIN_TABS tables in the query. Whenthere are only a few tables, it is reasonable to consider all joinorders. This involves the Join Order Heuristic - #Tables parameter.

In some cases, the optimizer must consider unconnected join ordersbecause a connected join path does not exist. In other cases, a crossproduct operation might actually be efficient and the optimizervoluntarily considers an unconnected join order. A classic exampleof this is a “star” query, where the optimal plan consists of taking thecross product of a series of small tables before joining with the larger



table. The Join Order Heuristic has been designed to identify thesecases.

➤ NoteThe Join Order Heuristic parameters should be left at their default values,

unless the optimizer is failing to detect optimal unconnected join orders,

which is very rare.

In the rare instances where the unconnected plans are frequentlyoptimal, the Join Order Heuristic parameter can be turned off to forcethe optimizer to consider them.

Limiting Search Time

The amount of time spent optimizing queries can be controlled withthe Limit Optimization Time and Search Limit -Seconds parameters.By default, the optimizer has no time limit imposed on it (the LimitOptimization Time is set to FALSE and Search Limit -Seconds equalsmaxint).

When the Limit Optimization Time parameter is set to TRUE, theoptimizer periodically checks how much time it has spent searchingfor the optimal plan. When it has spent the allotted amount of timespecified by the Search Limit -Seconds parameter, it exits from thesearch and keeps the best plan encountered. If the time spentoptimizing ad hoc queries accounts for a significant portion of theoverall response time, consider setting a time limit for the optimizer.

However, the optimizer cannot exit from its search until at least onevalid plan has been found. Therefore, if a time limit is imposed, itmight not be strictly adhered to for some queries. In addition, thetime limit only applies to the query optimizer’s “exhaustive searchalgorithm” and does not account for the time spent doing cataloglookups, code generation, and other compilation tasks.

➤ NoteIf at all possible, do not impose a time limit on the optimizer’s search for an

optimal execution plan. Spending extra time searching for an optimal

execution plan is minimal compared to the time needed to execute complex

queries.



Consider All Servers Parameter

The Consider All Servers parameter controls the number of realms thatparticipate in executing joins or other complex queries. WhenConsider All Servers is set to FALSE (the default), the optimizerexecutes the query using only those servers that are in the homes ofthe tables involved.

When Consider All Servers is set to TRUE, the optimizer considersusing all servers in the system to execute complex queries thatrequire repartitioning. This increases the degree of parallelism andleverages more of the system’s resources. In some cases, this canimprove response times or overcome problems resulting fromlimited work space in the tempdb database. On the negative side, thiscan disturb the workload that is normally dedicated to theseadditional servers.

One situation that might warrant turning this parameter on is whena high priority user is executing complex queries on the system for atemporary and specified period of time, and it is desirable todedicate all resources to the effort. Another possible situation iswhen execution of a given query exhausts the tempdb work spaceavailable (and there is no room on each SQL Server to expandtempdb). By turning this parameter on, the optimizer has theopportunity to spread the intermediate results across more serverswhich then increases the pool of available work space.

➤ NoteDo not use the Consider All Servers parameter as a workaround for

suboptimal database design. The degree of parallelism for a given query is

primarily determined by the partitioning layout of the tables. Make sure your

tables are partitioned on the appropriate number of servers to achieve the

desired degree of parallelism.

It is very important to dedicate the appropriate number of servers tothe execution of joins, since the join operation is usually more timeconsuming and resource intensive that other query operations. Thefollowing table summarizes how the optimizer chooses which



servers should participate in the join operation when the Consider AllServers parameter is set to FALSE.

When the Consider All Servers parameter is set to TRUE and the joinquery cannot be executed inplace, the optimizer considersperforming the redecluster-2 “wide-scope” strategy on all homeservers of the database(s) referenced in the query.

Table 12-5: Join server participation

Join Strategy Participating Join Servers

In-place Home servers of the tables being joined.

Redecluster-1 Home servers of the table that does not move.

Replicate Home servers of the table that does not move.

Redecluster-2 Home servers of either of the two tables, namely thehome with the greatest number of servers.


13 Recovery Manager 13.

This chapter describes how Recovery Manager works. The followingtopics are discussed:

• Enabling Recovery Manager 13-1

• Server Monitoring Scheme 13-2

• Input Used by Recovery Manager 13-3

• Output Produced by Recovery Manager 13-4

Recovery Manager does the following:

• Detects Sybase MPP system failure

• Reports the failure

• Recovers Sybase MPP at the server level

The Recovery Manager is part of the Control Server and the DBAServer. After a node failure, if possible, the Recovery Managerrestarts Sybase MPP in place. When this is not possible, if failover isconfigured, Recovery Manager moves the realm it is monitoring tothe alternate node, and restarts them there. The realm consists of theControl Server, and the Split Server, and SQL Servers. If the failureoccurs for the realm containing the DBA server, then the base realmis moved: DBA Server, Master Split/Merge Server, and the SchemaServer.

➤ NoteAny transactions in progress are lost.

You can set Recovery Manager to run under operator control. SettingRecovery Manager to run automatically is usually the preferredmethod.

Enabling Recovery Manager

Enable Sybase MPP’s Recovery Manager using Sybase MPPM’sConfiguration Management tool in the Recovery Monitoring menuoption.

The recovery interval, which specifies the number of minutesallowed for recovery, is set using the Configure Servers menu option.

13-2 Recovery Manager

Server Monitoring Scheme Sybase MPP Release 11.0.x

Server Monitoring Scheme

Sybase MPP uses a hierarchical monitoring scheme to detect serverfailure.

The DBA Server monitors the Control Servers and the ControlServers monitor the Split Servers and SQL Servers in the associatedrealm.

The DBA Server monitors the Schema Server and the Master SplitServer.

The DBA Server and the DBA Monitor monitor each other.

The monitoring frequency can be dynamically configured.


Sybase MPP Release 11.0.x Input Used by Recovery Manager

.

Figure 13-1: Server monitoring relationships

Input Used by Recovery Manager

Recovery Manager uses the following resources:

• nav_startup command line

• Environment variables

• Global directory tables

• SQL Server error logs

• MPPM’s Configuration Management tool

SchemaServer

DBAMonitor

ControlServer

ControlServer

Server

Schema SplitServer

DBA

SQLServer

SQLServer

SplitServer

SplitServer

(Base Realm)

(Realm 2)(Realm 1)

13-4 Recovery Manager

Output Produced by Recovery Manager Sybase MPP Release 11.0.x

Output Produced by Recovery Manager

Recovery Manager produces the following output:

• Supplemental logs and error logs for each Open Servercomponent.

• Error logs for each SQL Server.

• Status output to global directory tables.

• Internal data structures indicating current Sybase MPPconfiguration. This information is primarily about physicalserver locations.

• Dynamic status changes sent to Sybase MPPM’s ConfigurationManagement tool.

Kerberos Ticket Expiration

You must ensure that the Kerberos ticket for the installation owner isalways valid (for example, by using cron to re-initialize the ticketbefore it expires).

◆ WARNING!If a failover occurs during the window between the time theinstallation owner’s Kerberos ticket expires and the time it isre-initialized, the Recovery Manager will fail.


14 Using Sybase MPP Utilities 14.

This chapter describes the following Sybase MPP utilities:

• Using dpst 14-1

• Using pst 14-3

• Using nav_util 14-4

Using dpst

The dpst utility is located in $NAVIGATOR/bin. When you execute thecommand, you get output similar to the following:

DPST on SMP002-00

Instance 24 - Tue Apr 9 12:42:43 PDT 1996

------------------------------------------------------------------------

Name PID Nodename Started CPU Used DT Type

------------------------------------------------------------------------

D24600001 3240 SMP002-00 12:17:21 2:13 1 DBA Server

D24600011 7951 SMP002-10 12:14:48 1:04 0 DBA Monitor

S24200001 3246 SMP002-00 12:17:24 2:09 3 Schema

M24400001 3367 SMP002-00 12:19:38 0:09 0 Master S/M

C24300021 3280 SMP002-00 12:18:43 0:08 0 Control 2

C24300031 3286 SMP002-00 12:18:44 0:08 2 Control 3

C24300041 3289 SMP002-00 12:18:44 0:08 0 Control 4

M24400021 3416 SMP002-00 12:20:29 0:35 0 Split Mrg 2

M24400031 3410 SMP002-00 12:20:27 0:50 0 Split Mrg 3

M24400041 3407 SMP002-00 12:20:27 1:04 0 Split Mrg 4

Q24500021 3378 SMP002-00 12:19:45 1:35 2 Sql Serv 2

Q24500031 3379 SMP002-00 12:19:45 1:35 4 Sql Serv 3

Q24500041 3384 SMP002-00 12:19:45 1:36 1 Sql Serv 4

------------------------------------------------------------------------

TOTAL: 13 DBA Serv: 1 schema: 1 Master Split: 1 DBA Monitor: 1Control : 3 Split : 3 Sql Servers : 3

14-2 Using Sybase MPP Utilities

Using dpst Sybase MPP Release 11.0.x

There is a flag that can be passed to dpst that will not print any serversthat have a DT of 0. When you have a big instance, you don't want to seeinfo on all servers, just the active ones.

dpst -f

Instance 24 - Tue Apr 9 15:09:29 PDT 1996

ONLY DISPLAYING SERVERS THAT HAVE USED CPU TIME SINCE LAST CYCLE

--------------------------------------------------------------------------

Name PID Nodename Started CPU Used DT Type

--------------------------------------------------------------------------

Q24500021 3378 SMP002-00 12:19:45 23:45 1 Sql Serv 2

Q24500031 3379 SMP002-00 12:19:45 22:45 1 Sql Serv 3

Q24500041 3384 SMP002-00 12:19:45 24:02 1 Sql Serv 4

--------------------------------------------------------------------------

TOTAL: 13 DBA Serv: 1 Schema: 1 Master Split: 1 DBA Monitor: 1

Control : 3 Split : 3 Sql Servers : 3

The first two entries are the user (“mpp”) and the process number. Foreach process, the time it was started and the duration is listed. The itembeginning with “-DD” is the name of the DBA Server that the process istalking to. “-AD” indicates the name of the alternate DBA Server that theprocess is talking to. “-M0” is the Split/Merge Server and “-SS012” is theSchema Server. Entries beginning with“-T” are the process namesaccording to MPP.

Where Represents

Name Is the logical server name.

PID Is the UNIX process id number.

Nodename Is the node on which the server is running.

Started Is the date the server was started. If this value isdisplayed in time format, it was started on the currentday.

CPU Specifies the usage. This is the total time accumulated bythe process and is from the UNIX ps line.

DT Is the Delta time, which is the amount of time it hasaccumulated since the last time dpst checked.


Sybase MPP Release 11.0.x Using pst

See “Server Naming Conventions” on page 1-8 for information onserver names.

Using pst

The pst utility is located in $NAV_IDIR/bin. When you execute thecommand, you get output similar to the following:

navigato 14567 1 0 08:23:16 ? 15:11 dataserver -e/nav/sybase/install/errorlog_S01200001 -d/dev/rdsknavigato 14717 1 0 08:24:55 ? 11:54 dataserver -e/nav/sybase/install/errorlog_Q01500021 -d/dev/rdsknavigato 14732 1 0 08:25:12 ? 0:44 nav_server-TM01400021 -DD01600001 -M0 -AC01300021 -SS012navigato 15207 1 0 10:51:22 ? 0:09 nav_server-TM01400001 -DD01600001 -M1 -AD01600001 -SS012navigato 15269 1 0 10:54:22 ? 0:26 nav_server-TC01300021 -DD01600001 -M1 -AD01600001 -SS012navigato 15403 1 0 11:00:59 ? 0:54 nav_server-TD01600001 -DD01600001 -M1 -AD01600011 -SS012There are - 6 - Instance 01 servers

navig 14567 1 0 08:23:16 ? 15:11 /nav/sybase/bin/dataserver -e/nav/sybase/install/errorlog_S01200001 -d/dev/rdsknavig 14717 1 0 08:24:55 ? 11:54 /nav/sybase/bin/dataserver -e/nav/sybase/install/errorlog_Q01500021 -d/dev/rdsknavig 14732 1 0 08:25:12 ? 0:44 /nav/NAVSERVER/01/bin/nav_server-TM01400021 -DD01600001 -M0 -AC01300021 -SS012navig 15207 1 0 10:51:22 ? 0:09 /nav/NAVSERVER/01/bin/nav_server-TM01400001 -DD01600001 -M1 -AD01600001 -SS012navig 15269 1 0 10:54:22 ? 0:26 /nav/NAVSERVER/01/bin/nav_server-TC01300021 -DD01600001 -M1 -AD01600001 -SS012navig 15403 1 0 11:00:59 ? 0:54 /nav/NAVSERVER/01/bin/nav_server-TD01600001 -DD01600001 -M1 -AD01600011 -SS012There are - 6 - Instance 01 servers

The first two entries are the user (“navigator”) and the processnumber. For each process, the time it was started and the duration islisted. The item beginning with “-DD” is the name of the DBA Serverthat the process is talking to. “-AD” indicates the name of thealternate DBA Server that the process is talking to. “-M0” is theSplit/Merger Server and “-SS012” is the Schema Server. Entriesbeginning with “-T” are the process names according to NavigationServer.

The first two entries are the user (“navig”) and the process number.For each process, the time it was started and the duration is listed.The item beginning with “-DD” is the name of the DBA Server thatthe process is talking to. “-AD” indicates the name of the alternateDBA Server that the process is talking to. “-M0” is the Split/Merger


Using nav_util Sybase MPP Release 11.0.x

Server and “-SS012” is the Schema Server. Entries beginning with “-T” are the process names according to Navigation Server.

Refer to “Server Naming Conventions” on page 1-7 for informationon server names.

Using nav_util

The nav_util utility provides the following options for administeringthe MPP environment from the command line. Similar options areavailable in MPPM.

Navigation Server Adm Utilities menu...

(0)Navigation Server instance information

(1)Shutdown Navigation Server instance

(2)Clear instance supplemental logs

(3)Shutdown & clear Navigation Server instance

(4 Clear Navigation Server status history table

(5)Check Global Directory

(x)exit

Enter your menu choice:

Option 0 displays the name, associated environment variables,servers, and process information for the current instance.

Options 1 and 3 shut down the instance specified. Option 3 alsodeletes the supplemental logs. Use Option 2 to remove thesupplemental logs only.

Option 4 clears the status history stored in the global directory for theSybase MPP.

Option 5 displays the contents of tables in the global directory. Thecontents of these tables can be instrumental in troubleshootingproblems, such as determining why a particular server is not startingwith the other MPPs. The tables displayed are:

• gd_dba_servers

• gd_schema_servers

• gd_control_server

• gd_split_servers

• gd_sql_servers

• gd_cabinets


Sybase MPP Release 11.0.x Using nav_util

• gd_nodes

• gd_database_device_usage

• gd_scsi_buses

• gd_scsi_devices

• gd_scsi_device_units

• gd_scsi_unit_controls

• gd_dbrf_db_info


Using nav_util Sybase MPP Release 11.0.x


15 Troubleshooting 15.

This chapter describes problems that might occur in the Sybase MPPenvironment and suggests possible solutions.


• Sybase MPP Start-Up 15-1

• Performance Issues 15-4

Sybase MPP Start-Up

Checklist for Start-Up

The following things should be checked if problems occur duringstart-up. Check the following for error messages and supplementalinformation:

• SQL Server error logs

• Sybase MPP supplemental logs

Global Directory

• The node names in gd_nodes should match the node names ingd_schema_servers, gd_control_servers, gd_split_servers,gd_sql_servers, and gd_dba_servers.

• Port numbers in gd_split_servers should be unique within the setof Split Servers that run on a given node and within the set of allservers that are in the interfaces file and run on the same node.

• The tables gd_schema_servers, gd_control_servers, gd_split_servers,gd_sql_servers, and gd_dba_servers should contain one record foreach of the respective servers in the Sybase MPP configuration.

• gd_nodes should contain one record for each node on which aSybase MPP component executes. Make sure that thenode_address and ynet_address columns of this table containcorrect IP addresses.

• The table gd_database_devices should contain one record for eachdatabase device and their mirror devices, if any, for eachSQL/Schema Server.

15-2 Troubleshooting

Sybase MPP Start-Up Sybase MPP Release 11.0.x

Interfaces File

• All servers that comprise the Sybase MPP system should berepresented in the interfaces file, which should be in the directoryindicated by the $IFFILE environment variable.

• Port numbers must be unique within the set of servers that run oneach node.

Confirm All Nodes Are Up

• Make sure all nodes are up and running on the networks (systeminterconnect and external network).

• Start-up and recovery use the rsh UNIX remote shell commandfor inter-node execution. Make sure the rsh command succeedsby issuing an rsh command between nodes using node names asthey appear in the gd nodes table.

If this fails, make sure the .rhosts file in the “mpp” user’s homedirectory (on all nodes) contains the names of all the nodes in theSybase MPP configuration.

File Permissions

Start Sybase MPP using the “mpp” login and make sure thefollowing permissions are correctly set:

• Executable files in $NAVIGATOR/bin, $NAVIGATOR/startup,$SYBASE/install, and $SYBASE/bin need to have executepermission.

• The “mpp” user needs read, write, and execute permission onthese directories:

- $NAVIGATOR/bin

- $NAVIGATOR/log

- $NAVIGATOR/log/supplemental

- $SYBASE/install

• The” mpp” user needs write permission on the SQL Server errorlogs located in $SYBASE/install/errorlog_servername.

• The “mpp” user needs write permission on special device filesthat represent database devices (located in /dev). These devicesmust be owned by “mpp”.


Sybase MPP Release 11.0.x Sybase MPP Start-Up

mppdba User

Make sure all SQL and Schema Servers have a “navdba” login. (Thislogin should have been set up by the installation process.)

“sa” Password for Start-Up

Make sure the “sa” password is being entered correctly at the promptfrom nav_startup.

SQL Server Command Line Parameters

Each SQL Server should have a RUN script in $SYBASE/install. EachRUN script should contain a SQL Server command line, which shouldcontain the following:

• -e – specifies the path name of the SQL Server’s error log.

• -d – specifies the path name of the master device.

• -r – specifies the path name of the master device’s mirror. If themaster device is not mirrored, this parameter is not used.

Transaction Logs

Make sure the master database transaction logs are not full on eachSQL and Schema Server. (Refer to your SQL Server documentationfor information on dumptran and logs.

Disk Space

Make sure file space exists for supplemental and SQL error logs.

Memory

Make sure there is sufficient virtual memory on each node to runSybase MPP. Out-of-memory conditions might show up in serversupplemental logs as messages stating: “Unable to allocatememory.”


Performance Issues Sybase MPP Release 11.0.x

Performance Issues

Skew

The manifestations of skew are usually poor response time andconsequently poor price/performance as subsets of processors andnodes are under utilized. Skew can occur in many different formseither during data load time (row placement skew) or, dynamically,during run time (redecluster skew or join key skew).

Skew may also be a function of periodic fluctuations in workload. Inthis case, it depends on a complex mix of factors, such as theindividual queries in the application, and the frequency andcombinations in which they are run.

Diagnosis

Execute sp_spaceused for the object you are examining. sp_spaceuseddisplays the amount of space used by the object on each of theservers on which it exists. If the amount of space used on any of theservers is significantly different from the amount of space used onthe other servers, data skew exists.

Recommendation

Generally, you can resolve row placement skew by reloading thedata so that a new partitioning scheme is assessed and applied to thedata.

You can alleviate skew encountered while retrieving data bymodifying an application’s queries so that their response times areminimized.

Inserts into Indexed Tables

High insert volumes and frequencies to tables with clustered indexescan lead to poor performance. Each insert causes the clustered B-treestructure to realign to accommodate the new rows and may result inpage splitting, which leads to additional I/O rates per insert. Youmay observe 5–10 physical I/Os per insert in these situations.


Sybase MPP Release 11.0.x Performance Issues

Diagnosis

To calculate the approximate number of I/Os per insert you need touse:

• The iostat command to determine the device I/O activity

Recommendation

There are two possible solutions to reducing the number of I/O’s:

• Remove the clustered index from the table.

The benefit other queries gain by using the clustered index mayoutweigh the usefulness of this option.

• Replace the clustered index with one or more non-clusteredindexes.

This solution should reduce the level of I/O per insert, but evennon-clustered indexes cause some increased I/O for the inserts.

CPU Utilization of Sybase MPP

The CPU utilization in a Sybase MPP system is often considerablyhigher than for standalone SQL Server. This overhead is due to thefunctionality necessary to manage parallel relational databases. Thesize of the overhead depends on the extent and type ofparallelization required for a particular workload. Optimization ofquery SQL will reduce CPU utilization.

Overhead occurs for all kinds of workloads, but is most noticeable inOLTP workloads. For OLTP transactions, good performancegenerally depends on inter-query parallelism. For DSS and batchtransactions, good performance generally depends on intra-queryparallelism. Inter-query parallelism is more susceptible to SybaseMPP’s overhead due to Sybase MPP’s multi-layered architecture,which adds CPU use at each stage of the transaction’s progress.

Diagnosis

Compare the throughput for OLTP transactions running on a singleSQL Server in Sybase MPP with standalone SQL Server. A ratio of 1to 4 is to be expected. If you detect ratios that exceed this, you can tryto improve performance using the recommendations describedbelow.



Recommendation

For small systems, with eight or less nodes, the problem can bealleviated by adding more realms.

For larger systems, Sybase MPP can counter the lower throughput ifyou add more realms.

For any system, try to design the database schema and SQL queriesas to maximize in-place processing. See “Writing Queries in SybaseMPP’s Parallel Environment” on page 8-16.

High Operating System Paging Activity

When Sybase MPP memory usage exceeds the physical RAMavailable on the system, the operating system swaps pages out todisk, and back in to memory. Paging is especially detrimental toperformance when data structures in the SQL Server’s sharedmemory segment, or in the text segment of processes, are paged out.OLTP transaction suffer the most when excessive swapping occurs..

Diagnosis

Run the sar UNIX command on all nodes, using the -g option. If thephysical paging is high, or if it persists through the duration of theworkload, this indicates your system has insufficient memory tohandle its workload.

If memory constraints are severe, on entire process image may beswapped out of main memory to disk. Before execution of the imagecan take place, it must be swapped back in.

Recommendation

The solution is usually to reduce the memory used by anyapplication software running on the system. Use the sp_configuresystem procedure to decrease memory for each SQL Server untilpaging no longer occurs. See “System Procedures” on page 7-15 andthe SQL Server Administration Guide for information on usingsp_configure.

On some systems it is possible to “nail” or “pin” the shared memorysegment of the SQL Servers into RAM. This prevents it from beingpaged out by the operating system. This approach is advisable forOLTP workloads. Consult your operating system documentation for


Sybase MPP Release 11.0.x Performance Issues

information on how to “nail” or “pin” for shared memory segmentsused by SQL Server processes.

Concurrent Table Scans by Multiple Users

When concurrent, full table scans are executed by multiple users,physical I/Os are not sequential. Instead, they take on the characterof random I/Os, if the scans are on the same set of disks. Therefore,the I/O throughput for the multiple users may decrease dramaticallyfrom that of the single user.

The problem is caused by data sharing; if multiple, concurrentqueries are scanning a table, contention inevitably occurs.Sometimes, as the number of users making concurrent scansincreases, the I/O throughout improves, because the disk arm onaverage has to move a shorter distance between reads.

Diagnosis

To determine whether multi-user, concurrent table scans show poorperformance, look for poor scale-up of I/O throughput rates. Youcan do this by checking to see whether two or more concurrent scansperform significantly less well than a single scan by measuring:

• Response times

Recommendation

Avoid scans by rewriting queries and /or implementing SPROCS.

Sybase MPP Administration Guide for IBM RS/6000 POWERparallel A-1

A Sybase MPP System Tables A.

This appendix lists the Sybase MPP system tables that reside in theglobal directory (gdnavdb database).

gd_access

gd_cabinets

gd_control_servers

Column Name Type Lengthid int 4num_users smallint 2sequence smallint 2list varbinary 255

Column Name Type Lengthcabinet_id tinyint 1status int 4

Column Name Type Lengthcontrol_name dnservername 9control_id int 4status int 4local_sql_id int 4local_split_id int 4node_name dnnodename 4

A-2 Sybase MPP System Tables

gd_database_device_usage Sybase MPP Release 11.0.x

The server status shown in the “status” column translates to thefollowing:

gd_database_device_usage

gd_database_devices

The information in this table is used by Sybase MPP to determinewhich disks to open or reserve.

Status DN_INT Comment

0 DN_SRV_UNKNOWN Should never be seen

1 DN_SRV_DOWN Marked down – disabled

2 DN_SRV_SHUTDOWN Normal shutdown

4 DN_SRV_BFINGINGUP1


16 DN_SRV_RUNNING Good status

32 DN_SRV_SHUTTINGDOWN1


128 DN_SRV_SICK Not responding in interval

256 DN_SRV_QUIET

Column Name Type Lengthdb_name dnsysname 30db_device dndevicename 30sql_id int 4size int 4type int 4

Column Name Type Lengthdb_device dndevicename 30sql_id int 4total_size int 4avail_size int 4status int 4phys_name varchar 127mirror_name varchar 127


Sybase MPP Release 11.0.x gd_dba_servers

gd_dba_servers


Column Name Type Lengthdba_name dnservername 9dba_id int 4status int 4local_sql_id int 4local_split_id int 4node_name dnnodename 30











256 DN_SRV_QUIET


gd_dbadepends Sybase MPP Release 11.0.x

gd_dbadepends

gd_dbrf_activity

Stores information about current backup and restore activities onSQL Servers.

gd_dbrf_db_info

Stores general information and status for a backup or restore request.

Column Name Type Lengthcm_id int 4cm_number smallint 2sqlm_name dnsysname 30sqlm_owner dnsysname 30sqlm_number smallint 2

Column Name Type Lengthdb_name dnsysname 30sqlserver_id int 4dump_id int 4action int 4

Column Name Type Lengthdump_id int 4db_id int 4db_name dnsysname 30dump_device dndevicename 30dump_options int 4db_consistency int 4datetime datetime 8primary_server_id dnservername 9estimated_volumes int 4op_is_full tinyint 1volumes_complete int 4sqlserver_count int 4backup_states int 4restore_status int 4TMS_poolname varchar 25TMS_type int 4dump_media int 4tape_type int 4capacity int 4


Sybase MPP Release 11.0.x gd_dbrf_defaults

gd_dbrf_defaults

Stores the default backup and restore environment for each database.

gd_dbrf_device_info

Stores information for each tape volume created during a backupoperation.

label_option int 4parent_dump_id int 4

Column Name Type Lengthdb_name dnsysname 30db_consistency int 4db_history_aging int 4default_load_option int 4default_dump_media int 4default_tape_type int 4TMS_poolname varchar 25

Column Name Type Lengthsqlserver_id int 4dump_id int 4sequence int 4volume_name varchar 30backup_status int 4restore_status int 4

Column Name Type Length


gd_dbrf_dump_device_aliases Sybase MPP Release 11.0.x

gd_dbrf_dump_device_aliases

gd_dbrf_navtape_defaults

gd_dbrf_profile

Stores general information about backup profiles.

Column Name Type Lengthsqlserver_id int 4alias_name varchar 30logical_device_name varchar 30physical_device_name varchar 127device_type int 4media_type int 4

Column Name Type Lengthtape_type int 4capacity int 4label_option int 4

Column Name Type Lengthprofile_name varchar 30db_name dnsysname 30operation_type int 4all_servers tinyint 1db_consistency int 4media_type int 4tape_type int 4task_id int 4scheduler int 4dump_options int 4load_options int 4restore_id int 4dump_id int 4


Sybase MPP Release 11.0.x gd_dbrf_profile_devices

gd_dbrf_profile_devices

Stores the dump device name to be used for each server in thebackup profiles.

gd_dbrf_profile_schedules

Stores cron scheduling text from the backup profiles.

gd_dbrf_sql_server_info

Stores SQL Server specific data regarding a backup, and subsequentrestore operation.

Column Name Type Lengthprofile_Name varchar 30dump_device dndevicename 30sqlserver_id int 4sequence int 4

Column Name Type Lengthprofile_name varchar 30schedule_command varchar 80sequence int 4

Column Name Type Lengthsqlserver_id int 4dump_id int 4restore_id int 4parent_partial_dump_id int 4backup_status int 4restore_status int 4dump_device dndevicename 30media_type int 4cntrltype int 4volume_name varchar 30datetime datetime 8estimated_volumes int 4volumes_complete int 4current_volume int 4state int 4success int 4tape_type int 4label_option int 4


gd_dbrf_tape_sequence Sybase MPP Release 11.0.x

gd_dbrf_tape_sequence

Stores the last tape sequence number used for a particular backupoperation. This number is used by REELibrarian to create uniquevolume set names for the backup tapes.

TMS_psd varchar 12TMS_adn varchar 12

Column Name Type Lengthdn_id char 2dump_id int 4tape_sequence int 4



Sybase MPP Release 11.0.x gd_decluster_columns

gd_decluster_columns

gd_disks

gd_dump_devices

Stores data on every dump device defined in the system.

Column Name Type Lengthtable_name dnsysname 30owner dnsysname 30order_id tinyint 1column_id tinyint 1status tinyint 1data_type tinyint 1data_length tinyint 1varno smallint 2column_name dnsysname 30

Column Name Type Lengthdisk_name dndiskname 30partner_name dndiskname 30scsi_name dnscsiname 30disk_model varchar 20sql_id int 4status int 4node_name dnnodename 30

Column Name Type Lengthdump_device dndevicename 30sql_id int 4tape_type int 4media_type int 4status int 4phys_name varchar 127


gd_extend_recovery Sybase MPP Release 11.0.x

gd_extend_recovery

gd_global_params

Stores various parameters for each server.

Column Name Type Lengthdb_name dnsysname 30sql_id int 4

Column Name Type Lengthserver_name dnservername 9cid smallint 2param_id int 4param_name varchar 30param_label varchar 30param_type int 4min_val int 4max_val int 4def_val varchar 255cur_val varchar 255next_start_val varchar 255set_flag tinyint 1restart_reqd tinyint 1


Sybase MPP Release 11.0.x gd_history

gd_history

gd_indexes

gd_modules

Column Name Type Lengthname varchar 30cvs_version varchar 10rel_num int 4servers smallint 2databases smallint 2date datetime 8description varchar 80

Column Name Type Lengthtable_name dnsysname 30owner dnsysname 30index_name dnsysname 30index_id smallint 2data_pages int 4pages_allocated int 4pages_used int 4rows int 4status1 int 4status2 int 4max_rows_per_page int 4min_row_length int 4max_row_length int 4max_index_row int 4index_height int 4fill_factor tinyint 1last_modified datetime 8num_columns tinyint 1col_ids varbinary 16segment_name dnsysname 30

Column Name Type Lengthid int 4number smallint 2type int 4linksz int 4hash int 4


gd_nodes Sybase MPP Release 11.0.x

gd_nodes

Stores the system interconnect address in the ynet_address column.The address is used internally as a node identifier for physical serverlocation.

status smallint 2release varchar 30tree_length int 4tree image 16

Column Name Type Lengthnode_name dnnodename 30node_class varchar 20node_address varchar 20status int 4ynet_address varchar 20cabinet_id tinyint 1node_id tinyint 1num_procs tinyint 1proc_memory int 4node_alias varchar 255



Sybase MPP Release 11.0.x gd_object_aliases

gd_object_aliases

gd_range_decluster_info

gd_rm_history_log

Changes in server status are logged in this table.


Column Name Type Lengthobject_name dnsysname 30owner dnsysname 30alias_name dnsysname 30

Column Name Type Lengthtable_name dnsysname 30owner dnsysname 30order_id tinyint 1interval_id smallint 2sql_id int 4value varchar 255

Column Name Type Lengthsequence int 4server_name dnservername 9time datetime 8status int 4











gd_saved_dnconfig Sybase MPP Release 11.0.x

gd_saved_dnconfig

gd_schema_servers



256 DN_SRV_QUIET

Column Name Type Lengthserver_name dnservername 9server_id int 4control_id int 4sql_id int 4split_id int 4status int 4port smallint 2node_name dnnodename 30ynet_address varchar 20

Column Name Type Lengthschema_name dnservername 9schema_id int 4status int 4dba_id int 4node_name dnnodename 30











Sybase MPP Release 11.0.x gd_scsi_buses

gd_scsi_buses

gd_scsi_device_units

gd_scsi_devices

gd_scsi_unit_controls



256 DN_SRV_QUIET

Column Name Type Lengthscsi_name dnscsiname 30scsi_model varchar 20status int 4node_id smallint 2

Column Name Type Lengthscsi_name dnscsiname 30port_id tinyint 1unit_id tinyint 1status int 4unit_model varchar 20

Column Name Type Lengthscsi_name dnscsiname 30port_id tinyint 1status int 4device_type tinyint 1device_model varchar 20

Column Name Type Lengthscsi_name dnscsiname 30port_id tinyint 1unit_id tinyint 1unit_control_id tinyint 1



gd_segment_home_info Sybase MPP Release 11.0.x

gd_segment_home_info

gd_split_servers


status int 4

Column Name Type Lengthsegment_name dnsysname 30db_device dndevicename 30sql_id int 4

Column Name Type Lengthsplit_name dnservername 9split_id int 4status int 4control_id int 4sql_id int 4port smallint 2node_name dnnodename 30











256 DN_SRV_QUIET



Sybase MPP Release 11.0.x gd_sql_servers

gd_sql_servers


Column Name Type Lengthsql_name dnservername 9sql_id int 4status int 4control_id intnode_name dnnodename 30











256 DN_SRV_QUIET


gd_sqlmodules Sybase MPP Release 11.0.x

gd_sqlmodules

gd_table_decluster_info

gd_table_home_info

gd_table_stats

Column Name Type Lengthsqlm_name dnsysname 30sqlm_owner dnsysname 30sqlm_number smallint 2sequence smallint 2num_servers smallint 2sqlm_home varbinary 255

Column Name Type Lengthtable_id int 4table_name dnsysname 30owner dnsysname 30decl_mode tinyint 1num_servers smallint 2num_columns tinyint 1num_indexes tinyint 1hash_func tinyint 1segment_name dnsysname 30

Column Name Type Lengthtable_name dnsysname 30owner dnsysname 30interval_id smallint 2sql_id int 4

Column Name Type Lengthtable_name dnsysname 30owner dnsysname 30index_name dnsysname 30index_id smallint 2distribution_page image 16


Sybase MPP Release 11.0.x gd_triggers

gd_triggers

Column Name Type Lengthtrigger_name dnsysname 30trigger_owner dnsysname 30trigger_type int 4table_name dnsysname 30table_owner dnsysname 30


gd_triggers Sybase MPP Release 11.0.x

Sybase MPP Administration Guide for IBM RS/6000 POWERparallel Index-1

Index

Symbols() (parentheses)

in SQL statements xxiii, (comma)

in SQL statements xxiii... (ellipsis) in SQL statements xxiv[ ] (square brackets)

in SQL statements xxiii{} (curly braces) in SQL statements xxiii

Aaborting

pbcp 5-16Adding

devices 4-1realms 3-1 to 3-3, 8-11, 14-1 to 14-5

after 3-3procedure 3-2

Adding devicesDisk device 4-1Log devices 4-2using sp_logdevice 4-2

additional netmem 8-7, 8-9ADNs, REELibrarian (tape management

system) 6-29advantages and requirements for

in-place joins 8-18after adding 4-3after dropping 4-3Aggregate processing 8-23Aggregates 1-3alignment 8-6alter database 4-2, 4-5

command 4-2alter database command 4-5, 7-2alter database command, Backup and

Restore 6-16Alternate DBA Monitor Server 1-8Alternate installation node 1-8

Alternate node 1-8Alternate Server

overview 1-6Application errors, backup

strategy 6-26Applying

transaction logs 6-22attention 5-18

BBackup and Restore 6-1 to 6-43

any device 6-9application errors 6-26command line interface 6-18, 6-31concurrency 6-14 to 6-16database consistency 6-14 to 6-16database settings 6-13, 6-13dump media 6-2examples 6-8failover 6-10gdnavdb database 6-17 to 6-18graphical interface 6-31hardware requirements 6-2incremental backups 6-19master database 6-16 to 6-17media failure 6-25 to 6-26partitioned data 6-19peripheral configuration 6-13Settings window 6-14site failure 6-26 to 6-28software requirements 6-2specific device 6-9specific SQL Server 6-9stored procedures 6-38 to 6-43system configured for failover 6-10tape configuration 6-5tape naming conventions 6-5

Backup and restore6-1 to 6-43

administration 6-4

Index-2


Backup device namingconventions 6-5

Backup device parameters 6-6commands 6-1definition 6-1device administration 6-4Dump devices 6-3dump devices 6-3hardware requirements 6-2software requirements 6-2tape backup configuration 6-5tape management system 6-3

Backup deviceadministration 6-4 to 6-9naming convention 6-5parameters 6-6

Backup history Catalog 6-13Backup schedule 6-19, 6-26, 6-27Backup strategies 6-24 to 6-28Base realm 1-7basic output 10-2 to 10-4batchsize 5-7bcp 5-4bcp_paths 5-6bcp command 5-1 to 5-20, 7-14bcp utility 1-3buffer cache 8-12Buffer pools 8-12

CCase sensitivity

in SQL xxivcfg16kbufpool 11-2changes to existing system

procedures 7-16checklist 15-1checkpoint 7-10choosing an optimal value for

cfg16kbufpool 11-2Choosing packet sizes 8-8Clarification of escaping rulesLpbcp 5-10

to 5-11Client

load 5-1, 5-17master 5-1, 5-17

column_name 4-13columns 4-12Comma (,)

in SQL statements xxiiiCommand line interface

Backup and Restore 6-18, 6-31Commands

create database 4-1, 4-4dump transaction 4-4sp_extenddb 4-5

Completion timefaster 1-3fixed 1-3

Complex queries 1-3, 7-20Concurrency 6-14 to 6-16concurrent table scans by multiple

users 15-7config block parameter 11-5Configuration

Sybase MPP parameters 8-11Configuration considerations

Backup and Restore 6-12Configuration file

pbcp 5-12Configuring

peripherals 6-12 to 6-13tape backup 6-5

Configuring Schema server 8-3Configuring SQL server 8-3Configuring the Parallel Optimizer 12-6

cost model parameters 12-7parameters 12-7, 12-8, 12-10, 12-11,

12-12, 12-13, 12-14consider all servers 12-14Consistency

databases 6-14 to 6-16global 6-14, 6-26load database command 6-22local 6-14, 6-15, 6-26

consistency_option parameter, Backupand Restore 6-14

Control Server 1-7



overview 1-5server number 1-9and shutdown 2-5

Conventionsin this manual xxiiiSQL syntax xxiii

cost object-response time 12-7cost weight 12-8create database 4-2create database 4-4create database command 4-5, 4-6create database command, Backup and

Restore 6-9, 6-16create procedure command 7-3create table 4-11create table 4-11create table command 4-11, 7-4create trigger command 7-3create view command 7-4Creating

partitioined tables 4-11ct_cancel() routine 5-18Curly braces ({}) in SQL statements xxiii

DDatabase

devices 4-3global directory 3-2

Database Definition LanguageSee also DDL 1-5

Database homedefinition 4-4examples 4-4extending databases 4-5

database ID 7-19Databases

backing up 6-1 to 6-43consistency 6-14, 6-16devices 4-3fragments 1-4gdnavdb 3-2master 3-2model 3-2

overview 4-1performance 1-3restoring 4-3, 6-1 to 6-43settings, Backup and Restore 6-13settings, defaults 6-13striping 1-4

Data definition languageSee also DLL 7-2

Data devices 6-9datafiles 5-6Data Manipulation Language 1-5Data munipulation language

See also DML 7-4Data partitioning 1-2, 1-4Data partitioning schemes

hash 4-9range 4-8

DBA Monitoroverview 1-5

DBA Monitor ServerAlternate 1-8

DBA Server 1-5, 2-1, 3-2and interfaces file 2-7log file 2-1overview 1-5primary node 1-8server number 1-9and shutdown 2-5

DBA SMonitor erveralternate node 1-8

dbcc 7-10DDL 1-5

alter database 7-2create database 7-2create default 7-3create index 7-2create proc 7-3create rule 7-3create table 7-4create trigger 7-3create view 7-4

Decision Support SystemsSee also DSS 3-1

Declustering

Index-4


partial 4-6Declustering information 4-11default network packet size 8-7, 8-8default settings 6-13detailed output 10-4 to 10-11_devicename dump device name 6-6Devices

adding 4-1gd_dev 4-1

Directoryglobal

and nav_util 3-3disabling packet coalescing 8-12Disaster recovery 6-2, 6-15disk arrays 8-2Disk devices

adding devices 4-1disk init command, Backup and

Restore 6-16disk refit 7-11disk refit command 7-11disk reinit 7-11disk space 15-3DLL

See alsoData definition language 7-2DML 1-5

Aggregates 7-4group by 7-9group by all 7-9insert select 7-5joins 7-9miscellaneous 7-10See also Data manipulation

language 7-4subqueries 7-5, 7-9update decluster columns 7-8update or delete commands with an

outer join clause 7-8views defined with aggregates 7-9

DN Packet Size 8-11DN packet size parameter 8-11dpst

using 14-1DSS 4-6, 8-13, 12-7

See also Decision Support Systems 3-1Dump

media 6-2, 6-4dump 6-1dump_device parameter 6-6dump command 6-1 to 6-43

gdnavdb database 6-17syntax 6-21

dump database command 6-19Dump devices

naming convention 6-5dump transaction 4-4dump transaction command 6-20

EEllipsis (...) in SQL statements xxivEnvironment variables 2-5 to 2-6, 5-11

DISPLAY 2-6DN 2-6DSQUERY 2-6IFFILE 2-6, 2-9LANG 2-6LC_ALL 2-7NAV_VDIR 2-7NAVIGATOR 2-2, 2-7PATH 2-7REELENV 9-1SYBASE 2-2, 2-7XENVIRONMENT 2-7

ErrorsBackup and Restore 6-31

Exampleshash declustering 4-14pbcp

5-12range declustering 4-14schema declustering 4-13

examples 8-21execute 7-11execute command 7-11executing system procedures 7-15Explain

output 10-2, 10-4, 10-11



parallel query 10-1turning on 10-2utility 10-1

Extend database facilityhow it works 4-5

Extending databases 4-5 to 4-6how to 4-5

external SCSI disks 8-2

FFailover

backing up to disk 6-10backing up to tape 6-10changing volume groups 6-10logging into a control server 6-12restoring from disk 6-11restoring from tape 6-11

Fastercompletion time 1-3

field_terminator 5-8file_type 5-8file permissions 15-2file systems (currently not

supported) 8-3first_batch 5-8fix_test 7-10Fixed

completion time 1-3workload 1-3

Flags, tracing 5-20flow and congestion control of split

server 8-11FLow and congestion control of split

servers 8-11format_files 5-8Fragments 1-4Functions

image 7-13patindex 7-13text 7-13

GGD 1-6gd_dbrf_db_info, Schema Server

table 6-13gd_dbrf_db_info table 6-42, 6-43gd_dbrf_defaults table 6-41gd_dbrf_device_info table 6-43gd_dbrf_sqlserver_info table 6-43gd_dev

device 4-1gd_dump_devices table 6-8gd_get_dbrf_defaults stored procedure 6-42gd_return_dump_id stored procedure 6-43gd_set_dbrf_defaults 6-2, 6-8, 6-13gd_set_dbrf_defaults stored procedure 6-8,

6-13, 6-14, 6-22, 6-23, 6-30, 6-39 to6-41

gdnavdbglobal directory database 3-2

gdnavdb database 6-16 to 6-18stored procedures 6-38

general in-place strategy 8-24Global

consistency 6-14, 6-26directory

and nav_util 3-3variables 7-14, 8-14

Global Directory 6-16overview 1-6

Global directory 1-6database 3-2

global directory 15-1global join order 8-22Graphical interface

Backup and Restore 6-31

HHardware configuration 8-1Harsh partitioning

random 4-9Hash declustering

examples 4-14Hash partitioning 4-7, 4-9

Index-6


History log, Backup and Restore 6-13home 4-12Home directory

Sybase MPP 2-2

Iidentifiers 7-11IFFILE 15-2Image

function 7-13Incremental backups 6-19indexalloc 7-10indexes 8-15index ID access differences 7-19insert 15-5insert bulk command 5-19insert bulktablename 5-17inserts into index tables 15-4Instance 1-8

overview 1-8Instance number 1-8interfaces_files 5-8Interfaces file 2-2interfaces file 15-2interfaces file 2-7, 2-7 to 2-9, 7-20

example 2-8IFFILE 2-9modifying the 2-9mpp_netutil 2-9syntax 2-9

Inter-request parallelism 4-9intervals 4-13Intra-statement parallelism 1-2, 4-10iostat 15-5, 15-7isql command

master client 5-18, 5-19

Jjob processing 8-17Joins 1-3, 1-6, 7-19

Kkerberos 13-4Key, partitioning 1-4kill 7-10

LLarge I/O

cfg16kbufpool 11-2config block parameters 11-5default value 11-2disabling 11-4enabling 11-3guidelines 11-2guidelines for using 11-1overview 11-1technical notes 11-4, 11-5

Large I/O buffer pools 8-12LC_ALL 2-6lc_errfile_name 5-10lc_outfile_name 5-9limiting search time 12-13load 6-1load_option parameter, load database

command 6-22Load client 5-1, 5-17load client 5-1load command 6-1 to 6-43

syntax 6-24load database command, Backup and

Restore 6-22, 6-22 to 6-23consistency 6-22

load transaction command, Backup andRestore 6-22, 6-23 to 6-24

Localconsistency 6-14, 6-15, 6-26

local join order 8-22Local variables 7-14Log Devices

adding device 4-2Log devices 6-9Log file

DBA Server 2-1Logs



applying 6-22Backup and Restore 6-1

MManuals, related xxiiMaster client 5-1, 5-17

pbcp 5-17pbcp interface 5-17

master client 5-1master database 6-16 to 6-18Master thread 5-17master thread 5-1maxerrors 5-10maximum 16K buffers 11-4maximum network packet size 8-7, 8-9maximum value for cfg16kbufpool 11-2Media failure 6-25 to 6-26

example backup strategy 6-25memory 8-1, 15-3merge 5-1minimum value for cfg16kbufpool 11-2mode 4-12modifying 6-3Mounting backup volumes 6-21mpp_netutil 2-9mppdba user 15-3mppinstall 2-1

utility 3-2MPPM 2-4, 4-6

Configuration Management 1-6Log Manager 1-6

MPP Manager 2-4configuration management tool 8-3See also MPPM 8-3SQL Server configuration 8-3

mpp-netutil command 2-9multicolmn partioning keys 8-16Multicolumn partitioning keys 4-10multiple concurrent access 7-15

NNamed cache 8-12

Namesbackup device 6-5REELibrarian tape volumes 6-30server ID 1-9tapes 6-5

Naming conventions 1-8, 1-8 to 1-9nav_startup 2-1

options 2-2syntax 2-2

nav_startup command 2-1, 2-2, 2-4syntax 2-2

nav_util 14-4nav_util command 3-3navdisk_dumpdevice 6-7navdisk_dumpdevice 6-7navtape_dumpdevice 6-7new 7-18Node

alternate installation 1-8overview 1-8primary installation 1-8realms 3-1

node confirmation 15-2num_load_clients 5-7number_of_columns 4-12number_of_servers 4-12

Oobject ID 7-19OLTP 3-1, 4-6, 4-7, 8-13, 11-2, 12-7, 15-5One server optimization 8-13one server optimization 8-13Open Client

and ct_cancel() 5-18and pbcp 5-1sending an asynchronous

attention 5-18Open Server 5-1, 5-17optimal in-place strategy 8-24Optimization 8-14order by clause 7-12OSF/Motif graphical environment xxiOSO

Index-8


See also One server optimization 8-13Other manuals xxiioutput_fir 5-9Overridding parallel optimizer

report processing overridedirectives 12-6

selecting servers 12-2selecting servers for redecluster-2

joins 12-5setting directives 12-1specifying global join order 12-2specifying join strategies 12-4

Overviewpbcp 5-1

PP&T

Aggregate processing 8-24, 8-25aggregate processing 8-23choosing packet sizes 8-8, 8-9configuring schema server 8-3configuring servers 8-3, 8-6configuring serverssplit server

subsystem values 8-7configuring SQL Server 8-3disk arrays 8-2, 8-3external SCSI disks 8-2, 8-3hardware configuration 8-1inplace joins 8-21joins and datatypes 8-21large I/O buffer pool 8-12multiway join processing 8-21physical data design 8-15sizing tempdb 8-3software configuration 8-1, 8-2SQL server optimizatioins 8-13tuning split server performance 8-10,

8-11Writing Queries 8-16writing queries 8-16, 8-17, 8-18

packet_size 5-9Parallel

processing 1-1

processing systems 1-1Parallel bulk copy 5-1 to 5-20parallel environment 8-16Parallelism 1-1

inter-request 4-9intra-statement 1-2, 4-10partitioned 1-2pipelined 1-2shared nothing 1-2, 1-4

Parallel optimizeroverriding 12-1

Parallel processing systems 1-1Parallel query

global processing 10-1local processing 10-1See also Explain 10-2summary 10-1

Partial declustering 4-6Partitioned data 1-4

backup 6-19Partitioned parallelism 1-2Partitioned tables

rules for creating 4-11Partitioning

tables 4-6Partitioning key 1-4Partitioning keys

multicolumn 4-10Partitioning schemes 4-7 to 4-10

hash 4-9range 4-8schema 4-10

Partitioning Tables 4-6 to 4-15Partitioning tables 4-6

schemes 4-6Partitions 1-2Password

"sa" user 2-3password 5-8Patindex function 7-13pbcd

control commands 5-17, 5-18sample sequence of events 5-18trace flags 5-19 to 5-20



pbcp 5-4, 5-16aborting 5-16configuration file 5-12

parameters 5-6configuration file parameters 5-6, 5-7,

5-8, 5-9, 5-10control commands 5-17, 5-20, 6-2designing an API for 5-17

master client interfact 5-17graphical overview 5-3how it works 5-2overview 5-1performance guidelines 5-11preparing to use 5-4robopbcp 5-16Run examples 5-12 to 5-16setting the wait interval 5-11using the command line interface 5-5

pbcp_abort 5-17pbcp_abort command 5-18pbcp_done 5-17pbcp_done command 5-19pbcp_init command 5-17, 5-19pbcp_init number of routers 5-17, 5-20, 6-2pbcp_kill command 5-18pbcp_killtablename 5-18pbcp command 5-1 to 5-20

aborting 5-16and bcp, difference 5-4designing an API for

partially completedoperations 5-18

preparing to use 5-4pbcp configuration file parameter 5-6 to

5-10pbcp vs. bcp 5-4Performance

Backup and Restore 6-12 to 6-13database 1-3

Performance and tuningSee alsoP&T 8-1

Peripherals 6-13Physical data design 8-15

indexing 8-15

Pipelined parallelism 1-2Pools, REELibrarian (tape management

system) 6-29Primary installation node 1-8Primary node 1-8Processors

multiple 1-2.profile file 2-6pst

using 14-3pst command 3-3

RRAID levels 8-2 to 8-3Range declustering

examples 4-14Range partitioning 4-7, 4-8readtext 7-12readtext command 7-12Realm 1-7

base 1-7regular 1-8

realm 1-1Realms

adding 3-1, 3-2, 8-11, 14-1 to 14-5after 3-3procedure 3-2

after adding 3-3before adding 3-2narrow 3-1overview 1-7performance 3-1redistributing data 3-3wide 3-1

recovering from high setting of 16Kbuffer pool 11-5

Recovery 6-31Recovery Manager

overview 1-7Recovery manager

enabling 13-1input used by 13-3kerberos ticket expiration 13-4

Index-10


output produced by 13-4server monitoring scheme 13-2

Redistribution, data 7-20reducing the search space 12-12REELlibrarian 9-1

add user tape pool 9-3configuring 9-2environment variable 9-1installing 9-1managing 9-1starting 9-3submit tapes to user pool 9-4test 9-4

REELlibrarian (tape managementsystem) 6-3, 6-5

Regular realm 1-8Related manuals xxiirepartitioning strategy 8-24Response time 1-3restoring 6-3robopbcp

pbcp 5-16Rollback 7-20rollback behavior 7-20rollback transaction command 7-3router 5-1row_terminator 5-8RS_MAX_DATA_PACKET 8-10RS_MAX_DATA_PACKET

parameter 8-10RS_Q_HIGH/RS_Q_LOW 8-10RS_Q_HIGH/RS_Q_LOW

parameters 8-10rsh command 5-6Rules

partitioned tables 4-11sp_place_table 4-12

Ssa password 15-3sar 15-6"sa" user 2-3save transaction 7-12

save transaction command 7-12Scalable database performance 1-3Scale up 1-3, 4-9schema_split_server_name 5-7Schema declustering

example 4-13Schema partitioning 4-7Schema Server 1-8, 3-2

adding realms 3-2alternate node 1-8and interfaces file 2-7overview 1-6and pbcp 5-18primary node 1-8server number 1-9and shutdown 2-5sp_configure command parameters 8-5Split Server 5-1, 5-7stored procedures 6-38

Schema Splilt Servers 5-1Schema Split Server

and bcp 5-19and insert bulk 5-17master client 5-1, 5-17name 5-7Open Server 5-17and pbcp 5-4

search space 12-11See also Database Definition

Language 1-5See Also Data Manipulation

Language 1-5See also DML 1-5See also DML 7-4See also GD 1-6See also Global directory 1-6See also MPPM 2-4See also MPP Manager 2-4selectinto 4-11select into command 4-11selectivity 12-10Server

naming conventions 1-8Server ID



naming scheme 1-9servername 4-12Servers

number 1-9set command 7-12Settings window, Backup and

Restore 6-14Shared nothing parallelism 1-2, 1-4Shutdown 2-4

nowait 2-5thread 2-5

Shutdownwith nowait option 2-4

shutdown 7-10shutdown

utility 2-4shutdown command 2-4shutdown with nowait command 2-4Single point failure 6-15single table queries 8-17Site failure

backup strategy 6-26 to 6-28example backup strategy 6-27

Sizing tempdb 8-3skew 15-4Small tables 4-10software configuration 8-1sp_addmessage system procedure 7-16sp_addumpdevice 6-4sp_addumpdevice system procedure 6-5,

6-8, 6-17, 6-18sp_configure 8-4

parameters 8-4sp_configure command 8-4, 8-5sp_extenddb 4-5sp_extenddb stored procedure 4-5, 4-6sp_logdevice 4-2

examples 4-3sp_password system procedure 2-3sp_place_table 1-6, 3-3sp_place_table 4-8

parameter 4-12, 4-13parameters 4-12rules 4-12

using 4-11sp_place_table system procedure 4-11, 7-4

examples 4-13sp_spaceused 15-4speeding up repartitioning 8-15Speed up 1-3Split/Merge Server 1-7, 3-2

alternate node 1-8names 5-7network message size 8-10overview 1-6and pbcp 5-4, 5-7primary node 1-8Schema Server 5-1, 5-7server number 1-9and shutdown 2-5to SQL Server network packet

size 8-11thread buffer pools 8-10

split_server_names 5-7split packets 8-12Split server

flow control 8-11, 8-12Split server subsystem values 8-7SQL

commands 7-1Server

bcp 5-1and Control Server 1-7interfaces file 2-7master device 3-2parallel bulk copy 5-2and pbcp 5-18and pbcp_kill 5-18sp_configure command

parameters 8-4 to 8-7and sp_extenddb 4-5, 4-6Split Server network packet

size 8-11syntax conventions xxiii

SQL server 9.1-MPP 7-1SQL Server command lind

parameters 15-3SQL server optimization 8-13

Index-12


SQL server packets 8-11SQL Servers 1-2

server number 1-9Square brackets [ ]

in SQL statements xxiiiStart-Up

options 2-3Start up 2-1 to 2-2Start-up

mppinstall 2-1nav_startup 2-1syntax 2-2verifying Sybase MPP 2-4

Stored procedures 7-14Backup and Restore 6-38 to 6-43

storing 8-25storing user databases 7-19Striping 1-4Subqueries 1-3Sybase MPP

home directory 2-2software 1-4, 1-6system overview 1-6

sybtli command 2-9Symbols

SQL statement xxiii to xxivSyntax

create database 4-5Syntax conventions, Transact-SQL xxiii

to xxivsyslogs 4-2System

procedures 7-15System procedures

sp_extenddb 4-5sp_place_table 4-9

TTable

hash partition 4-9tablealloc 7-10tablename 5-6Tables

gd nodes 15-2partitioning 4-6scans 1-3small 4-10syslogs 4-2truncate table 5-16

Tapebackup configuration 6-5management system 6-3, 6-5management systems 6-29naming convention, backup 6-5

tempdb 8-3Terms

alternate node 1-8instance 1-8node 1-8partial declustering 4-6pbcp 5-1primary node 1-8realm 1-7

Textfunction 7-13

text 7-12Thread, master 5-17Thread, shutdown 2-5Trace flags

pbcd 5-19tracing=verbos 5-10Tracing flags 5-20Transaction

logs 6-1, 6-24logs, applying 6-22rate 4-9

transaction logs 15-3Transact-SQL 7-1

data definition language 7-2Data munipulation language 7-4datatype 7-13implementation 7-1other commands 7-10, 7-11, 7-12SQL server 9.1-MPP 7-1system functions 7-12system procedures 7-15, 7-16, 7-18system tables 7-19



tempdb 7-13temporary tables 7-14transactions 7-19, 7-20variables 7-14

Transact-SQL commands 7-1 to 7-12Triggers 7-3

and transactions 7-20Troubleshooting

MPP Start-up 15-1, 15-2, 15-3performance issues 15-4

TroubleTroubleshootingCPU utilization of Sybase MPP 15-5high operating system paging

activity 15-6performance issues 15-4, 15-7

truncate table 5-16Tuning split server performance 8-10

parameters 8-10, 8-11Two-phase commit 7-20two-phase commit 7-20

UUniform distribution 4-9Updates 6-15, 7-19updates and joins 7-19User

nav_startup 2-2"sa" 2-3

username 5-8using covered indexes 8-15Utilities

Backup and Restore 6-2dpst 3-3, 14-1Explain 10-1mpp_netutil 2-9mppinstall 3-2nav_util

14-4pst

14-3

Vvalue 4-13Variables

global 7-14, 8-14local 7-14

Variables, environment 5-11Version information

for Sybase MPP 2-4Views 7-4Volume sets, REELibrarian (tape

management system) 6-29VSA Engines 1-6

Wwaitfor 7-12waitfor command 7-12Workload 1-2

fixed 1-3large 1-3

Workload configurable values 8-6workload configurable values 8-6writetext 7-12writetext command 7-12Writing queries 8-16

Xx 5-6xdba program

shutdown 2-5X Window System xxi

Index-14
