|
Consulta muy sencilla, extrañamente lenta
Saludos al foro.
Quería consultaros un problemilla muy tonto que tengo pero que no acierto a ver cual podría ser el origen. Me explico: Tengo una base de datos enorme donde se recogen datos de unos sensores. Tengo una tabla de sensores con la siguiente estructura: Nombre del Campo Tipo Not null Explicación ------------------------------------------------------------------------------------------------- IDSENSOR * INTEGER TRUE (Clave primaria,autoincremento) IDPROYECTO INTEGER TRUE (Apunta a la tabla de proyectos) IDTIPOSENSOR * INTEGER TRUE (Apunta a la tabla tiposensor) REF CHAR(6) TRUE (Referencia corta) * UBICACION VARCHAR(150) FALSE (Lugar donde se encuentra, no obligatorio) NOMBRE * VARCHAR(50) FALSE (Nombre largo, no obligatorio) ACTIVO SMALLINT TRUE (0 Inactivo, 1 Activo) BUENAFUNCION SMALLINT TRUE (0 No va bien, 1 Va bien) * = indica que hay índice ascendente. Un ejemplo de los datos que contiene: IDSENSOR IDPROYECTO IDTIPOSENSOR REF UBICACION NOMBRE ACTIVO BUENAFUNCION ------------------------------------------------------------------------------------------------------------------------------------------------ 184 1 1 TEM001 Azotea SENSOR TEMPERATURA 001 1 1 185 1 1 TEM002 Azotea SENSOR TEMPERATURA 002 1 1 186 1 1 TEM003 Azotea SENSOR TEMPERATURA 003 1 1 187 1 1 TEM004 Azotea SENSOR TEMPERATURA 004 1 1 188 1 1 TEM005 Azotea SENSOR TEMPERATURA 005 1 1 189 1 1 TEM006 Azotea SENSOR TEMPERATURA 006 1 0 190 1 1 TEM007 Azotea SENSOR TEMPERATURA 007 1 1 Y así hasta 70 registros (setenta, menos de cien, no setenta mil, es decir, muy pocos registros). La tabla Tiposensor tiene la siguiente estructura: Nombre del Campo Tipo Not null ------------------------------------------------------------------------------------------------- IDTIPOSENSOR * INTEGER TRUE (clave primaria, autoincremento) TIPO_LARGO * VARCHAR(20) TRUE (Nombre largo, obligatorio) TIPO* CHAR(3) TRUE (Nombre corto, obligatorio) * ACTIVO SMALLINT TRUE (1=activo, 0=no activo) (No lo uso) IDTABLADATOS * INTEGER TRUE (Apunta a otra tabla) IDTIPODATO * INTEGER TRUE (Apunta a otra tabla) * = indica que hay índice ascendente. Esta tabla sólo tiene 6 registros: IDTIPOSENSOR TIPO_LARGO TIPO ACTIVO IDTABLADATOS IDTIPODATO ---------------------------------------------------------------------------------------------------------------- 0 INDEFINIDO NOT 1 0 0 1 TEMPERATURA EN ºC TEM 1 1 2 2 HUMEDAD HUM 1 1 1 3 LLUVIA LLU 1 2 4 4 ENCHARCAMIENTO ENC 1 2 5 5 TEMPERATURA EN ºK TEK 1 1 3 Y en fín, el problema: Tengo un MDODataSet con el siguiente SelectSQL: 'select * from sensores order by ref' Esto me devuelve 70 registros y tarda ¡30 segundos! Pero esta tardanza ocurre sólo la primera vez que se abre el MDODATASET; las siguientes veces tarda menos de 1 segundo que es lo lógico y esperable. El MDODATASET tiene los campos de datos y además un campo lookup que apunta a la tabla TipoSensor para traer el tipo de sensor, y dos campos calculados que son del tipo booleano para convertir los campos ACTIVO y BUENAFUNCION al tipo true/false. He probado de todo: quitar la apertura del mdodataset del evento formshow, quitar los campos calculados y lookup .... y ya no se me ocurre nada más. Estoy desesperadico. ¿Alguna idea? ¿A alguien le ha pasado algo parecido? ¿Es un bug de los MDO? Uso D7, Firebird 2.0 y componentes MDO. Gracias de antemano. PD: Perdón por el rollo. |
¡Hola!
Prueba si la conexión por sí misma tiene esa demora, abriéndola explícitamente antes de lanzar ninguna consulta. Algo como "ConexionMDO.Open;" (desconozco los componentes MDO). Podría tratarse de un retardo provocado por un factor externo a la base de datos, como un contrafuegos o algo por el estilo (aunque me parece mucho tiempo). También puedes verificar si te da tiempos similares abriendo la base de datos y ejecutando la consulta desde IB Expert o el programa administrativo que uses. Por otro lado, puede que tu programa esté realizando (quizá desde algún evento) alguna operación que demora mucho tiempo cuando se abre la base de datos o ejecuta la consulta. Sería cuestión de revisar el código. La depuración paso a paso (F7/F8) puede ayudarte a indagar en qué punto del código se está demorando la operación. No dejes de retroalimentar el hilo pa' saber que jue. Saludos. Al. :) |
|
Reevisa los drivers
Una vez tuve un problema similar trabajando con oracle y se debio a la configuracion del rollback del mismo.
No se que base de datos estes usando pero para que se te ponga tan lenta es que la conexion con esa base de datos esta usando los drives incorrectos por ejm si usas oracle en lugar de usar el driver de orcl estes usando el de odbc o mssql. Otra posible causa es que tue equipo tenga virus, especificamente gusanos Avisame como te fue |
La consulta debería ser instantánea, comprueba, tal y como te ha comentado Al González, depurar el programa paso a paso y asegurarte de que lo lento no es el abrir/conectar a la base de datos.
|
Saludos.
Prueba a ver si te falta algún indice por el campo que vas a ordenar, si usas IbExpert te marcara si esta consulta utiliza un PLAN NATURAL y podrás poner el indice adecuado. Hasta luego. |
Gracias a todos por vuestras intervenciones.
Hasta ahora todos los intentos son infructuosos. Como me indican Al y Casimiro he mirado el programa paso a paso y el parón se produce al hacer open. Lo de los drivers que apunta luchifer no es porque uso firebird 2.0 y no tengo problema en otros programas. Lo de un posible virus, hombre nunca se puede descartar eso, pero me llevo el programa a otro ordenador y produce el mismo resultado. Que haya el mismo gusano en dos ordenadores distintos es poco probable, a no ser que sea mi programa el que lo lleva. Acabo de pasarle el antivirus y nada. Ahora mismo, lo único que se me ocurre es que sea un bug de los componentes MDO. Curiosamente, desde IBManager la consulta es rápida, y desde otro programa mío que no usa MDO sino FIBPLUS también es rápida. Y también curioso que todo este problema me lo da única y exclusivamente con una tabla, la de sensores, que sólo tiene 70 datos aunque estoy haciendo pruebas continuamente y estoy añadiendo y borrando datos. Y la lentitud se produce también si accedo a sensores desde un MDOQUERY. Tengo otra tabla que recoge los datos de los sensores, con 5 millones de datos y consultas mucho más complicadas tardan 40 segundos. Ahorita mismo estoy totalmente perdido. Sólo se me ocurre sustituir el MDO por FIBPLUS. ¡Ah! Lo que me apuntaba juanelo: he leído la información que me sugerías pero no he sacado nada en claro. Al parecer a aquella persona le pasaba lo mismo que a mí pero no logró solucionarlo o no lo indica. Otro dato: la base de datos FB tiene extensión FDB y no GDB que, al parecer, da problemas. Si consigo alguna solución, la comentaré. Un saludo. |
Añadido:
Lo que comenta Rolphi de los índices ya lo he revisado y todos los campos por los que ordeno tienen índice. Un saludo. |
¡Hola!
Te agradezco que hayas retroalimentado el hilo. Cita:
Esperamos tus comentarios. Al. |
Y de paso puedes extraer un metadata de la base de datos y de los datos de esa tabla para que probemos con MDO también. Si puedes, claro.
|
He sustituido los componentes MDO por FIBPLUS y hasta ahora, las pruebas que he hecho han sido satisfactorias, es decir, el problema parece haberse arreglado.
Sin embargo y por intentar arrojar un poco de luz a este asunto y poder ayudar a alguien que le pase lo mismo, he hecho lo que me apunta Al y he intentado depurar el programa paso a paso con F7, incluso dentro de los distintos componentes. Lamento decir que no lo he conseguido porque me meto en un berenjenal que no parece tener fin: entro en forms, system, mdoquery y un larguísimo etcétera de unidades y procesos. Al cabo de 15 minutos de estar dándole a F7 me he mareado, he pulsado F9 y ¡aparece el parón pero no sé dónde! Sin duda es mi culpa pues mis conocimientos son muy escasos y estoy dando los segundos pasos con firebird (no los primeros, pero casi). Cita:
RecId Field Name Description Field Type Domain Not Null Default Source Computed Source 1 IDSENSOR INTEGER RDB$64 True 2 IDPROYECTO INTEGER RDB$65 True 3 IDTIPOSENSOR INTEGER RDB$66 True 4 REF CHAR(6) RDB$67 True 5 UBICACION VARCHAR(150) RDB$68 False 6 NOMBRE VARCHAR(50) RDB$69 False 7 ACTIVO 0 Inactivo, 1 Activo SMALLINT RDB$70 True 1 8 BUENAFUNCION 0 No va bien. 1 va bien. SMALLINT RDB$13 True 1 Si lo que quieres es eso, puedo extraer esos datos de la tabla sensores, tipo de sensor y alguna otra a la que apunta sensores y enviártelos mejor formateados. Gracias a todos por vuestra ayuda y un saludo. |
Añadido:
He copiado los mdodataset que me dan el problema y los he copiado a otra aplicación nueva. Estoy intentado discernir si el problema ocurre sólo con mi aplicación o es de los mdo. El caso es que lo he probado y funciona bien, pero claro, acababa de probarlo en mi aplicación con lo cual ya no es la primera vez que se ejecuta. Estoy dando palos de ciego... a ver si entre todos hallamos una solución. Gracias otra vez. |
¡Hola!
Cita:
Hay que usar F8 también, con puro F7 demorarías varias semanas en encontrar el problema. Creo que este otro mensaje puede orientarte al respecto: http://www.clubdelphi.com/foros/show...22&postcount=4 Un saludo. Al. :) |
Hola a todos. Por aquí de nuevo, con algo de retraso pero es que voy muy liado últimamente.
Casi he conseguido localizar dónde se produce el parón. Con F8 como me indicaba Al va mucho mejor que F7 que era para salir loco ;). Al grano: he dicho "casi" porque tengo el procedimiento donde se produce el parón, pero no la línea. El procedimiento es el siguiente: TMDOSQL.Prepare Ahora no puedo pasarle otra vez el F8 porque el problema, recordad, era sólo para la primera vez. (Manda huevos). En fín, aquí sigo, investigando... Un saludo. |
Cita:
Ya acorralaste a la anomalía, casi la has cazado. :cool: Seguimos leyéndote. Al. |
Cita:
|
Hola, de nuevo por aquí con algo más de información.
Cita:
Concretamente es la unit MDOSQL.PAS procedure TMDOSQL.PREPARE (copio y pego directamente del editor para tratar de ubicar un poco mejor el problema): Código Delphi [-]procedure TMDOSQL.Prepare; var stmt_len: Integer; res_buffer: array[0..7] of Char; type_item: Char; begin if FCursor = '' then FCursor := Name + RandomString(8); CheckClosed; FBase.CheckDatabase; FBase.CheckTransaction; if FPrepared then exit; if (FSQL.Text = '') then MDOError(mdoeEmptyQuery, [nil]); if not ParamCheck then FProcessedSQL.Text := FSQL.Text else PreprocessSQL; if (FProcessedSQL.Text = '') then MDOError(mdoeEmptyQuery, [nil]); try Call(isc_dsql_alloc_statement2(StatusVector, DBHandle, @FHandle), True); {PROBLEMA --> } Call(isc_dsql_prepare(StatusVector, TRHandle, @FHandle, 0, PChar(FProcessedSQL.Text), Database.SQLDialect, nil), True); { After preparing the statement, query the stmt type and possibly create a FSQLRecord "holder" } { Get the type of the statement } type_item := Char(isc_info_sql_stmt_type); Call(isc_dsql_sql_info(StatusVector, @FHandle, 1, @type_item, SizeOf(res_buffer), res_buffer), True); if (res_buffer[0] <> Char(isc_info_sql_stmt_type)) then MDOError(mdoeUnknownError, [nil]); stmt_len := isc_vax_integer(@res_buffer[1], 2); FSQLType := TMDOSQLTypes(isc_vax_integer(@res_buffer[3], stmt_len)); { Done getting the type } case FSQLType of SQLGetSegment, SQLPutSegment, SQLStartTransaction: begin FreeHandle; MDOError(mdoeNotPermitted, [nil]); end; SQLCommit, SQLRollback, SQLDDL, SQLSetGenerator, SQLInsert, SQLUpdate, SQLDelete, SQLSelect, SQLSelectForUpdate, SQLExecProcedure: begin { We already know how many inputs there are, so... } if (FSQLParams.FXSQLDA <> nil) and (Call(isc_dsql_describe_bind(StatusVector, @FHandle, Database.SQLDialect, FSQLParams.FXSQLDA), False) > 0) then MDODatabaseError; FSQLParams.Initialize; if FSQLType in [SQLSelect, SQLSelectForUpdate, SQLExecProcedure] then begin { Allocate an initial output descriptor (with one column) } FSQLRecord.Count := 1; { Using isc_dsql_describe, get the right size for the columns... } Call(isc_dsql_describe(StatusVector, @FHandle, Database.SQLDialect, FSQLRecord.FXSQLDA), True); if FSQLRecord.FXSQLDA^.sqld > FSQLRecord.FXSQLDA^.sqln then begin FSQLRecord.Count := FSQLRecord.FXSQLDA^.sqld; Call(isc_dsql_describe(StatusVector, @FHandle, Database.SQLDialect, FSQLRecord.FXSQLDA), True); end else if FSQLRecord.FXSQLDA^.sqld = 0 then FSQLRecord.Count := 0; FSQLRecord.Initialize; end; end; end; FPrepared := True; if not (csDesigning in ComponentState) then MonitorHook.SQLPrepare(Self); except on E: Exception do begin if (FHandle <> nil) then FreeHandle; raise; end; end; end; Y ya no sé qué mas hacer. Yo no soy capaz de resolver el problema ni aún sabiendo que está en esa línea. Lo que dije en un post anterior que con FIBPLUS se solucionaba, no es del todo cierto. Se soluciona al acceder a la tabla sensores en un primer momento, pero extrañamente, aparece el parón con retardo. Entiendo que debe ser algo relacionado con los registros que dependen de la tabla sensores. Hay que recordar que de esta tabla dependen dos tablas más que son las que almacenan los datos, y ahora mismo tienen más de 6 millones de datos entre las dos. Esto lo he deducido de una de mis múltiples pruebas a ciegas: he quitado los datos de las tablas de datos y el parón en la tabla de sensores desaparece (al menos así parece). ¿Es posible que un número muy grandes de datos de una tabla dependiente ocasione retardo en la tabla madre? Todo esto me da un dolor de cabeza tremendo y me temo que lo voy a dejar así. De lo que apunta Delfino de un campo lookup abierto en un momento inadecuado, no creo que sea eso porque ya desactivé el campo lookup y el problema persistía. Gracias a todos por vuestras aportaciones y en especial a Al que me ha animado a "cazar" la anomalía (aunque el cazador en este caso es un novato con un rifle de perdigones que no mataría ni un pollito). Si se te ocurre alguna otra prueba, Al, dímela y encantado la hago. Un saludo. |
Perdón, al hacer vista previa de mensaje, el código delphi se veía bien, pero al enviar la respuesta definitiva me lo formatea mal.
Vuelvo a enviar el código delphi formateado:
Disculpad. |
Y ahora me olvido indicar la línea con el problema.
Es ésta: Call(isc_dsql_prepare(StatusVector, TRHandle, @FHandle, 0, PChar(FProcessedSQL.Text), Database.SQLDialect, nil), True); Ruego a los moderadores perdonen mi torpeza (aunque en mi descargo diré que es un problema del botón "Vista Previa de Mensaje") |
Aunque no estoy convencido de ello, intenta preparar la query antes de abrirla, la query tiene un metodo llamado Prepare,
por otra parte intenta remplazar el MDOQuery por un MDODataset asignando la string de la SQL de la primera a la SelectSQL de la segunda.. Has mirado si esta linea existe tb en los Fibplus? |
Cita:
Gracias Delfino por tu ayuda. He hecho un prepare como me dices y el problema sigue. En cuanto a reemplazar el mdoquery por el mdodataset no ha lugar, porque siempre he usado mdodataset; es decir, el problema lo da con el mdodataset (aunque la línea del parón esté en una unidad llamada MDOSQL.prepare, esa unidad la llama mdodatset). He mirado, pero muy por encima, y no encuentro esa línea en los fibplus. Un saludo. |
¡Hola!
Normalmente no hay ninguna ganancia de velocidad por reemplazar un componente XQuery por un XDataSet, la mayoría de las veces ambos comparten gran parte de su código / herencia. Quisiera que nos concentráramos en la sentencia que nos muestras: Cita:
(se encuentra en la unidad IBSQL.pas de Delphi 7). A partir de este punto de la investigación hay todavía mucha tela de donde cortar, Ángel: 1. Has mencionado que algunas de las tablas tienen millones de registros. Aunque creo que no mencionaste cuántos hay solamente dentro de la tabla Sensores, ante tal cantidad de datos (que es perfectamente soportable por Firebird) conviene darle una "afinación" a los índices de cuando en cuando. Para ello, suelo tener en todas mis bases de datos Firebird este procedimiento almacenado utilitario, el cual me ha resuelto problemas similares al tuyo:
2. Si lo anterior no arregla nada, coloca un punto de ruptura en la sentencia que señalas y, una vez que se detenga ahí el programa, coloca otro en el Begin del método Call y presiona F9. Si demora un buen rato en llegar a ese segundo punto de ruptura, significa que efectivamente es isc_dsql_prepare y no el método Call el que se pone lento. 3. Una vez comprobado lo anterior, puedes crear un nuevo proyecto de "prueba aislada" con lo mínimo necesario para acceder a tu base de datos haciendo la misma consulta con un componente MDODataSet. Esto te ayudará a descartar que el problema sea causado por un elemento no evidente de otro lugar del programa. 4. Si no descubres nada relevante con el punto 3, existe la opción de hacer la misma prueba aislada, pero utilizando componentes IBX (aunque hay un pequeño riesgo de incompatibilidad con Firebird 2, pero por ser una prueba bien vale la pena intentarlo). Con esta opción, podrás detener el programa en la sentencia de IBSQL.pas que señalé arriba y probar que tan rápido se ejecuta presionando la tecla F8. Si en este caso no se presenta problema alguno de velocidad, conviene usar la ventana de observaciones ("watches") del depurador, para averiguar con qué parámetros se está llamando a la función isc_dsql_prepare y comparar los valores de esos parámetros contra la misma llamada que hacen los MDO, con el fin de encontrar alguna diferencia en los mismos que pueda ayudarte a inferir la razón del problema. Los parámetros interesantes a comparar serían: el arreglo al que apunta StatusVector, FProcessedSQL.Text y Database.SQLDialect. 5. Una quinta opción sería volver a crear, llenar con los mismos registros y probar nuevamente la consulta, pero en Firebird 1.5. Esto para descartar que la versión del motor esté relacionada con el problema. Seguimos en contacto, no dejes de comentarnos lo que hagas y observes. Gracias. Al González. :) |
Cita:
|
Cita:
|
De nuevo gracias a todos, especialmente a Al que me pone "deberes" ;). Disculpad si no paso por aquí todos los días pero es que ahora andamos de exámenes finales y voy un poquito de cráneo.
Cuando haga algunas pruebas os digo algo. Un saludo. |
Mismo problema
Que tal
Yo también tengo el mismo problema que Angel, yo utilizo Delphi7, DBExpress, Firebird 1.554926. La primera consulta me tarda aproximadamente 30 segundos, después de eso se ejecutan en un tiempo normal de menos de un segundo. Mis tablas no rebasan el millón de registros, apenas lo están alcanzando: 935,113. El tamaño de la base de datos es de 400 MB Intenté con otros componentes de conexión para probar si DBExpress era la causa, pero no fue así. Ya probé la opción que da Al sobre la afinación a los índices pero no solucionó el problema. Haré algunas pruebas con Linux para poder culpar sin dudas a Windows y también haré las pruebas aisladas que comenta Al. Saludos. Bismarck |
Cita:
¿Has probado con FIBPLUS? Yo he probado y ha desaparecido el parón aunque, extrañamente, hay alguna otra lentitud en momentos muy puntuales, pero no soy capaz de detectar un hilo conductor. De todos modos, con fib ha mejorado considerablemente. Mi BD tiene 6 millones y pico de datos y ocupa más de un 1.5 GB. Estoy un poco asustado porque ahora mismo tenemos datos de 3 meses. Cuando tengamos todo un año de datos tendremos una base de 4.5 Gb aprox. En windows un fichero tan grande se fragmenta muchísimo y hay que estar desfragmentando cada semana. Si en linux esto no ocurre, puede ser un puntazo a favor. Los deberes que me puso Al, siento decir que aún no me he puesto con ello. Es final de curso y tengo muchísimo trabajo. A ver si en 15 días hago las pruebas. Un saludo. |
¡Lo he solucionado (creo)!
Compañeros:
He logrado solucionar el problema... de forma accidental, como se logran los mayores avances en la ciencia. Aún no he tenido tiempo de hacer las pruebas que el maestro Al me puso como deberes (este final de curso se está complicando demasiado; por poner un ejemplo, casi pierdo mi puesto de trabajo y aún no está todo solucionado) pero trasteando con otras cosas creo haber hallado la solución. La solución pasa por hacer un gbak y luego restaurar la base de datos con un tamaño de página muy grande; yo le he puesto el mayor: 16384. Con esto he logrado hacer desaparecer la lentitud en la consulta a la tabla de sensores. Y no sólo eso: una consulta muy complicada que sobre una base FDB con tamaño de página de 1024 tarda más de 7 minutos, he logrado reducirla a menos de dos minutos con la base FDB con tamaño de página de 16384. Una advertencia: quizá esta solución no sirva para cualquier base fdb. Mi base es enorme: ahora mismo tiene unos 7 millones de registros y ocupa en disco 1,2 GB. Estoy hablando de una base fdb sobre Win XP SP2, usando firebird 2.0 y Delphi 7. Espero haber ayudado a otra gente con el mismo problema. Un saludo para todos y muchísimas gracias a todos los que me habéis ayudado. |
Podemos entender q el problema no tenia q ver con componentes?
y eso de q con FibPlus se soluciono y con los otros no? a Ver si das mas detalles ;) |
Cita:
Hay que recordar que el problema ocurría sólo la primera vez que se accedía a la tabla. Las veces sucesivas todo iba como la seda. Lo que sí puedo decir al 90% (no al 100% porque no he hecho muchas pruebas) es que aumentando el tamaño de paginación de la BD el acceso mejora y mucho. Ya no tengo esa demora de 30 segundos en el primer acceso a la tabla. Ahora es de menos de 1 segundo. He hecho varias pruebas y va bien. Pero muchísimo mejor. Todas las consultas tardan menos de la mitad de tiempo. Tengo que añadir una cosa que enturbia un poco esto que digo: también le he aumentado la ram a mi ordenador. De 1 GB he pasado a tener 2,5 GB. Sin embargo, con 2,5 GB he hecho pruebas con la base de datos con tamaño de página de 1024 y vuelve a ser lento todo. Con lo cual concluyo que sin duda el aumento de ram ayuda y mucho, pero el problema se ha "resuelto" con el aumento del tamaño de página. (Pongo "resuelto" entre comillas porque parece que no me lo termino de creer). Os iré diciendo si hago más pruebas y logro sacar más conclusiones. Un saludo. |
¡Hola Ángel!
Cuando tengas oportunidad, prueba el procedimiento almacenado de "afinación de índices" que te recomendé, bajo las mismas condiciones en que se encontraba tu base de datos.
Sospecho que eso hubiese ayudado en buena medida. Saludos desde Zacatecas (camino a Chihuahua ;)). Al. |
Al, lamento decir que no funciona el código que tan amablemente me propones. Lo ejecuto antes de lanzar la consulta y nada, tarda 30 segundos.
Sin embargo, puedo aportar algún dato más a este laberinto. Cuando he tratado de hacer un restore (de un archivo fbk) con tamaño de página 1024, para que la bd resultante fuera "lenta", me he encontrado con que no era "lenta". Iba bien. He tenido que recuperar una copia de la bd original "lenta" para realizar la comprobación que me dice Al. Haciendo un pequeño esquema, esto es lo que obtengo: Código a emplear BD_tamaño de página_lenta/OK (Ej: BD1_1024_lenta) Esquema: BD1_1024_lenta -- backup --> FBK1 -- restore (con opción -p 16834) --> BD2_8024_OK. Si ahora hago FBK1 -- restore (con opción -p 1024) --> BD3_1024_OK (??? No entiendo que vaya OK) No sé si el esquema ayuda a entender o lo complica aún más. El caso es que restaurando el fichero FBK, sin importar el tamaño de página, la base de datos resultante funciona bien. ¿Al final va a resultar que un simple backup-restore soluciona el problema? Quizá sí. Sin embargo, me reafirmo en lo dicho de que a mayor tamaño de página, mejor rendimiento. Espero vuestros comentarios. Un saludo. (Muchas gracias Al, guardo tu código como oro en paño). |
Cita:
En tu caso, si se soluciona haciendo un backup/restore, entonces puede ser que tuvieras algún problemilla en la base de datos o los índices muy "desbalanceados". Seguramente será esto último. |
Cita:
Se recomienda el tamaño de 4k, q es el mismo q usa el sistema operativo, pero si hay campos blob voluminosos se recomienda el del 8k.. al final va a ser q el tamaño importa en tu caso, como en muchos otros casos de la vida :D |
| La franja horaria es GMT +2. Ahora son las 12:16:04. |
Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2026, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi