Along these recovery lines... If you ever have filesystem corruption and have to delete one of the data or index files, you will end up having to add back an empty file. Then you will have to recover the tablespace, so the less tables in the tablespace, the less you will have to recover. Filesystem corruption is relatively rare, but it does happen.
John Lantz wrote: > Since you can recover at a tablespace level as opposed to a table level, we > use a single table per tablespace so that we can have table level recovery. > We've only had to recover a table once, and it sure was nice being able to > have the capablity. > > We do keep our "static" tables in a single tablespace though. > > Thanks. > > [EMAIL PROTECTED]@lugwash.org on 04/25/2002 05:26:56 PM > > Please respond to [EMAIL PROTECTED] > > Sent by: [EMAIL PROTECTED] > > To: [EMAIL PROTECTED] > cc: > > Subject: [DB2EUG] Many tables per tablespace versus one table per > tablespace > > Hello List, > > We currently have several UDB databases on both NT and AIX, but all of the > databases are used > in conjunction with a third party application that we purchased from some > other company. The databases > were installed with the software and therefore a majority of the tables > reside in the default userspace1 > tablespace. When we have had a reason to restore from a backup we have > just restored the entire > database rather than individual tablespaces. Now we are developing an > in-house application on > AIX and I am wondering what types of strategies do other UDB DBAs implement > when new applications > are being developed in-house. On the S/390, we put one table per > tablespace. Should the same type > of strategy be used in the distributed environment. When making this > decision, what do I need to consider > from a recovery point of view? Am I missing anything else that I need to > consider as well? > > As always, any input on this is appreciated. > > Thanks, > Tim Traxson > [EMAIL PROTECTED] > 479-820-8811 > > - > ::: When replying to the list, please use 'Reply-All' and make sure > ::: a copy goes to the list ([EMAIL PROTECTED]). > *** To unsubscribe, send 'unsubscribe' to [EMAIL PROTECTED] > *** For more information, check http://www.db2eug.uni.cc > > ******************* PLEASE NOTE ******************* > This E-Mail/telefax message and any documents accompanying this > transmission may contain privileged and/or confidential information and is > intended solely for the addressee(s) named above. If you are not the > intended addressee/recipient, you are hereby notified that any use of, > disclosure, copying, distribution, or reliance on the contents of this > E-Mail/telefax information is strictly prohibited and may result in legal > action against you. Please reply to the sender advising of the error in > transmission and immediately delete/destroy the message and any > accompanying documents. Thank you. > > - > ::: When replying to the list, please use 'Reply-All' and make sure > ::: a copy goes to the list ([EMAIL PROTECTED]). > *** To unsubscribe, send 'unsubscribe' to [EMAIL PROTECTED] > *** For more information, check http://www.db2eug.uni.cc - ::: When replying to the list, please use 'Reply-All' and make sure ::: a copy goes to the list ([EMAIL PROTECTED]). *** To unsubscribe, send 'unsubscribe' to [EMAIL PROTECTED] *** For more information, check http://www.db2eug.uni.cc
