¿como evitar los hot blocks?

04/05/2008 - 18:38 por AntonioFox | Informe spam
¿Que tal?

Estaba traspasando una clasica tabla de contadores (donde llevo contador
de facturas, documentos de venta, pedidos ...) a SQL Server y leo que
esta practica no es recomendada por el problema de los hot blocks

Entonses ¿que me recomienda para no tener el problema de los hot blocks
y como hago para tambien tener mis contadores? No me valen identities ya
que nesecito que me genere numeros realez

Gracias

AntonioFox

Preguntas similare

Leer las respuestas

#36 Gux (MVP)
05/05/2008 - 22:34 | Informe spam
Disculpas, apreté el botón equivocado, continúo el mensaje:

No es que quiera alimentar a troll alguno, sea lo que sea un troll :-) (va
definición en otro mensaje OT).

Realmente no pude entender la propuesta del mensaje de Alfredo, entonces
planteo un ejemplo de lo que yo he venido entendiendo de la discusión para
ver si sobre ese ejemplo se pueden clarificar las distintas posturas sobre el
tema.

Gustavo Larriera, Microsoft MVP
https://mvp.support.microsoft.com/p...o.larriera
Este mensaje se proporciona tal como es, sin garantías de ninguna clase.



"Gux (MVP)" wrote:

No es que quiera alimentar a troll alguno
Gustavo Larriera, Microsoft MVP
https://mvp.support.microsoft.com/p...o.larriera
Este mensaje se proporciona tal como es, sin garantías de ninguna clase.



"Maxi" wrote:

> Don't feed the troll ;-)
>
>
> -
> Microsoft M.V.P en SQLServer
> SQLTotal Consulting - Servicios en SQLServer
> Email:
> "Gux (MVP)" escribió en el mensaje
> news:
> >
> > "Alfredo Novoa" wrote:
> >
> >> On Mon, 5 May 2008 08:44:00 -0700, Gux (MVP)
> >> wrote:
> >>
> >> >En lo que respecta a usar tablas numeradoras, me parece una buena opción
> >> >para ciertos escenarios donde el usuario quiere por ejemplo, renumerar
> >> >un
> >> >cierto valor ("quiero que ahora las facturas se numeren a partir de X,
> >> >lo
> >> >quiero lo quiero lo quiero ya" :-)).
> >>
> >> Pues haces un update y listo. No necesitas las tablas numeradoras para
> >> eso.
> >>
> >
> > Por ejemplo, supongamos que la aplicación tiene una tabla Factura que
> > tiene
> > una columna Numero (el número único de cada factura). Imaginemos estos
> > datos:
> >
> > FACTURA (Numero, ... otros datos de factura ...)
> > 1 datos2
> > 2 datos4
> > 3 datos6
> >
> > Asumo ahora que la aplicación que inserta una nueva factura,
> > automáticamente
> > obtiene normalmente el Numero a insertra mediante un MAX(Numero) + 1.
> > Asumo
> > que se hacen los aislamientos necesarios para que dicho número no
> > colisione
> > con otra transacción intentando insertar una factura.
> >
> > El usuario hoy quiere que las facturas empiecen a partir de 100, sin
> > alterar
> > las facturas viejas. No vale hacer un UPDATE a la Factura 3 ni insertar
> > una
> > factura ficticia 100.
> >
> > No me doy cuenta cómo hacerlo con un UPDATE, cómo dice usted que podría
> > hacerse?
> >
> > Gracias, saludos
> > ~gux
> >
> >
> >
>
>
>
Respuesta Responder a este mensaje
#37 Alfredo Novoa
05/05/2008 - 22:34 | Informe spam
Hola Gux,

El Mon, 5 May 2008 11:07:02 -0700, Gux (MVP) escribió:

El usuario hoy quiere que las facturas empiecen a partir de 100, sin alterar
las facturas viejas. No vale hacer un UPDATE a la Factura 3 ni insertar una
factura ficticia 100.

No me doy cuenta cómo hacerlo con un UPDATE, cómo dice usted que podría
hacerse?



Hombre, si te puedes inventar todas las reglas que quieras solo para
fastidiarme entonces así cualquiera :-P :-)


Saludos
Alfredo
Respuesta Responder a este mensaje
#38 Gux (MVP)
05/05/2008 - 22:40 | Informe spam
SERIALIZABLE no es suficiente.

El script que ofreció Alejandro, con isolation SERIALIZABLE provoca
deadlocks. La alternativa que pude hacer funcionar es la que muestro en otro
post, donde aplico un hint TABLOCK cuando calculo el MAX.

Gustavo Larriera, Microsoft MVP
https://mvp.support.microsoft.com/p...o.larriera
Este mensaje se proporciona tal como es, sin garantías de ninguna clase.



"Carlos M. Calvelo" wrote:

Hola Alejandro,

On 5 mei, 18:49, Alejandro Mesa
wrote:
> Gux,
>
> Te lo dejo de prueba, veras lo que pasa cuando usas SERIALIZABLE .
>

READ COMMITTED no es suficiente. (Resultado no es correcto)
SERIALIZABLE es necesario. (Resultado es correcto)

Saludos,
Carlos

Respuesta Responder a este mensaje
#39 Gux (MVP)
05/05/2008 - 22:45 | Informe spam
Yo no tengo nada que ver: La culpa es del usuario, como siempre. Tienen una
inventiva muy especial :-)

Gustavo Larriera, Microsoft MVP
https://mvp.support.microsoft.com/p...o.larriera
Este mensaje se proporciona tal como es, sin garantías de ninguna clase.



"Alfredo Novoa" wrote:


Hola Gux,

El Mon, 5 May 2008 11:07:02 -0700, Gux (MVP) escribió:

> El usuario hoy quiere que las facturas empiecen a partir de 100, sin alterar
> las facturas viejas. No vale hacer un UPDATE a la Factura 3 ni insertar una
> factura ficticia 100.
>
> No me doy cuenta cómo hacerlo con un UPDATE, cómo dice usted que podría
> hacerse?

Hombre, si te puedes inventar todas las reglas que quieras solo para
fastidiarme entonces así cualquiera :-P :-)


Saludos
Alfredo

Respuesta Responder a este mensaje
#40 Alfredo Novoa
05/05/2008 - 22:50 | Informe spam
El Mon, 5 May 2008 12:30:00 -0700, Gux (MVP) escribió:

De la siguiente manera ejecutó correctamente sin violaciones de PK ni
deadlocks:

SET TRANSACTION ISOLATION LEVEL SERIALIZABLE

INSERT INTO dbo.t1 (contador, [id])
VALUES ('contador 1', (SELECT MAX(id) + 1
FROM dbo.t1 WITH (TABLOCK)
WHERE contador = 'contador 1'))



Gracias Gux, no conocía este truquillo. ¿No funcionaría poniendo WITH
ROWLOCK?

De todas formas parece que aun no tienen muy logrado lo de la concurrencia.

Una duda: ¿No debería de llegar con poner REPEATABLEREAD?


Saludos
Alfredo
Respuesta Responder a este mensaje
Ads by Google
Help Hacer una preguntaSiguiente AnteriorRespuesta Tengo una respuesta
Search Busqueda sugerida