Here is an example of an ALTER DBSPACE statement that adds 800 megabytes to a main database file: ALTER DBSPACE SYSTEM ADD 800 MB; For more information about ALTER DBSPACE, see Section 10.6.1, “File Frag - mentation,” earlier in this chapter. Step 8: Defragment the hard drive. Disk fragmentation hurts performance, and this is an excellent opportunity to make it go away. This step is performed after the database is increased in size (Step 7) because some disk defragmentation tools only work well on existing files. Step 9: Examine the reload.sql file for logical problems, and edit the file to fix them if necessary. You can perform this step any time after Step 2, and it is completely optional. Sometimes, however, databases are subject to “schema drift” over time, where errors and inconsistencies creep into the database design. At this point in the process the entire schema is visible in the reload.sql text file and you have an opportunity to check it and fix it. Some problems can be easily repaired; for example, removing an unneces - sary CHECK constraint, dropping a user id that is no longer used, or fixing an option setting. Other problems are more difficult; for example, you can add a column to a table, but deleting a column from a CREATE TABLE statement may also require a change to the corresponding LOAD TABLE statement; see Section 2.3, “LOAD TABLE,” for more information about how to skip an input column with the special keyword "filler()". Tip: At this point double-check the setting of database option OPTIMIZA- TION_GOAL. Make sure the reload.sql file contains the statement SET OPTION "PUBLIC"."OPTIMIZATION_GOAL" = 'all-rows' if that is what you want the setting to be — and you probably do. In particular, check the value after unloading and reloading to upgrade from an earlier version; the reload process may set this option to the value you probably do not want: 'first-row'. Step 10: Reload the database by running reload.sql via ISQL. This may be the most time-consuming step of all, with Steps 2 and 8 (unload and defragment) in close competition. Here is an example of a Windows batch file that runs ISQL in batch mode to immediately execute the reload.sql file without any user interaction: "%ASANY9%\win32\dbisql.exe" -c "DSN=volume" c:\temp\reload.sql Tip: Do not use the -ac, -an, or -ar options of dbunload.exe. These options can be used to partially automate the unload and reload process, but they often lead to problems and inefficiencies. In particular, they use an all-or-nothing approach wherein a failure at any point in the process requires the whole thing to be done over again. The step-by-step process described here is better because it can be restarted at a point prior to the failure rather than backing up to the beginning. This can make a big difference for a large database where the unload and reload steps each take hours to complete and there is limited time available to complete the task. 436 Chapter 10: Tuning Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. Step 11: Check to make sure everything’s okay. Here are some statements you can run in ISQL to check for file, table, and index fragmentation: SELECT DB_PROPERTY ( 'DBFileFragments' ) AS db_file_fragments; CHECKPOINT; SELECT * FROM p_table_fragmentation ( 'DBA' ); CALL p_index_fragmentation ( 'DBA' ); Following are the results; first of all, the entire 800MB database file is in one single contiguous area on disk, and that’s good. Second, the application tables all have one row segment per row, which is also good because it means there are no row splits caused by short columns; there are a lot of extension pages but in this case they’re required to store long column values (blobs). Finally, none of the indexes have more than two levels, and their density measurements are all close to 1, and those numbers indicate all is well with the indexes. db_file_fragments ================= 1 table_name rows row_segments segments_per_row table_pages extension_pages ========== ===== ============ ================ =========== =============== child 25000 25000 1.0 25000 25000 parent 5000 5000 1.0 5000 5000 table_name index_name rows leaf_pages levels density concerns ========== ========== ===== ========== ====== ======== ================= child child 25000 116 2 0.958616 child parent 25000 58 2 0.959599 parent parent 5000 17 2 0.944925 Step 12: At this point you can make the database available to other users; start it with dbsrv9.exe if that’s what is done regularly. Here is an example of a Win- dows batch file that starts the network server with support for TCP/IP connections: "%ASANY9%\win32\dbsrv9.exe" -x tcpip volume.db 10.7 CREATE INDEX Indexes improve the performance of queries in many ways: They can speed up the evaluation of predicates in FROM, WHERE, and HAVING clauses; they can reduce the need for temporary work tables; they can eliminate sorting in ORDER BY and GROUP BY clauses; they can speed up the calculation of the MAX and MIN aggregate functions; and they can reduce the number of locks required when a high isolation level is used. Some indexes are automatically generated: A unique index is created for each PRIMARY KEY and UNIQUE constraint, and a non-unique index is cre - ated for each foreign key constraint. Other indexes are up to you; here is the syntax for explicitly creating one: <create_index> ::= CREATE [ UNIQUE ] [ CLUSTERED | NONCLUSTERED ] INDEX <index_name> ON [ <owner_name> "." ] <table_name> <index_column_list> [ <in_dbspace_clause> ] Chapter 10: Tuning 437 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. <index_name> ::= <identifier> that is unique among indexes for this table <owner_name> ::= <identifier> <table_name> ::= <identifier> <index_column_list> ::= "(" <index_column> { "," <index_column> } ")" <index_column> ::= <existing_column_name> [ ASC | DESC ] | <builtin_function_call> AS <new_column_name> <builtin_function_call> ::= <builtin_function_name> "(" [ <function_argument_list> ] ")" <builtin_function_name> ::= <identifier> naming a SQL Anywhere scalar function <function_argument_list> ::= <expression> { "," <expression> } <expression> ::= see <expression> in Chapter 3, "Selecting" <existing_column_name> ::= <identifier> naming an existing column in the table <new_column_name> ::= <identifier> naming a COMPUTE column to be added to the table <in_dbspace_clause> ::= ( IN | ON ) ( DEFAULT | <dbspace_name> ) <dbspace_name> ::= <identifier> SYSTEM is the DEFAULT name Each index that you explicitly create for a single table must have a different <index_name>. That restriction doesn’t apply to the index names that SQL Anywhere generates for the indexes it creates automatically. These generated index names show up when you call the built-in procedures sa_index_levels and sa_index_density, or the p_index_fragmentation procedure described in Section 10.6.4, “Index Fragmentation.” Here is how those generated index names are created: n The PRIMARY KEY index name will always be the same as the table name even if an explicit CONSTRAINT name is specified. n A FOREIGN KEY index name will be the same as the role name if one is defined, or the CONSTRAINT name if one is defined; otherwise it will be the same as the name of the parent table in the foreign key relationship. n A UNIQUE constraint index name will be the same as the CONSTRAINT name if one is defined, otherwise it is given a fancy name that looks like “t1 UNIQUE (c1,c2)” where t1 is the table name and “c1,c2” is the list of col- umn names in the UNIQUE constraint itself. Tip: Use meaningful names for all your indexes, and don’t make them the same as the automatically generated names described above. Good names will help you later, when you’re trying to remember why the indexes were created in the first place, and when you’re trying to make sense of the output from proce - dures like sa_index_levels. Each index is defined as one or more columns in a single table. Two indexes may overlap in terms of the columns they refer to, and they are redundant only if they specify exactly the same set of columns, in the same order, with the same sort specification ASC or DESC on each column; otherwise the two indexes are different and they may both be useful in different circumstances. The UNIQUE keyword specifies that every row in the table must have a different set of values in the index columns. A NULL value in an index column qualifies as being “different” from the values used in all other rows, including other NULL values. A UNIQUE index based on columns that allow NULL val - ues isn’t really “unique” in the way most people interpret it. For example, the following INSERT statements do not generate any error because one of the index columns is nullable, and multiple NULL values qualify as “unique”: 438 Chapter 10: Tuning Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. CREATE TABLE t1 ( key_1 INTEGER NOT NULL PRIMARY KEY, ikey_1 INTEGER NOT NULL, ikey_2 INTEGER NULL ); CREATE UNIQUE INDEX index_1 ON t1 ( ikey_1, ikey_2 ); INSERT t1 VALUES ( 1, 1, 1 ); INSERT t1 VALUES ( 2, 1, NULL ); INSERT t1 VALUES ( 3, 1, NULL ); Note: The fact that multiple NULL values are allowed in a UNIQUE index is a SQL Anywhere extension that is different from the ANSI SQL:1999 standard. UNIQUE indexes based on NOT NULL columns are more likely to be used to improve the performance of queries because they impose a stronger restriction on the column values. Note: UNIQUE constraints generate UNIQUE indexes where all the column values must be NOT NULL, even if those columns were declared as nullable in the CREATE TABLE. The same is true for PRIMARY KEY constraints: They generate non-null UNIQUE indexes. If the UNIQUE keyword is omitted from CREATE INDEX, a non-unique index is created where multiple rows can have the same values in the index columns. This kind of index is used for foreign keys where more than one child row can have the same parent row in another table. Non-unique indexes are also very useful for sorting and searching. The order of the columns in a multi-column index has a great effect on the way an index is used. For example, the following index on last name and first name will not help speed up a search for a particular first name, any more than the natural order of printed phone book entries will help you find someone named “Robert”: CREATE TABLE phone_book ( last_name VARCHAR ( 100 ), first_name VARCHAR ( 100 ), phone_number VARCHAR ( 20 ) PRIMARY KEY ); CREATE INDEX book_sort ON phone_book ( last_name, first_name ); SELECT * FROM phone_book WHERE first_name = 'Robert'; You can see the execution plan in a compact text format by choosing “Long plan” in the ISQL Tools > Options > Plan tab and then using the SQL > Get Plan menu option or pressing Shift + F5. Here is what ISQL displays for the query above; a full table scan is done to satisfy the predicate, and the book_sort index is not used: ( Plan [ Total Cost Estimate: 0 ] ( TableScan phone_book[ phone_book.first_name = 'Robert' : 5% Guess ] ) ) To speed up that particular query, a different index is required, one that has first_name as the first or only column in the index: CREATE INDEX first_name_sort ON phone_book ( first_name, last_name ); Chapter 10: Tuning 439 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. Now ISQL reports that an index scan is used instead of a table scan: ( Plan [ Total Cost Estimate: 0 ] ( IndexScan phone_book first_name_sort ) ) By default, index column values are sorted in ascending order (ASC) in the index. SQL Anywhere is smart enough to use an ascending index to optimize an ORDER BY clause that specifies DESC on the index column, so you don’t have to worry too much about carefully picking ASC versus DESC when defining indexes. One place it does matter, however, is with multi-column sorts using different sort sequences; an index with matching ASC and DESC keywords is more likely to be used for that kind of ORDER BY. Here is an example of an ORDER BY on the same columns that are speci - fied for the book_sort index defined earlier, but with a different pair of sorting keywords, ASC and DESC, instead of the two ASC sorts used by the index: SELECT * FROM phone_book ORDER BY last_name ASC, first_name DESC; The ISQL plan shows that a full table scan plus a temporary work table and a sort step is used because the book_sort index doesn’t help: ( Plan [ Total Cost Estimate: .0377095 ] ( WorkTable ( Sort ( TableScan phone_book ) ) ) ) Here’s a different index that does help; in book_sort2 the column sort orders ASC and DESC match the ORDER BY: CREATE INDEX book_sort2 ON phone_book ( last_name, first_name DESC ); Now the plan looks much better; no more table scan, no more work table, no more sort step, just an index scan: ( Plan [ Total Cost Estimate: .000645 ] ( IndexScan phone_book book_sort2 ) ) If you define an index as CLUSTERED, SQL Anywhere will attempt to store the actual rows of data in the same physical order as the index entries. This is especially helpful for range retrievals where a query predicate specifies a nar - row range of index column values; e.g., “show me all the accounting entries for the first week of January this year, from a table holding entries dating back 10 years.” Only one index for each table can be CLUSTERED, simply because a sin - gle table can only be sorted in one order. As new rows are inserted SQL Anywhere will attempt to store rows with adjacent index values on the same physical page. Over time, however, the physical ordering of rows will deviate from the index order as more and more rows are inserted. Also, if you create a clustered index for a table that already has a lot of rows, those rows will not be rearranged until you execute a REORGANIZE TABLE statement for that table. 440 Chapter 10: Tuning Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. For more information about REORGANIZE TABLE, see Section 10.6.3, “Table Reorganization.” Tip: The primary key is almost never a good candidate for a clustered index. For example, the primary key of the ASADEMO sales_order_items table consists of the order id and line_id, and although the primary key index on those col - umns is useful for random retrievals of single rows, a range query specifying both of those columns is very unlikely. On the other hand, a query asking for all sales_order_items with a ship_date falling in a range between two dates might be very common, and might benefit from a clustered index on ship_date. Here are some examples of CREATE INDEX statements that were generated by the Index Consultant in Section 10.3 earlier; note that each clustered index is immediately followed by a REORGANIZE TABLE statement that physically rearranges the rows in the same order as the index: CREATE INDEX "ixc_volume_test4_1" ON "DBA"."parent" ( non_key_5 ); CREATE CLUSTERED INDEX "ixc_volume_test4_2" ON "DBA"."parent" ( non_key_4 ); REORGANIZE TABLE "DBA"."parent"; CREATE INDEX "ixc_volume_test4_3" ON "DBA"."child" ( key_1 ,non_key_5 ); CREATE INDEX "ixc_volume_test4_4" ON "DBA"."child" ( non_key_5 ); CREATE CLUSTERED INDEX "ixc_volume_test4_5" ON "DBA"."child" ( non_key_4 ); REORGANIZE TABLE "DBA"."child"; When processing a query SQL Anywhere will use at most one single index for each table in the query. Different queries may use different indexes on the same table, and if the same table is used twice in the same query, with different alias names, they count as different tables and different indexes may be used. There is a cost associated with each index. Every INSERT and DELETE statement require changes to index pages, and so do UPDATE statements that change index column values. Sometimes this cost doesn’t matter when com - pared with the huge benefits that indexes can bring to query processing; it’s just something to keep in mind if your tables are volatile. On the other hand, if a particular index doesn’t help with any query, the expense of keeping it up to date is a complete waste. The usefulness of an index depends on a combination of factors: the size of the index columns, the order of the columns in the index, how much of the index column data is actually stored in each index entry, and the selectivity of the resulting index entry. SQL Anywhere does not always store all of the index column data in the index entries, and it is all too easy to create an index that is worse than useless because it requires processing to keep it up to date but it doesn’t help the performance of any query. The declared data width of an index is calculated as the sum of 1 plus the declared maximum length of each column in the index. The extra 1 byte for each column accommodates a column length field. SQL Anywhere uses three different kinds of physical storage formats for index entries: full index, com - pressed index, and partial index. Here is a description of each format and how they are chosen: Chapter 10: Tuning 441 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. n A full index is created if the declared data width is 10 bytes or smaller. With a full index the entire contents of the index columns are stored in the index entries. For example, an index on a single INTEGER column will have a declared data width of1+4=5bytes, and the entire 5 bytes will be stored in each index entry. n A compressed index is created if the declared data width ranges from 11 to 249 bytes. With a compressed index the entire contents of the index col - umns are compressed to reduce the size of the index entries. For example, an index consisting of a VARCHAR(3)column plus a VARCHAR ( 100 ) column will have a declared data width of1+3+1+100=105bytes, and the column values will be greatly compressed to create index entries that are much smaller than 105 bytes. In fact, compressed indexes are often smaller in size than full indexes. n A partial index is created if the declared data width is 250 bytes or larger. With a partial index the column values are truncated rather than com - pressed: Only the first 10 bytes of the declared data width are actually stored. For example, an index consisting of a single VARCHAR ( 249 ) will have a declared data width of 1 + 249, and only the length byte plus the first nine characters from the column value are stored in the index entry. The partial index format is a variation of the full index format with the differ- ence being the index entry is chopped off at 10 bytes. Note that it’s the whole index entry that is truncated, not each column value. For example, if an index consists of an INTEGER column and a VARCHAR ( 300 ) column, the declared data width of1+4+1+300=306exceeds the upper bound of 249 for com- pressed indexes, so a partial index with 10-byte entries will be used. The whole INTEGER column values will be stored, but only the first 4 bytes of the VARCHAR ( 300 ) column will fit in the index entries. The truncation of wide index values has a profound impact on performance of queries where the affected index is being used. If the leading bytes of data in the index columns are all the same, and the values only differ in the portion that has been truncated and not actually stored in the index entries, SQL Anywhere will have to look at the table row to determine what the index column values actually are. This act of looking at the column values in the row instead of rely - ing on the values in the index entry is called a “full compare,” and you can determine how often SQL Anywhere has had to do this by running the follow - ing SELECT in ISQL: SELECT DB_PROPERTY ( 'FullCompare' ); If the value DB_PROPERTY ( 'FullCompare' ) increases over time, then perfor - mance is being adversely affected by partial indexes. You can see how many full compares are done for a particular query by looking at the “Graphical plan with statistics” option in ISQL as described earlier in Section 10.5, “Graphical Plan.” It is not uncommon for 10 or more full compares to be required to find a single row using a partial index, and each one of those full compares may require an actual disk read if the table page isn’t in the cache. You can also watch the number of full compares being performed for a whole database by using the Windows Performance Monitor as described in the next section. 442 Chapter 10: Tuning Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. The partial index format doesn’t completely defeat the purpose of having an index. Index entries are always stored in sorted order by the full index column values, even if the index entries themselves don’t hold the full values. However, when comparisons involving index columns are evaluated, it helps a lot if the full column values are stored in the index entries; the full and compressed index formats often perform better than the partial index format. 10.8 Database Performance Counters SQL Anywhere keeps track of what it is doing by updating many different numeric counters as different operations are performed and different events occur. These counter values are available to you via three different built-in func - tions (PROPERTY, DB_PROPERTY, and CONNECTION_PROPERTY) and three built-in procedures (sa_eng_properties, sa_db_properties, and sa_conn_properties). The PROPERTY function returns the value for a named property at the database server level. The DB_PROPERTY function returns the value of a property for the current database, and you can specify a database number to get the property for a different database on the same server. The CONNECTION_PROPERTY function returns a property value for the current connection, and you can specify a connection number to get a property value for a different connection. All of the performance counter values are available as property values returned by these functions. Here is an example showing calls to all three functions; the PROPERTY call returns the server cache size in kilobytes, the DB_PROPERTY call returns the number of disk writes to the current database, and the CONNECTION_PROPERTY call returns the number of index full compares made for the current connection: SELECT PROPERTY ( 'CurrentCacheSize' ) AS server_cache_size_in_K, DB_PROPERTY ( 'DiskWrite' ) AS database_disk_writes, CONNECTION_PROPERTY ( 'FullCompare' ) AS connection_full_compares; Here is the result of that query: server_cache_size_in_K database_disk_writes connection_full_compares ====================== ==================== ======================== 130680 26926 10909818 The three built-in procedures return the names and values of all of the properties as multi-row result sets. The sa_eng_properties procedure returns 90 different server-level property values, the sa_db_properties procedure returns 135 prop - erty values for each database, and sa_conn_properties returns 196 properties for each connection. Included in these lists of property values are all the perfor - mance counters; here is an example of calls to all three procedures: CALL sa_eng_properties(); all server properties CALL sa_db_properties(); all database properties for all databases CALL sa_conn_properties(); all connection properties for all connections The following CREATE VIEW and SELECT displays all the server-level and database-level performance counters in a single list. It eliminates most of the property values that aren’t performance counters by selecting only numeric Chapter 10: Tuning 443 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. values, and it uses the function calls PROPERTY ( 'Name' ) and DB_NAME ( Number ) to include the server name and each database name respectively. CREATE VIEW v_show_counters AS SELECT CAST ( STRING ( '1. Server ', PROPERTY ( 'Name' ) ) AS VARCHAR ( 200 ) ) AS property_type, PropName AS name, Value AS value, PropDescription AS description FROM sa_eng_properties() WHERE ISNUMERIC ( value)=1 UNION ALL SELECT CAST ( STRING ( '2. DB ', DB_NAME ( Number ) ) AS VARCHAR ( 200 ) ) AS property_type, PropName AS name, Value AS value, PropDescription AS description FROM sa_db_properties() WHERE ISNUMERIC ( value)=1 ORDER BY 1, 2; SELECT * FROM v_show_counters; Here are a few lines from the result set returned by that SELECT. This list shows that the cache is working well because almost all the cache reads are resulting in cache hits. However, index lookups are resulting in an enormous number of full compares, which means there is a problem with the way one or more indexes are designed: property_type name value description ================ ================ ======== ================================= 1. Server volume CacheHitsEng 26845056 Cache Hits 1. Server volume CacheReadEng 26845293 Cache reads 1. Server volume CurrentCacheSize 130680 Current cache size in kilobytes 1. Server volume DiskReadEng 470 Disk reads 2. DB volume CacheHits 26842887 Cache Hits 2. DB volume CacheRead 26843046 Cache reads 2. DB volume DiskRead 378 Disk reads 2. DB volume FullCompare 20061691 Number of comparisons beyond the hash value 2. DB volume IndLookup 1584417 Number of index lookups The Windows Performance Monitor can be used to watch individual perfor - mance counters over time. Here are the step-by-step instructions for setting up the monitor to display a graph showing how often index full compares are happening: 1. Open the Windows Performance Monitor via Start > Programs > Admin - istrative Tools > Performance. 2. Start monitoring the index full compares as follows: Press the right mouse button, then pick Add Counters to display the Add Counters dialog box shown in Figure 10-19. 3. Pick ASA 9 Database in the Performance object list. 444 Chapter 10: Tuning Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 4. Choose Select counters from list and then select Index: Full Compares/sec. 5. Choose Select instances from list and then select the database you’re interested in. 6. Press the Explain button to see a description of the currently selected counter. 7. Press the Add button, then Close to return to the Monitor window. 8. Adjust the graph properties as follows: Press the right mouse button, then pick Properties and Data to show the System Monitor Properties > Data tab in Figure 10-20. Chapter 10: Tuning 445 Figure 10-19. Adding a counter to the Performance Monitor Figure 10-20. Adjusting color and scale in the Performance Monitor Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. [...]... about SQL Anywhere Studio deliver the lowest cost of ownership Visit ianywhere.com It’s a pretty good place to Studio easily integrates with a wide range look for inspiration, too ©2004 iAnywhere Solutions, Inc All rights reserved iAnywhere Solutions, SQL Anywhere and Sybase are trademarks or registered trademarks of Sybase, Inc or its subsidiaries IAS1102 Please purchase PDF Split-Merge on www.verypdf.com... purchase PDF Split-Merge on www.verypdf.com to remove this watermark You plug it in It works Not a bad place to look for Inspiration SQL Anywhere Studio To simplify your life even more, SQL Anywhere Why have your customers install and maintain a of backend data sources, including Oracle, database to power your enterprise applications? Microsoft, IBM and Sybase It supports an array Just plug in SQL Anywhere ... isolated transaction, 313 isolation level, 3 39-3 55, 452 0, 340-343 1, 343-346 2, 346-349 3, 3 49-3 55 cursor, 200 hints, 81 performance, 168, 182 , 206 ISOLATION LEVEL cursor clause, 206 ISQL, 363 commands, 161 INPUT, 64-68 option, 310 OUTPUT, 160-164 , 64 , 64 , 64 , 64 , 160 J Jackson, Michael A.,... sp_hook_dbmlsync_download_ri_violation, 253 sp_hook_dbmlsync_download _sql_ error, 251 sp_login_environment, 309 sp_tsql_environment, 309 SPA lock, 338 , 107 , 19 special literals, 51 special privilege, 370-372 special update default, 20 , 20 split, row, 424 SPT lock, 338, 339 SQL output file format, 160 SQL Server, 212 SQLCODE, 19, 20 SQLSTATE, 19, 20, 356 update, 168,... 432 table constraint, 29-3 0 , 29 FORMAT input option, 65, 67 load table option, 56, 59 output option, 160, 163, 164 unload option, 156, 157 Fourth Normal Form, 45-46 FOXPRO input file format, 65 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark Index output file format, 160 fragmentation, 421-437 file, 421-423 index, 4 29-4 32 table, 423-428 ,... database option to '100' This will tell SQL Anywhere to maintain important query optimization information for tables as small as 100 rows as well as large tables; this information is held in the SYSCOLSTAT table Small tables can cause problems too, and the default MIN_TABLE_SIZE_FOR_HISTOGRAM value of '1000' is too large 25 Use the CREATE STATISTICS statement to force SQL Anywhere to create histograms for... 10-22 shows a database that was originally created with SQL Anywhere 7 and then upgraded to Version 9 with dbupgrad.exe; the red X’s show that quite a few important features are still missing, features that won’t be available until the unload/reload process is performed as described in Section 10.6.6 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark Chapter 10: Tuning 453... capabilities after using dbupgrad.exe 10.10 Chapter Summary This chapter described various methods and approaches you can use to study and improve the performance of SQL Anywhere databases It covered the major performance tuning facilities built into SQL Anywhere: request-level logging, the Index Consultant, the Execution Profiler, and the Graphical Plan Several sections were devoted to fragmentation at the... is the end of the book; if you have any questions or comments you can reach Breck Carter at bcarter@risingroad.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark This page intentionally left blank Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark Index , comma join, 81, 101, 175 _ LIKE character, 120 -, 102, 294 - LIKE character, 121 -ac dbunload... end_upload_rows, 232 ENDIF, 105 , 297 environment variable, 393 EPA lock, 338 EPT lock, 338 error, event, 296 handling, 324-336 handling download, 2 49-2 54 handling upload, 240-242 459 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark Index ErrorNumber, 294, 295 ESCAPE, 121 LIKE predicate, 120 unload option, 156 ESCAPE CHARACTER input option, 65, 67 load table option, . STATISTICS statement to force SQL Anywhere to create histograms for tables you’re having trouble with. Once a histogram is cre - ated, SQL Anywhere will keep it. study and improve the performance of SQL Anywhere databases. It covered the major performance tuning facilities built into SQL Anywhere: request-level logging, the