SAP BO. Mantenimiento preventivo de servidor y servicios de SAP Parte II
Posted On sábado, 6 de febrero de 2010 at en 10:04 by Edgar Avena Vázquez Como lo había comentado continuamos con esta segunda parte de mantenimiento preventivo de nuestro servidor. Ahora nos enfocaremos a lo que respecta el mantenimiento dentro de SQL Server. Los puntos a tratar serán los siguientes:
- Compactar base de datos "Shrink" SQL.
- Log de SQL.
- Log de SAP.
- Indexación de base de datos.
Compactar base de datos "Shrink" SQL
Como sabemos SAP libera notas que tratan temas de problemáticas, bugs, recomendaciones entre otras. En este caso hace tiempo SAP libero una nota que respecta a este tema. La nota es la numero 1224089 la cual textualmente dice lo siguiente:
Summary
Symptom
How to shrink the logfile of any database, including the sbo-common, on MSSQL Server 2005 or MSSQL Server 2008.
Other terms
shrink database, shrink, shrink DB, SAP Business One, MSSQL 2005 Server, MSSQL 2005, SQL 2005, SQL 2005 Server, Microsoft SQL Server 2005, MSSQL 2008 Server, MSSQL 2008, SQL 2008, SQL 2008 Server, Microsoft SQL Server 2008, truncate, truncate database, size, reduce, backup, logfile, log
Solution
1. Open the SQL Server Management Studio
2. Connect to the server (use user 'SA' and Password where the file to be shrunk is located.
3. In the Object Explorer window open the folder 'Databases'.
4. Right-click on the database, whose logfile you want to shrink.
5. Select 'Tasks', then 'Shrink' and then 'Files'.
6. Beside the field 'File type' click on the drop-down arrow and select 'Databasename_log'.
7. Select the 'Shrink action' desired. SAP Business One Product Support recommends to choose 'Release unused space' (Please refer to Microsoft documentation for details on 'Shrink action'.)
8. If desired, tick the box for 'Shrink the file later' and select a suitable date and time. (Please refer to Microsoft documentation for details on 'Shrink the file later'.)
9. Click on 'OK'and wait for the message from SQL Server Management Studio: 'Shrink log file completed successfully'.
10. Click on 'OK' in the message box.
Como ven la nota da los pasos a seguir para realizar el Shrink de una base datos. Esta nota aplica para SQL 2005 y 2008. Para aquellas personas que cuenta con SQL 2000 y quieran realizar esta acción les recomiendo que sigan la nota numero 1002099. Otra recomendación que les puedo hacer aquí, es que antes de realizar estos pasos de compactar su base de datos, primero cambien su modelo de recuperación (recovery model) a Simple y una vez hecho el proceso lo regresen a Completo, esto lo hacen:
- Seleccionen la base de datos.
- Clic derecho > Propiedades.
- Opciones.
- Modelo de recuperación = Simple, Completa, Registro Másivo
No ocupan reiniciar los servicios de SQL para que estos cambios apliquen.
Log de SQL.
Como se sabe es mucho mejor (aunque implique mas esfuerzo para el motor de SQL) manejar el modelo de recuperación Completa(Full) ya que estos nos brinda la capacidad de hacer respaldos del log de SQL. Y esto a su vez nos ayuda en gran parte a la alta disponibilidad de nuestro sistema mediante la combinación adecuada de respaldos de log, diferenciales y completos. Una de las consecuencias de tener nuestro modelo de recuperación completa, es que el tamaño del log de transacciones puede dispararse por diversas operaciones que se dan dia a día con el uso de SAP Business One, pero también ahí otras que suelen ocasionar un aumento indiscriminado de nuestro log como son las cargas masivas de información mediante DTW (Data Transfer Workbench) entre otras.
Los pasos que vamos a ver a continuación se deben de usar solo en caso de ser necesario y todos los usuarios deben de estar fuera del sistema antes de ejecutar este proceso. También les recomiendo realizar este proceso por la noche o fuera de horarios de trabajo y con mucho tiempo de holgura ya que este proceso puede tardar horas. Estos pasos son sentencias de SQL y los pasos son:
1.-Borrar el Log de transacciones.
BACKUP LOG WITH TRUNCATE_ONLY
2.-Reducir el tamaño del log de transacciones.
DBCC SHRINKDATABASE ( , TRUNCATEONLY)
Con estas dos instrucciones de SQL damos un mantenimiento adecuado a a nuestro log de transacciones. Les recomiendo que si sus archivos .ldf estan en el mismo disco duro que los .mdf, den este mantenimiento si los archivos .ldf superan los 2 Gb de espacio.
Log de SAP
Con lo que respecta al log de SAP solo es necesario hacer un pequeña configuración para que este no llene el disco duro de las computadoras que tienen el cliente de SAP. Este log se escribe cuando pasa algún error de SAP. Ejemplo claro de esto puede ser cuando perdemos conectividad con el servidor y al momento de querer establecer contacto de nuevo provoca un fallo (que no es de alarmarse).
La ruta por default donde se guardan dichos error es c:\Program Files\SAP\SAP Business One\Log\ donde se generar archivos *.DMP y archivos *.TXT. Los cuales traen información como esta:
--------Logger Started-------- at : 04/01/2010 10:10:55:468750
04/01/2010 10:10:55:421875 General NoteLogAlways ***** Help LOIO: Loading from Resource ***** C:\Program Files\SAP\SAP Business One\SAP Business One.exe PID=1188 TID=3512 d:\depot\BUSMB_B1\SBO\2006A_REL\Application\__Engines\HELP\__HELP.c 127
04/01/2010 10:12:12:203125 SystemMessage CriticalError Unhandled exception occur. See stack in 㾒δ㾐δ logfile C:\Program Files\SAP\SAP Business One\SAP Business One.exe PID=1188 TID=3512 d:\depot\BUSMB_B1\SBO\2006A_REL\InfraStructure\Common\UnHandledExceptionHandler.cpp 227
En algunas ocasiones para brindar soporte directo de SAP, se pueden llegar a solicitar los *.DMP que genera el sistema para su estudio. Estos generación de archivos es la que se configura en Parametrizaciones Generales en la pestaña Actividades
Indexación de base de datos
Como lo vimos en el punto Shrink, existe una nota de SAP con el numero 1241422 que nos indica y nos da una consulta que nos permite llevar la gestión de la indexación. Esta nota dice lo siguiente:
Summary
Symptom
During the lifetime of a SBO database and due to insert\update\delete of data, the information in indexes is fragmented. Fragmentation exists when indexes have pages in which the logical ordering, based on the key value, does not match the physical ordering inside the data file. Heavily fragmented indexes can cause slow performance.
Other terms
Index, performance, re-index, reindex, slow, poor, DB
Reason and Prerequisites
FAQ
Solution
It is recommended to run a rebuild the following procedure once\twice a month:
/*
Reindex procedure.
Will execute dbcc dbreindex on each table in db
*/
DECLARE @tableName as sysname
DECLARE @strExec as varchar(1000)
-- Cursor declartion
DECLARE tableNameCursor CURSOR READ_ONLY FAST_FORWARD FOR
-- Take all user table
SELECT [name] FROM sysobjects WHERE xtype = 'U'
OPEN tableNameCursor
FETCH NEXT FROM tableNameCursor INTO @tableName
WHILE @@FETCH_STATUS = 0
BEGIN
-- Create the statment
SET @strExec = 'dbcc dbreindex (''' + @tableName + ''','''',0 )'
-- Execute the procedure
exec (@strExec)
FETCH NEXT FROM tableNameCursor INTO @tableName
END
CLOSE tableNameCursor
DEALLOCATE tableNameCursor
Before running:
Be sure you have enough free space (up to twice the size of used space).
If you need to shrink the db (it is not recommended - it will create fragmentation) do it before re-index. You can use the following script:
/*------------------------------------------------------------------------
Shrink db
--------------------------------------------------------------------------*/
DECLARE @dbName as sysname
DECLARE @strExecShrink as varchar(500)
-- Get db name
SET @dbName = (select db_name())
SET @strExecShrink = 'DBCC SHRINKDATABASE(''' + @dbName + ''',10)'
EXEC(@strExecShrink)
The re-index will take a while (It may run more than two hours on large database); during his running the db will not be available for work.
Related resources:
SQL Server Books Online.
http://msdn.microsoft.com/en-us/library/ms189858(SQL.90).aspx.
Esta consulta es compatible con SQL 2005, y se puede obtener mas información en MSDN de Microsoft, al igual que con el log es importante que nadie este conectado y que se tenga el tiempo suficiente para que este proceso termine por que puede tardar horas. Antes de terminar con nuestro post le dejo un listado de recomendaciones.
Servicio Backup de SAP
- Respaldos diarios, 3 a.m. (preferentemente una unidad de almacenamiento diferente al servidor).
- Si es posible una unidad externa para uso exclusivo para respaldos.
- Depurar respaldos con antigüedad mayor a un mes.
- Archivar respaldos de cierre de mes en unidad externa (12 respaldos por año).
Servicios SQL
- Programar procesos de shrink e indexación por periodos de 3 meses
- Insisto hacerlo con tiempo de sobra, fuera de horarios de oficina y sin que ningún usuario este conectado al sistema.
