home *** CD-ROM | disk | FTP | other *** search
/ ftp.pasteur.org/FAQ/ / ftp-pasteur-org-FAQ.zip / FAQ / databases / sybase-faq / part5 < prev    next >
Encoding:
Internet Message Format  |  2004-04-21  |  43.1 KB

  1. Path: senator-bedfellow.mit.edu!dreaderd!not-for-mail
  2. Message-ID: <databases/sybase-faq/part5_1082468590@rtfm.mit.edu>
  3. Supersedes: <databases/sybase-faq/part5_1074677126@rtfm.mit.edu>
  4. Expires: 2 Aug 2004 13:43:10 GMT
  5. References: <databases/sybase-faq/part1_1082468590@rtfm.mit.edu>
  6. X-Last-Updated: 2003/03/02
  7. From: dowen@midsomer.org (David Owen)
  8. Newsgroups: comp.databases.sybase,comp.answers,news.answers
  9. Subject: Sybase FAQ: 5/19 - ASE Admin (2 of 7)
  10. Reply-To: dowen@midsomer.org (David Owen)
  11. Followup-To: comp.databases.sybase
  12. Distribution: world
  13. Organization: Midsomer Consultants Inc.
  14. Approved: news-answers-request@MIT.EDU
  15. Keywords: FAQ, DATABASES, SYBASE, ASA, ASE, REP
  16. Originator: faqserv@penguin-lust.MIT.EDU
  17. Date: 20 Apr 2004 13:45:04 GMT
  18. Lines: 1068
  19. NNTP-Posting-Host: penguin-lust.mit.edu
  20. X-Trace: 1082468704 senator-bedfellow.mit.edu 563 18.181.0.29
  21. Xref: senator-bedfellow.mit.edu comp.databases.sybase:106203 comp.answers:56949 news.answers:270289
  22.  
  23. Archive-name: databases/sybase-faq/part5
  24. URL: http://www.isug.com/Sybase_FAQ
  25. Version: 1.7
  26. Maintainer: David Owen
  27. Last-modified: 2003/03/02
  28. Posting-Frequency: posted every 3rd month
  29.    A how-to-find-the-FAQ article is posted on the intervening months.
  30.  
  31.                          User Database Administration                          
  32.                                                                                
  33.  
  34.  
  35.     1.2.1    Changing varchar(m) to varchar(n)
  36.     1.2.2    Frequently asked questions on Table partitioning
  37.     1.2.3    How do I manually drop a table?
  38.     1.2.4    Why not create all my columns varchar(255)?
  39.     1.2.5    What's a good example of a transaction?
  40.     1.2.6    What's a natural key?
  41.     1.2.7    Making a Stored Procedure invisible
  42.     1.2.8    Saving space when inserting rows monotonically
  43.     1.2.9    How to compute database fragmentation
  44.     1.2.10  Tasks a DBA should do...
  45.     1.2.11  How to implement database security
  46.     1.2.12  How to shrink a database
  47.     1.2.13  How do I turn on auditing of all SQL text sent to the server
  48.     1.2.14  sp_helpdb/sp_helpsegment is returning negative numbers
  49.    
  50. Advanced Administration Basic Administration ASE FAQ
  51.  
  52. -------------------------------------------------------------------------------
  53.  
  54. 1.2.1: Changing varchar(m) to varchar(n)
  55.  
  56. -------------------------------------------------------------------------------
  57.  
  58. Before you start:
  59.  
  60.     select max(datalength(column_name))
  61.       from affected_table
  62.  
  63. In other words, please be sure you're going into this with your head on
  64. straight.
  65.  
  66. How To Change System Catalogs
  67.  
  68. This information is Critical To The Defense Of The Free World, and you would be
  69. Well Advised To Do It Exactly As Specified:
  70.  
  71. use master
  72. go
  73. sp_configure "allow updates", 1
  74. go
  75. reconfigure with override /* System 10 and below */
  76. go
  77. use victim_database
  78. go
  79. select name, colid
  80. from syscolumns
  81. where id = object_id("affected_table")
  82. go
  83. begin tran
  84. go
  85. update syscolumns
  86. set length = new_value
  87. where id = object_id("affected_table")
  88.   and colid = value_from_above
  89. go
  90. update sysindexes
  91. set maxlen = maxlen + increase/decrease?
  92. where id=object_id("affected_table")
  93.   and indid = 0
  94. go
  95. /* check results... cool?  Continue... else rollback tran */
  96. commit tran
  97. go
  98. use master
  99. go
  100. sp_configure "allow updates", 0
  101. go
  102. reconfigure /* System 10 and below */
  103. go
  104.  
  105. Return to top
  106.  
  107. -------------------------------------------------------------------------------
  108.  
  109. 1.2.2: FAQ on partitioning
  110.  
  111. -------------------------------------------------------------------------------
  112.  
  113. Index of Sections
  114.  
  115.   * What Is Table Partitioning?
  116.       + Page Contention for Inserts
  117.       + I/O Contention
  118.       + Caveats Regarding I/O Contention
  119.   * Can I Partition Any Table?
  120.       + How Do I Choose Which Tables To Partition?
  121.   * Does Table Partitioning Require User-Defined Segments?
  122.   * Can I Run Any Transact-SQL Command on a Partitioned Table?
  123.   * How Does Partition Assignment Relate to Transactions?
  124.   * Can Two Tasks Be Assigned to the Same Partition?
  125.   * Must I Use Multiple Devices to Take Advantage of Partitions?
  126.   * How Do I Create A Partitioned Table That Spans Multiple Devices?
  127.   * How Do I Take Advantage of Table Partitioning with bcp in?
  128.   * Getting More Information on Table Partitioning
  129.  
  130. What Is Table Partitioning?
  131.  
  132. Table partitioning is a procedure that creates multiple page chains for a
  133. single table.
  134.  
  135. The primary purpose of table partitioning is to improve the performance of
  136. concurrent inserts to a table by reducing contention for the last page of a
  137. page chain.
  138.  
  139. Partitioning can also potentially improve performance by making it possible to
  140. distribute a table's I/O over multiple database devices.
  141.  
  142. Page Contention for Inserts
  143.  
  144. By default, ASE stores a table's data in one double-linked set of pages called
  145. a page chain. If the table does not have a clustered index, ASE makes all
  146. inserts to the table in the last page of the page chain.
  147.  
  148. When a transaction inserts a row into a table, ASE holds an exclusive page lock
  149. on the last page while it inserts the row. If the current last page becomes
  150. full, ASE allocates and links a new last page.
  151.  
  152. As multiple transactions attempt to insert data into the table at the same
  153. time, performance problems can occur. Only one transaction at a time can obtain
  154. an exclusive lock on the last page, so other concurrent insert transactions
  155. block each other.
  156.  
  157. Partitioning a table creates multiple page chains (partitions) for the table
  158. and, therefore, multiple last pages for insert operations. A partitioned table
  159. has as many page chains and last pages as it has partitions.
  160.  
  161. I/O Contention
  162.  
  163. Partitioning a table can improve I/O contention when ASE writes information in
  164. the cache to disk. If a table's segment spans several physical disks, ASE
  165. distributes the table's partitions across fragments on those disks when you
  166. create the partitions.
  167.  
  168. A fragment is a piece of disk on which a particular database is assigned space.
  169. Multiple fragments can sit on one disk or be spread across multiple disks.
  170.  
  171. When ASE flushes pages to disk and your fragments are spread across different
  172. disks, I/Os assigned to different physical disks can occur in parallel.
  173.  
  174. To improve I/O performance for partitioned tables, you must ensure that the
  175. segment containing the partitioned table is composed of fragments spread across
  176. multiple physical devices.
  177.  
  178. Caveats Regarding I/O Contention
  179.  
  180. Be aware that when you use partitioning to balance I/O you run the risk of
  181. disrupting load balancing even as you are trying to achieve it. The following
  182. scenarios can keep you from gaining the load balancing benefits you want:
  183.  
  184.   * You are partitioning an existing table. The existing data could be sitting
  185.     on any fragment. Because partitions are randomly assigned, you run the risk
  186.     of filling up a fragment. The partition will then steal space from other
  187.     fragments, thereby disrupting load balancing.
  188.   * Your fragments differ in size.
  189.   * The segment maps are configured such that other objects are using the
  190.     fragments to which the partitions are assigned.
  191.   * A very large bcp job inserts many rows within a single transaction. Because
  192.     a partition is assigned for the lifetime of a transaction, a huge amount of
  193.     data could go to one particular partition, thus filling up the fragment to
  194.     which that partition is assigned.
  195.  
  196. Can I Partition Any Table?
  197.  
  198. No. You cannot partition the following kinds of tables:
  199.  
  200.  1. Tables with clustered indexes (as of release 11.5 it is possible to have a
  201.     clustered index on a partitioned table)
  202.  2. ASE system tables
  203.  3. Work tables
  204.  4. Temporary tables
  205.  5. Tables that are already partitioned. However, you can unpartition and then
  206.     re-partition tables to change the number of partitions.
  207.  
  208. How Do I Choose Which Tables To Partition?
  209.  
  210. You should partition heap tables that have large amounts of concurrent insert
  211. activity. (A heap table is a table with no clustered index.) Here are some
  212. examples:
  213.  
  214.  1. An "append-only" table to which every transaction must write
  215.  2. Tables that provide a history or audit list of activities
  216.  3. A new table into which you load data with bcp in. Once the data is loaded
  217.     in, you can unpartition the table. This enables you to create a clustered
  218.     index on the table, or issue other commands not permitted on a partition
  219.     table.
  220.  
  221. Does Table Partitioning Require User-Defined Segments?
  222.  
  223. No. By design, each table is intrinsically assigned to one segment, called the
  224. default segment. When a table is partitioned, any partitions on that table are
  225. distributed among the devices assigned to the default segment.
  226.  
  227. In the example under "How Do I Create A Partitioned Table That Spans Multiple
  228. Devices?", the table sits on a user-defined segment that spans three devices.
  229.  
  230. Can I Run Any Transact-SQL Command on a Partitioned Table?
  231.  
  232. No. Once you have partitioned a table, you cannot use any of the following
  233. Transact-SQL commands on the table until you unpartition it:
  234.  
  235.  1. drop table
  236.  2. sp_placeobject
  237.  3. truncate table
  238.  4. alter table table_name partition n
  239.  
  240. On releases of ASE prior to 11.5 it was not possible to create a clustered
  241. index on a partitioned table either.
  242.  
  243. How Does Partition Assignment Relate to Transactions?
  244.  
  245. A user is assigned to a partition for the duration of a transaction. Assignment
  246. of partitions resumes with the first insert in a new transaction. The user
  247. holds the lock, and therefore partition, until the transaction ends.
  248.  
  249. For this reason, if you are inserting a great deal of data, you should batch it
  250. into separate jobs, each within its own transaction. See "How Do I Take
  251. Advantage of Table Partitioning with bcp in?", for details.
  252.  
  253. Can Two Tasks Be Assigned to the Same Partition?
  254.  
  255. Yes. ASE randomly assigns partitions. This means there is always a chance that
  256. two users will vie for the same partition when attempting to insert and one
  257. would lock the other out.
  258.  
  259. The more partitions a table has, the lower the probability of users trying to
  260. write to the same partition at the same time.
  261.  
  262. Must I Use Multiple Devices to Take Advantage of Partitions?
  263.  
  264. It depends on which type of performance improvement you want.
  265.  
  266. Table partitioning improves performance in two ways: primarily, by decreasing
  267. page contention for inserts and, secondarily, by decreasing i/o contention.
  268. "What Is Table Partitioning?" explains each in detail.
  269.  
  270. If you want to decrease page contention you do not need multiple devices. If
  271. you want to decrease i/o contention, you must use multiple devices.
  272.  
  273. How Do I Create A Partitioned Table That Spans Multiple Devices?
  274.  
  275. Creating a partitioned table that spans multiple devices is a multi-step
  276. procedure. In this example, we assume the following:
  277.  
  278.   * We want to create a new segment rather than using the default segment.
  279.   * We want to spread the partitioned table across three devices, data_dev1,
  280.     data_dev2, and data_dev3.
  281.  
  282. Here are the steps:
  283.  
  284.  1. Define a segment:
  285.    
  286.        
  287.         sp_addsegment newsegment, my_database,data_dev1
  288.        
  289.  2. Extend the segment across all three devices:
  290.    
  291.        
  292.         sp_extendsegment newsegment, my_database, data_dev2
  293.         sp_extendsegment newsegment, my_database, data_dev3
  294.        
  295.  3. Create the table on the segment:
  296.    
  297.        
  298.         create table my_table
  299.         (names, varchar(80) not null)
  300.         on newsegment
  301.        
  302.  4. Partition the table:
  303.    
  304.        
  305.         alter table my_table partition 30
  306.        
  307. How Do I Take Advantage of Table Partitioning with bcp in?
  308.  
  309. You can take advantage of table partitioning with bcp in by following these
  310. guidelines:
  311.  
  312.  1. Break up the data file into multiple files and simultaneously run each of
  313.     these files as a separate bcp job against one table.
  314.    
  315.     Running simultaneous jobs increases throughput.
  316.    
  317.  2. Choose a number of partitions greater than the number of bcp jobs.
  318.    
  319.     Having more partitions than processes (jobs) decreases the probability of
  320.     page lock contention.
  321.    
  322.  3. Use the batch option of bcp in. For example, after every 100 rows, force a
  323.     commit. Here is the syntax of this command:
  324.    
  325.        
  326.         bcp table_name in filename -b100
  327.        
  328.     Each time a transaction commits, ASE randomly assigns a new partition for
  329.     the next insert. This, in turn, reduces the probability of page lock
  330.     contention.
  331.    
  332. Getting More Information on Table Partitioning
  333.  
  334. For more information on table partitioning, see the chapter on controlling
  335. physical data placement in the ASE Performance and Tuning Guide.
  336.  
  337. Return to top
  338.  
  339. -------------------------------------------------------------------------------
  340.  
  341. 1.2.3: How to manually drop a table
  342.  
  343. -------------------------------------------------------------------------------
  344.  
  345. Occasionally you may find that after issuing a drop table command that the ASE
  346. crashed and consequently the table didn't drop entirely. Sure you can't see it
  347. but that sucker is still floating around somewhere.
  348.  
  349. Here's a list of instructions to follow when trying to drop a corrupt table:
  350.  
  351.  1.     sp_configure allow, 1
  352.         go
  353.         reconfigure with override
  354.         go
  355.         
  356.  2. Write db_id down.
  357.         use db_name
  358.         go
  359.         select db_id()
  360.         go
  361.  3. Write down the id of the bad_table:
  362.         select id
  363.          from sysobjects
  364.         where name = bad_table_name
  365.         go
  366.  4. You will need these index IDs to run dbcc extentzap. Also, remember that if
  367.     the table has a clustered index you will need to run extentzap on index
  368.     "0", even though there is no sysindexes entry for that indid.
  369.         select indid
  370.          from sysindexes
  371.         where id = table_id
  372.         go
  373.  5. This is not required but a good idea:
  374.         begin transaction
  375.         go
  376.  6. Type in this short script, this gets rid of all system catalog information
  377.     for the object, including any object and procedure dependencies that may be
  378.     present.
  379.    
  380.     Some of the entries are unnecessary but better safe than sorry.
  381.    
  382.          declare @obj int
  383.          select @obj = id from sysobjects where name = 
  384.          delete syscolumns where id = @obj
  385.          delete sysindexes where id = @obj
  386.          delete sysobjects where id = @obj
  387.          delete sysprocedures where id in
  388.             (select id from sysdepends where depid = @obj)
  389.          delete sysdepends where depid = @obj
  390.          delete syskeys where id = @obj
  391.          delete syskeys where depid = @obj
  392.          delete sysprotects where id = @obj
  393.          delete sysconstraints where tableid = @obj
  394.          delete sysreferences where tableid = @obj
  395.          delete sysdepends where id = @obj
  396.          go
  397.  7. Just do it!
  398.         commit transaction
  399.         go
  400.  8. Gather information to run dbcc extentzap:
  401.         use master
  402.         go
  403.         sp_dboption db_name, read, true
  404.         go
  405.         use db_name
  406.         go
  407.         checkpoint
  408.         go
  409.  9. Run dbcc extentzap once for each index (including index 0, the data level)
  410.     that you got from above:
  411.         use master
  412.         go
  413.         dbcc traceon (3604)
  414.         go
  415.         dbcc extentzap (db_id, obj_id, indx_id, 0)
  416.         go
  417.         dbcc extentzap (db_id, obj_id, indx_id, 1)
  418.         go
  419.    
  420.        
  421.         Notice that extentzap runs twice for each index. This is because the
  422.         last parameter (the sort bit) might be 0 or 1 for each index, and you
  423.         want to be absolutely sure you clean them all out.
  424.        
  425. 10. Clean up after yourself.
  426.         sp_dboption db_name, read, false
  427.         go
  428.         use db_name
  429.         go
  430.         checkpoint
  431.         go
  432.         sp_configure allow, 0
  433.         go
  434.         reconfigure with override
  435.         go
  436.  
  437. Return to top
  438.  
  439. -------------------------------------------------------------------------------
  440.  
  441. 1.2.4: Why not max out all my columns?
  442.  
  443. -------------------------------------------------------------------------------
  444.  
  445. People occasionally ask the following valid question:
  446.  
  447.     Suppose I have varying lengths of character strings none of which should
  448.     exceed 50 characters.
  449.    
  450.     Is there any advantage of last_name varchar(50) over this last_name varchar
  451.     (255)?
  452.    
  453.     That is, for simplicity, can I just define all my varying strings to be
  454.     varchar(255) without even thinking about how long they may actually be? Is
  455.     there any storage or performance penalty for this.
  456.    
  457. There is no performance penalty by doing this but as another netter pointed
  458. out:
  459.  
  460.     If you want to define indexes on these fields, then you should specify the
  461.     smallest size because the sum of the maximal lengths of the fields in the
  462.     index can't be greater than 256 bytes.
  463.    
  464. and someone else wrote in saying:
  465.  
  466.     Your data structures should match the business requirements. This way the
  467.     data structure themselves becomes a data dictionary for others to model
  468.     their applications (report generation and the like).
  469.    
  470. Return to top
  471.  
  472. -------------------------------------------------------------------------------
  473.  
  474. 1.2.5: What's a good example of a transaction?
  475.  
  476. -------------------------------------------------------------------------------
  477.  
  478.    
  479.     This answer is geared for Online Transaction Processing (OTLP)
  480.     applications.
  481.    
  482. To gain maximum throughput all your transactions should be in stored procedures
  483. - see Q1.5.8. The transactions within each stored procedure should be short and
  484. simple. All validation should be done outside of the transaction and only the
  485. modification to the database should be done within the transaction. Also, don't
  486. forget to name the transaction for sp_whodo - see Q9.2.
  487.  
  488. The following is an example of a good transaction:
  489.  
  490. /* perform validation */
  491. select ...
  492. if ... /* error */
  493.    /* give error message */
  494. else   /* proceed */
  495.    begin
  496.       begin transaction acct_addition
  497.       update ...
  498.       insert ...
  499.       commit transaction acct_addition
  500.    end
  501.  
  502. The following is an example of a bad transaction:
  503.  
  504. begin transaction poor_us
  505. update X ...
  506. select ...
  507. if ... /* error */
  508.    /* give error message */
  509. else   /* proceed */
  510.    begin
  511.       update ...
  512.       insert ...
  513.    end
  514. commit transaction poor_us
  515.  
  516. This is bad because:
  517.  
  518.   * the first update on table X is held throughout the transaction. The idea
  519.     with OLTP is to get in and out fast.
  520.   * If an error message is presented to the end user and we await their
  521.     response, we'll maintain the lock on table X until the user presses return.
  522.     If the user is out in the can we can wait for hours.
  523.  
  524. Return to top
  525.  
  526. -------------------------------------------------------------------------------
  527.  
  528. 1.2.6: What's a natural key?
  529.  
  530. -------------------------------------------------------------------------------
  531.  
  532. Let me think back to my database class... okay, I can't think that far so I'll
  533. paraphrase... essentially, a natural key is a key for a given table that
  534. uniquely identifies the row. It's natural in the sense that it follows the
  535. business or real world need.
  536.  
  537. For example, assume that social security numbers are unique (I believe it is
  538. strived to be unique but it's not always the case), then if you had the
  539. following employee table:
  540.  
  541. employee:
  542.  
  543.         ssn     char(09)
  544.         f_name  char(20)
  545.         l_name  char(20)
  546.         title   char(03)
  547.  
  548. Then a natural key would be ssn. If the combination of _name and l_name were
  549. unique at this company, then another natural key would be f_name, l_name. As a
  550. matter of fact, you can have many natural keys in a given table but in practice
  551. what one does is build a surrogate (or artificial) key.
  552.  
  553. The surrogate key is guaranteed to be unique because (wait, get back, here it
  554. goes again) it's typically a monotonically increasing value. Okay, my
  555. mathematician wife would be proud of me... really all it means is that the key
  556. is increasing linearly: i+1
  557.  
  558. The reason one uses a surrogate key is because your joins will be faster.
  559.  
  560. If we extended our employee table to have a surrogate key:
  561.  
  562. employee:
  563.  
  564.         id      identity
  565.         ssn     char(09)
  566.         f_name  char(20)
  567.         l_name  char(20)
  568.         title   char(03)
  569.  
  570. Then instead of doing the following:
  571.  
  572.  where a.f_name = b.f_name
  573.    and a.l_name = a.l_name 
  574.  
  575. we'd do this:
  576.  
  577.  where a.id = b.id 
  578.  
  579. We can build indexes on these keys and since Sybase's atomic storage unit is
  580. 2K, we can stash more values per 2K page with smaller indexes thus giving us
  581. better performance (imagine the key being 40 bytes versus being say 4 bytes...
  582. how many 40 byte values can you stash in a 2K page versus a 4 byte value? --
  583. and how much wood could a wood chuck chuck, if a wood chuck could chuck wood?)
  584.  
  585. Does it have anything to do with natural joins?
  586.  
  587. Um, not really... from "A Guide to Sybase..", McGovern and Date, p. 112:
  588.  
  589.     The equi-join by definition must produce a result containing two identical
  590.     columns. If one of those two columns is eliminated, what is left is called
  591.     the natural join.
  592.    
  593. Return to top
  594.  
  595. -------------------------------------------------------------------------------
  596.  
  597. 1.2.7: Making a Stored Procedure invisible
  598.  
  599. -------------------------------------------------------------------------------
  600.  
  601. System 11.5 and above
  602.  
  603. It is now possible to encrypt your stored procedure code that is stored in the
  604. syscomments table. This is preferred than the old method of deleting the data
  605. as deleting will impact future upgrades. You can encrypt the text with the
  606. sp_hidetext system procedure.
  607.  
  608. Pre-System 11.5
  609.  
  610. Perhaps you are trying to prevent the buyer of your software from defncopy'ing
  611. all your stored procedures. It is perfectly safe to delete the syscomments
  612. entries of any stored procedures you'd like to protect:
  613.  
  614. sp_configure "allow updates", 1
  615. go
  616. reconfigure with override /* System 10 and below */
  617. go
  618. use affected_database
  619. go
  620. delete syscomments where id = object_id("procedure_name")
  621. go
  622. use master
  623. go
  624. sp_configure "allow updates", 0
  625. go
  626.  
  627. I believe in future releases of Sybase we'll be able to see the SQL that is
  628. being executed. I don't know if that would be simply the stored procedure name
  629. or the SQL itself.
  630.  
  631. Return to top
  632.  
  633. -------------------------------------------------------------------------------
  634.  
  635. 1.2.8: Saving space when inserting rows monotonically
  636.  
  637. -------------------------------------------------------------------------------
  638.  
  639. If the columns that comprise the clustered index are monotonically increasing
  640. (that is, new row key values are greater than those previously inserted) the
  641. following System 11 dbcc tune will not split the page when it's half way full.
  642. Rather it'll let the page fill and then allocate another page:
  643.  
  644. dbcc tune(ascinserts, 1, "my_table")
  645.  
  646. By the way, SyBooks is wrong when it states that the above needs to be reset
  647. when ASE is rebooted. This is a permanent setting.
  648.  
  649. To undo it:
  650.  
  651. dbcc tune(ascinserts, 0, "my_table")
  652.  
  653. Return to top
  654.  
  655. -------------------------------------------------------------------------------
  656.  
  657. 1.2.9: How to compute database fragmentation
  658.  
  659. -------------------------------------------------------------------------------
  660.  
  661. Command
  662.  
  663. dbcc traceon(3604)
  664. go
  665. dbcc tab(production, my_table, 0)
  666. go
  667.  
  668. Interpretation
  669.  
  670. A delta of one means the next page is on the same track, two is a short seek,
  671. three is a long seek. You can play with these constants but they aren't that
  672. important.
  673.  
  674. A table I thought was unfragmented had L1 = 1.2 L2 = 1.8
  675.  
  676. A table I thought was fragmented had L1 = 2.4 L2 = 6.6
  677.  
  678. How to Fix
  679.  
  680. You fix a fragmented table with clustered index by dropping and creating the
  681. index. This measurement isn't the correct one for tables without clustered
  682. indexes. If your table doesn't have a clustered index, create a dummy one and
  683. drop it.
  684.  
  685. Return to top
  686.  
  687. -------------------------------------------------------------------------------
  688.  
  689. 1.2.10: Tasks a DBA should do...
  690.  
  691. -------------------------------------------------------------------------------
  692.  
  693. A good presentation of a DBA's duties has been made available by Jeff Garbus (
  694. jeffg@soaringeagleltd.com) of Soaring Eagle Consulting Ltd (http://
  695. www.soaringeagleltd.com) and numerous books can be found here.  These are
  696. Powerpoint slides converted to web pages and so may be difficult to view with a
  697. text browser!
  698.  
  699. An alternative view is catalogued below.  (OK, so this list is crying out for a
  700. bit of a revamp since checkstorage came along  Ed!)
  701.  
  702.                                  DBA Tasks                                 
  703.   +-------------------------------------------------------------------------+  
  704.   |          Task          |    Reason     |             Period             |  
  705.   |------------------------+---------------+--------------------------------|  
  706.   |                        | I consider    | If your ASE permits, daily     |  
  707.   |                        | these the     | before your database dumps. If |  
  708.   | dbcc checkdb,          | minimal       | this is not possible due to    |  
  709.   | checkcatalog,          | dbcc's to     | the size of your databases,    |  
  710.   | checkalloc             | ensure the    | then try the different options |  
  711.   |                        | integrity of  | so that the end of, say, a     |  
  712.   |                        | your database | week, you've run them all.     |  
  713.   |------------------------+---------------+--------------------------------|  
  714.   | Disaster recovery      | Always be     |                                |  
  715.   | scripts - scripts to   | prepared for  |                                |  
  716.   | rebuild your ASE in    | the worst.    |                                |  
  717.   | case of hardware       | Make sure to  |                                |  
  718.   | failure                | test them.    |                                |  
  719.   |------------------------+---------------+--------------------------------|  
  720.   | scripts to logically   |               |                                |  
  721.   | dump your master       | You can       |                                |  
  722.   | database, that is bcp  | selectively   |                                |  
  723.   | the critical system    | rebuild your  |                                |  
  724.   | tables: sysdatabases,  | database in   | Daily                          |  
  725.   | sysdevices, syslogins, | case of       |                                |  
  726.   | sysservers, sysusers,  | hardware      |                                |  
  727.   | syssegments,           | failure       |                                |  
  728.   | sysremotelogins        |               |                                |  
  729.   |------------------------+---------------+--------------------------------|  
  730.   |                        | A system      |                                |  
  731.   |                        | upgrade is    | After any change as well as    |  
  732.   | %ls -la <disk_devices> | known to      | daily                          |  
  733.   |                        | change the    |                                |  
  734.   |                        | permissions.  |                                |  
  735.   |------------------------+---------------+--------------------------------|  
  736.   | dump the user          | CYA*          | Daily                          |  
  737.   | databases              |               |                                |  
  738.   |------------------------+---------------+--------------------------------|  
  739.   | dump the transaction   | CYA           | Daily                          |  
  740.   | logs                   |               |                                |  
  741.   |------------------------+---------------+--------------------------------|  
  742.   | dump the master        | CYA           | After any change as well as    |  
  743.   | database               |               | daily                          |  
  744.   |------------------------+---------------+--------------------------------|  
  745.   |                        | This is the   |                                |  
  746.   | System 11 and beyond - | configuration |                                |  
  747.   | save the $DSQUERY.cfg  | that you've   | After any change as well as    |  
  748.   | to tape                | dialed in,    | daily                          |  
  749.   |                        | why redo the  |                                |  
  750.   |                        | work?         |                                |  
  751.   |------------------------+---------------+--------------------------------|  
  752.   |                        |               | Depending on how often your    |  
  753.   |                        |               | major tables change. Some      |  
  754.   |                        |               | tables are pretty much static  |  
  755.   |                        |               | (e.g. lookup tables) so they   |  
  756.   | update statistics on   | To ensure the | don't need an update           |  
  757.   | frequently changed     | performance   | statistics, other tables       |  
  758.   | tables and             | of your ASE   | suffer severe trauma (e.g.     |  
  759.   | sp_recompile           |               | massive updates/deletes/       |  
  760.   |                        |               | inserts) so an update stats    |  
  761.   |                        |               | needs to be run either nightly |  
  762.   |                        |               | /weekly/monthly. This should   |  
  763.   |                        |               | be done using cronjobs.        |  
  764.   |------------------------+---------------+--------------------------------|  
  765.   | create a dummy ASE and |               |                                |  
  766.   | do bad things to it:   | See disaster  | When time permits              |  
  767.   | delete devices,        | recovery!     |                                |  
  768.   | destroy permissions... |               |                                |  
  769.   |------------------------+---------------+--------------------------------|  
  770.   | Talk to the            | It's better   |                                |  
  771.   | application            | to work with  | As time permits.               |  
  772.   | developers.            | them than     |                                |  
  773.   |                        | against them. |                                |  
  774.   |------------------------+---------------+--------------------------------|  
  775.   | Learn new tools        | So you can    | As time permits.               |  
  776.   |                        | sleep!        |                                |  
  777.   |------------------------+---------------+--------------------------------|  
  778.   | Read                   | Passes the    | Priority One!                  |  
  779.   | comp.databases.sybase  | time.         |                                |  
  780.   +-------------------------------------------------------------------------+  
  781.  
  782. * Cover Your Ass
  783.  
  784. Return to top
  785.  
  786. -------------------------------------------------------------------------------
  787.  
  788. 1.2.11: How to implement database security
  789.  
  790. -------------------------------------------------------------------------------
  791.  
  792. This is a brief run-down of the features and ideas you can use to implement
  793. database security:
  794.  
  795. Logins, Roles, Users, Aliases and Groups
  796.  
  797.   * sp_addlogin - Creating a login adds a basic authorisation for an account -
  798.     a username and password - to connect to the server. By default, no access
  799.     is granted to any individual databases.
  800.   * sp_adduser - A user is the addition of an account to a specific database.
  801.   * sp_addalias - An alias is a method of allowing an account to use a specific
  802.     database by impersonating an existing database user or owner.
  803.   * sp_addgroup - Groups are collections of users at the database level. Users
  804.     can be added to groups via the sp_adduser command.
  805.    
  806.     A user can belong to only one group - a serious limitation that Sybase
  807.     might be addressing soon according to the ISUG enhancements requests.
  808.     Permissions on objects can be granted or revoked to or from users or
  809.     groups.
  810.    
  811.   * sp_role - A role is a high-level Sybase authorisation to act in a specific
  812.     capacity for administration purposes. Refer to the Sybase documentation for
  813.     details.
  814.  
  815. Recommendations
  816.  
  817. Make sure there is a unique login account for each physical person and/or
  818. process that uses the server. Creating generic logins used by many people or
  819. processes is a bad idea - there is a loss of accountability and it makes it
  820. difficult to track which particular person is causing server problems when
  821. looking at the output of sp_who. Note that the output of sp_who gives a
  822. hostname - properly coded applications will set this value to something
  823. meaningful (ie. the machine name the client application is running from) so you
  824. can see where users are running their programs. Note also that if you look at
  825. master..sysprocesses rather than just sp_who, there is also a program_name.
  826. Again, properly coded applications will set this (eg. to 'isql') so you can see
  827. which application is running. If you're coding your own client applications,
  828. make sure you set hostname and program_name via the appropriate Open Client
  829. calls. One imaginative use I've seen of the program_name setting is to
  830. incorporate the connection time into the name, eg APPNAME-DDHHMM (you have 16
  831. characters to play with), as there's no method of determining this otherwise.
  832.  
  833. Set up groups, and add your users to them. It is much easier to manage an
  834. object permissions system in this way. If all your permissions are set to
  835. groups, then adding a user to the group ensures that users automatically
  836. inherit the correct permissions - administration is *much* simpler.
  837.  
  838. Objects and Permissions
  839.  
  840. Access to database objects is defined by granting and/or revoking various
  841. access rights to and from users or groups. Refer to the Sybase documentation
  842. for details.
  843.  
  844. Recommendations
  845.  
  846. The ideal setup has all database objects being owned by the dbo, meaning no
  847. ordinary users have any default access at all. Specific permissions users
  848. require to access the database are granted explicitly. As mentioned above - set
  849. permissions for objects to a group and add users to that group. Any new user
  850. added to the database via the group then automatically obtains the correct set
  851. of permissions.
  852.  
  853. Preferably, no access is granted at all to data tables, and all read and write
  854. activity is accomplished through stored procedures that users have execute
  855. permission on. The benefit of this from a security point of view is that access
  856. can be rigidly controlled with reference to the data being manipulated, user
  857. clearance levels, time of day, and anything else that can be programmed via
  858. T-SQL. The other benefits of using stored procedures are well known (see Q1.5.8
  859. ). Obviously whether you can implement this depends on the nature of your
  860. application, but the vast majority of in-house-developed applications can rely
  861. solely on stored procedures to carry out all the work necessary. The only
  862. server-side restriction on this method is the current inability of stored
  863. procedures to adequately handle text and image datatypes (see Q1.5.12). To get
  864. around this views can be created that expose only the necessary columns to
  865. direct read or write access.
  866.  
  867. Views
  868.  
  869. Views can be a useful general security feature. Where stored procedures are
  870. inappropriate views can be used to control access to tables to a lesser extent.
  871. They also have a role in defining row-level security - eg. the underlying table
  872. can have a security status column joined to a user authorisation level table in
  873. the view so that users can only see data they are cleared for. Obviously they
  874. can also be used to implement column-level security by screening out sensitive
  875. columns from a table.
  876.  
  877. Triggers
  878.  
  879. Triggers can be used to implement further levels of security - they could be
  880. viewed as a last line of defence in being able to rollback unauthorised write
  881. activity (they cannot be used to implement any read security). However, there
  882. is a strong argument that triggers should be restricted to doing what they were
  883. designed for - implementing referential integrity - rather being loaded up with
  884. application logic.
  885.  
  886. Administrative Roles
  887.  
  888. With Sybase version 10 came the ability to grant certain administrative roles
  889. to user accounts. Accounts can have sa-level privilege, or be restricted to
  890. security or operator roles - see sp_role.
  891.  
  892. Recommendations
  893.  
  894. The use of any generic account is not a good idea. If more than one person
  895. requires access as sa to a server, then it is more accountable and traceable if
  896. they each have an individual account with sa_role granted.
  897.  
  898. Return to top
  899.  
  900. -------------------------------------------------------------------------------
  901.  
  902. 1.2.12: How to Shrink a Database
  903.  
  904. -------------------------------------------------------------------------------
  905.  
  906.    
  907.     Warning: This document has not been reviewed. Treat it as alpha-test
  908.     quality information and report any problems and suggestions to 
  909.     bret@sybase.com
  910.    
  911. It has historically been difficult to shrink any database except tempdb
  912. (because it is created fresh every boot time). The two methods commonly used
  913. have been:
  914.  
  915.  1. Ensure that you have scripts for all your objects (some tools like SA
  916.     Companion, DB Artisan or dbschema.pl from Sybperl can create scripts from
  917.     an existing database), then bcp out your data, drop the database, recreate
  918.     it smaller, run your scripts, and bcp in your data.
  919.  2. Use a third-party tool such as DataTool's SQL Backtrack, which in essence
  920.     automates the first process.
  921.  
  922. This technote outlines a third possibility that can work in most cases.
  923.  
  924. An Unsupported Method to Shrink a Database
  925.  
  926. This process is fairly trivial in some cases, such as removing a recently added
  927. fragment or trimming a database that has a log fragment as its final
  928. allocation, but can also be much more complicated or time consuming than the
  929. script and bcp method.
  930.  
  931. General Outline
  932.  
  933. The general outline of how to do it is:
  934.  
  935.  1. Make a backup of the current database
  936.  2. Migrate data from sysusages fragments with high lstart values to fragments
  937.     with low lstart values.
  938.  3. Edit sysusages to remove high lstart fragments that no longer have data
  939.     allocations.
  940.  4. Reboot ASE.
  941.  
  942. Details
  943.  
  944.  1. Dump your database. If anything goes wrong, you will need to recover from
  945.     this backup!
  946.  2. Decide how many megabytes of space you wish to remove from your database.
  947.  3. Examine sysusages for the database. You will be shrinking the database by
  948.     removing the fragments with the highest lstart values. If the current
  949.     fragments are not of appropriate sizes, you may need to drop the database,
  950.     recreate it so there are more fragments, and reload the dump.
  951.    
  952.        
  953.         A trivial case: An example of a time when you can easily shrink a
  954.         database is if you have just altered it and are sure there has been no
  955.         activity on the new fragment. In this case, you can directly delete the
  956.         last row in sysusages for the db (this row was just added by alter db)
  957.         and reboot the server and it should come up cleanly.
  958.        
  959.  4. Change the segmaps of the fragments you plan to remove to 0. This will
  960.     prevent future data allocations to these fragments.
  961.    
  962.        
  963.         Note: If any of the fragments you are using have user defined segments
  964.         on them, drop those segments before doing this.
  965.        
  966.         sp_configure "allow updates", 1
  967.         go
  968.         reconfigure with override  -- not necessary in System 11
  969.         go
  970.         update sysusages
  971.            set segmap = 0
  972.          where dbid   = <dbid>
  973.            and lstart = <lstart>
  974.         go
  975.         dbcc dbrepair(<dbname>, remap)
  976.         go 
  977.    
  978.     Ensure that there is at least one data (segmap 3) and one log (segmap 4)
  979.     fragment, or one mixed (segmap 7) fragment.
  980.    
  981.     If the server has been in use for some time, you can shrink it by deleting
  982.     rows from sysusages for the db, last rows first, after making sure that no
  983.     objects have any allocations on the usages.
  984.    
  985.  5. Determine which objects are on the fragments you plan to remove.
  986.         traceon(3604)
  987.         go
  988.         dbcc usedextents( dbid,0,0,1)
  989.         go 
  990.    
  991.     Find the extent with the same value as the lstart of the first fragment you
  992.     plan to drop. You need to migrate every object appearing from this point on
  993.     in the output.
  994.    
  995.  6. Migrate these objects onto earlier fragments in the database.
  996.    
  997.     Objids other than 0 or 99 are objects that you must migrate or drop. You
  998.     can migrate a user table by building a new clustered index on the table
  999.     (since the segmap was changed, the new allocations will not go on this
  1000.     fragment).
  1001.    
  1002.     You can migrate some system tables (but not all) using the sp_fixindex
  1003.     command to rebuild its clustered index. However, there are a few system
  1004.     tables that cannot have their clustered indexes rebuilt, and if they have
  1005.     any allocations on the usage, you are out of luck.
  1006.    
  1007.     If the objid is 8, then it is the log. You can migrate the log by ensuring
  1008.     that another usage has a log segment (segmap 4 or 7). Do enough activity on
  1009.     the database to fill an extents worth of log pages, then checkpoint and
  1010.     dump tran.
  1011.    
  1012.     Once you have moved all the objects, delete the row from sysusages and
  1013.     reboot the server.
  1014.    
  1015.     Run dbcc checkdb and dbcc checkalloc on the database to be sure you are ok,
  1016.     then dump the database again.
  1017.    
  1018. Return to top
  1019.  
  1020. -------------------------------------------------------------------------------
  1021.  
  1022. 1.2.13: How do I audit the SQL sent to the server?
  1023.  
  1024. -------------------------------------------------------------------------------
  1025.  
  1026. This does not seem to be well documented, so here is a quick means of auditing
  1027. the SQL text that is sent to the server.  Note that this simply audits the SQL 
  1028. sent to the server.  So, if your user process executes a big stored procedure,
  1029. all you will see here is a call to the stored procedure.  None of the SQL that
  1030. is executed as part of the stored procedure will be listed.
  1031.  
  1032. Firstly, you need to have installed Sybase security (which involves installing
  1033. the sybsecurity database and loading it using the script $SYBASE/scripts/
  1034. installsecurity).   Read the Sybase Security Administration Manual, you may
  1035. want to enable a threshold procedure to toggle between a couple of audit
  1036. tables.  Be warned, that the default configuration option "suspend auditing
  1037. when device full" is set to 1.   This means that the server will suspend all
  1038. normal SQL operations if the audit database becomes full and the sso logs in
  1039. and gets rid of some data.  You might want to consider changing this to 0
  1040. unless yours is a particularly sensitive installation.
  1041.  
  1042. Once that is done, you need to enable auditing.  If you haven't already, you
  1043. will need to restart ASE in order to start the audit subsystem.  Then comes the
  1044. bit that does not seem well documented, you need to select an appropriate audit
  1045. option, and the one for the SQL text is "cmdtext".  From the sybsecurity
  1046. database, issue
  1047.  
  1048. sp_audit "cmdtext",<username>,"all","on"
  1049.  
  1050. for each user on the system that wish to collect the SQL for.  sp_audit seems
  1051. to imply that you can replace "<username>" with all, but I get the error
  1052. message "'all' is not a valid user name".  Finally, enable auditing for the
  1053. system as a whole using
  1054.  
  1055. sp_configure "auditing",1
  1056. go
  1057.  
  1058. If someone knows where in the manuals this is well documented, I will add a
  1059. link/reference.
  1060.  
  1061. Note: The stored procedure sp_audit had a different name under previous
  1062. releases.  I think that it was called sp_auditoption.  Also, to get a full list
  1063. of the options and their names, go into sybsecurity and simply run sp_audit
  1064. with no arguments.
  1065.  
  1066. Return to top
  1067.  
  1068. -------------------------------------------------------------------------------
  1069.  
  1070. 1.2.14: sp_helpdb/sp_helpsegment is returning negative numbers
  1071.  
  1072. -------------------------------------------------------------------------------
  1073.  
  1074. A number of releases of ASE return negative numbers for sp_helpdb. One solution
  1075. given by Sybase is to restart the server. Hmm... not always possible. An
  1076. alternative is to use the dbcc command 'usedextents'. Issue the following:
  1077.  
  1078. dbcc traceon(3604)
  1079. dbcc usedextents(, 0, 1, 1)
  1080.  
  1081. and the problem should disappear. This is actually a solved case, Sybase solved
  1082. case no: 10454336, go to http://info.sybase.com/resolution/detail.stm?id_number
  1083. =10454336 to see more information.
  1084.  
  1085. Return to top
  1086.  
  1087. -------------------------------------------------------------------------------
  1088.  
  1089. Advanced Administration Basic Administration ASE FAQ
  1090.  
  1091.